User tests: Successful: Unsuccessful:
This change adds an extra filter on the Extensions -> Manage page to filter extensions on whether they are core or 3rd party extensions.
Don't know
Any feedback on the language strings is appreciated.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_installer Language & Strings |
I have tested this item
@erikvandoorne please mark at https://issues.joomla.org/tracker/joomla-cms/13795 your test successful (blue Button "Test this").
@erikvandoorne I have marked your test result.
btw, I have no idea what this AppVeyor test is or if I need to do anything for it :)
I have tested this item
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-01-29 13:56:42 |
Closed_By | ⇒ | wilsonge | |
Labels |
Added:
?
?
|
I've tested with latest beta but doesn't work. With Show Core extensions selected, all extensions (core & non-core) are shown. With Show third party extensions selected nothing is shown.
MAMP Pro with PHP 7.0.13 &MySQL 5.6.34. Installed JCE 2.6.8RC3 & Akeeba 5.2.5.
Why need that filter? You could as well just sort by ID descending and get the same result.
I'm not even sure if that is accurate in each instance. There may be casess where a core extension was discovered for some reason or in case of decoupled extensions (eg Weblinks), on legacy sites it would show up as core while on new installations it would show up as 3rd party.
btw, I have no idea what this AppVeyor test is or if I need to do anything for it :)
That's because Michael already activated the webhook but it doesn't work yet correctly. Just ignore for now. It would run the Unit tests on a Windows enviroment.
for none core extensions the dbquery is 'extension_id' >= 10000.
With a clean Joomla install latest extension_id 802. First 3th party extensions starts at 803.
An additional field 'core' in the extensions table would maybe not a bad idea.
I have tested this item
I've tested with latest beta but doesn't work. With Show Core extensions selected, all extensions (core & non-core) are shown. With Show third party extensions selected nothing is shown.
For none core extensions the dbquery is 'extension_id' >= 10000.
With a clean Joomla install latest extension_id 802. First 3th party extensions starts at 803.
With a clean Joomla install latest extension_id 802. First 3th party extensions starts at 803.
No, first 3rd party should start with 10000. not with 803. If it starts with 803 you have a messed up installation.
this is a very handy feature to have a quick look which 3th party extensions are installed without the need to go through hundreds of lines of core/non-core files.
As said, just order the list by ID descending and the first lines will be the 3rd parties.
But this may not be always the case. Eg if you for example uninstalled a core extension (eg the Hathor template) and discover it again later on it will have an ID higher than 10000 allthough being a core extension.
I have revert this one I think it is wrong to look at the extension number we need to look at the protected flag instead
Weird. I've started over and 3th party extensions start now indeed with 10000. Handy to know that 3th party extensions start with 10000
I have tested this item
I have revert this one I think it is wrong to look at the extension number we need to look at the protected flag instead
We actually already can filter by protected or unprotected.
An interesting option may be to filter by Author. That would also be usefull to find extensions from a specific vendor (eg all RegularLabs or Akeeba ones). However it's also not completely accurate for core vs non-core. I think especially the templates have another author in it.
An interesting option may be to filter by Author. +1
@rdeutz The protected flag is what I first looked at but to me that is not enough. A lot of extensions with a number below 10000 have protected set to unprotected. Any new extension you install will get a number of 10000 or more, that is why I filtered on that value.
One of Andre's old PRs has a lot of discussion on this. Core !== Protected. All that's a flag of is whether Joomla lets you disable/uninstall the extension.
Any new extension you install will get a number of 10000 or more, that is why I filtered on that value.
That's true (if there is nothing messed up in the databse itself), but as said also core extension may end up with a number higher than 10000. So while you could say all 3rd parties are higher, it's not true to say all core ones are lower.
To stop this discussion because there is no real answer as Michael pointed out. Would it make any sense to add a column that designates an extension as core or not?
Imho no. As it would break as well as soon as you uninstall Hathor (or other non-protected core extensions) and discover_install it later (after next update when files are back) again.
What point is there in adding a field that says "core"? Also, what stops developers from flagging their extensions as core too? It already happens with the protected field.
#13037 is probably the best effort you get to designate "core" extensions without adding a tracking field which serves no purpose. It also fixes some long standing issues with what the definition of protected is.
Yeah, you're right. It's useless. As an extension developer I can fubar what I like in the database anyway.
Tested, this patch is working correctly.