Fatal conflict with mobile plugin

  • Resolved msauers

    (@msauers)


    10 years, 7 months ago

    (This happened with Version 2.1.4.6. We removed the problem plugin before upgrading to the latest version of NSCloner so we don’t know if that update fixes this problem or not. We’re not going to reinstall the problem plugin to test it since this is a production machine and we don’t want to re-break things.)

    The problem as we experienced it:

    We are running a WP multi-site install on IIS. When attempting to enter the dashboard of a cloned sited from the Network Admin>Sites screen or directly by typing the /wp-admin at the end of the site url, the whole back-end of the WordPress install locked up until the request timed out with a 500 error. The public side of the sites continued to display correctly.

    The back-end of sites made from scratch both before and after the problem started always worked.

    Here is an excerpt from the server’s Process Monitor while the problem occurred. (https://dl.dropboxusercontent.com/u/42699085/ProcessMonitorWordPressClonedSite.jpg)

    Lines 50643, 50646, and 50652 show the lines captured by process monitor that led us to the mobile plugin from websitez.com as causing some kind of problem with the cloned sites; and happily, deleting the plugin solved the problem. That plugin is WP Mobile Detector. (http://wordpress.org/plugins/wp-mobile-detector/)

    Also: Line 50665 shows the line captured indicating action created by NSCloner to write to its own log file. Do we know the purpose of that?

    Thanks,
    Michael Sauers
    Nebraska Library Commission

    http://wordpress.org/plugins/ns-cloner-site-copier/

Viewing 1 replies (of 1 total)
  • Plugin Author Never Settle

    (@neversettle)

    10 years, 7 months ago

    Thanks for the details, Michael. Do you have a dev environment on IIS that you can test the latest version (2.1.4.8) with?

    I’m wondering how good the wp-mobile-detector plugin’s multisite support is. Normal process would be to create a new site, and individually activate each plugin for that site, correct? (Or do you have that mobile plugin activated network wide?)

    The Cloner process is to clone everything directly and bypass all that. Normally this works fine. But if there’s non-standard dependency that the mobile plugin relies on the activation process every time for something then that will inherently not be compatible with the Cloner. Based on the FAQ that states:

    I am getting an error that it was unable to install correctly. What do I do?
    Please try deactivating and reactivating the plugin.

    …and looking at your log where it isn’t finding that plugin’s config file, I’m wondering if that plugin #1 requires activation every time and #2 stores its settings in a flat file rather than the options database table where it should.

    If my assumptions are correct it will not be compatible with the Cloner. However, it is quite likely that the following scenario could still work for you:
    1) Build a template site without the mobile plugin activated
    2) Clone the site
    3) Activate the mobile plugin on the new site

    It’s an extra step, but could still save you a bunch of other configuration steps outside that mobile plugin.

    The Cloner log write is completely expected behavior. If that main file doesn’t exist at first then it gets created so that it can log clone operations.

    Hope that helps. Thanks!

Viewing 1 replies (of 1 total)
  • The topic ‘Fatal conflict with mobile plugin’ is closed to new replies.