After after running update.php we see the cheery message:

Updates were attempted. If you see no failures below, you may proceed happily to the administration pages. Otherwise, you may need to update your database manually. All errors have been logged.

But we have no guidance for users who do see failures below, and who need to (less happily) update their database manually. I'm willing to write such a page, probably somewhere in http://drupal.org/Troubleshooting-FAQ , but I haven't the knowledge of what should be there.

It should probably start with a few pointers on how to get at your database (for instance Cpanel or command line + http://dev.mysql.com/doc/index.html).

Some concrete questions:

When I ran into this problem earlier today (fixed now, thanks to mdixoncm), there were a lot more error messages on the landing page I got to after update.php, than in the log. I assume both sets are relevant, and that the user should copy them all to a text file before doing anything else. Correct? Or can the user assume that all she needs to know is in the log?

When error messages on the landing page give "Failed: CREATE TABLE {something}, the user can look for the table. If it exists, can she assume that this isn't a problem, and ignore that error message?
If it doesn't exist, what should she do?

What about messages like "Failed: INSERT INTO {table name} (lots of stuff...}"
What should the user do about those?

Or am I following the wrong track here, and any general advice should be on different tracks?

Comments

robbiethegeek’s picture

robbiethegeek commented

After thinking about this issue I think that there may need some re-wording of the error message from:

Otherwise, you may need to update your database manually

to something like:

If you are seeing errors below, please check the issue queue of the module who's update failed. (With the module that failed)

tamlin’s picture

tamlin commented
Version: » 6.x-1.x-dev

I'd like to know how to run update.php when "Database schema" on the logs page says: "Up to date"

I have two Drupal sites running on my server with different databases. To conserve disk space I have symlinked the addon module folders (not the core modules, though I don't know if that makes any difference.) so I only have one copy of each.
This has been working fine until I needed to upgrade User_Mailman_Register, it needs to add a 'version' field to the drupal_maiman_lists table. On the first installation update.php ran correctly and everything is good. However, the second install thinks that everything is fine too, but I haven't run the update on it yet and get error messages complaining that the 'version' field doesn't exist. Which of course it doesn't because I haven't run the update on that installation yet. How do I force update to run? or will that not work as it won't know what it needs to do?

P.S. I'm running 5.x not 6.x
---

Solved:

update.php can be run from the Administer->Site building->modules page

(I actually stuffed up my tables trying to do it manually before I found this, and consequently update.php failed. I ended up copying the table structure from the installation that had worked. All seems fine now.)

a.bond’s picture

a.bond commented
Version: 6.x-1.x-dev »

My update.php has failed and in a week no one's seen fit to actually help me. Can anyone help me do a manual update?

zirvap’s picture

zirvap commented
Assigned: zirvap » Unassigned

I guess I'd better un-assign myself from this issue, as I don't have the knowledge to solve it.

leehunter’s picture

leehunter commented
Component: New documentation » API documentation files
jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented
Title: How to update your database manually when update.php fails » No information on how to update your database manually when update.php fails
Project: Documentation » Drupal core
Version: » 8.4.x-dev
Component: API documentation files » database update system
Category: Task » Bug report

This is a message generated by Drupal Core. It needs to be fixed there if it's still an issue.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

martinma’s picture

martinma commented
Category: Bug report » Feature request
Status: Active » Needs work

Its a feature request, not a bug ...

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

smustgrave commented
Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!