@photodude tests are welcomed

sound's something like #5460

@alex7r i have just added some simple cs changes see: 933f075

btw is there a reason echo vs. $this->out() (for the exeption messages)

on "echo vs ->out" the thing there is not echo but print_r in case of arrays.
"echo" there is because of my shortcut template

ok ?

@alikon I believe it's something similar but without "extra" things in which I see no use cases:
like getTemplate() is called with exceptions I believe and in this case:
The tool is for automated extensions installation at 1st place.
And it's not for working with Joomla from CLI for 100%.

Really I believe nobody even try to work with joomla from CLI.
Why I think so? Because I was looking 2 days for some instructions on "how to install Joomla" with CLI and every where I found at least something it was:

Instruction how to install Joomla with CLI:

type wget
unzip
open your browser and do everything else with browser

Now you can find one (even at Joomla docs at stackoverflow) as I've wrote one.
So I doubt regular users would use CLI.
It's more for custom developers and automated testing. And you can't stop the progress because of some extensions that depends on Route in installation script (whatever they do it for).

Really I believe nobody even try to work with joomla from CLI.

There is more sad truth to this than I care to admit to. Unless it deals with Joomla's HTML interface, good luck getting support for it. Even core's RSS/JSON output is poorly supported (if it works at all, thanks to bad plugins).

@mbabker RSS time-to-time, json - you should sweat to make it to.

I have tested this item ? unsuccessfully on 933f075


Tested as follows from the command line

php cli/installextension.php -u https://www.akeebabackup.com//download/akeeba-backup/5-3-1/pkg_akeeba-5-3-1-core-zip.zip

Trying to install from: \htdocs\
PHP Notice:  Trying to get property of non-object in \libraries\joomla\session\handler\joomla.php on line 69

Notice: Trying to get property of non-object in \libraries\joomla\session\handler\joomla.php on line 69
PHP Fatal error:  Call to a member function get() on null in \libraries\joomla\session\handler\joomla.php on line 71

Fatal error: Call to a member function get() on null in \libraries\joomla\session\handler\joomla.php on line 71

Let me check

@photodude can you try once again and provide more info if you can, as I encountered another error. (branch is updated)
And after fixing

MESSAGE: Installation of the package was successful.

So can not imagine how you got yours. (Sessions are not called)

Update is also successful.

retested with your recent changes and
3.7.0-beta3
php 5.6.26

retested with with your recent changes on nightly build
3.7.0-dev-RC1
php 5.6.26

in both cases I still get the errors listed above

@photodude seems like I'm testing with 3.6 will update to latest RC
Also added automated tests.
Can be deleted afterwards

Really I believe nobody even try to work with joomla from CLI.

@alex7r i don't believe this , (cause i'm one of the few friends of "nobody")
rather, i'm more incline to believe that:

It seems that many of us are reinventing the same small but very convenient wheel.

as @nikosdion said in 2014

@alikon But why nobody posts anything about it? Why so many errors on each step than?

About errors
@photodude as travis fails it seems like the issue is 3.7 release ))) I'm updating joomla

Well we need @mbabker here on https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/plugin/helper.php#L293 that triggers the issue.

It definitely has something to do with /libraries/joomla/session/session.php
as 3.6.4 version works fine
it all ruined with line like

if (!$this->isActive())
{
	$this->start();
}

Exact lines are https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/session/session.php#L484-L487

You are stumbling at already solved problems because you guys are trying to reinvent the wheel. I have already written about it and I've written the code for it.

My code, unsurprisingly, works with all of my extensions. None of my extensions is "demanding" as I saw very wrongly stated above. I use the MINIMUM subset of the Joomla! API that a human can possibly use during installation. However, most extensions just assume that they are installed in a browser, with a user logged in interactively. Take, for example, Kunena. It assumes that the post-installation message will appear in the backend of a logged in Super User, in a browser, and do funky stuff with AJAX. This won't install through CLI. I do understand what they're doing and why but unless Joomla! forces an acceptable maximum subset of features which can be used during extension installation / update your CLI extension installation will always fail. I know because I've been there, done that, two and a half years before you.

