New to the community? Start here

Pushing of Staging to Production SItes

Hey guys,

I have recently started playing with your staging server that you offer. Setting up is quick and easy but unless I am missing something, using it is not so user friendly.

1. Using a page builder, pushing the changes to the production server is very inconsistent. I have mentioned this in a live chat and they said they would look into it. What happens is that after pushing it to the production server, it does not reflect. I clear all cache (including object cache) and it finally reflects the changes only to revert to the original the next day. My question is does it take some time to make the changes or is there a step I am missing? This is specifically dealing with pagebuilder sites. Sites I build have not presented any issue thus far.

2. The other issue is that when developing on the staging server and pushing it to the production server, any images that were uploaded are still displaying the staging server url. I my mind, this is not good practice. Surely when pushing the media, urls should be rewritten to reflect the production server url?

Hope this can sorted. Again, if I am missing a step or two please do enlighten me.

Thanks

Thu, 16 May 2019 10:34:02
  • Adam Czajczyk
    • Support Gorilla

    Hi Baldafrican

    I hope you’re well today!

    Before we go any further, I’d like to analyze the issue a bit more. Or rather – get a better picture and make sure that we’re on the same side.

    The issue with pushing staging to production (or any migration for that matter) is that whenever you use any tools to build the site in staging environment (may it be some builder or some other plugin that includes some resources in site) they’re pulling URLs accordingly to the location they’re working on. For example:

    – site’s at staging.domain.com

    – you’ve added a background image for some text block on page, using some builder tool

    – the builder generated CSS that handles that (the css might be stored in db and printed out as inline CSS or may be printed out to a new file that’s then included in site)

    Now, the builder tool might use absolute or relative URL for such image. So it might be something like “/images/image.jpg” or like “https://staging.domain.com/images/image.jpg” and that will be “hard-coded” in CSS.

    While pushing the staging site to production the site URL will be changed from the “staging.domain.com” to “domain.com”. There’s a WordPress Address (URL) and Site Address (URL) setting in WordPress and it’s surely updated.

    But then: if the site code – regardless whether it’s generated by some builder, some plugin or even created manually – doesn’t actually use that but simply “hard-codes” URLs then if they are relative, everything should be fine but if they are absolute that might pose an issue.

    I’d say that following “good practices” would mean that in any case a full url (including site URL) is used on site it should actually use value of these options. That’s how themes and plugins should be created. But in reality it’s not what happens. But it also means that in many cases pushing staging to live would mean actually full scan of the database (a “search&replace” kind of) and actually scan and parsing files such as theme files and any custom CSS/JS/template files that are/may be generated by builders/plugins.

    That’s a bit “tricky” thing – can be resource-intensive and can actually be quite “dangerous”.

    This is one thing though. The second thing is what you described in the point 1 as “inconsistent behavior”. This looks like some db<->cache problem, although on staging there’s no caching. But I see you’re using Divi. What happens if with staging->live pushing if you try following setup:

    – in Divi -> Theme Options -> General disable both CSS and JS optimization options on staging

    – in Divi -> Them Options -> Buider -> Advanced disable Static CSS File Generation option

    – clear HB cache and on Hummingbird -> Asset Optimization re-check files (make adjustments after that if necessary)

    – then try pushing the site to live

    Theoretically speaking, “migrating” the site (and pushing to live from staging is a migration “kind of”:wink: shouldn’t be done with all such optimization options enabled. Could you give it a spin and see how this behaves then? Since you have Asset Optimization enabled in Hummingbird already it’s not advised to keep Divi CSS/JS minification enabled anyway but you could actually try switching Builder to generate static CSS files back after stage-to-live push to see how it works then.

    Would you try that and let me know how this worked for you?

    Best regards,

    Adam