Delete Protostar template.

How did you delete it?

I uninstalled it from backend
Edit: Have edited the original post.

Change default template to Cassiopeia

This change should not have bee necessary after a successful update. The database updates should have done that for you if Protostar or Beez3 was the default template before the update. Has that been the case?

I can confirm the problem and there is at ;least one other open issue here about this

When you uninstall a template it does NOT remove the database entry for any overrides for that template in #__template_overrides.

As a result the count on the quickicon does not change.

This site was a j3 site that has now been updated to j4

Before

After uninstalling the template (called editor)

It probably needs the following code to be added to the finaliseUninstall function in the TemplateAdapter but that will not fix existing problems

        // Remove any overrides
        $query = $db->getQuery(true)
            ->delete($db->quoteName('#__template_overrides'))
            ->where($db->quoteName('template') . ' = :template')
            ->bind(':template', $element);
        $db->setQuery($query);
        $db->execute();

What will fix the existing problem?, Do I need too fiddle with the database? If what do I need to do?

What will fix the existing problem?, Do I need too fiddle with the database? If what do I need to do?

You could use following SQL statements in PhpMyAdmin to clean it up (replace the #__ by your actual database prefix):

DELETE FROM `#__template_overrides` WHERE `template` NOT IN (SELECT `name` FROM `#__extensions` WHERE `type`='template');

@richard67 will that query work if I put it in an update sql

If so then I will create a PR with the query AND the ammended code to make sure they are removed on uninstall

@richard67 will that query work if I put it in an update sql

If so then I will create a PR with the query AND the ammended code to make sure they are removed on uninstall

@brianteeman It will work with an update SQL, but an update SQL would not be the right place because if someone updates to a version so it is run and then later deletes the template, they have the problem again, and the update SQL will not run anymore because older than the database schema version.

I.e. the problem can happen at any time on any version, and not only at a particular version.

Therefore it should not be added to any update SQL script but to a procedure in script.php which runs at the end of each update.

Another possibility would be to add it to the database checker and fixer so it runs only if such a problem was detected, using a pre-defined check and update query similar to the utf8mb4 check we still have.

If that is the way to go, I would prefer that it's me who implements it because there are not many other people who know in detail how the database checker works.

P.S.: But I won't have time before the weekend to do anything.

dont worry its a combination pr. #38714 just writing the test isnstructions

P.P.S.: Of course if we can make sure the problem does not happen again, we can make an update SQL script which runs when updating to the version with that fix, and later we won't need it again. But as soon as the delete statement on template uninstallation fails for some reason, the problem will be back.

So maybe do a PR with both things now, and later when we implement the health check (was somewhere on the road map for a future version) we can add a check for that.

dont worry its a combination pr. #38714 just writing the test isnstructions

@brianteeman Yes, we can do that. The PR looks ok to me.

Please test #38714

Closing as having a pull request. Please test #38714 . Thanks in advance.