So, the point is, do you want to ship a CLI script which works with a small number of 3PD extensions or do you simply not ship it until you start enforcing what developers can and cannot do during installation / update?

@nikosdion everyone can solve anything he wants as much as he wants in his notepad, or even on GitHub, but as far as code not making it to release the problem is NOT solved.
Kunena, EasySocial are using ajax, but this is the choice of those extentions. If you do so you can't be installed via CLI, what's the problem? If I do not use Joomla updater I do not, period. No one gonna cut out Joomla update system because of that. We are not changing. We are adding. And developers either stay with use, or mark their extension "not installable via CLI" if they want to do stuff that can not be done with CLI at all.

I am not against adding this but I think we have it already here: https://github.com/joomla-projects/cli-update/blob/develop/src/cli/update.php

It is called update but it can also do the install stuff. We made this at WHD Hackathon 2016

thanks, I'll check the file and post my findings

@rdeutz So it's not shipped with installation? Can this be added to core? because as it is now - you must find repo first - which is already a challenge, and then find suiting branch... Not quite easy as if it would be in a core.
Also I believe working, but still strange thing to see you using full (JApplicationSite) application.

Can't say what the reason was to use JApplicationSite. As you can see joomla-projects/cli-update#1 also these days we had a discussion about the script. So I let it there because tired of fighting.

everyone can solve anything he wants as much as he wants in his notepad, or even on GitHub, but as far as code not making it to release the problem is NOT solved.

@alex7r What the hell are you smoking?! I have deployed my code before you even dreamed of writing your own CLI extensions installer script. Look at the GitHub commit history and the date of that blog post. What exactly is deployment for you? Putting it in Joomla?

No, man, that's not deployment. Unless, of course, you imply that Kunena doesn't solve the problem of having a forum on your Joomla! site and Akeeba Backup doesn't solve the problem of taking backups just because they are not part of Joomla!. Including code in Joomla IS A PRIVILEGE, not the qualifier for deployment.

Kunena, EasySocial are using ajax, but this is the choice of those extentions. If you do so you can't be installed via CLI, what's the problem?

No, it's NOT as simple as that. These extensions are trying to solve a problem inherent with Joomla!'s extensions installer, i.e. it will timeout and barf installing big extensions on crap hosting which uses the FTP layer. When you get off your high horse you'll see this is the majority of Joomla! hosting, services bought by people who don't know better and just want a site, fast, cheap.

It is the duty of the CMS and us developers to deal with these issues. The decent thing to do is fix the installer and create a working relationship with top extension developers. Forcing a CLI installer script out there and putting pressure on the extension developers to work around the two incompatible and mutually exclusive installation paths is NOT decent. If anything, it reinforces the "us vs them" dynamic between the PLT and extension developers.

In case you are about to write more crap about me, I have written a white paper on refactoring the Joomla! extensions installer to solve those issues in 2012. I also tried to include that in the Joomla! 4 specifications in 2015. I've done much more work trying to fix this bloody mess of a CMS than you will ever know. It's not my fault that politics get into the way every single time. The project manager and team for Joomla! 4 (now Joomla! X) was forced upon me unilaterally by the PLT. It was so bad that they ended up trying to reinvent Symfony and Laravel at which point I said "the hell with you idiots" and left.

If I do not use Joomla updater I do not, period. No one gonna cut out Joomla update system because of that. We are not changing. We are adding. And developers either stay with use, or mark their extension "not installable via CLI" if they want to do stuff that can not be done with CLI at all.

This is an outright idiotic way to behave. Developers will tell you "screw you and your code, you ignorant son of a dog" and they will be right. Joomla! NEEDS developer buy in for developer-oriented features. For YEARS the extensions installer did NOT support paid extensions. I had to use my own updater. You can't go ahead and tell me that I am to blame for this!!! What was I supposed to do, give up my business because some moron in the PLT didn't want to merge a feature I had written to support paid extensions for 9 or so months? Do you think Joomla would be better if developers gave up on it because it's outright hostile towards them? You have to be a complete moron to think like this.

