Problem/Motivation

Any sites that upgraded from the defunct Metatags (plural) module from 2011, and who did not uninstall the module properly, end up with a {metatag} table that is out of date and causes the site to error out on pretty much every page load. A key problem problem with resolving this is that it can't be resolved during hook_install() as the schema will already be loaded; besides which, it could involve a lot of data manipulation and there's no way of running the Batch API during hook_install().

Proposed resolution

Either:

  1. Use hook_requirements to check if the tables already exist and are not up to spec, delete the tables if they are empty or rename them if they contain data; this would need a follow-on task to provide some method of importing/migrating the data.
  2. Do something similar only from hook_schema().
  3. Do nothing. This isn't a particularly good idea as it leaves sites potentially broken.
  4. Other ideas?

Remaining tasks

  1. Identify the best approach to take.
  2. Build & test a patch.

User interface changes

Unsure.

Original report by @username

I have usedon a long develop website metags (That was 6 month ago).
Today I have mistakely download metatag to /modules as well and even instal it!
When I have discoverd I unintall metatags and delete the module files + clear cache.
Then I reinstal metatag, run update.php and it's seems fine.
But - I get fatal error on all pages except admin pages.

The error in the log messeges:
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'instance' in 'where clause': SELECT t__0.* FROM {metatag_config} t__0 WHERE (instance IN (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2)) ; Array ( [:db_condition_placeholder_0] => node:page [:db_condition_placeholder_1] => node [:db_condition_placeholder_2] => global ) in ctools_export_load_object() (line 427 of /home/maayan/public_html/sites/all/modules/ctools/includes/export.inc).

Any idea?

CommentFileSizeAuthor
#14 metatag-n1391554-14.patch2.69 KBdamienmckenna

Comments

dave reid’s picture

Category: bug » support

Did you uninstall the module via admin/modules/uninstall before you deleted the module files?

amirtaiar’s picture

Yes.
I disabled the module >> then admin/module/uninstall >> delete the file.

damienmckenna’s picture

Title: Fatal error after swithing between metatags to metatag » Fatal error after switching between metatags to metatag
Category: support » bug
Status: Active » Postponed (maintainer needs more info)

@amirtaiar: Sorry for the lack of response. How were you able to resolve the problem?

damienmckenna’s picture

Title: Fatal error after switching between metatags to metatag » Fatal error after switching from metatags to metatag
Status: Postponed (maintainer needs more info) » Active

It might be worth adding something to the install script to look for an old schema.

damienmckenna’s picture

Thinking through it I'm not sure that would work - the installation will fail as the table already exists, which would cause it to not run any hook_install function.. maybe a custom task to be fired from hook_requirements? Hrm..

damienmckenna’s picture

Priority: Normal » Minor
Status: Active » Postponed

Reviewing the codebase, the only time that the metatag_config table did *not* have an "instance" field was v7.x-1.0-unstable1 from August 16th, 2011, i.e. the very first basebones release of the module when it had only ten commits, and it was changed 13 days later on August 29th.

I'm not going to work on this right now, but if anyone wants to put some work into it I'd be happy to include any working patches.

damienmckenna’s picture

Title: Fatal error after switching from metatags to metatag » Fatal error after switching from Metatags to Metatag
Issue summary: View changes
Priority: Minor » Normal
Status: Postponed » Active
Parent issue: » #2175021: META: Plan for Metatag 7.x-1.0-rc1 release
Related issues: +#2177455: Updates not running correctly when updating to beta9
damienmckenna’s picture

I'm proposing adding code to hook_install that either:

  1. Fixes the old tables:
    • Checks to see if the {metatag} table already exists, if it does then it fixes the table.
    • Checks to see if the {metatag_config} table already exists, if it does then it fixes the table.
  2. Deletes the old tables:
    • Checks to see if the {metatag} or {metatag_config} tables already exists, if they do they're removed

Any thoughts on which path to take?

damienmckenna’s picture

A third option would be:

  1. Rename the existing tables to something else, e.g. {metatag} becomes {metatag_old}.
damienmckenna’s picture

Bumping this to 1.0 so that 1.0-rc1 can be released pronto.

damienmckenna’s picture

I'm honestly not sure how to do this. I think renaming the tables might be the best option, but the question is - where to do so? During hook_requirements() where $phase == 'install'? It wouldn't work during hook_install() as the schema will already have been loaded.

damienmckenna’s picture

Issue summary: View changes

I've updated the issue summary.

greg boggs’s picture

A 4th option which would be good if no other option has been completed, detect the old tables and link to this page that explains the problem and the work needed to resolve it.

damienmckenna’s picture

Status: Active » Needs review
StatusFileSize
new2.69 KB

Hows about this? It checks during hook_requirements() when $phase == 'install' - if the table is found and is missing one of the columns it will rename the table, but if the table is empty is imply removes it.

damienmckenna’s picture

Other considerations:

  • Expand it with a variable that keeps track of whether the table was renamed, so that it can be dealt with later.
  • Add an item to hook_requirements() for when $phase == 'runtime' that informs the site builder that the table was renamed.

  • DamienMcKenna committed 6c79464 on 7.x-1.x
    Issue #1391554 by DamienMcKenna: Handle scenarios where the legacy...
damienmckenna’s picture

Status: Needs review » Fixed

Committed. This will at least prevent sites blowing up and it can be improved upon later.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.