• Resolved hommealone

    (@hommealone)


    I’d like advice about using this plugin on a website with staging and production environments. How can we keep the statistics separate, and how can we keep the collection of stats going continuously on the production environment, while we work on a copied version of the production site in our staging environment?

    Some hosting companies, like WPEngine, allow us to exclude individual tables in the database when copying an environment. Other hosting companies do not; copying the database up and down is an all or nothing operation. In those cases, the new data in the staging environment database over-writes the data in the production environment database when it is copied from staging to production.

    In those all or nothing situations, if we copy the production environment down to the staging environment, do some work on the site there for a few days, and then copy back up to the production environment, there will have been no stats about visitors to the production site collected for those several days.

    Might there be any possibility, for example, of storing the data in a separate database rather than the main WP database? Perhaps one that is stored outside of the website root directory? Or of somehow merging, rather than overwriting the database information?

    Perhaps the statistics data could be “export”-able using the standard WP export tools? Then the statistics data could be “exported” from the production environment, via the standard WP export tools, just before up-copying the staging environment to production, and then “import”ed again after the up-copying?

    Any other ideas about dealing with these situations?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Rogier Lankhorst

    (@rogierlankhorst)

    I think what you could try is using a tool like Duplicator, which allows you to exclude tables and files from the export. Then exclude everything except the Burst tables, and export these before pulling in the staging.

    Then afterwards you can import just those Burst tables again.

    I think there are multiple ways to handle this, but if the host doesn’t allow excluding tables, the above seems simplest.

    Thread Starter hommealone

    (@hommealone)

    Thank you for the suggestion! (And for your prompt reply!) If that is the simplest way to handle it, I’d hate to see what the less simple ways are ?? !

    Not exactly a simple or quick process, but if that is the only option, it might be workable none the less.

    If you can think of other ways, even if they seem less simple to you, perhaps one of those might fit into our work routine better, so I’m open to all options!

    Am I right in assuming that if I copy the database down from production to staging, then work on the staging environment for an hour, then copy the database back up to the production environment, the only statistics which will have been lost will be that hour’s worth?

    Plugin Author Rogier Lankhorst

    (@rogierlankhorst)

    You could use Duplicator to export the entire site to staging, and exclude the burst tables, work on it, then restore. Much simpler, but don’t know if it fits your needs.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.