This time, I examined the update.php results page properly, after another of my testing 5.x->6.x upgrades. I noticed that several updates claim to have no queries (or no action in more loose understanding) executed, which is either not true, or a reason to remove them. I looked at this closer, and found that:
- Several update functions were really empty (leftovers from further changes after they were introduced). Apparently, people got used to turn removed updates into so called "no-op" empty functions, but this makes no sense as I see it: The numbering of updates is NOT required to be continuous, there may well be a hole. So no need to have empty updates, hanging around on the update.php screens (results page especially). So I removed these, leaving just comments at their original places: system_update_6004(), system_update_6012(), system_update_6028().
- Additionally, system_update_6031() was a duplicate of system_update_6014(), so I removed it too.
- Other update functions in fact performed some tasks, but returned no messages. Although the exact queries executed are not available (due to nature of these functions), it's still useful to return some sensible message. This is not new: system_update_6017() already reports executed variable_set() calls and the like, system_update_6021() says "Relocated xxx existing items to the new menu system." instead of listing all the queries.
I think it's really necessary to add some messages to all updates, so that the update.php results page (copied to a clipboard, for example) may be later analyzed for troubleshooting purposes, to find what exactly happened, and where this or that change was introduced (i.e. on update, or somewhere else in code). Otherwise, we might as well nuke that page entirely, and only show failed queriers. Currently the update process silently hides such changes, as enabling a new module (dblog), or adding new filters to my existing input formats (HTML corrector), which is not nice. So I added such messages to system_update_6013(), system_update_6014(), system_update_6018(), system_update_6029(), and comment_update_6002().
- Along the way, I found one apparently broken message in system_update_6018(), where a plain string was returned instead of proper array structure, even using a t() call (which is generally not used in updates as I understand it).
- Also update.php was using a t() on one place (only one). I see that the update.php script is not translatable and uses no t() calls, so this should be consistent. Also using a t() there is not a good idea, because the locale module itself is a subject to updates, so if the script is ever going to be translatable, it should use something along the lines of st() as I see it. Additionally, there's no need to clutter the runtime translations database with update.php strings.
This change is not random from me: I often got a weird message at the very end of updates, when there was just 1 item left, and although I didn't track it down exactly (quite difficult in that exact location), I ran into this t() misuse on that very message. (And surprisingly, it seems to fix my problem, although it might be as well random move of the percentage with other changes in this patch.)
|update-messages.patch||4.93 KB||Ignored: Check issue status.||None||None|