Under the child domain, there are no rewrite rules and the vhost conf for OLS looks almost identicle to the parent with slight differences:
docRoot /home/example.com/public_html/staging.example.com
vhDomain $VH_NAME
vhAliases www.$VH_NAME
&
SSL keys path being correct for child.
I just remembered, so prior to the SSL for child being created, accessing staging.example.com would throw a security error in browser (understandable) after SSL installed it just instantly redirects. So redirect is happening post 443 OLS listener engaging.
@Richard
I fixed the rewrite rule copying issue, but it will come in v1.8.9. About the preview feature, it is better to temporarily edit your computer/laptop A record or add DNS record for staging site rather then using the preview feature. Because applications are configured on diffrent URLs, so better is to use actual DNS record.
I personally use DNS records, I simply didn’t know if the preview method was the intended method of access of the clone. Thank you for confirming it is a rewrite rule issue.
Look forward to v1.8.9, for now, I’ll just pull a clone to local development for continued testing.
Thank you for the continued responses and for making CyberPanel ever greater!
@CyberPanel
FYI: I deleted the staging site from the main website as a child. I just went to take a WP clone (Duplicator plugin) and found that the staging site still has files present. Therefore it’s not removed the files.
It’s also created a number of duplications i.e:
public_html > parent_wp > child_wp > child_wp (the second child doesn’t have all WP files just some html files)
Also, if there is more than one clone created, the second clone creates a copy of the first clones wp files into it as well, including the second child version of its self. This is creating a serious amount of bloat within the system.
With regards to the database, I am not sure if it’s cloned the database, but the wp-config file for the clones has the parent DB + credentials. Although it has created I assume a clone as it has random db name + user listed under parent websites DB.
Sidenote: the random database name is a bit annoying as it’s difficult to determine which site it’s for. i.e. if I had created staging & dev as child clones, I wouldn’t easily know which DB the site is for.
@Richard
Thanks for digging in a little deeper, I also feel their needs to be an option to name DB & User while creating staging or even main WordPress installation for easy identification instead of some random characters.
Hi @CyberPanel
I recently tested the staging function with latest v 1.8.9
On the staging site in admin I getting this error line in header:
Can NOT find LSCWP path for object cache initialization in /home/domain.com/public_html/stage.domain.com/wp-content/object-cache.php
While the LScache plugin is not copied in the staging site the changes made in theme customizer were also not copied. Can you check if this is happening at your end.
I get the same error line on some staging sites but not all of them. You can fix it by just deleting the object-cache.php file that it references.
The theme customiser settings are not copied and neither are setting for some plugins.
@Mysterious_Beans @cloudrider
Where does WordPress store customiser settings and settings for plugins?
What we basically do now:
- Create dump of main site.
- Replace urls of database dump of main site.
- Create new database and restore dump.
- Then copy all the files from master to child.
In between we don’t copy lscache wp plugin to child-site.
Did I miss something?
@CyberPanel
Not tested v1.8.9 yet, but to be honest I am a little weary after last update so giving time for bugs to be reported if any.
On the MySQL dump are you doing a sed replace like this before reimporting?
sed -i -e ‘s/oldurl.tld/newurl.tld/g’ wp.sql
Or are you being a little more selective with DB URL changes?
Sed replace should catch everything in sql file. I find it works well on 3GB multipress network DB too.
Using subdomains on multipress DB I use:
sed -i -e ‘s/.oldurl.tld/.newurl.tld/g’ wp.sql
It’s a very efficient method. It could also be used to loop through theme folders and catch hardcoded URL’s in html/php/css/js files. Maybe a 3rd party theme customizer (not WP customizer) is storing options in a file rather than in a database?
@CyberPanel Thank you for this 
Did I miss something?
That sounds like it should catch everything, but it doesn’t seem to for whatever reason.
When I have some time later I will take a look at the particular things that don’t seem to be getting copied over and see where they are stored or if I can think of any other issues that might be causing it.
WP staging is a great feature to have and I’m glad you have implemented it, CyberPanel continues to improve, I’m sure we can find the root cause of any bugs and then it will be really useful.
@Mysterious_Beans
Sure if you find anything let me know.
You can also see function in raw format that do this task cyberpanel/StagingSetup.py at d495ce416075698a8bd16ee50ede710d4d58ed83 · usmannasir/cyberpanel · GitHub
If you can read python code, you can easily understand what exactly happens.
i cant use because of that:
public_html > parent_wp > child_wp > child_wp (the second child doesn’t have all WP files just some html files)
Also, if there is more than one clone created, the second clone creates a copy of the first clones wp files into it as well, including the second child version of its self. This is creating a serious amount of bloat within the system.
my main site is 100MB
i trying clone it 10 times. i calculate this much: 100x10= 1000MB… but the result is as follows:
100+100+200+400+800+1600+3200+6400+124000…
i must setup 40 site, and i cant calgulate how much ?
Was there ever any progress on adding the ability to clone a web app to another domain?