@therealgggeek thanks for writing in about this. You’re correct there really isn’t a “test mode” but I’m not exactly sure what you would be wanting to test given the fact you’re also anonymizing user data.
Without knowing too much about your intent on this dev environment, I would first ask if the Mailchimp plugin REALLY needs to be used in this scenario or not.
Wouldn’t it make more sense to simply just deactivate the plugin when you’re in dev mode? Of course you could connect this to a test account as you’ve done, but my first thought was to disable that plugin since it’s meant to be a syncing engine to your marketing platform.
Totally open for discussion on what you would like to see here, we would always want to keep developers encouraged to innovate 🙂
You might be right that, if there is no mailchimp sandbox available, there is probably little value in having the plugin enabled.
However, in my experience, it is always a good idea to have dev and test environments set up as close as possible to the production ones. It is not hard to imagine a case where enabling the plugin does introduce errors in some other parts of the site, f.e. because of some bad code loading unconditionally a vendor library also used this plugin, but using a different version.
Also, connecting the plugin to a test mailchimp account would allow at least testing that the syncing of the user accounts does work – ruling out network/firewall issues.
Last but not least, I feel more safe with a plugin which misses the config for connecting to mailchimp than with one having the correct config and simply disabled – the latter is only one click away from being reenabled by mistake by an admin.
Oh, and not having the production secret keys present in databases passed around by often-careless developers, is also a good thing.
I have seen that other plugins allow to override the config stored in in the DB using php constants defined in wp-config.php. This is imho a good solution to allow different envs to use different credentials, and to have the secrets injected by configuration management code instead of having them stored in the db and managed via a gui…
@therealgggeek yes I agree with everything you’re saying here – but It sounds as if you’re literally cloning production -> then loading everything into staging. My recommendation would be to completely separate the environments so you can do anything you want, in a controlled environment.
Now, i do understand that some services have a “clone to staging” button which might be what you’re doing here, but even then I would question the workflow of development to production. The right thing to do is separate the two for code testing.
That being said ^^ I’m curious as to what would you like to see done that might help your situation? We may just need to simply disable the JOBS that are being created which can be done through a simple filter.
Here comes the long version… 🙂
In most of my projects, I set up at least 3 envs: one for each developer, one for test/staging, and prod. The version of the code deployed to each is separate, and managed usually via git tags or branches; configuration settings related to the current env and to the 3rd-party services in use get injected into the applications from env vars, .env files or similar methods. For php projects, nowadays I use Composer for dependency management – in fact I use it even for WP projects, and disallow updating plugins from the admin interface. For the data, I find that having “dev” or “staging” databases kept completely independent from the prod ones is not good enough: they drift apart quickly; they generally don’t have enough data to allow troubleshooting problems related to scaling; and devs are not quite as good as end users at inserting illogical / illegal values.
This is why I often develop scripts which can be manually executed from time to time, to re-seed a dev or test environment with the prod database (regardless of the exact code version running on the respective envs, but that can be managed via migrations and such). Re-seeding a dev db with a copy from prod generally involves scraping or anonymizing end-user data to be compliant with security and privacy norms.
What I am looking for is to minimize the db scraping required during the re-seeding process specifically to change the configuration of WP plugins.
I know that WordPress’ is geared towards cloud/shared-hosting and non-developer users, where everything can be managed via the web interface, and that is why plugins store by default their configuration in the database. Yet I found that some, such as wp mail smtp, go the extra mile and also allow to override it via wp-config.php.
Maybe I could indeed use some extra filters to achieve what I want instead of changing the configuration of the plugin, but, for me, the problem in doing that would not be much different: I would need some (reliable) docs about which filters to implement instead of docs about which database values to alter…
Thanks for the info… I’m still a bit unclear though on exactly what you would like to do here. If simply having a filter to override the data that we typically store in the “options” table would work, that’s totally doable. Maybe that’s all we need here. Would it work if there was a filter that allowed you to load a dummy options array? I could back that pretty easily.
Sure, that seems like a good way to achieve what I want
