we have a LIVE website, with active (recurring) paid subscribers...
every month - they get charged on their credit card through paypal.
(so far - all good)
now - while creating the next version, updates, etc -
on DEV - we migrated all live user info and started working with it
(ouch)
and then - all our paid subscribers - got a false message - that their credit card cannot be charged!
my question is -
moving forward, as we are going to have automatic notification on content added, newsletters, recurring payment, etc.
is there any safe method / workflow -
to work on DEV, with latest info - without anything being sent (or charged) from there like it happens on LIVE?
so we can debug only, and work with sandbox, instead of real users?
btw - when we finish a version on DEV -
we run a script - to create STAGE server -
it copies all functionality changes, views, panels, etc from DEV
it copy all users, and content from LIVE
and then we QA on STAGE - to make sure it ready to switch,
to become the new LIVE.
(also with that workflow, i'd like to prevent any false information being sent out, until STAGE is ready, and becoming LIVE)
hope it make sense...
thanks for your help!
Comments
Some Options
What we normally do for a similar system is to actually mangle all the email addresses in the system, so if we do accidentally send an email, it goes to a non-existent account on our domain instead of the real email. It's done by a script, and we run it right after a database copy.
Other thoughts:
Ken Winters
www.coalmarch.com
Ken Winters
For emails
See http://drupal.org/project/reroute_email and http://drupal.org/project/advanced_mail_reroute
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
another option and know your not alone
Here is one more module to evaluate - http://drupal.org/project/mail_redirect
I think ideally we would like an email trap that is dependent on the domain being sent from. So if email is sent from production it passes normally but if sent from any other Domain it is trapped and sent to a development email address. Hook_mail_alter should be most of what I need. http://api.drupal.org/api/function/hook_mail_alter/5
I recently had a similar experience. **Don't forget to also turn off Google analytics module if your run that. Other wise you will be sending data from your dev and stage as well as production. Google analytics doesn't really care where the data comes from.
Regards,
Michael Hofmockel
iMed Studios
Open Source || Open Access || Open Mind
Regards,
Michael Hofmockel
Open Source || Open Access || Open Mind
Devel Module Turn Off SMTP
I'm not sure if this answers your question, but you can use the Devel module's settings to turn off SMTP for a site and send any messages to the log only. This is what I do for my development sites that are configured to send messages.
Mark W. Jarrell
Manager of Web Services
Jones Knowledge Integration Group, Inc.
http://fleetthought.com
http://www.jones.com
http://www.jonesdifference.com
http://www.jiu.edu
Twitter: attheshow
Mark W. Jarrell
Online Applications Developer
Richland Library
http://www.richlandlibrary.com
http://fleetthought.com
Twitter: attheshow
Reminds me of the talk given
Reminds me of the talk given by Sacha Chua in Drupalcon Washington DC 2009. This is tip #12.
http://dc2009.drupalcon.org/session/totally-rocking-your-development-env...
Here's a complete page just
Here's a complete page just for this:
Managing Mail Handling for Development or Testing
overall sandbox / redirect solution
thank you guys,
similar to the Mail Redirect solution,
i'm looking for a way to have some kind of 'sandbox',
anytime data is processed in DEV / STAGE -
should always go to that place where i can check it,
but without the real users - knowing anything about it.
beyond emails -
i still have to deal with message notifications (sms, IM, etc)
and charging credit cards through ubercart subscription.
What we do
it's a pretty low tech solution that reflects the sysadmin in me and I think it dates back to 4.6 or 4.7 before all these fancy modules :)
It would probably only work for very similar setups to us - eg you control the mail infrastructure, and the settings for the different instances (eg dev, test etc) are handled via multisites in the same codebase.
We have the production sites email address in the DB set to something that our external smtp relay is configured to always drop eg 'blockme@example.com'. Then the settings.php for the production multisite instance overrides the site email variable to the actual address. That means that only the production site can send mail to the rest of the internet.
That means that anyone can takes a copy of the production DB, and set it up somewhere within our network without spamming any outside users. And the email will still work to addresses within our LAN which is handy for testing - it is only emails that try to escape our network that get blocked.
--
Cheers
Anton
--
Cheers
Anton
hey, how do these live
hey, how do these live websites work? What are the softwares you have to use? Just tell me the pros and cones.