Upgrade database wouldn’t go away after upgrade

  • Resolved StandOutSites

    (@standoutsites)


    5 years, 7 months ago

    First of all, thank you for an awesome plugin! It rocks. Really a life saver! But I’m having a problem with it now which I can’t resolve. We have a multisite installtion, and the plugin is network activated. After the plugin updated, we get a message on each subsite to upgrade the redirection database. Everything goes fine on all sites but one. On that subsite, upgrade goes successfully, but then when I click away and go anywhere else in the dashboard, the prompt to upgrade the redirection database appears again. I’ve gone through the upgrade already 10 times, but the message wouldn’t go away. What do you recommend to do. Can I delete the redirection tables? How do I go about it. first disable plugin, delete the tables for that specific subsite and then reactivate the plugin? is there just one table or are there more and are there other entries in other tables?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter StandOutSites

    (@standoutsites)

    I want to add that we recently changed PHP version from 7.2 to 7.3. Would that coz the problem. Also just now discovered that deleting the plugin, doesn’t automatically delete the tables. I attempted to delete the tables, but now I can’t re-install the plugin. On setup I’m getting an error. 

    Message: No stage found for upgrade handle_double_slash
Installed: -
Next: 4.1
Debug:

Table "wp_29_redirection_items" is missing
Table "wp_29_redirection_groups" is missing
Table "wp_29_redirection_logs" is missing
Table "wp_29_redirection_404" is missing
Stage: handle_double_slash
    Thread Starter StandOutSites

    (@standoutsites)

    I restored the database to the moment before I delete the redirection tables, and things got worse I can not go through the redirection setup now. Keep getting the message No stage found for upgrade handle_double_slash

    Message: No stage found for upgrade handle_double_slash
Installed: -
Next: 4.1
Debug:

CREATE TABLE <code>wp_29_redirection_items</code> (
  <code>id</code> int(11) unsigned NOT NULL AUTO_INCREMENT,
  <code>url</code> mediumtext COLLATE utf8mb4_unicode_520_ci NOT NULL,
  <code>regex</code> int(11) unsigned NOT NULL DEFAULT '0',
  <code>position</code> int(11) unsigned NOT NULL DEFAULT '0',
  <code>last_count</code> int(10) unsigned NOT NULL DEFAULT '0',
  <code>last_access</code> datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  <code>group_id</code> int(11) NOT NULL DEFAULT '0',
  <code>status</code> enum('enabled','disabled') COLLATE utf8mb4_unicode_520_ci NOT NULL DEFAULT 'enabled',
  <code>action_type</code> varchar(20) COLLATE utf8mb4_unicode_520_ci NOT NULL,
  <code>action_code</code> int(11) unsigned NOT NULL,
  <code>action_data</code> mediumtext COLLATE utf8mb4_unicode_520_ci,
  <code>match_type</code> varchar(20) COLLATE utf8mb4_unicode_520_ci NOT NULL,
  <code>title</code> text COLLATE utf8mb4_unicode_520_ci,
  PRIMARY KEY (<code>id</code>),
  KEY <code>url</code> (<code>url</code>(191)),
  KEY <code>status</code> (<code>status</code>),
  KEY <code>regex</code> (<code>regex</code>),
  KEY <code>group_idpos</code> (<code>group_id</code>,<code>position</code>),
  KEY <code>group</code> (<code>group_id</code>)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci

CREATE TABLE <code>wp_29_redirection_groups</code> (
  <code>id</code> int(11) unsigned NOT NULL AUTO_INCREMENT,
  <code>name</code> varchar(50) COLLATE utf8mb4_unicode_520_ci NOT NULL,
  <code>tracking</code> int(11) NOT NULL DEFAULT '1',
  <code>module_id</code> int(11) unsigned NOT NULL DEFAULT '0',
  <code>status</code> enum('enabled','disabled') COLLATE utf8mb4_unicode_520_ci NOT NULL DEFAULT 'enabled',
  <code>position</code> int(11) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (<code>id</code>),
  KEY <code>module_id</code> (<code>module_id</code>),
  KEY <code>status</code> (<code>status</code>)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci

CREATE TABLE <code>wp_29_redirection_logs</code> (
  <code>id</code> int(11) unsigned NOT NULL AUTO_INCREMENT,
  <code>created</code> datetime NOT NULL,
  <code>url</code> mediumtext COLLATE utf8mb4_unicode_520_ci NOT NULL,
  <code>sent_to</code> mediumtext COLLATE utf8mb4_unicode_520_ci,
  <code>agent</code> mediumtext COLLATE utf8mb4_unicode_520_ci NOT NULL,
  <code>referrer</code> mediumtext COLLATE utf8mb4_unicode_520_ci,
  <code>redirection_id</code> int(11) unsigned DEFAULT NULL,
  <code>ip</code> varchar(45) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  <code>module_id</code> int(11) unsigned NOT NULL,
  <code>group_id</code> int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (<code>id</code>),
  KEY <code>created</code> (<code>created</code>),
  KEY <code>redirection_id</code> (<code>redirection_id</code>),
  KEY <code>ip</code> (<code>ip</code>),
  KEY <code>group_id</code> (<code>group_id</code>),
  KEY <code>module_id</code> (<code>module_id</code>)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci

CREATE TABLE <code>wp_29_redirection_404</code> (
  <code>id</code> int(11) unsigned NOT NULL AUTO_INCREMENT,
  <code>created</code> datetime NOT NULL,
  <code>url</code> varchar(255) COLLATE utf8mb4_unicode_520_ci NOT NULL DEFAULT '',
  <code>agent</code> varchar(255) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  <code>referrer</code> varchar(255) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  <code>ip</code> varchar(45) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  PRIMARY KEY (<code>id</code>),
  KEY <code>created</code> (<code>created</code>),
  KEY <code>url</code> (<code>url</code>(191)),
  KEY <code>referrer</code> (<code>referrer</code>(191)),
  KEY <code>ip</code> (<code>ip</code>)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci

Stage: handle_double_slash
    Plugin Author John Godley

    (@johnny5)

    You’ve got things into a very weird state. Probably the best thing is to look in your wp_29_options table and delete the row for redirection_database_stage. Then you should be able to proceed.

    Regarding the original problem this is likely caused by something being cached.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Upgrade database wouldn’t go away after upgrade’ is closed to new replies.