Learn how to treat developers with respect instead of going all "MY CODE IS BETTER THAN EVERYONE ELSE'S AND IF YOU DON'T LIKE IT SOD OFF". This is the exact mentality that brought Joomla! to its knees.

As far as the code goes, I am telling you again to stop being an ignorant moron and read the comments on my blog and my code. I HAVE ALREADY SOLVED THESE ISSUES, STUPID! Hello!!! I am giving you free code without even asking for recognition. Use your brain (if you have one).

Why do I bother with you lot... You don't know how to deal with mass distributed code, yet here you are trying to write some. Meh.

@nikosdion Hey, calm down, and excuse me if something, point me to parts that you feel are offensive to you. (May be by email (alex7r@ya.ru), as here is not a place to do it.) But I was NOT pointing anyone and specifically you, neither your code! (Yes I do not have good feelings about FOF or F0F, but it's not matter as it's only my feelings of situation and I do not think that it's the only way.)
So once again: @nikosdion , excuse me if you felt like some of my statements are offensive (to you).
And let me break it down a bit.

Reference to "updater" was just to show that some extensions may support it or not - and updater still out there and everyone OKAY with it. (I'm TOO. JED forcing to use updater is another story, but it's also okay with me as far as there is only "show updates" is a must.)

About "notepad", what I meant was: even this PR do not solve issue (even despite code is working) as far as it's outside of the Joomla installation. You need to look for, download and add files to Joomla installation to be available to install extensions with CLI. And I can't call it "Joomla supports CLI installation", but only "there is 3rd party workaround to install Joomla extensions with CLI".
Here is joomla-projects/jacs#1 issue (and no I see reference in description that either I overlooked when saw the post initially, or they was added after) that was created in 2016 and that also proofs that people looking for this functionality in core.

"Kunena and others" text block:
I understood that they not just putting code, but trying to solve problems.
But extension developer can add switch and check (if they want to support CLI) if this is a CLI or WEB and simplify installation for CLI. (bad hostings do not provide CLI access, and CLI access have more running time)
Generally my thoughts here and at "updater" is Joomla should not stop progress if some extensions do not use new functionality. It should think to stop if new functionality is blocking old functionality, but this is not the case here.

Once again I did not mean any offense here.
The only thing that I'm strongly against is "Joomla code style with exactly 2 spaces in doc block, when main CS rules just use 1".

p.s. Overall I'm feel offense from "Joomla society" (do not know how to name this situation right) too, but I'm not calling ANYone an "idiot" or any. Also I acknowledge that I might express my thoughts in the way someone can feel offensive even when I did not mean this, we had situation with @mbabker in another PR, but he just reacted to it in a calm manner an explained that he think that I said a wrong thing. And I admit it, and we solved (I believe so) the situation.
Once again, NO OFFENSE.

@nikosdion Please watch your language. No matter how right you may be with the facts, this language will not be tolerated.

Sure. Whatever. Stop mentioning me on this repository, will you? It's annoying.

To sum up:
Is there many developers for/against this feature?
What are questions and doubts?
So we can develop/go further with this PR?

Well, any news?

Hi, is that any news about this feature?

@destinycan as far as i see in Thread no Decision is made by Maintainers or Release Lead.

if someone can start to share some test results, instead of bla bla bla.... ?
it can be some good point to re-start IMHO

I do not know if we should fight through all the resistance coming that was faced here, or just wait for J4 (something like this will make it into).

But some test results definitely would help.

thx @alex7r for investing your time into this PR.
J3 is on feature freeze so this PR can't go into J3 but we have a gsoc project for J4 #21452
It would be great if you can help to finalize it so it can be merged into J4.

thx for trying to make Joomla! a better CMS. I'm closing this PR in favor for #21452