Looks like you are removing more strings than you need to

@chmst Your update SQL for postgresql is equal to the one for mysql, but it needs different names quoting.

Thanks @richard67,
@brianteeman - I have spent much time with testing in different constellations but could not find a non-translated string. So any better test is appreciated.

I have tested this item ✅ successfully on 5a00c30

Done :)

in 3.9 updated sites got a message COM_CPANEL_MSG_ADDNOSNIFF_BODY which i think is triggered by https://github.com/joomla/joomla-cms/tree/4.0-dev/administrator/components/com_admin/postinstall

I think you need to review all the files in https://github.com/joomla/joomla-cms/tree/4.0-dev/administrator/components/com_admin/postinstall and not just the one I highlighted. It could be that some of those fiules can be removed as you have removed the text in this pr or that you have to put the files back.

Basically you have done more in this pr than you described in the original post

We need to remove COM_CPANEL_MSG_EACCELERATOR_TITLE too. I think this is good otherwise

Brian is kinda right too though. I think we can remove admin_postinstall_updatedefaultsettings_condition - which are 3.8.8 default settings changes. We can probably also remove the htaccess changes as well. I don't think we need to keep these forever. We can remind users to check outstanding postinstall messages as part of the upgrade docs.

@chmst You have to rename the 2 update SQL scripts 4.0.0-2020-12-31.sql to a date later than the last Beta release, which was on February 2, eg. to 4.0.0-2021-02-28.sql. Otherwise they will not run when updating a Beta 7 to the next Beta or RC.

Update: Done after talk on Glip.

I have tested this item ✅ successfully on a2c06a3

I've done 3 tests on 2 identical copy of my homepage which I had updated to 3.10 Alpha 5 and cleaned up by a not 4.0 compatible extension:

1. Updated copy 1 to latest 4.0 nightly without this PR applied to reproduce the issue.
2. Updated copy 2 to the update package for this PR to make sure the PR works as expected when updating from 3.10.
3. Updated the result of test 1 to the update package for this PR to make sure the PR works as expected when updating from 4.0 Beta 7 or later nightly.

The PHP files are not removed with the update.

They have to be added to script.php to the list of files to be deleted before making the next 4.0 release of whichever kind (beta or RC). Normally @wilsonge cares for that.

@brianteeman Could you give this release blocker here a test? Thanks in advance, it would be really appreciated.

You are removing the file for the htaccess changes (as requested by @wilsonge) but the language strings are still present and the database record is not removed

Also you need to check the condition_file in the database and make sure that those files are removed if the record is removed as they will never be used

Thank you. Yes, I have forgotten language strings, sorry. Condition files must be removed in the script (see description / testing instruction).

ondition files must be removed in the script (see description / testing instruction).

I saw the comment about leaving that to @wilsonge and I dont agree that we should leave it to him (yes I am guilty of forgetting to add files to that list).

However that list is for how to handle files that exist on sites when they are upgraded but no longer present in the core - such as the two files you are removing here.

I am saying that there are more condition files that need to be removed from core

@brianteeman I've just checked the files used as action file or condition file by the removed postinstall messages. From my point of view all is ok regarding the sources:

• administrator/components/com_admin/postinstall/eaccelerator.php, administrator/components/com_admin/postinstall/joomla40checks.php and plugins/captcha/recaptcha/postinstall/actions.php have been removed already in the 4.0-dev sources
• administrator/templates/hathor/postinstall/hathormessage.php has also been removed from sources and should already be in script.php for removing the hathor template.

What remains is to check and if necessary complete file deletion in script.php.

@chmst To me it seems the messages with title keys COM_CPANEL_MSG_HTACCESS_TITLE and COM_CPANEL_MSG_UPDATEDEFAULTSETTINGS_TITLE should be deleted in database, too. They belong to those 2 PHP files deleted by this PR but currently they are not deleted with the update SQL script of this PR or any other, so they are still in database after an update.

Beside this, it would be better to use one delete statement with an IN clause and order the key in that clause alphabetically. Assuming my above assumption is right, this would be for MySQL:

DELETE FROM `#__postinstall_messages`
 WHERE `title_key`
    IN ('COM_CPANEL_MSG_EACCELERATOR_TITLE',
        'COM_CPANEL_MSG_HTACCESS_TITLE',
        'COM_CPANEL_MSG_JOOMLA40_PRE_CHECKS_TITLE',
        'COM_CPANEL_MSG_UPDATEDEFAULTSETTINGS_TITLE',
        'PLG_PLG_RECAPTCHA_VERSION_1_POSTINSTALL_TITLE',
        'TPL_HATHOR_MESSAGE_POSTINSTALL_TITLE');

For PostgreSQL use the same, just with different name quotes ".

@brianteeman I've just checked the files used as action file or condition file by the removed postinstall messages. From my point of view all is ok regarding the sources:

Look at the Joomla 3 install sql and the postinstall messages table

Here you can find the location of all the postinstall files. They were not all in the component folder. Some of the messages that have now been removed had a postinstall file that also has to be removed and hasnt been.

For example we still have files such as https://github.com/joomla/joomla-cms/blob/4.0-dev/plugins/twofactorauth/totp/postinstall/actions.php

This file is completely redundant now

@brianteeman Well, I have checked only for those postinstall messages handled by this PR, I haven't checked the others.

As the PR is to "cleanup postinstall messages on update" then this PR is not complete

@brianteeman On a new installation of a clean 4.0-dev the postinstall message with title_key = 'PLG_TWOFACTORAUTH_TOTP_POSTINSTALL_TITLE' is still in database. Are you sure that this is redundant now?

My bad on that one - need more coffee. I swear when I checked it last night that message wasnt included any more. It probably should be removed but that is a different issue to this. Sorry for the confusion

Sorry for the confusion

No problem, you made me check it again, and better one check more than one check missing.

@chmst I was so free to solve a merge conflict in script.php because it was my just merged PR #32582 which caused it, and I committed also a small code style changes for one of the SQL scripts so it's same as the other one.

Thanks!

Will test again later or tomorrow if still necessary then.

I have tested this item ✅ successfully on b01f597

I've done 3 tests on 2 identical copy of my homepage which I had updated to 3.10 Alpha 5 and cleaned up by a not 4.0 compatible extension:

1. Updated copy 1 to latest 4.0 nightly without this PR applied to reproduce the issue.
2. Updated copy 2 to the update package for this PR to make sure the PR works as expected when updating from 3.10.
3. Updated the result of test 1 to the update package for this PR to make sure the PR works as expected when updating from 4.0 Beta 7 or later nightly.

In both cases 2 and 3 the PHP files and database records of the obsolete postinstall messages handled by this PR are removed with the update, and the remaining messages do not contain any untranslated language strings.

I have tested this item ✅ successfully on b01f597

RTC