• On Sunday I tried to update the Ninja Forms plugin (2.6.5–>2.9.6) after updating WordPress (3.9.5–>4.2). The upgrades to the forms settings and email settings and such all went fine as far as I know (I’m not the developer who set those up), but when I went to update the submissions table (the process that took the longest based on the tests on my development server) it did not show progress and after briefly giving me the message about being patient it redirected to a blank page/pane at a URL that looked something like: https://mysite/wp-admin/index.php?page=nf-upgrades&nf-upgrade=upgrade_subs_to_cpt&step=1 (I know it was step=1, but I grabbed this URL from Dev while it was bobbing along successfully.)

    I reverted to a site backup and retried again to Ninja Forms version 2.9.11 and got the same response. I reverted the server back to a virtual snapshot as my maintenance window was ending.

    I had previously tested the update to the plugin successfully on the dev server, though it only got upgraded to WordPress 4.1. Yesterday and today I’ve refreshed my development server’s files and database data from production, tried the update to WordPress (now 4.2.1) and then the Ninja Forms plugin (performed by shutting down IIS on Server 2008 R2, deleting the plugins\ninja-forms folder and replacing it with the new version, then starting IIS back up again). The dev server continues to perform the submissions table upgrade successfully.

    Does anyone have any idea how I can troubleshoot this issue? I have tried modifying permissions on the dev server to see if I can replicate the behavior I saw on prod on Sunday, but so far I’ve struck out (meaning dev continues to succeed on the update).

    Thanks for any help.
    Chris

    https://wordpress.org/plugins/ninja-forms/

Viewing 6 replies - 1 through 6 (of 6 total)
  • Hello! Thanks for using Ninja Forms. This is more likely an issue with the database itself in how it stores the submissions.

    Thread Starter cclayton18

    (@cclayton18)

    The developer I’m working with likes the plugin and has seen in Dev that the updated version will help with an email notification format problem the customer has reported. So I’m motivated to get this working!

    I’m not sure where to look for a problem with the database, however. To refresh the Dev server, I use the mysqldump.exe utility on the Prod server to create a backup file and feed it back in to mysql.exe on the Dev server. This, along with a robocopy of the files, typically does a good job of refreshing the structure and content of the development server. Is there something in this process I might be missing? A similar process was used to deploy the production site to an existing MySQL database after initial development was complete on the dev box.

    I don’t see why anyone wouldn’t like the plugin! 🙂

    I’m not sure what the issue may be with the database if you used a mysql dump in which you only had to search for and change the site name in the file. I believe the key is to ensure that 1) the WordPress versions are the same, 2) the version of MySQL is the same, and 3) the contents of the wp-content folder is the same.

    I have done this many times and I didn’t really have a problem. So in your case, it is not that easy to pinpoint the actual problem.

    Thread Starter cclayton18

    (@cclayton18)

    I have made use of the searchreplacedb2cli.php script to rename the WordPress site as it moves from one server to the other, and that happens after the MySQL restore is complete. So the logical sequence here is:

    1. Site developed on Dev server including plugin first installation.
    2. Site copied to Prod server and renamed to Prod name.
    3. Site copied back to Dev server and renamed back to Dev name.
    4. Plugin update on Dev server succeeds.
    5. Plugin update on Prod server fails.

    Is there something about Ninja Forms that ties the data to a site, via site name or a GUID or something in the tables?

    Perhaps there is a difference in the MySQL grants to the database user between the two environments, as I don’t think the restore would change that. I’ll look into that as well.

    Thread Starter cclayton18

    (@cclayton18)

    As a small follow-up, the grants for the user on both servers are identical:
    GRANT ALL PRIVILEGES ON ‘mydatabase’.* TO ‘myuser’@’localhost’

    There has to be something different between the two servers, but that’s apparently not it.

    Like I said earlier, this is difficult of a problem to pinpoint since I can’t see the server you are working with. Maybe it is just best to upload a fresh copy of the plugin to the production server.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Problem upgrading submissions table’ is closed to new replies.