User tests: Successful: Unsuccessful:
Added Commands for:
All testing instruction can be found in the documentation here
JDocs for this PR is here, It explains everything on how to use the commands
Project Repository is here
Status | New | ⇒ | Pending |
Category | ⇒ | CLI Libraries Unit Tests |
Title |
|
Labels |
Added:
?
?
|
Category | CLI Libraries Unit Tests | ⇒ | CLI Installation Libraries Unit Tests |
Title |
|
Category | CLI Libraries Unit Tests Installation | ⇒ | Administration com_media CLI Installation Libraries Front End Templates (site) Unit Tests |
Category | CLI Libraries Unit Tests Installation Administration com_media Front End Templates (site) | ⇒ | Administration com_media CLI Installation Libraries Front End Templates (site) |
Labels |
Removed:
?
|
Please create or reuse a result constants
.
Maybe it would be better to define the constants (at least the generic one) in AbstractCommand.
for example:
class AbstractCommand {
/**
* Command executed successful
*/
const RESULT_SUCCESS = 0:
/**
* Generic command error
*/
const RESULT_ERROR = 1;
}
And define the command specific error to the command class starting with 2. Any opinions?
It's a good idea!
So, I attempted to implement the result constants inside AbstractCommand
, I figured out that it's part of the Joomla framework, i.e a package installed inside libraries/vendors/joomla/console/AbstractCommand.php
.
It's not on this repository.
You shoudn't have a package-lock.json in your PR
Category | CLI Libraries Installation Administration com_media Front End Templates (site) | ⇒ | CLI Installation Libraries Front End Templates (site) |
Category | CLI Libraries Installation Front End Templates (site) | ⇒ | CLI Installation Libraries |
or maybe PBF can help us on having more tests and/or feedback
I am not very experienced (I use the cli the first time), so I write in detail what I have tested.
I made a new installation and run php cli/joomla.php
in the Joomla Root. I saw this error.
php cli/joomla.php
PHP Notice: Undefined index: REQUEST_URI in /var/www/html/joomla-cms/includes/framework.php on line 21
PHP Stack trace:
PHP 1. {main}() /var/www/html/joomla-cms/cli/joomla.php:0
PHP 2. require_once() /var/www/html/joomla-cms/cli/joomla.php:35
PHP Notice: Undefined index: REQUEST_URI in /var/www/html/joomla-cms/includes/framework.php on line 21
PHP Stack trace:
PHP 1. {main}() /var/www/html/joomla-cms/cli/joomla.php:0
PHP 2. require_once() /var/www/html/joomla-cms/cli/joomla.php:35
Then I applied this path via git fetch origin pull/21452/head:m1_copy
and git checkout m1_copy
. After that this command looks fine.
php cli/joomla.php
Joomla! 4.0.0-alpha5-dev
Usage:
command [options] [arguments]
Options:
-h, --help Display the help information
-q, --quiet Flag indicating that all output should be silenced
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Flag to disable interacting with the user
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
Available commands:
check-updates Checks for Joomla updates
help Show the help for a command
list List the application's available commands
cache
cache:clean Cleans expired cache entries
config
config:get Displays the current value of a configuration option
config:set Sets a value for a configuration option
core
core:install Sets up the Joomla! CMS.
core:update Updates joomla core
extension
extension:install Installs an extension from a URL or from a Path.
extension:list List installed extensions
extension:remove Removes an extension
session
session:gc Performs session garbage collection
session:metadata:gc Performs session metadata garbage collection
site
site:down Puts the site into offline mode
site:up Puts the site into online mode
update
update:extensions:check Checks for pending extension updates
update:joomla:remove-old-files Removes old system files
After that I tested the different commands. but I see errors. For example:
php cli/joomla.php extension:list
PHP Fatal error: Uncaught TypeError: Argument 1 passed to Symfony\Component\Debug\ExceptionHandler::handle() must be an instance of Exception, instance of Error given in /var/www/html/joomla-cms/libraries/vendor/symfony/debug/ExceptionHandler.php:106
Stack trace:
#0 [internal function]: Symfony\Component\Debug\ExceptionHandler->handle(Object(Error))
#1 {main}
thrown in /var/www/html/joomla-cms/libraries/vendor/symfony/debug/ExceptionHandler.php on line 106
Am I doing something wrong?
I have one note. If Joomla is not already installed, you will see the following error message, which might be more accurate.
php cli/joomla.php extension:list
[Joomla\Database\Exception\ConnectionFailureException]
Could not connect to MySQL: Access denied for user 'root'@'localhost' (using password: NO)
extension:list [--type TYPE]
Category | CLI Libraries Installation | ⇒ | CLI Installation Libraries External Library Composer Change |
Labels |
Added:
?
|
@astridx I have seen the error and got if fixed now, it happened that the getClientId
method is required by Plgsystemdebug
on this Line.
That's the reason for the error. I have pushed the little change I made to this branch, when you update your local branch with this branch it should be fixed now.
@wilsonge @mbabker please review this commit - it's the fix for the error encountered above by @astridx , I want to know if it's done appropriately.
Great PR! I wish I could have it now on my servers.
These are the results of simple tests on J4 A5:
check-updates, ERROR
[Symfony\Component\Debug\Exception\FatalThrowableError]
Call to undefined method Joomla\CMS\Extension\MVCComponent::createMVCFactory()
help, ERROR
[Symfony\Component\Debug\Exception\FatalThrowableError]
Type error: Argument 1 passed to Joomla\Console\Application::getCommand() must be of the type string, null given, called in /app/www/libraries/vendor/joomla/console/src/Command/HelpCommand.php on line 32
list, OK
cache:clean, OK
config:get, OK
config:set, OK
core:install, OK
core:update, ERROR
[Symfony\Component\Debug\Exception\FatalThrowableError]
Call to undefined method Joomla\CMS\Extension\MVCComponent::createMVCFactory()
extension:install, ERROR
[Symfony\Component\Debug\Exception\FatalThrowableError]
Class 'JNamespacePsr4Map' not found
extension:list, OK
extension:remove, ERROR
[Symfony\Component\Debug\Exception\FatalThrowableError]
Class 'JNamespacePsr4Map' not found
session:gc, ERROR
[ERROR] Garbage collection was not completed. Either the operation ERRORed or is not supported on your platform.
Thanks @anibalsanchez and @astridx for the test, I will look into the errors and get you updated once resolved.
I think some changes in J4 A5 core seems to be affecting this PR as it depends on some components in the core, i will see that everything works perfect.
@astridx and @anibalsanchez you can test again now, issues have been fixed. Others can also test too.
@mbabker @wilsonge I will like to know what's left for this PR to be merged and will be glad to work on it.
I just want to test this branch.
I applied it like in this comment and I run composer update
and npm install
.
Then I php cli/joomla.php
run and I get the message
$ php cli/joomla.php PHP Warning: Declaration of Joomla\Event\DispatcherAwareTrait::setDispatcher(Joomla\Event\DispatcherInterface $dispatcher) should be compatible with Symfony\Component\Console\Application::setDispatcher(Symfony\Component\EventDispatcher\EventDispatcherInterface $dispatcher) in /var/www/html/joomla-cms4/libraries/src/Application/ConsoleApplication.php on line 37 PHP Stack trace: PHP 1. {main}() /var/www/html/joomla-cms4/cli/joomla.php:0 PHP 2. Joomla\DI\Container->get() /var/www/html/joomla-cms4/cli/joomla.php:79 PHP 3. Joomla\DI\Resource->getInstance() /var/www/html/joomla-cms4/libraries/vendor/joomla/di/src/Container.php:96 PHP 4. Joomla\CMS\Service\Provider\Application->Joomla\CMS\Service\Provider\{closure}() /var/www/html/joomla-cms4/libraries/vendor/joomla/di/src/Resource.php:175 PHP 5. spl_autoload_call() /var/www/html/joomla-cms4/libraries/src/Service/Provider/Application.php:96 PHP 6. JClassLoader->loadClass() /var/www/html/joomla-cms4/libraries/src/Service/Provider/Application.php:96 PHP 7. Composer\Autoload\ClassLoader->loadClass() /var/www/html/joomla-cms4/libraries/cms/class/loader.php:55 PHP 8. Composer\Autoload\includeFile() /var/www/html/joomla-cms4/libraries/vendor/composer/ClassLoader.php:322 PHP 9. include() /var/www/html/joomla-cms4/libraries/vendor/composer/ClassLoader.php:444 PHP Fatal error: Class Joomla\CMS\Application\ConsoleApplication contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Joomla\CMS\Application\ConsoleApplication::getLogger) in /var/www/html/joomla-cms4/libraries/src/Application/ConsoleApplication.php on line 37 PHP Stack trace: PHP 1. {main}() /var/www/html/joomla-cms4/cli/joomla.php:0 PHP 2. Joomla\DI\Container->get() /var/www/html/joomla-cms4/cli/joomla.php:79 PHP 3. Joomla\DI\Resource->getInstance() /var/www/html/joomla-cms4/libraries/vendor/joomla/di/src/Container.php:96 PHP 4. Joomla\CMS\Service\Provider\Application->Joomla\CMS\Service\Provider\{closure}() /var/www/html/joomla-cms4/libraries/vendor/joomla/di/src/Resource.php:175 PHP 5. spl_autoload_call() /var/www/html/joomla-cms4/libraries/src/Service/Provider/Application.php:96 PHP 6. JClassLoader->loadClass() /var/www/html/joomla-cms4/libraries/src/Service/Provider/Application.php:96 PHP 7. Composer\Autoload\ClassLoader->loadClass() /var/www/html/joomla-cms4/libraries/cms/class/loader.php:55 PHP 8. Composer\Autoload\includeFile() /var/www/html/joomla-cms4/libraries/vendor/composer/ClassLoader.php:322 PHP 9. include() /var/www/html/joomla-cms4/libraries/vendor/composer/ClassLoader.php:444
Did I do something wrong
Use composer install
, not composer update
.
OK. I now used composer install but it does not change my result.
If you ran composer install
after composer update
that would be expected because composer update
updates the composer.lock
file whereas composer install
installs dependencies based on what is in the lock file.
Long and short, NEVER run composer update
or npm update
unless you are truly aiming to update your dependencies. ALWAYS run the install
commands to grab the dependencies in the state set by the lock file.
Tried what @mbabker said, it's very true @astridx , composer update
breaks the code.
You need to revert the changes made to composer.lock
before composer install
will work again.
You can then delete the libraries/vendor
folder and run composer install
again, the error will go that way.
Thanks @mbabker .
Thank you for helping me with composer. I forgot, that only composer install
ensures the same dependencies are used in my test as in development of this PR.
php cli/joomla.php
command worked as expected.
site:down
and site:up worked fine.
cache:clean
worked without failure although I had an issue: #23250
php cli/joomla.php cache:clean
Cleaning System Cache
=====================
[OK] Cache cleaned
Here I was confused about the text value not set
I expected false
or 0
.
php cli/joomla.php config:set debug=true
[OK] Configuration set
$ php cli/joomla.php config:get debug
-------- -------
Option Value
-------- -------
debug 1
-------- -------
$ php cli/joomla.php config:set debug=false
[OK] Configuration set
$ php cli/joomla.php config:get debug
-------- ---------
Option Value
-------- ---------
debug Not set
-------- ---------
extension:list
and extension:install
worked fine.
But: when I searched for an update, I get no message, that an update is found. I only see a message, that the command was executed correct. In the backend I could see that update. And the remove did not work correct. The extension was installed, although I saw a message, that let me think, that everything is uninstalled correctly.
$ php cli/joomla.php extension:list
Installed extensions.
=====================
-------------------------------- -------------- ------------------ ----------- --------
Name Extension ID Version Type Active
-------------------------------- -------------- ------------------ ----------- --------
com_mailto 1 4.0.0 component Yes
com_wrapper 2 4.0.0 component Yes
com_admin 3 4.0.0 component Yes
com_banners 4 4.0.0 component Yes
com_cache 5 4.0.0 component Yes
com_categories 6 4.0.0 component Yes
com_checkin 7 4.0.0 component Yes
com_contact 8 4.0.0 component Yes
com_cpanel 9 4.0.0 component Yes
com_installer 10 4.0.0 component Yes
com_languages 11 4.0.0 component Yes
com_login 12 4.0.0 component Yes
com_media 13 3.0.0 component Yes
com_menus 14 4.0.0 component Yes
com_messages 15 4.0.0 component Yes
com_modules 16 4.0.0 component Yes
com_newsfeeds 17 4.0.0 component Yes
com_plugins 18 4.0.0 component Yes
com_search 19 4.0.0 component Yes
com_templates 20 4.0.0 component Yes
com_content 22 4.0.0 component Yes
com_config 23 4.0.0 component Yes
com_redirect 24 4.0.0 component Yes
com_users 25 4.0.0 component Yes
com_finder 27 4.0.0 component Yes
com_joomlaupdate 28 4.0.0 component Yes
com_tags 29 4.0.0 component Yes
com_contenthistory 30 4.0.0 component Yes
com_ajax 31 4.0.0 component Yes
com_postinstall 32 4.0.0 component Yes
com_fields 33 4.0.0 component Yes
com_associations 34 4.0.0 component Yes
com_workflow 35 4.0.0 component Yes
com_csp 36 4.0.0 component Yes
lib_joomla 103 13.1 library Yes
lib_phpass 106 0.3 library Yes
mod_articles_archive 200 3.0.0 module Yes
mod_articles_latest 201 3.0.0 module Yes
mod_articles_popular 202 3.0.0 module Yes
mod_banners 203 3.0.0 module Yes
mod_breadcrumbs 204 3.0.0 module Yes
mod_custom 205 3.0.0 module Yes
mod_feed 206 3.0.0 module Yes
mod_footer 207 3.0.0 module Yes
mod_login 208 3.0.0 module Yes
mod_menu 209 3.0.0 module Yes
mod_articles_news 210 3.0.0 module Yes
mod_random_image 211 3.0.0 module Yes
mod_related_items 212 3.0.0 module Yes
mod_search 213 3.0.0 module Yes
mod_stats 214 3.0.0 module Yes
mod_syndicate 215 3.0.0 module Yes
mod_users_latest 216 3.0.0 module Yes
mod_whosonline 218 3.0.0 module Yes
mod_wrapper 219 3.0.0 module Yes
mod_articles_category 220 3.0.0 module Yes
mod_articles_categories 221 3.0.0 module Yes
mod_languages 222 3.5.0 module Yes
mod_finder 223 3.0.0 module Yes
mod_custom 300 3.0.0 module Yes
mod_feed 301 3.0.0 module Yes
mod_latest 302 3.0.0 module Yes
mod_logged 303 3.0.0 module Yes
mod_login 304 3.0.0 module Yes
mod_menu 305 3.0.0 module Yes
mod_popular 307 3.0.0 module Yes
mod_quickicon 308 3.0.0 module Yes
mod_status 309 3.0.0 module Yes
mod_title 311 3.0.0 module Yes
mod_toolbar 312 3.0.0 module Yes
mod_multilangstatus 313 3.0.0 module Yes
mod_version 314 3.0.0 module Yes
mod_stats_admin 315 3.0.0 module Yes
mod_tags_popular 316 3.1.0 module Yes
mod_tags_similar 317 3.1.0 module Yes
mod_sampledata 318 3.8.0 module Yes
plg_authentication_joomla 401 3.0.0 plugin Yes
plg_authentication_ldap 402 3.0.0 plugin No
plg_content_contact 403 3.2.2 plugin Yes
plg_content_emailcloak 404 3.0.0 plugin Yes
plg_content_loadmodule 406 3.0.0 plugin Yes
plg_content_pagebreak 407 3.0.0 plugin Yes
plg_content_pagenavigation 408 3.0.0 plugin Yes
plg_content_vote 409 3.0.0 plugin No
plg_editors_codemirror 410 5.35.0 plugin Yes
plg_editors_none 411 3.0.0 plugin Yes
plg_editors_tinymce 412 4.8.3 plugin Yes
plg_editors-xtd_article 413 3.0.0 plugin Yes
plg_editors-xtd_image 414 3.0.0 plugin Yes
plg_editors-xtd_pagebreak 415 3.0.0 plugin Yes
plg_editors-xtd_readmore 416 3.0.0 plugin Yes
plg_search_categories 417 3.0.0 plugin Yes
plg_search_contacts 418 3.0.0 plugin Yes
plg_search_content 419 3.0.0 plugin Yes
plg_search_newsfeeds 420 3.0.0 plugin Yes
plg_system_languagefilter 422 3.0.0 plugin No
plg_system_cache 424 3.0.0 plugin No
plg_system_debug 425 3.0.0 plugin Yes
plg_system_log 426 3.0.0 plugin Yes
plg_system_redirect 427 3.0.0 plugin No
plg_system_remember 428 3.0.0 plugin Yes
plg_system_sef 429 3.0.0 plugin Yes
plg_system_logout 430 3.0.0 plugin Yes
plg_user_contactcreator 431 3.0.0 plugin No
plg_user_joomla 432 3.0.0 plugin Yes
plg_user_profile 433 3.0.0 plugin No
plg_extension_joomla 434 3.0.0 plugin Yes
plg_content_joomla 435 3.0.0 plugin Yes
plg_system_languagecode 436 3.0.0 plugin No
plg_quickicon_joomlaupdate 437 3.0.0 plugin Yes
plg_quickicon_extensionupdate 438 3.0.0 plugin Yes
plg_captcha_recaptcha 439 3.4.0 plugin No
plg_system_highlight 440 3.0.0 plugin Yes
plg_content_finder 441 3.0.0 plugin No
plg_finder_categories 442 3.0.0 plugin Yes
plg_finder_contacts 443 3.0.0 plugin Yes
plg_finder_content 444 3.0.0 plugin Yes
plg_finder_newsfeeds 445 3.0.0 plugin Yes
plg_finder_tags 447 3.0.0 plugin Yes
plg_twofactorauth_totp 448 3.2.0 plugin No
plg_authentication_cookie 449 3.0.0 plugin Yes
plg_twofactorauth_yubikey 450 3.2.0 plugin No
plg_search_tags 451 3.0.0 plugin Yes
plg_system_updatenotification 452 3.5.0 plugin Yes
plg_editors-xtd_module 453 3.5.0 plugin Yes
plg_system_stats 454 3.5.0 plugin Yes
plg_installer_packageinstaller 455 3.6.0 plugin Yes
plg_installer_folderinstaller 456 3.6.0 plugin Yes
plg_installer_urlinstaller 457 3.6.0 plugin Yes
plg_quickicon_phpversioncheck 458 3.7.0 plugin Yes
plg_editors-xtd_menu 459 3.7.0 plugin Yes
plg_editors-xtd_contact 460 3.7.0 plugin Yes
plg_system_fields 461 3.7.0 plugin Yes
plg_fields_calendar 462 3.7.0 plugin Yes
plg_fields_checkboxes 463 3.7.0 plugin Yes
plg_fields_color 464 3.7.0 plugin Yes
plg_fields_editor 465 3.7.0 plugin Yes
plg_fields_imagelist 466 3.7.0 plugin Yes
plg_fields_integer 467 3.7.0 plugin Yes
plg_fields_list 468 3.7.0 plugin Yes
plg_fields_media 469 3.7.0 plugin Yes
plg_fields_radio 470 3.7.0 plugin Yes
plg_fields_sql 471 3.7.0 plugin Yes
plg_fields_text 472 3.7.0 plugin Yes
plg_fields_textarea 473 3.7.0 plugin Yes
plg_fields_url 474 3.7.0 plugin Yes
plg_fields_user 475 3.7.0 plugin Yes
plg_fields_usergrouplist 476 3.7.0 plugin Yes
plg_content_fields 477 3.7.0 plugin Yes
plg_editors-xtd_fields 478 3.7.0 plugin Yes
plg_sampledata_blog 479 3.8.0 plugin Yes
plg_system_sessiongc 480 3.8.6 plugin Yes
plg_behaviour_versionable 482 4.0.0. plugin Yes
plg_filesystem_local 483 4.0.0 plugin Yes
plg_media-action_crop 484 4.0.0 plugin Yes
plg_media-action_resize 485 4.0.0 plugin Yes
plg_media-action_rotate 486 4.0.0 plugin Yes
plg_installer_webinstaller 487 1.1.1 plugin Yes
plg_system_httpheaders 488 4.0.0 plugin Yes
plg_sampledata_multilang 489 4.0.0 plugin Yes
plg_extension_namespacemap 490 4.0.0 plugin Yes
plg_installer_override 491 4.0.0 plugin Yes
plg_quickicon_overridecheck 492 4.0.0 plugin Yes
atum 509 1.0 template Yes
cassiopeia 510 1.0 template Yes
English (en-GB) 600 4.0.0 language Yes
English (en-GB) 601 4.0.0 language Yes
files_joomla 700 4.0.0-alpha6-dev file Yes
English (en-GB) Language Pack 802 4.0.0.1 package Yes
-------------------------------- -------------- ------------------ ----------- --------
$ php cli/joomla.php extension:install url --url=https://github.com/joomla-projects/gsoc18_override_management/files/2204984/mod_agosm-1.0.27.zip
[OK] Extension installed successfully.
$ php cli/joomla.php extension:list
Installed extensions.
=====================
-------------------------------- -------------- ------------------ ----------- --------
Name Extension ID Version Type Active
-------------------------------- -------------- ------------------ ----------- --------
com_mailto 1 4.0.0 component Yes
...
English (en-GB) Language Pack 802 4.0.0.1 package Yes
mod_agosm 10006 1.0.27 module Yes
-------------------------------- -------------- ------------------ ----------- --------
$ php cli/joomla.php update:extensions:check
Fetching Extension Updates
==========================
[OK] Finished fetching updates
$ php cli/joomla.php extension:remove mod_agosm
Are you sure you want to remove this extension? [yes/no]:
> yes
$ php cli/joomla.php extension:list
Installed extensions.
=====================
-------------------------------- -------------- ------------------ ----------- --------
Name Extension ID Version Type Active
-------------------------------- -------------- ------------------ ----------- --------
com_mailto 1 4.0.0 component Yes
...
English (en-GB) Language Pack 802 4.0.0.1 package Yes
mod_agosm 10006 1.0.27 module Yes
-------------------------------- -------------- ------------------ ----------- --------
@astridx the ID of the extension is what should be used as an argument when running extension:remove
command instead of the name.
In this case, it will be:
$ php cli/joomla.php extension:remove 10006
Instead of:
$ php cli/joomla.php extension:remove mod_agosm
I have updated the code to show error notification when it's not the ID that is passed as the argument.
Thanks for testing.
Why is .htacess
deleted and included in pr.
Why is
.htacess
deleted and included in pr.
I don't know why yet, I'm still trying to find out how it got there.
Okay, I will get on this now.
Thanks, @HLeithner and @dneukirchen
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-02-20 13:55:49 |
Closed_By | ⇒ | bosunski |
Accidentally closed this!
Status | Closed | ⇒ | New |
Closed_Date | 2019-02-20 13:55:49 | ⇒ | |
Closed_By | bosunski | ⇒ |
Status | New | ⇒ | Pending |
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-02-20 17:31:08 |
Closed_By | ⇒ | bosunski |
..
Status | Closed | ⇒ | New |
Closed_Date | 2019-02-20 17:31:08 | ⇒ | |
Closed_By | bosunski | ⇒ |
Status | New | ⇒ | Pending |
Code updated. @HLeithner @dneukirchen @alikon @mbabker
From reading the documentation there are some inconsistencies in how you use this
php cli/joomla.php extension:list --type=language
php cli/joomla.php extension:install url --url=https://.......
I would have expected both of these to be constructed in the same way so they would be like this
php cli/joomla.php extension:list --type=language
php cli/joomla.php extension:install --url=https://.......
@mbabker Thanks for the reviews!
Notice: In this, Factory::getUser()
returns null after updating this PR with merges from 4.0-dev
, and it breaks the CLI app.
However, if we change this to Factory::getApplication()->getIdentity()->getAuthorisedViewLevels()
and then Update the getIdentity
method inside IdentityAware
Trait to call loadIdentity
like this:
public function getIdentity()
{
$this->loadIdentity();
return $this->identity;
}
Everything Works fine.
Is this supposed to be? Or what am I missing? Should the PluginHelper
be updated maybe with another PR?
We need to find a solution as it prevents the whole CLI App
from running.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-03-27 14:09:33 |
Closed_By | ⇒ | bosunski |
Status | Closed | ⇒ | New |
Closed_Date | 2019-03-27 14:09:33 | ⇒ | |
Closed_By | bosunski | ⇒ |
Status | New | ⇒ | Pending |
getIdentity
should not also be arbitrarily loading anything so that's not a viable option.
This PR still has changes in Factory::getUser()
in comparison to the main 4.0 branch. Revert those changes too then see what happens.
It's still the same thing. The issue still persists after reverting changes compared to 4.0-dev
.
From reading the documentation there are some inconsistencies in how you use this
php cli/joomla.php extension:list --type=language php cli/joomla.php extension:install url --url=https://.......
I would have expected both of these to be constructed in the same way so they would be like this
php cli/joomla.php extension:list --type=language php cli/joomla.php extension:install --url=https://.......
@brianteeman you can install an extension in 2 ways - from a remote url
or from a local path
, the processes to install either is different, in other to differentiate what process we're using, that's why I added the argument. That is why something like this is done:
php cli/joomla.php extension:install url --url=https://.......
For the case of a Path, you do this:
php cli/joomla.php extension:install path --path=/var/www/...
You shouldn't need both an argument and an option. The command should have checks to ensure that at least one of the options is set and raise an error if they're both missing or both set.
So either the command has two arguments (install type, one of "path" or "url" (though this should probably also support the plugin driven approach introduced to the component) and the address for that type), or a single argument (the install type) and an option for the address (path/URL/whatever), or two options (--type=<foo> --address=<bar>
). But it should not end up as it is now where you have an argument specifying the type AND an option specifying the type. Or, if the command is built in a way where it supports multiple installs, then you would omit the type argument completely and your options would turn into something that can exist multiple times (InputOption::VALUE_IS_ARRAY
instead of one of the other VALUE_*
constants) then you'd have something like extension:install --path=/var/www/path1 --path=/var/www/path2 --url=https://www.example.com
which turns into an array in the PHP code.
Why not
Install --url=Https://example.com
Install --path=/path/to/extension.zip
On Wed, 27 Mar 2019, 17:33 bosunski, notifications@github.com wrote:
From reading the documentation there are some inconsistencies in how you
use thisphp cli/joomla.php extension:list --type=language
php cli/joomla.php extension:install url --url=https://.......I would have expected both of these to be constructed in the same way so
they would be like thisphp cli/joomla.php extension:list --type=language
php cli/joomla.php extension:install --url=https://.......@brianteeman https://github.com/brianteeman you can install an
extension in 2 ways - from a remote url or from a local path, the
processes to install either is different, in other to differentiate what
process we're using, that's why I added the argument. That is why something
like this is done:php cli/joomla.php extension:install url --url=https://.......
For the case of a Path, you do this:
php cli/joomla.php extension:install path --path=/var/www/...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#21452 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8U4rfur4Lqzd0cC-seoaOLJLJsH1ks5va48wgaJpZM4VykbL
.
What part of the CLI application is not running without your modifications to how the User object is loaded? Last I checked the 4.0 branch, the CLI commands were all running correctly, which means there is a change introduced into this PR that is causing your issues. If you really need whatever change I said to back out, then it needs to be clearly documented why it exists because in a pull request whose job is to add some console commands a change at that part of the architecture seems wrong without some additional context.
Category | CLI Libraries Installation External Library Composer Change | ⇒ | CLI External Library Installation Libraries |
Labels |
Removed:
J4 Issue
|
Category | CLI Libraries Installation External Library | ⇒ | CLI Installation Libraries External Library Composer Change |
@HLeithner What is the status of this PR? Can the conflicts be fixed and tested?
yes ... I'll see to that @HLeithner
Category | CLI Libraries Installation External Library Composer Change | ⇒ | Installation Libraries External Library Composer Change |
Thank you for updating this.
@HLeithner and @roland-d, I ran into this issue after updating the PR.
The part saying Class Joomla\Component\Acyionlogs\... Not found
rm libraries/autoload_psr4.php
and try again
Then you're still getting an exception in booting up the framework/application. Dump the exception in libraries/vendor/symfony/debug/ExceptionHandler.php
, inside the handle()
method, and go from there.
Michaels-Mac-mini:joomla-cms mbabker$ git checkout pr-21452
Switched to branch 'pr-21452'
Michaels-Mac-mini:joomla-cms mbabker$ php cli/joomla.php
Fatal error: Declaration of Joomla\CMS\Console\SiteDownCommand::configure() must be compatible with Joomla\Console\Command\AbstractCommand::configure(): void in /Users/mbabker/Sites/joomla-cms/libraries/src/Console/SiteDownCommand.php on line 115
Check your command class method signatures again. Presumably they weren't updated after the console application was updated to a PHP 7.2 minimum, which included adding some void return types in places they didn't exist before.
Then you're still getting an exception in booting up the framework/application. Dump the exception in
libraries/vendor/symfony/debug/ExceptionHandler.php
, inside thehandle()
method, and go from there.
I got this when I dumped the exception message"Failed to start application"
.
Joomla\Console\Command\AbstractCommand
As for this, I just pushed some changes correcting those. But the initial issue still persists. If you update the PR now, you should see the command Classes updated.
Well I don't know what to tell you right now but for me none of the applications are working now, everything is failing trying to write the libraries/autoload_psr4.php
file to disk.
Just for the sake of testing, I made this change (which should not be applied, but will bypass the "failed to start application" error in a janky way):
diff --git a/libraries/src/Filesystem/File.php b/libraries/src/Filesystem/File.php
index 4ff6c73203..c64a240855 100644
--- a/libraries/src/Filesystem/File.php
+++ b/libraries/src/Filesystem/File.php
@@ -351,7 +351,7 @@ class File
}
else
{
- $FTPOptions = ClientHelper::getCredentials('ftp');
+ $FTPOptions = ['enabled' => 0] /*ClientHelper::getCredentials('ftp')*/;
if ($FTPOptions['enabled'] == 1)
{
After that, things are working fine for me (the default list
command shows everything, the extension:list
, config:get
, and user:list
commands dump their info, and site:down
and site:up
updates the config appropriately).
Well I don't know what to tell you right now but for me none of the applications are working now, everything is failing trying to write the
libraries/autoload_psr4.php
file to disk.Just for the sake of testing, I made this change (which should not be applied, but will bypass the "failed to start application" error in a janky way):
diff --git a/libraries/src/Filesystem/File.php b/libraries/src/Filesystem/File.php index 4ff6c73203..c64a240855 100644 --- a/libraries/src/Filesystem/File.php +++ b/libraries/src/Filesystem/File.php @@ -351,7 +351,7 @@ class File } else { - $FTPOptions = ClientHelper::getCredentials('ftp'); + $FTPOptions = ['enabled' => 0] /*ClientHelper::getCredentials('ftp')*/; if ($FTPOptions['enabled'] == 1) {After that, things are working fine for me (the default
list
command shows everything, theextension:list
,config:get
, anduser:list
commands dump their info, andsite:down
andsite:up
updates the config appropriately).
Thanks for taking the time to look into this!
What would you recommend I do to fix this issue?
Category | Libraries Installation External Library Composer Change | ⇒ | Installation Libraries |
Labels |
Removed:
?
|
OK So I've always been nervy about this because of the changes required to base files for the installation part. As a result I'm more than happy to merge the CLI for the non-installer. And I'd like to see the installation in a separate PR that can be audited properly by our security team etc.
Labels |
Added:
Conflicting Files
?
|
@bosunski is it possible for you to remove the installation part of this PR so we can merge the rest?, as george said we would like to have a seperate jcli script for installation and maybe as wrapper for joomla.php
@wilsonge Should we preserve the changes needed for the installer to make it easier to create a jcli script?
No the changes to includes etc are exactly the reason why we separate out this part.
@bosunski is it possible for you to remove the installation part of this PR so we can merge the rest?, as george said we would like to have a seperate jcli script for installation and maybe as wrapper for joomla.php
@wilsonge Should we preserve the changes needed for the installer to make it easier to create a jcli script?
@HLeithner, Do you mean the part that lets you set up the new Joomla application?
@bosunski exactly, we want to remove all the modifications you have to add to the framework to install joomla.
The reason is that installation is the only part that doesn't need a proper setup joomla installation, doing the installation in a separate cli script without booting the framework is maybe a better approach .
Ok. I'll start work on separating it out.
@HLeithner @wilsonge is it possible to help with identifying files that changed because of installation ALONE? I've been having a hard time figuring out all changes (that happened because of the installation feature) apart from the command class.
@HLeithner @wilsonge is it possible to help with identifying files that changed because of installation ALONE? I've been having a hard time figuring out all changes (that happened because of the installation feature) apart from the command class.
I would follow your installation function and remove all parts that are not longer needed based on the function calls.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-05-03 07:41:13 |
Closed_By | ⇒ | alikon | |
Labels |
Added:
?
Removed: Conflicting Files |