Is there a way to programatically disable the plugin? Something like this:

define('WPMS_DISABLE', WP_ENV === 'development');

Here’s why – I’m using environments for my WP back-end (development, staging, production) and I’m testing my HTML e-mails with MailHog (thanks Roots/Trellis!). I would like to keep using that. I know that I can just turn the plugin on and off but that seems a bit messy.

Also do you have documentation for developers? I could not find it on your web or your current GitHub.

Thanks again, P!

We have three WP environments: Dev, QA and Production. Is there a way to copy the countdown clocks we create in Dev to the other environments? Like an import / export feature? We just bought the Pro version.

Please let me know. Thank you.

Thanks for this handy plugin, it seems to work a treat!

One thing that I’m interested in is whether or not there will be support for Environments. Ideally, I would like to specify which environment to run in when configuring as we have Staging and Production versions of tags.

Thanks

What I mean is – imagine you are working on a big project with a team of people. Ofc you use versioning (say github), and have a repo posted where everyone is working on. You have master, development, staging and bunch of other branches, but the first three are your main concern.

Say you’ve already deployed your product and now a new update comes out. First you’ll work locally, then push it to dev. After tests pass, this can be pushed to staging, where client will be able to test the site. If all of that passes, you can deploy this to a live server and safely update the site.

Is it possible to have a script that runs either on Semaphore or Travis CI so that you have automatic deploying without much fuss (say staging to production)?

The first link I added seems like a great way to have this separation, but the problem is deployment – especially on production – and especially the database.

What is the best way of solving this issue? Writing your own scripts? Doing all this manually?

So far I’ve only worked for small clients, so I’d just develop locally on my vagrant and then migrate it all by hand using a search and replace script.

But I’d like to streamline this process.

I have a question about relative domain name in wp database.
I would like to deploy my wordpress site (files + database) easily in many environments (local / dev / prod …)
I use wp-cli with this command : wp search-replace <LOCAL_URL> <PROD_URL> --all-tables --verbose and I have this response :

| Table                  | Column                | Replacements
| wp_options        | option_value        | 10
| wp_postmeta     | meta_value          | 10
| wp_posts           | post_content        | 8
| wp_posts           | guid                      | 349
| wp_usermeta     | meta_value          | 1

*Success: Made 378 replacements.*

*Can I use relative url in my database to avoid having to do this command and only need to change siteurl & home value from options table ?* Why have I 349 replacements in wp_posts ? Why are not relative URLs stored in this table ? It would be easier if I had to change only siteurl and home value. Thx for your reply adn sorry for my english

Kudos for this great plugin !

Any plan to support environments or advice to make it work with the plugin ?

Kind regards,

Phil

https://www.ads-software.com/plugins/duracelltomi-google-tag-manager/

Now it seems to me that all this could be easily accomplished with a plugin, (or other tool), which did a copy between locations, (while making any necessary changes to links and references so it worked in the new location).

Is there a ‘one click’ type solution for this please?

Cheers, Nick

https://www.ads-software.com/plugins/w3-total-cache/

I’m a relatively new WordPress user, and I haven’t coded much of anything in quite some time. However, I’ve been doing my best to pour over all the documentation that’s out there regarding WordPress in an effort to understand some best practices for getting a new site up and going. I am currently working on one site, but I hope to launch many more over the coming months–thus, my search for best practices.

I started dabbling with my new site, but I soon realized that I’d need a testing environment. Therefore, after a ton of online reading, I was able to successfully establish https://dev.mysite.com, which is now basically just a mirror of https://www.mysite.com. I used the “Moving WordPress” tutorial in the Codex–and several other great resources, for that matter–to successfully make the necessary database updates, file moves, configurations, etc. My URLs seemed to work, and I was happy.

Currently, I’m in the process of establishing a local installation of WordPress using XAMPP by using the “Test Driving WordPress” tutorial in the Codex, not to mention a few other tutorials for good measure. There’s enough information out there where I feel relatively confident in my ability to get that piece up and running. However, the more I learn and think about things, the more questions I have. Enter the issues described below:

Moving files seems to be relatively straightforward, as there are many comparison tools out there–and for the more ambitious, content versioning systems. However, with WordPress storing so much information in the database, I can’t seem to wrap my head around how one can successfully migrate/merge database information through multiple environments.

For example, say I do some design work locally–maybe even install a plugin or two (i.e. some database changes are made). I then deploy the changes to my https://dev.mysite.com website to share the proposed changes with a client (making all the ugly database URL updates and such that are required–ugh.) Say I get the “go ahead” for production. Now what? The production database will have posts, comments, and other data present that I’ll need, but it won’t have the proper structure, plugins, design changes, etc. that I just made. How do I reconcile this issue? Do I only merge certain tables from the development environment? If so, where do I look to learn how to do this? Again, my mySQL and PHP skills aren’t anything to write home about at the moment, but I’m getting better….

Last, how do I make a move to production without having any down time? I’m not talking about moving an entire site between servers; I’m talking about just moving incremental file and database changes. My development site and production site are on the same server, as I mentioned earlier, with the development site existing as a subdomain. I suppose I intend to use the development site somewhat like a dev/staging combo, and my local installation as a pure development environment.

All I ever heard from people before this project was how easy WordPress was to get up and working. While that might be true if you have no desire for any process or customization behind your work, I’m finding WordPress to be far from straightforward at the moment.

Any help, pointers, references, etc. would be much appreciated. I poured over anything I could get my hands on all yesterday afternoon and evening, and I still feel like I’m coming up short….

Thanks in advance for your replies! As of right now, I feel like I’m just going to have to write down all my successful changes in my development environment and then re-do them all by hand in production at 3:00 AM or something….

Mike

A lot of high(er) end CMS products offer functionality for a multi environment scenario where new versions of the application are being built on a specific environment and then being propagated to the other environments. The handling of all exceptions in such a process can be quite complex. In my personal experience, I’ve never seen a tool that covers 100% of the exceptions but there are tools that will make life a lot easier for you. Is there such a tool for WordPress?

Thanks,
Erwin