[#25553] - [4.0] Download key manager - GSoC Expand Extensions Manager Redo
- Fixed in Code Base
- 4 Sep 2019
- Medium
- Build: 4.0-dev
- # 25553
- Diff
- roland-d:download_key_manager
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
Redo
This is a redo of #17575 as I can no longer push to the original repo.
Introduction
Currently there is no clear overview of which extensions have download keys to make users download their extensions with an extra_query with their keys included to allow the download. Developers have been currently hacking this system by creating their own view to add a download key to the extra_query field in the #__update_sites table (Example of an extra_query field: dlid=key&dummy=my.zip).
Each extension developer may have a different way to build this extra query so the idea is to make a view to manage and insert the download keys of all extensions in a single view in com_installer.
To set or customize the prefix and suffix of the download key you need to have an tag with prefix and suffix in your installation file like this:
<dlid prefix="dlid=" suffix="&dummy=my.zip"/>
(note: remember to close />)
If an extension has no download ID set in the manifest file, the download key will show up as N/A in the list and will not be editable.
Testing Instructions
Here are the extensions to test the feature. I have not included all types as I think these 3 already make clear what this is about.
- Run the MySQL update query or the Postgres update query depending on the database you use
- Apply the patch
- Install the extensions below
Component
keycomponent.zip
Plugin:
keyplugin.zip
Module:
keymodule.zip - Go to System -> Update Sites
The list shows just the name of the extension and the update site URL.
- Clicking on the extension name will open the Edit screen.
The Download Key is shown without the prefix and suffix. Only the developer will be responsible to define the prefix and suffix of the download key.
You are going to need a real extension with a download key to see if the download key is send. For now you could also check the database by doing this:
- Go to the table __update_sites table
- Check the field
extra_queryfor the extension where you added the download key. It should have the format ofprefixkeysuffix
Expected result
A simple a intuitive way to the user manage his download keys and less work to the developers to create a view to generate the extra_query
Actual result
There is no single place to manage your download keys.
Documentation Changes Required
Yes, once merged I will write a document on how to incorporate the tags in the installer XML
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_cpanel com_installer com_plugins Language & Strings Libraries |
| Labels |
Added:
?
?
|
||
I can see a value in this, we have build a complete extension install from our backend and extensions make Joomla great even if you can do a lot with core.
The points raised by @mbabker and @joeforjoomla are, with all due respect, part of a chicken/egg discussion. If we want to improve the handling of download/update keys, and thus updates themselves (which is much needed imho), something needs to be done. The current situation where we leave this to developers is confusing and time-consuming to both end-users and developers. In my own experience, a lot of my customers leave extensions unpatched/not updated because they can not be updated with the built-in updater. This is an undesired effect of the current situation, unwanted for all of us.
If such a feature will become part of the Joomla! core, and we could persuade at least a number of developers to participate and make use of it, this could be a very strong feature and make Joomal! even more user-friendly
Erik
@MastersOfMedia with all due respect for you, imho i see this as something optional given that only a small subset of paid extension use it and that must be managed by the extension itself when and if needed, not by the Joomla core.
In my own experience, a lot of my customers leave extensions unpatched/not updated because they can not be updated with the built-in updater. This is an undesired effect of the current situation, unwanted for all of us.
This pull request is not going to fix that. It's still up to the developer to build support into their extensions to use the updater, just like it's still going to be up to the developer to build support into their extensions to use a core "owned" download key manager. Who says this key manager is going to work with all of the systems that developers are presently using for their extensions, or that developers are going to commit to rewriting their extensions (and possibly their backend systems validating things) to use this system when they already have a working system (basically, why make change for the sake of change).
Is it useful? Yes. Is this core territory? IMO, no. And if it were core territory, there would have been more feature requests asking for it over the years, unless I've had my head buried in the sand this only came up within the GSoC team the year the project was accepted (which is part of my reason for the "core looking for problems to solve" comment before).
I agree with everyone ... we need it, it shouldn't be in the core, its a chicken/egg thing.
I think the best solution would be for one of the major extension developers (akeeba/regular labs) to develop this as an extension first that all can use. THEN once it has lots of user and developers using it (which would only happen if one of those MAJOR extension devs release it) it could get to the point where other developers use it and THEN it might be wise to have it in the core.
But until something like that happens, I agree, it might be more 'excess core never used' feature (and I agree, might be more confusing to users).
So ... anyone else willing to pick this up and run with it?
@cpaschen the download key system (which has been around for a while just without a UI) already came from akeeba (i don't know if nic still does use this as he decouples his stuff more and more from Joomla Core). However there's no central place to manage this. I believe this does have a place in core as the questions on how to use the download key in modules and plugins (and there was no easy way). So I believe this is actually fine for Joomla as long as extensions opt into it in their XML files (so only extensions that use the Joomla Download Key mechanism show up in the list of extensions to add a key to)
Please look at how I added a <caption> to tables
Is there a reason that this is seperate from com_installer&view=updatesites
Is there a reason that this is seperate from com_installer&view=updatesites
None other than that nobody thought about it or asked about it. I do agree, it might be better integrated there. Especially since most of the data is all the same.
I am going to make the changes and integrate it there.
I am going to make the changes and integrate it there.
Great. It will make things much easier going forward. Less duplicate code to maintain etc etc
It would need some sort of label
How does the the update site list view work when an extension has more than 1 update site (like core for example). Is it multiple rows in that list (in which case download keys don't work) or is it multiple text boxes for a single extension?
Update site list view
Where are the multiples?
| Category | Administration com_cpanel com_installer com_plugins Language & Strings Libraries | ⇒ | Administration com_installer com_plugins Language & Strings Libraries |
| Category | Administration com_installer com_plugins Language & Strings Libraries | ⇒ | Administration com_installer com_plugins Language & Strings |
| Category | Administration com_installer com_plugins Language & Strings | ⇒ | Administration com_installer Language & Strings |
No stress. Just making sure :)
| Category | Administration com_installer Language & Strings | ⇒ | SQL Administration com_admin Postgresql com_installer Language & Strings Installation |
Is this ready for testing again?
@wilsonge Yes, it is ready for testing again. I have updated all the instructions to reflect the latest changes.
Also pinging @sanderpotjer
I have tested this item
I just compared the database table #__update_sites where in the field extra_query it is stored correctly. One thing mentionend: The example component has a spelling error where the xml file defining the "donwload key part" has a key sufix, but it should call suffix with double f. For some tester it could be useful to change that to see that the patch works correct.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25553.
I have tested this item
As bees4ever wrote, I had to edit the keycomponent/downloadkeytestcomponent.xml .
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25553.
I have tested this item
As bees4ever wrote, I had to edit the keycomponent/downloadkeytestcomponent.xml from
to .
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25553.
| Status | Pending | ⇒ | Ready to Commit |
Status "Ready To Commit". 1 build failing.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-09-04 14:59:15 |
| Closed_By | ⇒ | wilsonge | |
| Labels |
Added:
?
|
||
Thanks!
Thank you thank you thank you
Add documentation for this feature: https://docs.joomla.org/Manifest_files
I still don't believe this is a core responsibility. Has anyone gauged interest among the extension ecosystem to determine how many vendors would provide support for this instead of their own solutions? Because without ecosystem support, you're going to have a interface in core that end users think they are going to be able to use but the reality of it is if extensions don't support it it's just going to confuse the heck out of users wondering why they can't use a core feature.
These types of projects come across as core looking for problems to solve without figuring out if it is a real problem to be solved (or moreso someone not liking the fact that extension responsibilities are left to the extension to be implemented).