Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Sync Breaks When Creating New Staging Environments #1188

Open
3 of 6 tasks
ricardoaraujo330 opened this issue Aug 15, 2024 · 4 comments
Open
3 of 6 tasks

[BUG] Sync Breaks When Creating New Staging Environments #1188

ricardoaraujo330 opened this issue Aug 15, 2024 · 4 comments

Comments

@ricardoaraujo330
Copy link

Describe the bug
Whenever I create or update a staging environment using Cloudways, the Mailchimp for WooCommerce plugin is copied over along with everything else from the live site. Even though I deactivate and delete the plugin from the staging site immediately, Mailchimp assumes I have two stores, causing the sync on the live site to break. This results in a lengthy re-sync process and pauses all of my automation/journeys.

To Reproduce
Steps to reproduce the behavior:

  1. Go to Cloudways platform.
  2. Create a new staging environment or update an existing one using "Pull from live".
  3. The Mailchimp plugin is copied to the staging environment.
  4. Deactivate and delete the plugin from the staging environment.
  5. See the sync on the live site break, leading to a re-sync of 50,000 users and 50,000 orders, which takes almost a month.

Expected behavior
I expected the live site to maintain its sync with Mailchimp without disruption, regardless of the creation or update of a staging environment. Ideally, the plugin should be tied to a specific domain, so that the integration is not broken when a new staging site is created.

Screenshots
don't have

Operating environment (please complete the following information):

Store URL: floresnocais.pt
Plugin version: 4.2.1
WooCommerce version: 9.1.4
WordPress version: 6.6.1
PHP version: 7.4

Things to verify before submitting a ticket:

  • I have verified that I am using the most up-to-date plugin version.
  • I have enabled "Remote Diagnostics" from the plugin's Settings tab (if possible).
  • I have checked if there are any fatal errors in WooCommerce (WooCommerce -> Status -> Logs).
  • I have confirmed with my hosting provider that WP_CRON is activated and that the queue powered by Action Scheduler is functioning properly.
  • I have verified that caching plugins or services are not interfering, especially with Redis, Nginx, or MemCache, and have ensured the necessary paths are excluded from the REST API and /wp-json/mailchimp-for-woocommerce. I have referred to the Wiki help page on this topic for more information.
  • I have ensured that my server memory limit is sufficiently high (1GB or more) to accommodate the sync.

Additional context
Given the significant impact this issue has on large stores with high numbers of users and orders, I strongly suggest that the plugin be tied to a specific domain. This would prevent sync disruptions when creating or updating staging environments. Please consider this or any other solution to avoid breaking the live site's connection with Mailchimp when a staging site is created.

Thank you for your attention to this issue, as it is highly frustrating and has a substantial impact on our operations.

@khungate
Copy link
Collaborator

khungate commented Sep 3, 2024

@ricardoaraujo330 thanks for reaching out, we'll be checking this out and will report back.

@ricardoaraujo330
Copy link
Author

Hi @khungate thank you so much for checking this issue.
I look forward for updates on this 🙏

@jordanrichiii
Copy link
Contributor

Hey there @ricardoaraujo330 in my testing of using a staging environment, I found that there is no duplicate store created when the live version of the WooCommerce store is copied to the staging directory. The tool I used was with a recommend Wordpress hosting provider that has a staging tool that pulls the live version of the site to a subdomain of the users choice.

I did not delete or delete the plugin , new orders will properly sync to Mailchimp as expected. Also checked the Mailchimp API and found there were no new stores created and my live Woocommerce store was present with the prober domain.

Next I tested making some changes to my staging environment such as change the theme, and finally published the changed site to the production site. The Mailchimp plugin remained intact syncing still operated as normal.

Finally I tested deactivated/deleted the plugin in the staging environment made other changes such as to the theme once more and published to the live production of the site, this resulted in the plugin also being deleted on the live site which also resulted in the WooCommerce store being deleted via the API in MC. This in my opinion is to be expected because generally when using staging environments publishing replaces your files and database with the staging copy. The Mailchimp plugin cannot control the process of writing the newly published staging files to production.

I would recommend when using the staging environment to not deactivate/delete the Mailchimp plugin and leave it installed and logged in. Totally understandable how it could seem as though there are 2 stores syncing because the staging environment will show active plugin that is syncing but this doesn't seem to be case.

@ricardoaraujo330
Copy link
Author

Thank you for your detailed response and for all the tests you conducted along with their descriptions.

It seems that copying the live site to the staging environment doesn't interrupt the synchronization, but deactivating the plugin in staging does, correct?

That being said, this is still a concerning issue. Testing often involves activating and deactivating plugins to identify problems, and there’s no guarantee that if I give access to a support team for debugging, they won’t accidentally deactivate the Mailchimp plugin.

Ideally, there should be a way to safeguard this scenario, preventing unnecessary synchronizations, which typically take several days to complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants