Please add languagefilter system plugin to your list.

Please add languagefilter system plugin to your list.

It's already there
See line 115.

can not be uninstalled (locked = 1).
but can be disabled (protected = 0).

Correct?

My list above is just a Summary of Changes. It doesn't include extensions that have already the correct states.

@ReLater Just at the end when all is ready in the update sql, don't forget to change the joomla.sql, too, and please do all for both mysql and postgresql.

Just at the end when all is ready in the update sql, don't forget to change the joomla.sql, too, and please do all for both mysql and postgresql.

Jepp. Please read #28527 (comment)

@ReLater List in description looks ok to me, the actual sql changes I haven't verified yet.

Update: I've just checked the changes in the update sql, and to me they look consistent to the descriptions. So that looks good to me so far.

But I have the feeling that @alikon will want com_finder and workflows be uninstallable ;-) (joke for insider)

ahhh sure i really want those 2 to be unistallable as well
should i say for having a more light core to be user friendly ?

@alikon How about mail templates? (other joke for insiders)?

@ReLater Don't take us serious: Workflows, smart search and mail templates should not be uninstallable. We're just making silly jokes.

mail templates what ?
yeah please forgive me
but it's better to complain about piece of software than the current worldwide situation

p.s
yes agree with @richard67 only silly jokes

@ReLater
Not on desktop right now, but when I tested previously, I could uninstall languagefilter plugin.

@richard67

Just at the end when all is ready in the update sql, don't forget to change the joomla.sql, too, and please do all for both mysql and postgresql.

If you say "We don't support updates and basta." Do we need the update files 4.0.0-2020-03-25.sql at all? Isn't joomla.sql sufficient then? At the end the update files change nothing in a fresh installtion. States are all identical then.

@ReLater I haven't said we don't support updates, I have said we don't support updates yet between J4 versions existing up to now. But the update sql files are necessary for updating from 3.10 mainly. Most of the stuff in it is for updating from 3.10. It may be that statements for stuff added in J4 is not necessary in the update sql, but that's only a small part, and leaving it away would make it harder to maintain.

And btw. don't forget postgresql.

updating from 3.10

Yes, I forgot that completely ;-) What is Joomla 3?

@ReLater The title of the last commit sounded as if it would also include postgresql/joomla.sql, but it didn't. Maybe just forgotten? Or still in progress?

Hint for me: Commit "PostgreSql. Installation. All" is "PostgreSql. Update." (wrongly named).

@ReLater I just see that appveyor says the PR is not mergeable, and now I know why: The joomla.sql has been split to several files with recently merged PR #28350 . That means you have to solve merge conflicts, i.e. find out in which of the new files your changes below, save your joomla.sql files somewhere, then accept the deletions and then merge your changes into the new file (I think it will be base.sql but am not sure right now).

Do you think you can handle that and solve these conflicts? If not let me know and I will try to help with a PR to your branch.

@ReLater base.sql it is where the extensions table is filled, so your changes for meanwhile removed joomla.sql files should go into that.

@ReLater Shall I help you with updating this to latest changes in 4.0-dev? I will not be available for long anymore today.

@richard67

Shall I help you with updating this to latest changes in 4.0-dev? I will not be available for long anymore today.

Yes, please.

@ReLater Done.

Thanks!

SQL files look consistent to me.

Btw, @ReLater , did you know that for J4 PR#s, drone recently generates patched installation and update packages? There is a link at the bottom of your PR in the CI test results:

(If necessary it needs to use the "Show all checks" link before to see that).

A good test of this PR would be to make a new installation with the patch of this PR applied to a clean 4.0-dev or using the created installation package for this PR, export a "SELECT * FROM #__extensions order by type, element, folder, client_id" into a csv file, then updating a clean 3.10-dev to 4.0-dev using the created update package for this PR and do the same export, and compare if they are equal except of expected differences like e.g. the extension_id's. And to do the same for both types of databases and also compare if results are same for both.

See also the testing instructions in PR #28462 .

@ReLater Sure the joomla extension should not be locked? Maybe it was vice versa, the udpate sql was right and the base.sql (former joomla.sql) was wrong at this point?

Sure the joomla extension should not be locked? Maybe it was vice versa, the udpate sql was right and the base.sql (former joomla.sql) was wrong at this point?

I'm absolutely not sure. Reason is a bit lack of descriptions inside the plugins. I deactivated it yesterday and all effects that I saw were that rebuild of update sources didn't work but with a clear message:

But I could install new plugins and update sources were correctly written.

Simply instruct whenever you think or know that it's a bad idea!

@ReLater I know as little as you do about if it's needed or not. Let's see if some other comments come.

"This is a list of extensions that can be disabled at current state" moved to #28563 (comment)

can you look at
[09-Apr-2020 08:08:34 UTC] PHP Notice: Undefined property: Joomla\CMS\Table\Extension$locked in /Applications/MAMP/htdocs/joomla-cms-3.10-dev/libraries/src/Installer/InstallerAdapter.php on line 1155

This happens when updating 3.10

@infograf768

Thank you. Good find. I have to check if a Joomla version_compare is possible there or if I have to add isset rules for protected AND locked and so on.

I have to check if a Joomla version_compare is possible there or if I have to add isset rules for protected AND locked and so on.

@ReLater If you ask me, I would prefer isset.

There are no prebuilt packages available (no links under "Download"). I don't know which of the unsuccessful test tools is responsible for that.

It’s drone. I restart it, maybe that helps.

Restarted drone again and this time it worked. Appveyor is another stuff.

I just made a new installation with the prebuilt zip of this pr.

After that I checked cassiopeia (I started at the end of your table). In my case cassiopeia is locked. If I read your table correctly (could it be, that client_id should be locked?) then it should not be locked.

This is the state of my extensions after installing joomla with the prebuild of this pr:

Cleared:

I don't understand.

Hint:
But it can't be disabled as long it's the FE standard template. That's not part of this pr but Joomla behavior.

Thank you for explaining and sorry for the confusion. I don't know why, but I assumed the table contained locked and protected and client_id is a typo. But you are right. Core extensions are all locked, so this column is unnecessary.

Can you please pull the latest changes from 4.0-dev, so that all tests pass correctly?

Can you please pull the latest changes from 4.0-dev, so that all tests pass correctly?

I have no idea how.

@ReLater I've done that for you. It just needs to have a remote in your git client pointing to the CMS repo (I've called it "upstream"), and then merge the 4.0-dev branch of that remote into your patch-2 branch.

I wonder if all core extensions really need to be protected before uninstalling.
In the worst case, with a plugin that does not have its own database table, it can happen that the files are in the file system again during the next update and could be discovered. right?

@astridx Was all discussed before, just read previous discussions here and in the original PR by Michael Babker. If an extensions has database tables it can end in a mess.

@astridx P.S.: Microsoft also doesn't allow you to uninstall Windows Command Shell (CMD) even if you never use it ;-)

@astridx Was all discussed before, just read previous discussions here and in the original PR by Michael Babker. If an extensions has database tables it can end in a mess.

Yes. That is why I wrote "if it has no database table".
Do you mean with original PR this one: #28462?

@astridx The very original one was this one: #17219 .

I see even #17219 had a predecessor: #13037 . So it's really a long story.

@richard67

I've done that for you.

Thank you again.

It just needs to have a remote in your git client pointing to the CMS repo (I've called it "upstream"), and then merge the 4.0-dev branch of that remote into your patch-2 branch.

Still the same answer: "I have no idea how." ;-)

Well there was once a button for that on GitHub, but is seems they’ve removed it in their new UI.

@ReLater

1. Checkout your branch in your repo
2. Run
   git pull origin/4.0-dev
   where origin is the remote name of https://github.com/joomla/joomla-cms
   You can check this name via git remote show
3. Run
   git push yourremotename/yourbranchname

