• Resolved angelxas

    (@angelxas)


    After upgrading my multi-site installation to 3.6 all links to images in the media library have broken. I was previously using 3.5.2 with no problems, and have had to restore my site (https://www.edutronic.net) to that version.

    In 3.6, the images do not show on the site, nor in the dashboard media library, nor do they display if I use the direct URL to the image.

    As part of the troubleshooting I disabled all plug-ins, but this did not fix the fault.

    Has anyone else had this issue and found a solution?

Viewing 14 replies - 1 through 14 (of 14 total)
  • I have not had this issue with 3.6 but I have had something similar when I upgraded a multi-site installation with sub-directories. Check the file upload URL in each of your site settings page. If it is blank, which shouldn’t be a problem, try specifying overtly the proper URL. I believe your Upload url path should be the physical location of the files, ie the url of the multisite plus the Upload Path, probably wp-content/uploads.

    Thread Starter angelxas

    (@angelxas)

    Thanks for this advice.

    I think my files are stored in the folder:

    wp-content/blogs.dir/4/files/

    Does this perhaps mean I should be updating my .htaccess file? It currently reads:

    # BEGIN WordPress
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    
    # uploaded files
    RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
    
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule . index.php [L]
    
    RewriteRule ^([_0-9a-zA-Z-]+/)?siteN/files/(.+) wp-content/blogs.dir/N/files/$2 [L]
    # END WordPress

    C

    Thread Starter angelxas

    (@angelxas)

    If anyone’s reading this and might be able to help, some further information is that the server correctly delivers files if I use the absolute path, like this one:

    https://chris.edutronic.net/wp-content/blogs.dir/4/files/2013/07/inspiration_can.jpg

    but not if I use the link wordpress generates:

    https://chris.edutronic.net/files/2013/07/inspiration_can.jpg

    Reverting back to 3.5.2 again… If anyone can help I’ll be eternally grateful.

    Thread Starter angelxas

    (@angelxas)

    I’m not sure if anyone else is having the same problem as me, but after a lot of time experimenting with different options I still haven’t managed to find a solution.. I assume the problem resides in the .htaccess file but don’t have the necessary knowledge to fix it!

    Any help would be much appreciated.

    Chris

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    Can you check in your DB and see if ms_files_rewriting is set in wp_sitemeta?

    Thread Starter angelxas

    (@angelxas)

    Hi there!

    I’ve checked and there is no entry in wp_sitemeta with the key “ms_files_rewriting

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    *hrm* Well that’s ‘good’ (if it is there, that’s what tells 3.6 to use, or not use, the ms-files.php file).

    I noticed you have this in your .htaccess:

    RewriteRule ^([_0-9a-zA-Z-]+/)?siteN/files/(.+) wp-content/blogs.dir/N/files/$2 [L]

    Have you ALWAYS had to force WP to redirect like that? That’s indicative of your sever not knowing how to handle this:

    RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

    And that generally means that your httpd.conf file is too restrictive and doesn’t have ‘AllowOverride’ set to ‘All’ (or ‘Options All’ – depends on the server)

    Thread Starter angelxas

    (@angelxas)

    Hi there.

    Thank you so much for attempting to assist me with this. Here is what my httpd.conf file contains:

    Options All -Indexes -ExecCGI -Includes +MultiViews
    		AllowOverride All

    – Which looks right, I think. I wish I could be more useful here.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    Have you ALWAYS had to force WP to redirect like I asked above?

    (You may need to change httpd.conf from AllowOverride All to AllowOverride Options All)

    Thread Starter angelxas

    (@angelxas)

    As I recall, yes I have always had to force the redirect.

    I’ll make that change to the httpd.conf and try upgrading again and let you know how it goes.

    Thread Starter angelxas

    (@angelxas)

    Unfortunately this didn’t work either.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    ?????? Advisor and Activist

    Well, I hate to say this, but the problem is your server. If you’ve always had to put in lines like this, then there’s something majorly wrong and it doesn’t understand complex htaccess :/

    RewriteRule ^([_0-9a-zA-Z-]+/)?siteN/files/(.+) wp-content/blogs.dir/N/files/$2 [L]

    I would actually recommend you change your site to no longer use the /files/ stuff at all. You can tweak your site to use the ‘new’ standard, of /wp-content/uploads/sites/ instead – https://halfelf.org/2012/dumping-ms-files/

    It’s not super easy, but if your server doesn’t like the htaccess stuff, you may have to :/

    Thread Starter angelxas

    (@angelxas)

    Thank you again!

    I’ll have a look into this, but as I have other multisite installations on this server working perfectly, it seems only to be an issue with this one, which was upgraded from an older version. The others are a fresh installation at WordPress 3.6

    I’ll keep investigating. I’m sure it’s something small and simple.

    Again, I really appreciate your continued support.

    Chris

    Thread Starter angelxas

    (@angelxas)

    Hi again.

    I decided to solve this by making a clean installation of wordpress 3.6 multisite on my server and manually importing all the old blogs. It’s worked well and there are no problems with file locations.

    I just wanted to thank you for your help and wish you a good day!

    Chris

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Media links broken after upgrade to 3.6 multisite’ is closed to new replies.