Doesn’t handle site migrations well

  • When a developer builds a website, the process is normally:

    – create the site in a subfolder on a development server
    – migrate the site to the live domain, running a (serialized) search/replace in the database from the old site URL to the new site URL (via a script, WP-CLI, etc).

    There are two issues with this plugin:

    a) The URLs used are root-relative URLs, and do not include the domain. This means replacing https://www.devsite.com/abc with https://www.livesite.com will not update these URLs correctly, making them all return a 404 due to the nonexistent subfolder on the live site. Replacing just the string /abc with an empty string is far riskier as there may be false positives.

    All other plugins/core code etc use full absolute URLs including the domain for anything like this, both in the database and output in the HTML (take a look at the HTML in the head tag for any site, for example – this is the only one starting with a slash). Can the plugin be updated to use full URLs as well? I can see no downside in doing so, but plenty of upside.

    b) The browserconfig.xml and manifest.json are a bit more complicated since they’re hardcoded in uploads to the server. This isn’t ideal – nowhere else in WordPress are URLs hardcoded into static files – but I’m not sure of a quick fix for making them dynamic. However, what about a simple button in the admin which ‘regenerates’ them? Ideally, this button could automatically appear as a warning prompt at the top of the screen if it the settings don’t match where your site is located.

    • This topic was modified 8 years, 5 months ago by smerriman.
Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author phbernard

    (@phbernard)

    Thank you for your comprehensive feedback!

    I never realized full URLs were preferred. Now that you mention it, that sounds obvious.

    a) This part is easy. Next version will use full URLs in the HTML code.

    b) No obvious solution here:

    • Make static files dynamic: although the processing should be lightweight, this might have an impact on performance. From day one, the plugin has been designed to be extremely lightweight (for the public part; dashboard doesn’t have the same requirements). That would be a major breach in the contract it has with its users, who expect absolutely no performance penalty just for a simple favicon.
    • The solution you mention seems to be the right way to go: the plugin tracks domain name changes and is able to do a search-and-replace. You are talking about a button. Don’t you think an automated upgrade, triggered every day and/or during dashboard interaction, would be a better option? I don’t think prompting the site admin adds any value: he probably won’t understand the issue and “Upgrade now” will be the only choice.
    Thread Starter smerriman

    (@smerriman)

    Yeah, dynamic is probably not a good idea performance wise. I was thinking that this would only happen when a developer migrates a site, so a prompt would just be a reminder that something (not obvious at first sight, if ever!) isn’t working and needs fixing – but of course having it automatically edit the file is just as ideal.

    • This reply was modified 8 years, 5 months ago by smerriman.
    Thread Starter smerriman

    (@smerriman)

    A bit hacky but you could store a base64-encoded version of the site URL as an autoloaded option as a validator. Then it wouldn’t be updated by the search/replace, so all you need is one line of code to check if the value matches that correct value rather than using regular file I/O.

    Thread Starter smerriman

    (@smerriman)

    But on second thought, probably still better to show a prompt (the favicon files are out of date, click here to fix) than write to files without the user knowing, especially on high traffic sites where you may get a lot of people visiting at the same time. But for now I probably won’t forget to update them anymore anyway!

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Doesn’t handle site migrations well’ is closed to new replies.