0

Whilst trying to update Drupal 7.0 core and installed modules using Drush 4.x I appear to have broken a project site (Ubuntu 11.04 box using pure LAMP) and hence I get the dreaded 'white screen' so cannot get past it or get into the backend of the site. I would like to simply get D7 core/and all current modules (which there is a good 40 modules or so) updated and back working. It is a project for learning but I have done a good fair amount of work on it over the past 6 months and really I don't want to trash the mySQL DB and start all over again as I'll lose a fair amount of hours work. Can anyone provide a Drush command to get it back up and running whilst also updating the D7 core/modules and get it back on track. I understand the concept of the Drush CLI, but am really a 'learning' novice at present across all of the Drupal framework. The modules included are the general Panels/Rules/Views (PRV) etc along with Ubercart and subscriptions etc so a fair amount of PRV work has already been done.

I also get the following:

PHP Fatal error: Class 'RulesIdentifiableDataWrapper' not found in /var/www/sitename/sites/all/modules/flag/flag.rules.inc on line 27 Drush command terminated abnormally due to an unrecoverable error.

So what do I do now??, I really don't want to start the whole project all over again after spending a good 6 months on this project.

Concluding: The whole process trashed my project site. Some 6 months work (with a lot of typing input) may have gone. the mySQL tables are still there and the data has been backed up, but whether I can get d7.14 and the current used modules and all the P/R/V and Ubercart user subscrition data to work is still to be seen. I'm sure this is NOT the way to be efficient in web building and management.

1 Answer 1

1

It's best practice to always backup your database first when updating modules (especially when working with -dev versions). A useful module is Backup and Migrate, when installed it also provides a Drush command to backup the database (drush bb). (But avoid GZ compression at the moment, bug introduced with version 2.3). Since you currently have a fatal error, you'll probably have to make a backup of your database via your database management tool in Ubuntu, or use something like phpMyAdmin. You should also note which modules you will update and what the currently installed versions are. If you do all upgrading via Drush, it creates a backup of all modules it updates (so you don't have to keep track manually), and if something goes really wrong you can go back to the previously working code and if necessary put your backed-up database in place.

It looks like the current version of your Flag module is throwing the fatal error which is preventing you from updating / accessing the site. I assume this is still an old version (cf. e.g. this report), and it's likely that if you put the latest recommended relase of Flag in place the error goes away (remove the current flag module folder and replace with the 7.x-2.0-beta6 version). (If this doesn't solve the Fatal error, you should provide some more details on what versions of Flag and Rules you were using previously, and what version they are at now).

Once you get the site back working, it's a matter of doing the regular Drush commands from your Drupal directory. For example:

# If you have many sites you can check to make sure you're working on the right site
drush status

# update all modules but not Drupal core
drush up --no-core

# make sure update.php is run (in my experience sometimes some updates aren't run)
drush updatedb

Now check that your site is still working properly and then update Drupal core.

drush up drupal

And check your site again. The status report will show you if all modules and themes are up to date and if there are any database upgrades that still have to be executed.

For more info on Drush also check out drush.org.

8
  • Thank you for your prompt response Arjan. Indeed DB backups I appreciate are always 100% essential, and did so yesterday, but now I cannot get into the D7 backend due to a frontend white screen. Flag was an older version along with many others including the D7 at v7.0. Being a newbie with some basic knowledge and trying to get upto speed with Drupal upgrade adin, I took the Drush and this morning it corrupted what was even, though an old version, site a working one at that. I could try simply deleting the whole flag DIR on my lampbox, seems nothing left to lose now except recent changes. ))-:
    – Paul B
    Commented May 19, 2012 at 13:11
  • Alas no joy, neither of your suggestions work. I have read drush.org previously and cannot find a solution.
    – Paul B
    Commented May 19, 2012 at 13:20
  • What Drush commands did you execute? It's possible that while doing these updates the combination of different versions created a problem, or the order in which modules were upgraded in your particular case was problematic. But it doesn't look like the database itself would be corrupted (so you can still do a backup from phpMyAdmin), it's just that Drupal tries to execute all the current code, and the error prevents it from continuing. So try removing the flag module and then putting the current version in there (Drupal expects to find that module).
    – arjan
    Commented May 19, 2012 at 13:21
  • Ive been at this since 11.00gmt, and today never made any paper notes. Looking at my Drush log, can't see at the moment what I did but it was nothing more than drush up etc in the site's home. ( I have multiple projects running all separate d7 installs, mostly for forthcoming commercial projects off my own bat. God help us supporting D7 then me thinks!!). As stated else where I'm a newbie upskilling for Drupal projects but off my own bat. I'll try the delete Flag DIR now see if Drush ignores it, would rather fix than trash 6 weeks work prior to last major SQL backup.
    – Paul B
    Commented May 19, 2012 at 13:31
  • So you currently have the current Flag in the modules folder? Try clearing the cache. You can try drush cc all (this may not work due to the error, but try it a couple of times anyway. I've sometimes had it work only after several tries in similar situations). Otherwise you can manually empty cache tables (Truncate), e.g. from phpMyAdmin.
    – arjan
    Commented May 19, 2012 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.