@richard67 Correct me please if I am wrong.

@astridx That’s not right in all cases. If you have an own fork, origin is the remote name of your own repo and not of the CMS repo, and then your commands keep your local and remote branch of your repo in synch, but it does not update your branch with the changes in the base branch in the cms repo.

I don't use a local git client for Joomla CMS, only the github.com GUI.

As far as I remember there's a way somehow via the Compare feature ("compare across forks") and make a PR but one have to use several tricks for setting the correct compare direction with the GUI inside your own branch. Maybe it works if I start the compare in this Repo plus 4.0 branch here?? I will check it next time...

Yes, that would work. Easiest way is to compare 2 branches and the modify the url so at the end you compare the cms repo's 4.0-dev branch with your branch. Then you can make a PR to your repo and merge it. Only problem is when there are merge conflicts which are so severe that the GitHub UI can't provide a way to fix them. In such case ask a maintainer (e.g. me) for help ;-)

Example URL for doing such comparison for your branch here:

ReLater/joomla-cms@patch-2...joomla:4.0-dev

@ReLater If you are on Windows I recommend the GitHub Desktop for Windows application as local client. Itas was poor at the beginning but meanwhile has improved and is really good. It comes with a git client and a GUI.

	'mod_tags_popular',
	'mod_tags_similar',

should be under:

OR (type= 'module' ANDclient_id= 0 ANDelement IN (

How to handle this one?

Quick Icon - Missing Download Key Notification is protected when upgraded from J3.10 to J4 but not with new J4 installation.

@Quy

Quick Icon - Missing Download Key Notification is protected when upgraded from J3.10 to J4 but not with new J4 installation.

I checked the joomla.sql in current 3.10 nightly. I can't find a quickicon plugin "Missing Download Key Notification".

I just find these:

(437, 0, 'plg_quickicon_joomlaupdate', 'plugin', 'joomlaupdate', 'quickicon', 0, 1, 1, 1, '', '', '', '', 0, '0000-00-00 00:00:00', 0, 0),

(438, 0, 'plg_quickicon_extensionupdate', 'plugin', 'extensionupdate', 'quickicon', 0, 1, 1, 1, '', '', '', '', 0, '0000-00-00 00:00:00', 0, 0),

(458, 0, 'plg_quickicon_phpversioncheck', 'plugin', 'phpversioncheck', 'quickicon', 0, 1, 1, 1, '', '', '', '', 0, '0000-00-00 00:00:00', 0, 0),

(488, 0, 'plg_quickicon_privacycheck', 'plugin', 'privacycheck', 'quickicon', 0, 1, 1, 0, '', '{}', '', '', 0, '0000-00-00 00:00:00', 0, 0),

@ReLater It came new in J4.

Quick Icon - Missing Download Key Notification is protected when upgraded from J3.10 to J4 but not with new J4 installation.

Reason "my" update sql 2020-03-25 runs before 2020-04-11. Latter one installs that plugin.

@ReLater You can fix the protected value then in these 2020-04-11 files . As we are not beta yet you can update these files.

@ReLater @mbabker posted a comment above regarding the last change. I think he is right. Unfortunately the comment is hidden in the resolved code conversation when not explicitly expanding that, so I post here the link: #28563 (comment)

Update: Links seems not to help, at least not on mobile, when the resolved discussion is not expanded.

I have tested this item ✅ successfully on c15bd16

I've found relevant differences between new install and updated from 3.10-dev for MySQL. Will post details soon.
Update: False alarm regarding these differences, they are not related to this PR.

I have tested this item ? unsuccessfully on c15bd16

At least one of the SQL update scripts for PostgreSQL contains MySQL name quotes, so an update from 3.10 fails with an SQL error.

Beside this, there are differences in protected and locked statuses between new install and update at least for MySQL. I'll post the details later.
Update: False alarm regarding these differences. But the above error with PostgreSQL still is valid.

I have tested this item ✅ successfully on c15bd16

RTC

Thankyou very much for working through this!