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

Sort by date Sort by votes
philmckrackon said:
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
Click to expand...
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?
 
Upvote 0 Downvote
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)

1714422934834.webp
 
Upvote 0 Downvote
Mouth said:
Will you put in a bug/feature request for this?
I agree that bouncing handling shouldn't be active when emailing is disabled.
Click to expand...
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?
 
Upvote 0 Downvote
Neilski said:
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 :))
Click to expand...
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.
 
Upvote 0 Downvote
Mouth said:
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.
Click to expand...
I can't imagine wanting a cloned test site to handle bounces, ever.

For a live site, I struggle to imagine good reasons to turn off email temporarily; best I can come up with is if you have an issue with the mail config and need to update it, you might shut off outgoing emails for a while. There'd be no reason not to keep on handling bounces of the emails that had already gone out though...
 
Upvote 0 Downvote
Neilski said:
I can't imagine wanting a cloned test site to handle bounces, ever.

For a live site, I struggle to imagine good reasons to turn off email temporarily; best I can come up with is if you have an issue with the mail config and need to update it, you might shut off outgoing emails for a while. There'd be no reason not to keep on handling bounces of the emails that had already gone out though...
Click to expand...
Hence my point and bug/suggestion thought ... why would you want bounce handling on a site that has email delivery turned off.
 
Upvote 0 Downvote
Mouth said:
Hence my point and bug/suggestion thought ... why would you want bounce handling on a site that has email delivery turned off.
Click to expand...
Sorry, forgot to reply to this.
You may have misunderstood me (my point was that if you turn off email temporarily, you could reasonably prefer to keep the bounce handling going, since that might prevent fresh emails being sent to a bouncing address immediately after the email was turned back on again; remembering that the bounces are only checked twice per hour).
However, I basically agree with your overall approach - the simple (and least surprise?) solution would be to switch off all email-related stuff when the master email switch is thrown... Will propose this in a moment.
 
Upvote 0 Downvote
I've utilised these instruction to create a duplicate site for dev purposes, with XF v2.2.16, on the same server.

When accessing it's URL I'm getting a http 500 error, I see the following in the web server (nginx) error log ...
Code: 
2024/08/14 14:44:44 [error] 973365#973365: *18337528 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Cannot declare class XF, because the name is already in use in src/XF.php on line 6" while reading response header from upstream, client: 172.<redacted>.211, server: dev.<redacted>.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "dev.<redacted>.com"

Same outcome for CLI ...
Code: 
# php cmd.php
PHP Fatal error:  Cannot declare class XF, because the name is already in use in src/XF.php on line 6

As per Resource steps/instructions, within src/config.php I've changed cookie prefix and disabled/false all cache options.
 
Last edited:
Upvote 0 Downvote
Mouth said:
I've utilised these instruction to create a duplicate site for dev purposes, with XF v2.2.16, on the same server.
Click to expand...
Following this up, in case it benefits anyone else looking to solve the same/similar issue ...

PHP Fatal error: Cannot declare class XF, because the name is already in use in src/XF.php on line 6

Is caused by XF not working properly, in situations of multiple XF sites/environments on the same webserver, with php opcache enabled.
Disable php opcache in this scenario, and then the second/subsequent XF site/environments works as expected.
 
Upvote 0 Downvote
Mouth said:
Disable php opcache in this scenario, and then the second/subsequent XF site/environments works as expected.
Click to expand...

This seems like it shouldn't be necessary. I find it hard to believe that there aren't multiple XenForo sites running on the same webserver with OPCache enabled without issue. You might want to further track down the route of the issue here. Something doesn't seem right.
 
Upvote 0 Downvote
Mouth said:
Is caused by XF not working properly, in situations of multiple XF sites/environments on the same webserver, with php opcache enabled.
Click to expand...
I'm surprised by this. We have multiple test copies running, and it just works. (I did have to change the memcache namespace for each copy, which I thought I had learned from this guide, but I can't now locate anything about that in the main resource or the update... weird.)
bzcomputers said:
This seems like it shouldn't be necessary. I find it hard to believe that there aren't multiple XenForo sites running on the same webserver with OPCache enabled without issue. You might want to further track down the route of the issue here. Something doesn't seem right.
Click to expand...
Agreed, though I'm not sure what.
When I use the OPcache visualisation on our site I can see lots of files from each tree, separately listed.

Checking the config, one option jumped out at me: opcache.use_cwd. [edit: this defaults to on, and is indeed on for our system]
The manual has this to say about that option:
If enabled, OPcache appends the current working directory to the script key, thereby eliminating possible collisions between files with the same base name. Disabling this directive improves performance, but may break existing applications.
Click to expand...
 
Upvote 0 Downvote
Last edited:
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

Anatoliy
  • Solved
XF 2.2 Problem with duplicating a live site to use as a test site
Replies
7
Views
912
ShikiSuen
ShikiSuen
J
  • Question Question
XF 2.2 Is there a up to date guide on how to duplicate your site for testing purposes?
Replies
1
Views
880
Paul B
Paul B
rwm1962
  • Question Question
XF 1.5 Duplicate live site as test site & slim down attachments - space issue
Replies
8
Views
1K
vkams
vkams
RobinHood
  • Suggestion Suggestion
Create an onboarding framework to introduce new users how to use the forum and add-ons
Replies
4
Views
7K
RobinHood
RobinHood
Back
Top Bottom