Alamoxie Web Design

I can’t be sure of the exact problem you are having, but here’s something to try.

https://mobile.awsblog.com/post/Tx1OSMBRHZVM9V0/Understanding-Amazon-Cognito-Authentication-Part-3-Roles-and-Policies suggests “Access policies don’t require Principal elements, it sounds like you may have been entering this as a trust policy, not as an access policy.”

Thanks for your thoughts, George.

I already had a unique S3 user for that bucket; nobody could download from that bucket without that user’s access token and secret access key, and that user only had access to that one bucket.

I have the website configured to keep plugins and the WordPress core up to date automatically, and to check for and prevent security issues.

The passwords I use are always very long and fully randomly generated, so they would definitely not be in any top password list.

I could be wrong, but I believe a skilled attacker would not be stopped by not knowing the database name or table prefix ahead of time.

However, you have provided much valuable food for thought–your post prompted me to do further research on WordPress security, and now I am taking extra steps to secure my sites going forward. In addition, I have changed much of what you suggested, to be absolutely certain of avoiding issues. Thanks for your detailed and helpful response!

Thanks Jan, much appreciated.

Thanks for the great support, Daniel! The new policy (replacing both instances of “dhdev” with my specific bucket name) works on PHP 5.4 and 5.2. The old Amazon S3 IAMS policy worked just fine–until the server used anything higher than PHP 5.2. Now I have a solution for my sites, and hopefully the information here will be of use to others in the future. Thanks again!

I have the exact same situation.

Here is my brutal hack. If anyone has an alternative plugin suggestion, or if the plugin adds this feature in the future, that would be awesome.

Edit youtube-sidebar-widget/script.js

In
$('body').prepend("<div id='ysw-overlay'></div><div id='ysw-viewer'><a href='#'>close</a><iframe title='YouTube video player' width='640' height='390' src='https://www.youtube.com/embed/" + hash + "' frameborder='0' allowfullscreen></iframe></div>");

add
?rel=0
to the end of the link to result in:

$('body').prepend("<div id='ysw-overlay'></div><div id='ysw-viewer'><a href='#'>close</a><iframe title='YouTube video player' width='640' height='390' src='https://www.youtube.com/embed/" + hash + "<strong>?rel=0</strong>' frameborder='0' allowfullscreen></iframe></div>");

In my WP 3.3 installation, I noticed that if you change the main post editor between Visual and HTML, then the Advanced Custom Field WYSIWYG does not change immediately… but when you refresh the post edit page, it also changes types. A little inconvenient, but I can use the WYSIWYG editor in either HTML or Visual mode that way, by changing the main one at the top of the page and then refreshing. Does that help you, or does yours never change?

Will the plugin use cURL soon? Suddenly the plugin stopped working on multiple sites on my HostGator account. I developed issues with another plugin at the exact same time. Support wasn’t very helpful; in the end, they said there was some mod_security rule they had to whitelist on a site-by-site basis as I requested it, which is obviously a major pain in the rear, and the fault there lays with HostGator.

I suspect they are making configuration changes, server by server, to cause trouble for anything using fopen (although that’s just a hypothesis at the moment). Even if I set php.ini to allow it, their settings cause problems for several plugins.

So what I’m saying is, IF I’m right and it’s an fopen thing, then your plugin may not work at all on some web hosts (at least not without extensive quality time with their tech support). I’m hoping changing to cURL will fix this, and that anyone having trouble using it on HostGator will see this thread and know what to try.

luxman, bradleyclarke, did you try downloading (manually) and uploading (via FTP) the plugin? The version currently in the plugin repository identifies as the same version you probably already have, but actually does contain different code that fixes the error.

Bradleyclarke, I did have problems sometimes trying to access the dashboard, but usually if I refreshed the page I could get in.

I also developed issues with another plugin at exactly the same time, again on multiple sites, so obviously HostGator is making some sort of configuration change to their servers. Regarding the other plugin, they told me they needed to whitelist the URL for a mod_security rule, but refused to tell me which one. (I don’t know, but suspect it may have something to do with fopen) If you go to them and ask them to find the error in their logs and find the appropriate mod_security rule to whitelist, that may take care of the same issue, or related issues that happen at the same time.

Downloading the most recent version of the plugin and uploading that seems to work as well as deleting and reinstalling the program–which surprises me, since WordPress was showing that I have the most recent version.

Daniel Hueskan, this is an AWESOME plugin and I appreciate all your work… but please, when you make functional code changes to the plugin, please increment the version number so that we are aware we are not using the oldest version and can easily update it (through the WordPress interface without FT or deleting and reinstalling the plugin).

Although I have a solution, I have no idea what caused the problem. BackWPUp was working splendidly until today, so what could have causes it to simultaneously stop functioning on almost all my sites? No idea…

I’m having similar issues. Just started happening today on HostGator.

Warning: file_get_contents(https://alamoxie.com/wp-content/plugins/backwpup/job/job_run.php) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/alamoxie/public_html/wp-content/plugins/backwpup/backwpup-functions.php on line 732

This same error started happening on ALMOST all my HostGator sites (which are all on the same server). I’m not sure why a few were not affected. If I completely uninstall and reinstall the plugin, it seems to work again, but that may just be temporary.

I’m using Amazon S3 + CloudFront + W3 Total Cache. Latest versions of WordPress and W3 Total Cache.

You may have the same problem I do if you make some change to minification–for example, adding or removing a CSS or JS file–and then it can’t find the file. I check this in Google Chrome by right-clicking the page, clicking “Inspect Element” and then going to the Resources tab and expanding the different types of files. A red flag shows beside any CSS or JS files with errors… and often the error, for the combined file W3 Total Cache created, is a 404. Indeed, when I look in the Amazon S3 bucket I see that the file it is referring to is not actually there!

After extensive experimentation, I think there’s some bug in W3 Total Cache, and the workaround is to disable minify and then enable minify each and every time you make a change to any minify settings. Hopefully this will help other people.