plg_editors_codemirror (it's an optional editor)

IIRC it's hardcoded into the template manager so I don't think I'd change this one.

IIRC it's hardcoded into the template manager so I don't think I'd change this one.

yes, you are right https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_templates/models/template.php#L368

so i guess that one needs to be locked ... anyway i think by reading the code we get a warning if we have it disabled.

Yes that's correct

ok i will lock that one again

I am not convinced about some of this. Some of these are dependant on
others but this enables them to be disabled independently. Pretty sure
thats why they are protected

@brianteeman if you are referring to com_redirect and plg_system_redirect, look at com_search and com_finder and their plugins they are all unlocked.

It's different. Com_redirect requires plg_redirect. Com_search doesn't
require plg_search_contact

On 21 Nov 2016 5:14 p.m., "andrepereiradasilva" notifications@github.com
wrote:

@brianteeman https://github.com/brianteeman if you are referring to
com_redirect and plg_system_redirect, look at com_search and com_finder and
their plugins they are all unlocked.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12961 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8S3pLiMQcNoqSvEBpepdT5q2s1VKks5rAdFqgaJpZM4K4csv
.

well i tried to disable com_redirect and enable plg_system_redirect to check the worst case scenario, and i think the only thing that happens is that i cannot manage the redirect urls, it probably will use the ones already in that are already in the database table.
and that's the worst case scenario, ie, when a user disable the com_redirect and enables the plg_system_redirect plugin.

And what happens when the user clicks on the link in the warning to enable
the plugin?

the same that happens when click on the message in com_finder ... goes to the edit plugin (which is disabled)

Content plugin "joomla" is using com_messages to send emails about new content submitted in frontend,

I guess the email message will be sent even if component is disabled,
-- but users will not be able to read the messages

I guess administrators will see this and reenable the component ?

Also 3rd party extensions, now assume that the component is always active and never disabled,
i was thinking of using com_messages

IIRC com_messages was one of the components that would be removed from the core
Right: https://developer.joomla.org/cms/roadmap.html

assume is not a word i use in programming ?

Decoupling was basically cancelled since nobody can figure out how to fully manage it. I think that's the Reader's Digest of that decision anyway.

the same that happens when click on the message in com_finder ... goes to the edit plugin (which is disabled)

Except that removing the protection enables me to uninstall the plugin
If I do that then I just get a list of plugins when i follow the link

The problem is that unlocking them enables the user to uninstall them ... and this will cause errors because some of the plugins were once added in the core's schema update scripts ... and this will cause errors on updating from old versions like e.g. 2.5. I think that's why they were locked.

hi @richard67 !

if that's so a decision is needed on this, either lock all core extensions (including the ones unlocked now, eg, com_banners, com_contact, com_finder, com_search, etc) or only lock the ones essencial for the cms functioning (like it is now + plus this PR).

@andrepereiradasilva Yes, I agree. Just wanted to mention that some of the schema update scripts can cause problems if not fully decoupled.

Should'nt this be more correclty handled in the 4.X branch ?

The other problem, as I see it, is that if one uninstalls stuff like the language filter plugin, there is no easy way to install back.
Also, uninstalling them may also delete the related language strings.

@infograf768 thats true for the existing unprotected extensions

On 24 November 2016 at 07:42, infograf768 notifications@github.com wrote:

The other problem, as I see it, is that if one uninstalls stuff like the
language filter plugin, there is no easy way to install back.
Also, uninstalling them may also delete the related language strings.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12961 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8eRynjfGoW-_ppFpOJomW5u2Rtzfks5rBT_3gaJpZM4K4csv
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Alas, yes, Does not mean we have to do it for others until we find a way to get this process more user friendly.

the problem i see is that "lock" does two things:

• not able to uninstall the extension
• not able to enable/disable the extension

Maybe it should do just one thing. Not able to uninstall.
And we would have another field for able to enable/disable... Just lanching the idea.

I hear you about it being useful to disable the extension

On 24 November 2016 at 09:25, andrepereiradasilva notifications@github.com
wrote:

the problem i see is that "lock" does two things:

• not able to uninstall the extension
• not able to enable/disable the extension

Maybe it should do just one thing. Not able to uninstall.
And we would have another field for able to enable/disable... Just
lanching the idea.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12961 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8dOHPH6Whe0XWq_NwbpXidiW40xTks5rBVgKgaJpZM4K4csv
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

please comment on this RFC #13037 if this solves all the issues found here.