Title: Altering mailchimp connection account programmatically
Last modified: January 12, 2024

---

# Altering mailchimp connection account programmatically

 *  Resolved [Gaetano Giunta](https://wordpress.org/support/users/therealgggeek/)
 * (@therealgggeek)
 * [2 years, 5 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/)
 * Hello all.
 * I am developing scripts that will take a copy of a production Woocommerce installation(
   db and uploads) and transform it so that it is fit to be used in test/dev envs.
   This entails f.e. anonymizing user data, but especially making sure that all 
   3rd party connectors are switched to “test mode”, to avoid polluting production
   data as well as sending emails/sms to real users.
 * As mailchimp does not seem to provide a “test mode” which could be used for this
   scenario, I resorted to creating a test account instead.
 * What I’d like to achieve is thus to automate altering the configuration of the
   plugin to move it from one mailchimp account to another.
 * So far I have found serialized config in wp options table under key “mailchimp-
   woocommerce” – but there are many other rows in that table which look like they
   should be modified…
 * Is this a good approach or is there a better one? Does anyone have a complete
   list of config data which should be modified?
    -  This topic was modified 2 years, 5 months ago by [Gaetano Giunta](https://wordpress.org/support/users/therealgggeek/).

Viewing 6 replies - 1 through 6 (of 6 total)

 *  Plugin Author [ryanhungate](https://wordpress.org/support/users/ryanhungate/)
 * (@ryanhungate)
 * [2 years, 5 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/#post-17339038)
 * [@therealgggeek](https://wordpress.org/support/users/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 🙂
 *  Thread Starter [Gaetano Giunta](https://wordpress.org/support/users/therealgggeek/)
 * (@therealgggeek)
 * [2 years, 5 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/#post-17339187)
 * 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…
 *  Plugin Author [ryanhungate](https://wordpress.org/support/users/ryanhungate/)
 * (@ryanhungate)
 * [2 years, 4 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/#post-17345019)
 * [@therealgggeek](https://wordpress.org/support/users/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](https://github.com/mailchimp/mc-woocommerce/wiki/Filter-for-ignoring-products-or-orders).
 *  Thread Starter [Gaetano Giunta](https://wordpress.org/support/users/therealgggeek/)
 * (@therealgggeek)
 * [2 years, 4 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/#post-17345073)
 * 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…
 *  Plugin Author [ryanhungate](https://wordpress.org/support/users/ryanhungate/)
 * (@ryanhungate)
 * [2 years, 4 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/#post-17345212)
 * 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.
 *  Thread Starter [Gaetano Giunta](https://wordpress.org/support/users/therealgggeek/)
 * (@therealgggeek)
 * [2 years, 4 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/#post-17346240)
 * Sure, that seems like a good way to achieve what I want

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Altering mailchimp connection account programmatically’ is closed to 
new replies.

 * ![](https://ps.w.org/mailchimp-for-woocommerce/assets/icon-256x256.png?rev=1509501)
 * [Mailchimp for WooCommerce](https://wordpress.org/plugins/mailchimp-for-woocommerce/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/mailchimp-for-woocommerce/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/mailchimp-for-woocommerce/)
 * [Active Topics](https://wordpress.org/support/plugin/mailchimp-for-woocommerce/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/mailchimp-for-woocommerce/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/mailchimp-for-woocommerce/reviews/)

## Tags

 * [staging](https://wordpress.org/support/topic-tag/staging/)

 * 7 replies
 * 2 participants
 * Last reply from: [Gaetano Giunta](https://wordpress.org/support/users/therealgggeek/)
 * Last activity: [2 years, 4 months ago](https://wordpress.org/support/topic/altering-mailchimp-connection-account-programmatically/#post-17346240)
 * Status: resolved