? For long time I have been wondering why simple feature like this had not been implemented. There are times where updating fails on some unknown and maybe even temporary error and that for the most users mean incomplete update even after fixing the database. For example upgrading older J3 to J3.5+ was problematic if you used default opcache settings (it failed on an error because of old version of JVersion was being used).

See following screenshots about the expected results:

1. Extensions -> Manage -> Discover
   

2. Extensions -> Manage -> Database
   

   ---

   _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17146.}

@BastianWie Would this PR here be Ok for you, too?

@mbabker Please let me know your opinion.

@brianteeman If you find time, please check the texts. And of course your general opinion on this is welcome, too.

@brianteeman I am almost sure you will not like the <br /><br /> in the texts, and that you would like to have the texts shorter. I thought it is more readable like it is now, and I wanted to describe things as clearly as possible within that little space, but if you want I will change that. And maybe the button names should be in strong letters?

Sorry but I dont see the point in writing code to support people who chose not to update joomla with the provided and supported tools.

Well, it still could help people who used the right method where the update has timed out or been aborted for some other reason. It is at least a better way out than the database fixer for the reasons mentioned in the description.

And this is different from the Upload & Update tab in the install component how?

It is less likely to timeout because of slow uploads.

@mbabker It does the same as your script Post-Manual Update Script does.

@richard67 yes that looks usefull for the users/admins.

Seems I have 2 pros and 2 cons up to now. Of course it already can be tested.

Honestly, I really hate the fact we keep turning what is supposed to be a database status page into the one stop shop to fix all of your core issues. And honestly, if you're having issues with timeouts because of the package download or uploading to a crap server, that's a scenario where you should just use my script. The project does not support upgrades outside of our update component. We shouldn't be stepping backwards to support 1.5 style manual upgrades again.

@mbabker In general I share your opinion, but again and again reading issues and forum posts related to broken updates made me feel the need to propose this here as a workaround until the database manager is able to fix broken updates in a better way or there is another real solution. For me the existing methods and 1 time in past your script after I had an incomplete update caused by PHP 7 opcache problems were sufficient. But I thought for people who don't know about your script it could be helpful to have something more visible.

Anyway I will accept any opinion and especially of PLT or other responsibles and have no problems to close this PR if there is no acceptance.

This just encourages people not to use the installer

The database fix stuff isn't broken. We as a project have misused that resource since the day the underlying API was introduced and we continue to fail to address procedural (and inherently architectural).

We as a project also failed in turning the database status page into a one stop shop for fixing all the things. The database fix button no longer just attempts to get your database schema to the required state; it includes two function calls to code in other components that is in no way related to schema updates (the remove deleted files function and purging the core update check record in the updates table).

We really need to stop monkey patching things and fix our core issues the right way. Yes, that is going to mean retraining users/contributors and breaking muscle memory. Yes that is going to mean for once a code related issue is going to have to get priority over whether buttons in the toolbar are too wide or the drop shadow the status module creates.

For me, Upload & Update is the biggest compromise we can make as far as supporting manual upgrades. We should not introduce something into the UI that even gives the impression to a user they can do a 1.5 style manual upgrade, click a button, and everyone be rainbows and unicorns happy. Our update process is too complicated for that, compounded by the project's misuse of resources resulting in some of our changes breaking sites (every INSERT/DELETE statement we have in our update SQL files for the menu table has resulted in the corruption of the nested tree model in that table as an example).

I hope in J4 we wont repeat these mistakes of the past

@mbabker @brianteeman And how about showing the message somewhere with a link to the upload and install tab of the update component in case if an incomplete update was detected? Would that be ok for you, i.e. you only dislike the buttons? Or you dislike any help for the people who are in that kind of trouble?

@brianteeman @mbabker I try it again with my question before I will close this PR here:

How would it be show show a message in the database checker view and the discover extensions view if an incomplete update was detected?

Only show a warning message telling that it could be fixed with the Joomla Update component, installing Joomla files again using the Upload & Install way, nothing else?

Revisiting this RFC I still don't think this is something that should be accepted