See also: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33668

@test success on mysql & postgresql
don't tested the language/multilanguage side

@test by and large successful on mysql & postgresql & mssql
I tried a lot of settings but definitely not all combinations. mysql_pdo is missing as of the time of writing it was not present. I was not able to install another language other than the default language.

@nikosdion I saw that you did something "similar" lately with your cli for installing joomla extension. Maybe you could do a review?

@totten here are a quick PR that fixes some CS issues: totten#1

I have one question before giving a +1. One some options I see that the option name is followed by a colon, e.g. 'getopt' => 'name:',. I believe this is wrong because the user would need to pass an option like --name:=Something instead of the UNIX standard --name=Something. I don't see any functional reason to keep the colons.

Other than that, I wish this feature existed three months ago. It would have saved me tons of time. I love the concept and I love that this implementation is also able to modify most configuration.php parameters without the need for an additional script.

getopt has its own little language for how to describe parameters, and the trailing ":" means "this parameter requires the user to supply a value". http://php.net/getopt illustrates this with an example:

<?php
// Script example.php
$shortopts  = "";
$shortopts .= "f:";  // Required value
$shortopts .= "v::"; // Optional value
$shortopts .= "abc"; // These options do not accept values

$longopts  = array(
    "required:",     // Required value
    "optional::",    // Optional value
    "option",        // No value
    "opt",           // No value
);
$options = getopt($shortopts, $longopts);
var_dump($options);

A ha! That's why it didn't stick with me. What you're doing is an overkill and entirely non-Joomla!. You should be using $this->input to get the option values. I mean, if a CLI script in Joomla! itself doesn't use the official (and very well-written and perfectly working) input object then what is the message we're giving to 3PDs? Don't trust Joomla core and reinvent the wheel a million times over?

FWIW... I'm fairly sure Joomla (Drupal and Symfony and everyone else) is reinventing getopt -- the margin isn't exactly close. For example, in the time between the creation of getopt (http://en.wikipedia.org/wiki/Getopt#History) and the creation of Joomla (http://en.wikipedia.org/wiki/Joomla#History), I did the following tasks: be born, learn to walk, learn to talk, learn to code, go to high school, go to college, get a job, and cook dinner. ;)

But more seriously... good point. I've added bdde646 which replaces getopt with JInputCli.

Aside: It might be nice if any of the cli examples in joomla-cms or in https://docs.joomla.org/How_to_create_a_stand-alone_application_using_the_Joomla!_Platform used any command-line arguments.

It's a wiki so please feel free to add those examples.

On 17 December 2014 at 10:01, Tim Otten notifications@github.com wrote:

FWIW... I'm fairly sure Joomla (Drupal and Symfony and everyone else) is
reinventing getopt -- the margin isn't exactly close. For example, in the
time between the creation of getopt (
http://en.wikipedia.org/wiki/Getopt#History) and the creation of Joomla (
http://en.wikipedia.org/wiki/Joomla#History), I did the following tasks:
be born, learn to walk, learn to talk, learn to code, go to high school, go
to college, get a job, and cook dinner. ;)

But more seriously... good point. I've added bdde646
bdde646
which replaces getopt with JInputCli.

Aside: It might be nice if any of the cli examples in joomla-cms or in
https://docs.joomla.org/How_to_create_a_stand-alone_application_using_the_Joomla!_Platform
used any command-line arguments.

—
Reply to this email directly or view it on GitHub
#2764 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@totten Please add "pdomysql" to line 125.

@waader, done

Suggest Joomla to standardize on '/' instead of DIRECTORY_SEPARATOR.
Leaving DIRECTORY_SEPARATOR only for those situations that it is required.

@sovainfo, updated (f22862f)

should go with this one #5460 too
so you can setup all from CLI

Is this taking into account a specific localise.xml?
https://github.com/joomla/joomla-cms/blob/staging/installation/localise.xml

@nikosdion
REf: #2764 (comment)

I mean that when we have a forced language —<forceLang></forceLang>—(in a distro), the same language should be set as default for site and admin as they are usually present in the distro.

@infograf768 I have not commented on this PR regarding the forced language. I am also not the person who wrote it. I think you meant to ping @totten about it? Please note that I wrote the PR regarding extensions installation from the CLI on an existing Joomla! site. This PR (gh-2764) is about the ability to install a brand new Joomla! site from the command line.

@nikosdion
Correct, sorry for disturbing. :)

This proposed improvement is a really exciting step forward for Joomla. It sounds like there a few minor things about it that could be improved (most of which totten has already addressed) but overall it works and is very useful.
Could someone please either merge this PR or explain why not?

@colemanw I have also written a similar CLi script and filed a PR. While discussing it we figured out that JInstaller and many 3PD extensions' installation scripts depend on methods which are only present in the JApplicationWeb / JApplicationAdministrator but not in JApplicationCli which is the only application class which will work properly under CLI. Until JInstaller is fully decoupled from JApplicationAdministrator we can't have a CLI extensions installer script because it won't work with many (most?) third party extensions.

@colemanw It's not obvious from what I said: installing Joomla! also bumps on the similar obstacles as my extensions installation PR, that's why BOTH PRs are currently not merged.

@nikosdion thanks for the explanation.

On one hand, I agree with @nikosdion that this stumbled slightly on the issue of JApplication(Web vs Cli) -- which basically led to the small kludges/workarounds highlighted in the original description. OTOH, I think it's less problematic for the core-installer than for the extension-installer. (The core installer is a smaller, more closed use-case with everything defined in the core repo.) From my perspective, the main obstacle was more managerial -- not knowing which of the two kludges needed to be addressed to make it mergable (or even if the feature generally was considered acceptable).

Regardless, @stevenrombauts appears to be making progress on this use-case as part of joomla-console (https://github.com/joomlatools/joomla-console/blob/develop/src/Joomlatools/Console/Command/Site/Install.php , joomlatools/joomla-console#5), so I'm closing the PR on joomla-cms.

good thing I have found this ticket. I've already started working on my own similar code, but it's best to join all of our efforts on the same project