[#5568] - Standardizing the install paths for discover_install
- Closed
- 9 Jan 2015
- Medium
- Build: staging
- # 5568
- Diff
- mbabker:DiscoverInstallAdapter
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Continuing the JInstallerAdapter implementations and standardizing the adapter paths, this PR focuses in on the discover_install path. As you'll see in the JInstallerAdapter class itself, the routine has been standardized and is a stripped down version of the main install method.
As the component's adapter had support for all features in its implementation of discover_install, the other adapters are now updated to support these same features. This means discover install of modules, for example, will support the use of extension scripts. Note that the file and package adapters, which did not previously support discover, continue to not do so; also the language adapter is not yet updated (same situation as the previous pull).
Testing Instructions
Since some of the common methods between install and discover_install are modified, you'll want to first test that installing components, modules, plugins, libraries, and templates still functions OK. But this works to our advantage as it will position extension files in place to test discover installs. After you've verified this continues to work OK, you'll need to prepare your environment to test the discovery of uninstalled extensions and then install them. One of the easiest things to do is to delete the configuration.php file and re-install Joomla (with the same instance you previously installed extensions into). Another option is to go into the database and manually remove all of the data for your installed extensions (template styles, tables the extensions may add to the database, the extension records themselves, and menu, asset, and module records as appropriate). Make sure you do not delete the extensions from the filesystem while doing this reset. Once you've gotten this far, you'll want to go to the Extension Manager's Discover view and click the Discover button; you should now get a list of extensions which are not installed. Select them and click the install button; all should correctly install.
Extension Concerns
Components previously supported the preflight, install, and postflight extension script methods and that is the support that has been added for the other extension types. This could cause some concerns in extension scripts that don't account for the possibility to be triggered via a discover installed (I discovered one such issue with com_patchtester while testing this). If it's decided this specific change may do more harm than good for extensions, we can update the discover routine to only process the script files for components so as to not remove a feature's support in a release that does not allow breaking B/C.
jissues-bot
- | Labels |
Added:
?
|
||
@rdeutz I agree totally. My goals right now are to clean up some of the duplicated code in the adapters, get each route acting consistently for all adapters (every extension type should support the maximum features possible and perform their routine's steps in a consistent manner), and make it generally easier to follow what's going on. I only raise the concern because if there are people performing discover installs (and in all honesty I hope that number is at a minimum), it can cause some scripts to break. This is solvable in scripts by checking the $route param before performing an action.
zero-24
- | Category | ⇒ | Administration Libraries |
@test: I found an issue that is also there when not applying this patch. I have copied a package, component, plugin, module and template into the discover site. When I run discover I see them, so I select 1 component to install and click Install. Joomla goes on to install everything it found during discovery.
Another thing I found, the package (Kunena in this case) is listed as all it's individual extensions rather as a package. This makes installing the extension as a package impossible.
Did you notice as well, when I do a discover on a clean Joomla system, the beez3 template and Captcha - NoCaptcha plugin show up?
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5568.
On 4 January 2015 at 08:19, RolandD notifications@github.com wrote:
Did you notice as well, when I do a discover on a clean Joomla system, the
beez3 template and Captcha - NoCaptcha plugin show up?I can not confirm this
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
Did you notice as well, when I do a discover on a clean Joomla system, the beez3 template and Captcha - NoCaptcha plugin show up?
They do not show as discover here and are indeed present in joomla.sql. Installed with no sample data.
Retested on current staging with no sample data - I still get no results
when doing a discover
On 4 January 2015 at 08:52, infograf768 notifications@github.com wrote:
Did you notice as well, when I do a discover on a clean Joomla system, the
beez3 template and Captcha - NoCaptcha plugin show up?They do here and are indeed present in joomla.sql. Installed with no
sample data.—
Reply to this email directly or view it on GitHub
#5568 (comment).
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
I corrected my comment above as it was unclear.
They do NOT show as discoverable indeed.
@brianteeman @infograf768 Thanks for testing. I made a new installation and now it doesn't show up either. I guess my database was outdated.
@roland-d The issue you noted is expected. Package extensions do not support discover installations at all, even if you drop all the package files in their expected places (the manifest, language files, and optional install script). Joomla has never supported it, this patch doesn't implement that support. Truth be told, I'm not sure adding that support is even feasible.
As for the everything being installed part, it's a Joomla quirk. When Joomla discovers extensions, records are added to the #__extensions table and each discovered extension has a state of -1. But that's the only awareness Joomla has of these discovered but not fully installed extensions. You could purge those records and it wouldn't affect anything in normal operations, but they'll come back the next time you ask Joomla to discover uninstalled extensions.
I installed and discovered the different types with success. The only thing I found is this notice:
PHP Notice: Undefined property: JInstallerAdapterTemplate::$getName in joomla34\libraries\cms\installer\adapter\template.php on line 189, referer: http://localhost/joomla34/administrator/index.php?option=com_installer&view=discover
@waader It's actually fixed with this PR. Line 189 has the undefined property pre-patch, the same line is now line 192 post-patch and has the correction (see https://github.com/joomla/joomla-cms/pull/5568/files#diff-e51140681f5ec23ca5c71b64063a9c49L189).
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-01-09 15:27:42 |
| Milestone |
Added: |
||
wilsonge
-
I think we should let the pre/postflight and install methods run. It is good if "Installation" works in the same way whatever we install. I personally never understands or could remember when something is executed or not.