rtklwm

Thanks for the response and explaining the issue and updating the plugin.

Unfortunately, I was not able to resolve the issue and ended up writing a function to do the job. Although I reckon your update is not related to my issue, I would test it … but my site is launched and getting its peak in traffic at the moment.

FWIW, I tested network activating the plugin on both sites as well as not, so maybe that wasn’t the issue. I also tried a few other things like re-saving permalinks, which tends to help with other plugins once in a while.

My guess is that it’s W3tc-related. I’d guess 50%+ of the “issues” I encounter seem to tie back to that plugin but, unfortunately, I don’t often have opportunity to turn that off on production. So, I never know.

Or, .htaccess is another thing that is obviously not exactly the same in both environments, so maybe that’s it.

Thanks again. I like this plugin and wanted to use it. Wanted to provide feedback just in case it’s useful to others or reveals potential fix for others.

I just tested this. It did not seem to change anything for me. I’m using ThreeWP and w3TC W3 Total Cache with Rackspace Cloud Hosting CDN.

Is $target a variable I should change? I’m not sure I understand the edit, but I would like to.

My manual workaround is to go to the media library and “purge the CDN” for the image listed.

This happened to me when I added ShareThis script to my header without using a plugin. I did that so that I could customize it.

I’m not sure what the hash is supposed to do, but they include the option automatically so I wouldn’t be surprised if removing it causes unexpected problems.

https://support.sharethis.com/customer/portal/questions/852209-remove-see-more-sthash-link-from-copy-paste#sthash.vwR0FhSR.dpbs

Hope that helps someone.

Before

doNotHash:false,
doNotCopy:false,
hashAddressBar:true

After

doNotHash:true,
doNotCopy:true,
hashAddressBar:false

Thank you, Abhishek. We are using Ubuntu.

What little I know of permissions tells me that to recursively CHMOD a directory like this to 777 is an unsafe idea, even if it’s a dev server living behind our firewall. Eventually it will go live and I probably will have forgotten that I did this by then.

Anyhow, I did it … and WordPress created /uploads and moved the zip to the file on command. However, it did not run the next step of unzipping. Instead of the original “unable to create directory” error page I got when “uploading” a zip, I now get the “FTP creds required” page: /wp-admin/update.php?action=upload-plugin

So, thank you — that gave me more info. I guess I will look to the Ubuntu forum, per your suggestion … but I feel like I’m missing knowledge of how WordPress handles plugins.

And now I CHMOD wp-contents back to 755. (had to sudo this…) Hope that’s sufficient.
https://codex.www.ads-software.com/Changing_File_Permissions