-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
S3-Uploads failing to create a new monthly directory #46
Comments
FYI. The Wordpress server created a new monthly directory at 12 am on 9/1 automatically. It doesn't appear that S3-Uploads intercepted this action. |
Hi @Grendel61, So S3 doesn't create the directory, as technically s3 doesn't actually have directories - only paths to files that include If WordPress is still creating the directory, it sounds like it's not using S3 Uploads somehow, because as far as WordPress is concerned, it's uploads directory is the s3 location. We do also have a bug in the verify command in #39 so the passing of the verify may be giving you a false positive. Can you confirm your website is serving the files from s3? Rather than the local site url |
Thanks for the reply. It turns out this isn't a problem generally with S3 Uploads. I did notice that the plugin may have been turned off when I was debugging a theme and then I didn't resync, but that was a separate issue. The problem is isolated to a plugin called Buddypress Cover Photo https://wordpress.org/plugins/buddypress-cover-photo/ from SeventhQueen. Its a fairly popular plugin, and it must be doing some kind of absolute pathing, because it can't get past the upload. Because, the file doesn't get pushed to the S3 and the it doesn't get put on the server either. I need to sort this out, because there isn't a better plugin for the purpose, and my users like this feature. I just hadn't got to a test case with S3 Uploads and this plugin's cover photo process. Somehow the plugin overrides the URL pathing from S3 Uploads and looks in the server directory. The files that were synced are out on S3, but it doesn't use them. So this plugin seems to force the upload and the read to look in the absolute path. If you've seen this problem before, maybe you could give me a hint where to look for this issue. My own investigation turned up this ...
If I can figure out how this is causing the problem, maybe I can contact the plugin vendor, or possibly call a different function. |
@Grendel61 I had a look at the plugin, and it appears to use |
Yeah it is the plugin, or possibly some override in the theme (Kleo) which is made by the same company, but I doubt it. I don't have any other problems in the core. The annotation on the code says that it modified the core somehow, I thought that meant customizing the profile picture upload in Buddypress, but I think they may have done something else to it. I'd appreciate if you could see if the plugin fails on your Wordpress with S3 Uploads, if it does maybe I can help the plugin developer quickly isolate the problem. I'll spend some more time and see if the customization made any obvious changes, but I suspect the next step will be talking to the developer. |
Hi,
Great work on this!
I've been using the code for about a month in a staging server. I installed the code and moved the historical files in August, and with it moved the file structure which included a folder for August (uploads/edd/2015/08). As the month flipped from August to September, I tried uploading a file today and it is showing an error on the Wordpress side that it can't move the file to uploads/edd/2015/09. When I look on S3 the directory wasn't created, however there is a directory on the Wordpress server. Permissions on the "09" directory are set to 776 and the owner/group is correct as well.
I could obviously create the folder on S3, and try it. The permissions on S3 have worked, and the "verify" command was successful (although it doesn't create a directory). I suppose I haven't seen the code create a directory before with the exception of the initial load.
Any ideas?
The text was updated successfully, but these errors were encountered: