After #2233403: Let update.php invoke hooks again and now that update.php doesn't have any major update responsibilities, we could run update.php in a full environment.
Copy/pasting from #2233403-30: Let update.php invoke hooks again
Since we don't need to support major updates, if we wanted a full environment we could do the following:
1. Move it from a separate file to just a route.
2. Have that route
- (optionally?) put the site into maintenance mode
- collect updates + figure out order/dependencies similar to now
- run the updates in a batch
Would simplify the update runner a lot.
If you had an update that's going to completely break an install, then you'd need to tell people to do an 8-8 migration.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | interdiff-2250119.txt | 2.34 KB | ParisLiakos |
| #15 | drupal-update_php_route-2250119-15.patch | 70.33 KB | ParisLiakos |
| #12 | drupal-update_php_route-2250119-12.patch | 69.96 KB | devin carlson |
| #8 | drupal-update_php_route-2250119-8.patch | 70.91 KB | ParisLiakos |
| #8 | interdiff.txt | 15.91 KB | ParisLiakos |
Comments
Comment #1
catchHas to happen before release because:
1. it's a UI change
2. It'll be subtle API changes for update handlers
3. I'm not convinced update.php even works right now - given we removed all the core updates we only have some very limited test coverage.
Comment #2
catchAlso beta target since at that point modules can theoretically add hook_update_N().
Comment #3
ParisLiakos commentedI already started working on this locally
Comment #4
ParisLiakos commentedlets see what bot says
Comment #5
ParisLiakos commentedhm, last patch was incomplete, disregard
Comment #8
ParisLiakos commentedalright.
thats a lot of deletions :)
Comment #9
catchComment #10
moshe weitzman commentedJust seeing this. I'm happy to review it, if we can get a reroll. No chance it still works as well as it did in June. Thanks!
Comment #11
ParisLiakos commentedwont be able to reroll till i am back, next week
Comment #12
devin carlson commentedAttempting a reroll. The only change is that DbUpdateNegotiator's methods are now passed
$route_matchinstead of$request.Comment #13
moshe weitzman commentedThanks! Just minor nits.
Seems like this could use theme_item_list(). NIH so can be a follow-up
$op needs Doxygen
NIH, as of D7 we display messages, not queries. Would be nice to clean up code comment and variable name.
Comment #14
andypostFor #13.1 #1222254: Remove theme_task_list() and call theme('item_list__tasks') instead.
Comment #15
ParisLiakos commentedthanks moshe for the review and Devin for the reroll!
Comment #16
moshe weitzman commentedThx for fixing up the nits. This one is ready.
Comment #17
catchLooks good, nice to get this in sooner than later so we can be running with this when we start to add minor updates. Committed/pushed to 8.0.x, thanks!
Comment #19
scor commentedDoesn't look like UPGRADE.txt was updated with this patch. It's still referring to update.php.Nevermind, didn't realize the path was added to system.routing.yml and remained the same to match the old update.php file.
Comment #21
kay_v commentedLooks like update.php file is removed from /core directory and example.com/update.php returns a 404. As things stand, to invoke a database update, users need to add a trailing slash (example.com/update.php/ will work where example.com/update.php with no trailing slash returns 404).
I've poked around the issue queue a fair bit without seeing specific discussion. Looks like @scor's comment above suggests path shouldn't have special requirements. Anyone know whether there's more to consider?
Since the unique requirement may lead to some confusion, I've opened an new issue #2353907: update.php requires trailing slash or returns 404 with nginx and related it to this one.