Hi,
if i tail -f the log when i clone i get:
2013-04-25 05:21:31 - Site: wealthawareness.com.au/neilns// created!
2013-04-25 05:21:31 - wealthawareness.com.au/neilns/ cloned in 0.821026086807 seconds.
Yes some of the media is not getting cloned
That looks like the Historical Log. What about the Detailed Log? It will be named something like:
ns-cloner-20130425-054251.html
Can you please tail -5 (or more) that and post? Thanks!
I am running 3.5.1 and the /wp-content/uploads/sites/IDNUMBER is set to 755
Thanks, yeah, those permissions should be fine. From the full log it looks like something (maybe your theme or another plugin) might be altering the default uploads location (or at least the location that the WP API returns for wp_upload_dir()). We’ve noticed that some themes (like roots) or plugins that modify or add dynamic rewrites, affect the output of wp_upload_dir() which the cloner relies on to auto-detect the correct folders to copy. From your log, here is where WP is telling the cloner that the location is:
2013-04-25 05:21:31 – From: /home/wealthaw/public_html/wp-content/uploads/sites/19/2013/04/sites/19
2013-04-25 05:21:31 – To: /home/wealthaw/public_html/wp-content/uploads/sites/23/2013/04/sites/23
Obviously, that last /2013/04/sites/19 should not be in the path. We added some advanced additional handling in the Pro version to detect situations like this where wp_upload_dir() returns bad info, but we haven’t had a chance to port those updates to the Free version yet. We’ll try to get that done.
In the meantime, you can always manually copy the /wp-content/uploads/sites/19 dir to a new /wp-content/uploads/sites/23 dir (or whatever the correct IDs are) and that should take care of the media files and everything else should work correctly.
Look for updates to the plugin in the near future to fix this issue (it’s actually fairly rare, but once in a while crops up with when the uploads location is modified by a theme or plugin). Thanks!
ok thanks so does that also answer the original error?
FYI – the same issue regards the path also had incorrect media upload path when trying cloning with ‘Add Cloned Sites for WPMU (batch)’
The theme used is http://themeforest.net/item/scrn-responsive-single-page-portfolio/2964855
Sure thing!
Yes – the cloner tries to create the target dir (ID) if it doesn’t exist. In this case the mkdir is failing because it’s trying to create /23 in the path /home/wealthaw/public_html/wp-content/uploads/sites/23/2013/04/sites/ but that path doesn’t exist (it should be /home/wealthaw/public_html/wp-content/uploads/sites)
Once we patch this it should work with any theme / plugin even ones that modify the path, as it will systematically check the returned path to see if it exists. If it doesn’t exist (bad theme/plugin), then it will look for the standard places where the path should be. When it finds it, then will it run the copy.
Your case will be great to verify the update fixes the issue. Thanks!
ok happy to test whenever you’re ready – have set thread to follow-up via email
Thanks! We’ve pushed an update that should fix this issue. Please confirm and re-open this thread if it did not work in your scenario. You can check your detailed log when the cloning completes and should see new entries that indicate when additional path verification has to kick in to compensate for wp_upload_dir() weirdness.
Let us know if this works for you!
Have a great weekend!
Hi there – I am still getting the same error when cloning:
Warning: mkdir() [function.mkdir]: No such file or directory in /home/wealthaw/public_html/wp-content/plugins/ns-cloner-site-copier/ns-cloner.php on line 1048
Warning: mkdir() [function.mkdir]: No such file or directory in /home/wealthaw/public_html/wp-content/plugins/ns-cloner-site-copier/ns-cloner.php on line 1048
Warning: mkdir() [function.mkdir]: No such file or directory in /home/wealthaw/public_html/wp-content/plugins/ns-cloner-site-copier/ns-cloner.php on line 1048
Warning: Cannot modify header information - headers already sent by (output started at /home/wealthaw/public_html/wp-content/plugins/ns-cloner-site-copier/ns-cloner.php:1048) in /home/wealthaw/public_html/wp-includes/pluggable.php on line 876
Here is the log…
http://wealthawareness.com.au/wp-content/plugins/ns-cloner-site-copier/logs/ns-cloner-20130427-050353.html
Arg! ok it looks like maybe the new updates are getting bypassed in your scenario because those paths already include the site ID (even though the paths themselves are wrong and repeat the date and ID).
We just pushed another update (2.1.4.4) that should force the new checks in your situation. Fingers crossed. It will also add a couple new clues in the logs if it still doesn’t work and we’ll have a little more to go on. There might be something weird going on with your .htaccess file or dynamic rewrites. Everything else works fine though, right?
Anyway, please give 2.1.4.4 a whirl and let us know. Thanks!
Hi thanks for the follow through – if I use the plugin in a pure ‘vanilla’ set up it works fine. I must have an issue with this particular site or theme or restore issue from an older version of backupbuddy multisite import.
I was trying to clone the master site in a WPMU set up but I know that has its own issue and is something you are trying to address.
So I created a standalone site did a backup with backupbuddy and then a multisite import in my WPMU setup and yes I am noticing the site id year/month duplication in the path which i guess is causing the initial error and then creating invalid image paths.
It it is of any use the last log is below – I will try the backup/import process again and ensure I have latest version of backupbuddy and the try nsclone to do the duplication and see how i go – many thanks…
http://wealthawareness.com.au/wp-content/plugins/ns-cloner-site-copier/logs/ns-cloner-20130428-083634.html
Cool, yeah – that would be my guess too. Thanks for trying the latest version. I think there is some sort of problem with that site’s media file path. From the log here’s what is getting returned:
2013-04-28 08:36:36 - Original basedir returned by wp_upload_dir() = /home/wealthaw/public_html/wp-content/uploads/sites/20/2013/04/sites/20
I expected this to get auto-corrected by the new version but it isn’t dropping into that section of code which means it’s passing both tests:
#1 – it contains the site ID
#2 – that directory actually exists in the source site (the one we suspect might be messed up somehow, because that is a wonky media file uploads location).
What happens is that directory exists so it thinks that it can create the target directory (29) but /uploads/sites/29/2013/04/ doesn’t exist because the normal path is /uploads/sites/
Anyway, glad to hear it works on a vanilla site. You can always also check /wp-admin/network/site-settings.php?id=20 and do a page search for Upload and see / change those values to correct them. They might be messed up in the options table from something gone awry somewhere. You should be able to delete 2013/04/20 from the end of those and be good to go. (unless something else is messing that site up too)
Take care!
