Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
function _system_update_utf8()
says:
* This update is designed to be re-usable by contrib modules and is
* used by system_update_169().
system_update_169() is gone, so should this be.
I'm fairly sure there's few remaining use cases for this in contrib - but if it turns out there are then the code comments need a refresh.
Comment | File | Size | Author |
---|---|---|---|
cruft.patch | 1.94 KB | catch | |
Comments
Comment #1
catchA quick check around core, and I can't see anything referring to system_update_n() lower than 4.7 - and every bit of code mentioning 4.6 is gone now, so hopefully this really is the last one.
Comment #2
Gábor HojtsyThanks, committed. This again makes the installer lighter which is always good :)
Comment #3
JirkaRybka CreditAttribution: JirkaRybka commentedSidenote: This utf8 update (along with another bit inside update.php - not sure whether it's still in there) is needed for MySQL update to 4.1, and so is Drupal-version independent. It seems rather weird to me that it was only supported on the 4.6.x update (so users who upgraded MySQL back then got a fix, while users on shared hostings with a bit slower upgrade turnaround didn't get the fix later, and so ran into serious problems, as often seen in support requests). Another boom of need for utf8 updates is going to happen on 5.x->6.x upgrades, because 6.x is the first one not only *supporting*, but really *requiring* 4.1 minimum (MySQL), so people are going to switch servers and the like. There were some code-snippets circulating in the past, to help these users, which used to rely on this now removed function.
But luckily, this is now solved elsewhere - now we have a handbook page on this, with a stand-alone helper script (I participated on that myself), which fixes the problem better, and luckily doesn't rely on the helper fucntions in core. So the removal is OK now, indeed.
Just adding more insight here, otherwise this issue stays as Fixed :)
Comment #4
Gábor HojtsySo since when do we require MySQL 4.1?
Comment #5
JirkaRybka CreditAttribution: JirkaRybka commented6.x-dev (system.module):
define('DRUPAL_MINIMUM_MYSQL', '4.1.0');
5.x:
My site is pretty happy on a shared hosting, which runs 4.0.x. http://drupal.org/requirements mentions even 3.23.17 as acceptable (page categorized as 4.7.x + 5.x).
So I believe 6.x is the first, thus enforcing upgrades/migrations to 4.1+ servers. But as I said earlier, we managed to put a solution into Troubleshooting FAQ (+contrib sandbox) in-time, so the old hacks relying on here-removed stuff are no more needed (and frankly, never worked too well, failing on prefixed tables, php timeouts and the like, and lacking necessary documentation of what they do and what they do not.) http://drupal.org/node/187689 is where we discussed that.
Comment #6
catchJanuary:
http://drupal.org/node/105855#comment-484340
(that took ages)
Comment #7
(not verified) CreditAttribution: commentedAutomatically closed -- issue fixed for two weeks with no activity.