PHP error when uninstalling Panels

You running pgsql?

Also, just want to make sure you're aware that there are some serious potential hazards inherent in running -dev, as I detail #262525: Updating from 5.x-2.x-beta3-dev to beta4. If you do a mid-dev update.php that screws your schema, we really can't help.

This is caused by panels_mini_uninstall() in panels_mini.install.

The table panels_display has already been dropped, but Panels Mini tries to remove its displays.

doh! thanks sun. I was wondering what I was missing...

@sun

thanks, bud. committed.

@Fayna -

Yeah, running -dev will _always_ be a hazard for this reason. For a lot of contrib modules it's not going to matter 95% of the time (and to make matters worse, some module authors simply expect you to run -dev), but when it comes to the way that you're technically supposed to do it...they're all wrong :) Here's why.

For every module you have present in a directory where drupal can read it (i.e., /modules, sites/*/modules/) Drupal keeps track of the current 'schema version.' The schema version are those arbitrary-seeming numbers you see when you run update.php; aside from the fact that the first number is supposed to correlate with the drupal major version (which many module authors don't bother with), there's no correlation _whatsoever_ between the schema version and any other version information about the module. The schema version has exactly one purpose: to allow drupal to keep track of when there are updates that need to be made to the database for a given module.

Let's use Panels as our example: if you were running beta5, even on a fresh install, then drupal would know that your current schema version is 5217. That's because when it's first installed, drupal goes through all the functions of the form 'panels_update_####()' in panels.install and picks out the highest number, then assigns that as your schema version. So when update.php is run, drupal does a compare between the value in the db and the highest available update #. If there's a difference, it (by default) will pop up the latest schema version number in that dropdown box.

The key thing here is that drupal has no clue - at least in D5 - about what's actually IN those update functions. The only thing it knows is the schema version numbers. That's where the risk of running -dev comes in: most modules don't need to do schema updates that often. Some modules don't even need a .install file at all. When those modules do need to make an update, though, they tend to write the changes in, commit them, and never change things around later before making an actual release. If you're running -dev and run update.php to get one such new update that they've added, then you're fine - as long as they don't change the contents of that update function _after_ you've already run update.php. If they change that update function after having already made a release with that update function in it, then they're breaking a cardinal drupal rule and are just bad maintainers.

Panels doesn't/can't/won't guarantee that any given update function is set in stone UNTIL it's been included in a release. There are several reasons for that, even though we technically don't _need_ a reason - code in -dev is by definition in flux. But it happens fairly frequently that we'll commit a new panels_update_####() function - say, like panels_update_5218() - then decide we need to change something in it and so change around or even wholly eliminate that function. No harm no foul, unless someone is running -dev and has run update.php on 5218. If they do that, then they'll be in a pickle - drupal _thinks_ it has schema version 5218 installed, but it has no idea that its schema v. 5218 is actually wrong. By the time we actually release the next version with the final 5218 schema in it, the version of the function you used to upgrade is either different or COMPLETELY gone, retrievable only in some obscure diff from version control. The only way the even the Panels devs would be able to help you in figuring out how to solve your problem would be if you happened to remember the exact day and time when you downloaded -dev, so that we could have a look at the exact version you updated from, figure out how to roll back the bad changes, manually roll back your last good db schema version (UPDATE {system} SET schema = 5217 WHERE name = 'panels'), and then you could hopefully proceed forward. Of course, depending on what was actually in the bad update, it could be entirely impossible to recreate your db prior to the update, short of you restoring a backup.

I wrote #262525: Updating from 5.x-2.x-beta3-dev to beta4 as a courtesy - and a means of maintaining my own sanity ;) - because a lot of people had been running -dev during the beta3 => beta4 period. But hopefully that all explains why I pretty much flatly refuse to help when people run update.php on -dev.

So, moral of the story: feel free to run -dev versions, but only run update.php on them if you want a one-way ticket to drupal hell :)

Thanks, that was worth reading. =) However, the common practice is to manifest module updates in development versions, too. Bug fixes are always happening, but db updates should never be removed, replaced or extended. If the most recent update is obsolete, just nuke the update function's contents (to ensure the next will get a new schema version). Aside from that, Drupal's update system is also able to run updates that are not numbered in sequence (i.e. 5201, 5202, 5206, ...). If an update is missing in a function, there should always be a new update function to execute the missing updates.

Anyway, I'm glad you mentioned this, because I know that we need to check for altered update functions now.

sdboyer, that's a fascinating rundown.

If I understand you correctly, while it's a Really Bad Idea to run update.php on -dev, it should be fine to disable previous version, uninstall, upload, enable/install new version. Do I understand?

@sun - Thanks :) I'm not 100% clear on what you mean, but it seems to me that you're saying that _EVEN_ for -dev versions, once the update to a new schema version has been committed, it's set in stone. Or maybe not, because you also talk about gutting update functions that are wrong then using the next update schema - let's call it update N. But that would still screw people who run update.php on -dev and update using an update function that gets rolled back before a release is made. Even if the proper update function is put into a subsequent update N+1, their db is still potentially out of sync, b/c they should be going from N - 1 to N + 1, and N + 1 can't deal with changes made to N if N no longer exists. Or if it does, then we're including old crufty code that shouldn't be there. Plus, this is all under the assumption that the mistakes made in N are _recoverable_ mistakes - what if (lol) you accidentally dropped a table in update N? Duplicating that in the first half of N+1 just screws everyone because no matter how much dancing you do in the second half of N+1, it's still borked. No, I can't see any possible way that that's a policy that could work.

Err, that's a weird circle, but it made sense in my head. Bottom line is that I am rock-solid on not changing update functions once they actually are released, precisely because once we do that, we abandon all hope of symmetry between what we think a person's db structure will be and what it actually is. But I'd also never submit to a convention that once it's in -dev, it's there to stay - that's just silly. It's -dev. In my mind, it is by definition unstable and subject to change - the moment that it becomes stable is the moment that it gets released (barring some other factor).

@escoles - Thanks! yep, that's a great distillation of my whole story: it is a Really Bad Idea (I like that!) to run update.php on -dev. There's a decent chance you wouldn't even need to disable the old version when you install the new one (BUT DO NOT UNINSTALL IT! Any module worth its salt will drop the tables it created on uninstall and remove all entries in the variables table - meaning you'd be starting from a blank, unrecoverable slate when you put the new version in and enable it). Assuming that the changes in -dev don't absolutely require those db alterations, or that you're not touching the parts of the module that do, you're perfectly safe downloading and installing the -dev tarball, so long as you don't run update.php.

...perfectly safe, probably 85% of the time :) Most of the changes that are made in db updates are of a type where what I say here will hold true. But not always. Which is why running -dev is always risky business. Things that restructure the actual data in the fields without altering table structure (see, for example, the last update in http://drupal.org/project/og_collections, although that doesn't quite fit the bill because it's designed to move peoples' data over to og_blueprints) can be a problem, because presumably once that stuff has been written, the code of the module WILL expect the different data, and can choke in all sorts of ways if it doesn't get what it expects, and maybe even start ripping holes in your db data. Who knows what could happen. Godzilla and Mothra might come out to play. Which is why I so often refer to my original decision to remove the -dev tarball of Panels2 from the project page ;)

This post just gave me nightmares.