How to duplicate a live site to use as a test site

[Paul B]

See the resource for the most up to date instructions.

How to duplicate a live site to use as a test site

These instructions explain how to create a test installation which is an exact duplicate of your live installation. On Your Server Create a new test database with a different database name, user name and password to your live installation...

xenforo.com

 

[Neilski]

Got me thinking, the server cron is set to a live site (live site cmd.php path) not the test site so it's only firing once, not two times. The test site fails so it really never runs the bounce check and nothing goes on the server log??? So by setting the cron to server based it effectively kills the process. @Neilski

Ahh, OK yes this would be a drawback of the server-based cron I guess - if you forget to set up a new cron job (or swapping back to activity-based) when cloning the site then the cron jobs never happen at all... (A good reminder, given that I'm considering swapping to server-based on our site.)

So we're back to basically having nothing to contradict my impression that email bounce handling can fire on a test site even when mail is disabled.
@Paul B - can you definitively comment?

 

[Neilski]

Finally got around to putting it to the test...
In short: the email bounce handler does run even when email is disabled.

See pic below... (At first, I manually triggered the job, and then realised that for completeness I should let it run by itself. Both runs fetched a bounce.)

I'd rate the chances of this "breaking"* bounce handling for the live site as fairly low, if the cron job is activity-based and the live site is reasonably busy. However, I'll be disabling it for my test sites from now on, via the DB. (I used UPDATE `dbname`.`xf_option` SET `option_value` = '{"enabled":false,"type":false,"host":false,"port":false,"username":false,"password":false,"encryption":false,"oauth":false}' WHERE (`option_id` = 'emailBounceHandler');)

(* by "breaking" I mean preventing the live site from seeing and acting on the bounces)

 

[Mouth]

In short: the email bounce handler does run even when email is disabled.

Will you put in a bug/feature request for this?
I agree that bouncing handling shouldn't be active when emailing is disabled.

 

[Neilski]

Will you put in a bug/feature request for this?
I agree that bouncing handling shouldn't be active when emailing is disabled.

Fair question.
I am not actually certain that it should be considered a bug in XF, as such. (It's perhaps more of a bug in this "duplicate your site for testing" guide, if anything )
It really depends on what one wants/expects to achieve by disabling outgoing emails. On anything other than a test/clone site, you might reasonably want and expect incoming bounces to keep being handled without significant delay. Then again, if you turn the email back on again in a reasonable time period (hours?) then the queued bounces would probably still be OK to process.
May also be worth considering as a feature request... Not sure.

Honestly, my instinct would be to just flag it in this resource, because I think the only time the behaviour can actually do (minor?) harm is when you create a test site and don't realise that it can subvert the bounce handling.

Could really do with your input on this @Paul B - thoughts?

 

[Mouth]

I am not actually certain that it should be considered a bug in XF, as such. (It's perhaps more of a bug in this "duplicate your site for testing" guide, if anything )

Fair enough. I cannot perceive a scenario though where you would want an XF installation (test/dev. or production) not sending emails but also handling bounces of emails that you haven't sent.