User tests: Successful: Unsuccessful:
A wrong path for the main configuration file prevents the database from open a connection under CLI scripts.
Create and run a typical CLI script from scratch as described in the documentation
Example 1: Hello World Command Line Interface (CLI) App
In JFilterInput::__construct() an attempt to connect to the database with $db->connect();
fails because the configuration files has not been read yet
(it will be read afterwards, but it is too late and the invalid database connection is cached and served to subsequent calls)
No matter whether you have a valid configuration.php or not, this always raises an exception and makes
absolutely unreachable the recent code added to handle UTF8mb4
// And now we can decide if we should strip USCs
$this->stripUSC = $db->hasUTF8mb4Support() ? 0 : 1;
the instruction within the catch block will be always executed instead
// Could not connect to MySQL. Strip USC to be on the safe side.
$this->stripUSC = 1;
Since the exception is caught and the program flux continues, I think that the only way to inspect this behaviour is using a breakpoint to follow the execution.
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
Category | ⇒ | CLI |
Thanks @wilsonge I confirm that including the configuration file makes the things work. This is the workaround I used in my own scripts. Nevertheless I thought to propose a PR.
Since the Database Object relies in the configuration, I think that it should be able to load the config file by itself, if needed.
My two cents...
JFactory::createConfig()
has had this default since it was introduced, which has always gone against the CMS' default config path. Technically it's probably the stupidest B/C break that could be introduced but it is one, and dammit it needs to be made because the fact that JFactory can't by default load the application's configuration is probably one of the dumbest things the API does right now.
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-08 07:50:44 |
Closed_By | ⇒ | wilsonge |
Just a question about Github behaviour: since this PR has been already merged, can I safely delete this branch from my own repository?
yes
Hey. I'm pretty sure that to get things to work all you need to do is require the configuration file like in this script https://github.com/joomla/joomla-cms/blob/staging/cli/finder_indexer.php#L51
Note that I agree with your change and support us merging it - as this has been an issue for a long long time...