This issue ONLY applies to individuals who have been using the -dev version of Panels2 since the release of beta3, and have run update.php using -dev some time or another in that process. Specifically, this applies to people whose Panels db schema version is listed as either 5216 or 5217. If your schema version is 5215 (or less), you should be fine simply downloading beta4 and running update.php as normal. You can find the db schema by looking in the 'schema_version' field in the System table. If you have command line mysql access (sorry, I don't know the pgsql offhand), then this query will give you your schema version. Make sure to replace 'db name' and 'table prefix' with the appropriate values; these can be found in the settings.php file for your site:
SELECT schema_version FROM <db_name>.<table_prefix>system WHERE name = 'panels';
Update 5216 contains some new fields that went through a few different revisions, but because I changed the name and location of those fields a few times, anyone who ran one of the old versions of update 5216 will have outdated versions of these fields, and your drupal install won't know the difference (please note: this is EXACTLY why there's a big red 'X' on the -dev versions, why I removed the dev snapshot from the module download page, and why you run -dev at your own risk). Because of the way drupal's hook_update() system works, there's no way for me to know when you ran the original update, and therefore no way for me to know what wrong version of these fields you have, and therefore no way for me to write a scripted solution that will solve everyone's problems. You need to sort it out yourself.
The basic task is ensuring that the tables defined in hook_install() of panels.install are exactly the same as the ones you've got operating in your current install. For figuring that out, your best buddy is DESCRIBE. Specifically, there are two tables that there could be problems with: panels_display and panels_pane. Below is what we want the output of DESCRIBE panels.panels_pane; (which is the syntax for my local sandbox - MAKE SURE to replace it with the db/table prefixes appropriate to your install) to look like:
+---------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+-------+
| pid | int(10) | NO | PRI | 0 | |
| did | int(10) | NO | MUL | 0 | |
| panel | varchar(32) | YES | | NULL | |
| type | varchar(32) | YES | | NULL | |
| subtype | varchar(64) | YES | | NULL | |
| shown | int(1) | YES | | 1 | |
| access | varchar(128) | YES | | NULL | |
| visibility | text | YES | | NULL | |
| configuration | longtext | YES | | NULL | |
| cache | longtext | YES | | NULL | |
| position | int(5) | YES | | NULL | |
+---------------+--------------+------+-----+---------+-------+
11 rows in set (0.00 sec)
And, the output for DESCRIBE panels.panels_display;:
+-----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| did | int(10) | NO | PRI | 0 | |
| layout | varchar(32) | YES | | NULL | |
| layout_settings | longtext | YES | | NULL | |
| panel_settings | longtext | YES | | NULL | |
| cache | text | YES | | NULL | |
| title | varchar(128) | YES | | NULL | |
| hide_title | int(1) | YES | | NULL | |
+-----------------+--------------+------+-----+---------+-------+
7 rows in set (0.03 sec)
The only discrepancies I expect people to see are the presence of a 'hidden' field in either panels_pane, panels_display, or both, as well as possibly the absence of a 'shown' field in panels_pane. Dropping the 'hidden' fields isn't absolutely necessary, as they're inactive, but if you don't have a 'shown' field, then none of your panes will ever show up. Ever. So, as needed, you should execute some/all of the following three queries:
ALTER TABLE <db_name>.<table_prefix>panels_display DROP COLUMN hidden;
ALTER TABLE <db_name>.<table_prefix>panels_pane DROP COLUMN hidden;
ALTER TABLE <db_name>.<table_prefix>panels_pane ADD COLUMN shown int(1) DEFAULT 1 AFTER subtype;
Again, make sure to substitute the values appropriate to your environment for <db_name> and <table_prefix>. If you follow all these steps carefully, then you should be hunky-dory.
It's important to note that this is not a 'bug' in Panels, and NOT something you can expect to work differently in the future, as it is the result of the Panels developers using the drupal project release system as intended. If this issue applies to you, it is because you _chose_ to run the -dev version rather than the recommended release. The -dev version was, is, and always will be unsupported, which means you use it at your own risk.
Comments
Comment #1
messenger commentedthanks for this info, in my case I was missing the visibility field in panels.panels.pane. This post got me pointed in the right direction for a fix.
thanks!