WordPress.org

Forums

[resolved] upload path missing? (42 posts)

  1. For some reason, some of the newer subsites created on my multisite are all saving their images to wp-content/uploads, instead of wp-content/blogs.dir/(site#) like other subsites in the install. (I haven't figured out why, but one of them was an imported site, migrated with BackupBuddy...)

    So I opened network edit sites, and while I can find "Upload Url Path" and "Fileupload Url", I can't find an option for "Upload Path" on one of the subsites.

    Why would I be missing this, and where can I find it to fix the upload path?

  2. Are they in /uploads/sites/#/ or in plain /uploads/ out of curiosity?

  3. (Sigh) They were are in /uploads/.

    But here's the really weird thing:

    So the whole issue came to light when after an update (I'm thinking 3.6.1), some sites in the network were missing image headers, then I discovered some sites were missing other images too. At first, I thought it was an iThemes' Builder issue, but then two non-Builder themed sites were affected.

    So this afternoon, after thinking that it's an upload path issue, I started trying to tracking down the missing image files in backups. The missing images were still listed in the affected site media library, and in the media library, individual file urls showed that the file in blogs.dir/#/files, but weren't there!

    I found these files all in /uploads/. They have been there in all my oldest backups. Out of curiosity, I copied the files into the correct blogs.dir folder, and voila-- all the images on the site were back!

    Up until Aug 4 (I'm thinking that's when I updated to 3.6), all the media files in /uploads/ were only for the main site. After that, there are files for a number of other sites mixed in there. For instance, the image header for one site shows it's URL in the media library as: http://subsite.mainsite.com/wp-content/blogs.dir/66/files/2013/07/imageheader.jpg, BUT that file is actually located now at wp-content/uploads/2013/08.

    But I KNOW that this site was functioning normally and displaying this image header correctly about 10 days ago. When I copy the image file to the blogs.dir location, the issue is resolved.

    So I'm thinking that the uploads issue from the 3.6 update might have started this. Here is my original post: http://wordpress.org/support/topic/media-files-not-uploading-to-correct-dir-after-wp36?replies=10

    What I can't figure out is why the update to 3.6.1 triggered this all over again!

    I will get all the images in /uploads/ that don't belong there moved back to their folders, and check the uploads path for the affected sites to double check. [But I also know I have at least one subsite without an option for setting "uploads path". Not sure what to do about that one!]

    What I can't figure out is why those image files from Aug 4 onward that were in /uploads/ (they appear there in all my backups), with file urls to blogs.dir, suddenly stopped working with a WP update.

    Think if the files keep going to /uploads/ that they will keep having this issue every WP update?

    And making sure the upload path is blogs.dir/#/ should keep them from going to /uploads/, right?

  4. Apparently, some of the newer sites don't have an "Upload Path" option. Is that because of the newer way of uploading media? Because this is an older install with blogs.dir, shouldn't all the sites stay that way? Or is there a way to set them to stay that way?

    And if they can't, and the newer sites have to use /uploads/, how come they aren't going to uploads/sites/? All uploads from all the affected sites are comingling in the uploads/2013/month folders.

    Wont' that create issues if I need to export a single site for a client later?

  5. The upload path overrides the default, so in THEORY you never need it unless you've moved stuff or (as in your case) you need to force it.

    I would think if you force it in the options, that would take care of this.

    As for why the update did this, I would speculate it was a plugin gone wild, but I bit the bullet and moved all my uploads to the new format to ditch ms-files.php, which caused me headaches.

  6. I suspect that somehow, iThemes Builder was involved in the triggering of this problem. I did a Builder update to 5.0 on one multisite network, but not another--which also had a few sites with this problem in August, but don't have the issues on the un-updated network. I'm going to test that theory by updating Builder in a bit to see if it triggers issues in that network.

    The files seemed to be uploading to /uploads/, but have file urls in blogs.dir, and seemed to display just fine, until somehow, the update rendered them not found. When I manually moved the uploads to blogs.dir, they reappeared. Weird.

    Here are remaining questions:

    1.) The sites that are uploading to /uploads/ are all uploading into the same directories -- they are uploading into /uploads/2013/09 this month-- all the media from all the sites co-mingling.

    If I bite the bullet to move to the new format, shouldn't the format be /uploads/sites/#/2013/09? And how do I make that happen? (I suspect from your first question above, that you have seen this problem before...)

    2.) Some of the newer sites don't have an "Upload Path" option to change on their site settings. How can I change the upload path for these sites?

    3) Can you point me toward some guidance about biting the bullet and shifting to the new format? (I've searched, but I'm not finding anything) Especially when I have domain mapping on all the subsites going. There are 60 sites, and while they are not generally media-intensive, I want to minimize doing this by hand, if possible. I'm assuming that I have to do it all at one time, and it's not something that can be staged over time...

  7. Ok. This upload path stuff just gets weirder and weirder:

    One of the affected sites (http://berkeleychineseucc.churchwebsiteprogram.com/) was created on 2013/06/24, it's missing serveral images off the home page, but all of them have urls "wp-content/uploads/2011/05/"!

    And, I can't find those images on the server or in my backups! They are no longer in the site media library either.

    In the uploads/2011/05/ directory, I find images for another subsite that was created 2013/08/23.

  8. More weirdness:

    in wp-content/upoads/2013, all months except 09 were missing! I found them in my backup, FTP'ed them in, and images returned to sites.

    Starting with /uploads/2013/08, and in 2013/09, there are media files from the main site, plus at least four subsites, all comingled.

    I'm thinking that means that the funkiness started with WP 3.6...

    Is there some way that 3.6 changed or dropped support for blogs.dir upload paths?

  9. I've searched quite a bit, and I'm not finding out much to help sort this out. I'm still hoping that Ipstenu or someone with more knowledge about this will eventually find time to respond with a suggestion about how to fix my image upload issue.

    I have a multisite install that seems to be trying to use both blogs.dir and uploads. The main site files are in uploads, and I'm ok to leave them there. But:

    1.) the newer sites in the install (created since WP3.6) do not have an option on the network admin edit site settings page to set the upload path. These sites are uploading to uploads/2013 along with the main site. There is no uploads/sites/ directory.

    While this "works" for now-- the images display properly-- if I needed to export one of these sites, the BackupBuddy export of the single site includes all the files in wp-content/uploads/-- which includes all the main site files, plus all the other sites created since WP3.6. That's not too many right now, but it will keep growing!

    I tested the export function of WP, and it fails to import any of the media files.

    So clearly, I want to get this worked out! Is there a way to globally set the upload path for all the sites in the network to blogs.dir?

    OR, how can I get the newer sites to use uploads/sites/[year]/?

    2.) I've also discovered image files for site ID=40 in blogs.dir/70/, and a few other sites are similarly uploading their files to the wrong site ID directory in blogs.dir/#/. Any ideas about what might need to get looked at or reset to keep that from happening?

  10. Thanks for the reply, Mika.

    (sigh) I was naïvely hoping that perhaps this weirdness was something you had seen before that a simple settings change could fix.

    I understand enough of the manual move & scripts posts to know that I need to hire someone to do it before I really mess it up. :-)

    And, that they will probably need to figure out some of what's going on with the flakey sites before the move away from ms-files.php.

    Thanks!

  11. One more question: I just saw this from Ipstenu posted in: http://wordpress.org/support/topic/wordpress-35-upgrade-multisite-issues?replies=31

    As of 3.5, all new installs are in /wp-content/uploads/sites/#/ (except for the main site, which is still in /wp-content/uploads/

    Of note: Nothing changed for existing Multisite instances. They're still in blogs.dir, using /files/ as a redirect via ms-files.php - nothing was moved. The only way WP knows to use uploads instead of blogs.dir is if a new field was added to your database's wp_options table (that is, the absence of the field means you still use /blogs.dir).

    If I have some newer sites using uploads (not uploads/sites/#, but just /uploads/), would it mean that somehow that new field in wp-options got created, and that if I remove it, that will fix my issue? That all the sites will go back to using blogs.dir?

  12. It's a possibility :/ The thing is? It should NEVER change.

  13. Would I be able to tell if it HAD been by looking at the wp-options in the dateabase through myPHPAdmin? What would I be looking for?

  14. My curiosity got the better of me. I looked at the wp_options table, but didn't see anything that look like it should affect upload path.

  15. Is there an entry in wp_sitemeta for ms_files_rewriting ?

  16. Nope. Should there be?

    I thought that got handled in the .htaccess with a RewriteRule...

  17. No, it only gets set if you're starting from WP 3.5 and up.

  18. So it sounds like we have ruled out those two tables as the source of the problem.

    Got my hopes up that we might have found it. :/

  19. Yeah, I'm trying to think of what else to do, except manually force everything ...

  20. How would I manually force those newer sites when they don't have an option for "upload path" in the site settings?

  21. You could create the option in the database, directly. Just edit the table and add that in.

  22. oohh! I've never done that, and it sounds like living on the edge! (for me, at least!)

    Two questions:
    1.) I will definitely backup, but is this something that could break the network, or would I just undo the edit to the table and be ok?

    2.) Does this go in wp_sitemeta or wp-options, or does it go in the options for only the subsites that need it? If in the subsite, which table? And I assume I'm adding "upload_path" and then what would be the correct syntax?

    Ok, that's really more than two questions. I'm game to try it, I just don't want to create even bigger problems!

  23. 1. It shouldn't break the network, but ... well. Anything can happen.

    2. You would put it in wp_x_options

    Looks like this: http://cl.ly/image/0M39313P2139

    So there I have it blank, but if you just make it you'll be able to edit it.

  24. Thanks, Mika! I'll try this over the weekend!

  25. Yaayy! I didn't break anything! :-) And I learned my way around the database a little.

    I added upload_path to the couple of sites that didn't have it, and they now seem to have uploads going to the right blog.dir/[site#]/.

    What I discovered though, in trying to add upload_path to another couple of sites having issues is that they already had an options_name for upload_path, and usually the option_value was to the correct blogs.dir directory, but that the option_id was some random number. None of them were the same. In looking through several other wp_x_options tables, some of the ones with random option_id's had issues, some didn't.

    I wasn't sure at first about changing that option_id, but I did notice that in most of the sites NOT having issues, that option_id was 56. So I made sure all the sites have option_id 56, and upload_path and the correct site# for the upload path.

    In this network, I do have one site ("newsite") that I use as a time-saving template when creating new sites. I clone it by exporting that single site with BackupBuddy, and importing it as a new site. I've done this for quite a while, and most sites have no issues with uploads. But a couple of them had upload paths that were to the blogs.dir/[newsite id#]. Solved that mystery, and corrected their upload paths.

    Now to untangle all the old uploads to wrong directories...

    Thanks for your help, Mika!

  26. That's... weird. 56? What on earth does that mean. Well hey, now we know more!

  27. I thought the 56 as an option_id was somehow tied to "upload_path", although I couldn't find any documentation about this in the codex. The sites that were missing upload_path as an options_name, did not have any option_id for 56-- they just skipped from 55 to 57 (although as mentioned above, some of them had weird IDs like 2116 or 23145 for the ID on upload_path. And other option_names seemed to always have the same option_id number.

    I've never forced a database to do my will before, and it was kind of fun. :-) I do realize (since I am a parent) that forcing it too often will create more problems than it solves, but nice to know that I can get in there to tidy up when needed. Thanks again.

    I'm still tidying, but think it's worth getting some help and migrating the network away from ms-files? That doing that would mean fewer problems down the line?

  28. Just in case anyone comes along later with a similar issue, I'll share that I figured out how I got into this mess:

    To create new sites in the network, I had been using BackupBuddy to export a template site, complete with some base themes, content I wanted all new users to see, and some settings that are the same on all network sites. This was a huge time-saver. And, it worked just fine for more almost 40 sites, up until WP 3.5 and the shift to "uploads/sites".

    Starting after I upgraded to 3.5, those cloned sites have very funky upload issues. Some have no upload_path at all, some have an upload-path with the wrong option_id, some use wp-content/uploads (shared with the main site), some were uploading the same file to multiple directories (for example, "uploads/2013/09" AND "blogs.dir/60/files/2013/09").

    I tested with creating new site through the network admin panel. No issues. Created a new BUB clone: more issues.

    I've reported the issue to iThemes. They show multisite support for BUB as beta, and have hinted that they will not continue to develop it, so I'm not sure if it will get fixed or not.

    BTW, it wasn't until I started to sort this out that I realized that when WP uploads, it creates the date directories based on the original publication date of the post/page. THAT finally explains why a cloned site I created last month has upload directories for 2012!

Topic Closed

This topic has been closed to new replies.

About this Topic