2.9.2 to 3.0 htaccess not upgrading & breaks image paths

[gazouteast]

The following bug report refers to three different hosts, where using installations in "add-on" domains (i.e. not the main hosting account domain names) - all DNS and Vhosts and other WPMU requirements were / are set correctly, and all affected domains were running perfectly under WPMU 2.9.2 / WP 2.9.2 standalone. All WPMU installs were and remain subdomain installs.

I tried to auto-upgrade (from wp-admin) from 2.9.2 (single blog and WPMU) to WP 3.0 (single blog and WPMU) and had the same results each time ....

Issues common to all upgrades -

• loss of images display in admin, media uploader (after upload), and on page/post editor, and on published and draft posts (both preview and published).

The only way to view images was to use the edit image button in the media gallery, or to go to the subblog folder in cPanel/Plesk and select to view file - no other method showed the image was present if using any path/to/folder variation associated with normal URLs or file paths.

Fix?

• Delete completely (or comment-out / rename for roll-back use) the entire WP / WPMU 2.9.2 .htaccess content.
• Insert the standard WP 3.0 .htaccess content posted all over the wp.org forums - be sure to choose the CORRECT .htaccess content to insert (single blog or multi-site? / subdomain or subdirectory setup?).

This only works fully PROVIDED the server has fread() and fopen() enabled on it, otherwise it still does not work.

• if any of those three are not done, images will not display.

<u>Note:</u> fread() / fopen() are going to cause deprecated-class problems on PHP 5.3.x servers (see php.net notes around those for PHP 5.3+). WP should begin building in forward compatibility for the replacement classes.

The prime cause appears to be

• WP failing to correctly update the .htaccess file (in none of my installs did it make any changes at all - they all had to be done manually, which is not what I call an "automatic upgrade").
• plus the switch from wp-content/blogs.dir.php to wp-includes/ms-blogs.php (for MU / MS installations' sub-blogs) caused issues as below.

Issues common to all WPMU (subdomain) to 3.0ms upgrades -

• Sub-blogs display only the theme and the sidebar / menu lists of categories, pages, posts (plus the content quantity is enabled),
• - the actual posts and pages, single-posts, category_pages, tags_pages, archives, etc., pages all return "nothing found" 404 pages.
• In admin, looking at any of the page, post, category, tag etc., edit/manage lists does the same - it does show how many are in the database at the top of the list, but returns a "nothing found" / "list is empty" short message immediately under the top of list buttons, and does not display the expected data.
• Fix? I've tried everything I can find that is suggested in these forums, at trac.wp.org, and on the WPMU and BuddyPress forums - nothing cures this. My multi-site domains are completely non-functional except for the home blogs on each, which still work.

After upgrade to v3.0, the sub-blogs posts pages etc showed in admin and public side, but no images were showing anywhere on the network in admin or public side - hence the manual change to the htaccess, which returned the images to the home blogs in a multi-user site.

But that then caused the full loss of post and page content display, even though side bar content lists (category, latest posts etc) showed the correct post-titles lists, and admin shows the correct (numerical)number of (page / post / tag / category) items on the respective lists pages, but returns "nothing found" in the location where the items should list out. All the info is still in the database, but the site is giving a 404 error when trying to view it, including on the home page of any sub-blog. Only the home blog is functioning normally.

I've had this on the three hosts listed below, on at least two sites each, and nothing in the WP.org, WPMU, or BuddyPress forums have offered a fix that's worked, neither has anything here on trac. I think I've tried everything written and suggested in all of them.

Many, many people are reporting similar issues in the forums mentioned above (it is NOT "just a few", it is many people!), sometimes jumping on other people's threads, sometimes starting their own - esmi moderator's liturgous chant with the copy and paste "fix list" is not working for people.

I see many people now posting they have given up on 3.0 and rolled back to 2.9.2 - this is major bad news for WP ... could a CafePress-WordPress style of code-fork appear because of this, and a new competitor for WP emerge because of it? Is WP doing an eBay? How much of this comes from the "capital-P-dangit" intrusion?

There is something broken in either the new ms-blogs.php and/or the htaccess updater. There is certainly something majorly wrong with WP 3.0 if the avalanche of forum and blogging posts is anything to go by.

I have found NO (working) fix to get the sub-blog content displaying after fixing the image display issues with htaccess, and no fix for the image display if reverting to sub-blog content displaying - 3.0 is allowing me one or the other, not both.

Sample site to view this happening = ​http://checkedbyyou.com (home blog) and ​http://webhosting.checkedbyyou.com (sub-blog) - this is a site I began working on under WPMU 2.9.2 (subdomain install) and used as an early test of the auto-upgrade to WP 3.0 - it has just enough content on it to show the problems described above. It worked fully and perfectly under 2.9.2

Repeatable? Heck yes - every domain I've done so far has resulted in this.

WEB-HOSTS INFO
webhostingpad.com (cPanel)

• Linux 2.6.18-194.3.1.el5
• MySQL 5.1.46
• Apache 2.2.14
• PHP 5.2.12

unlimitedwebhosting.co.uk (Cloud / Plesk)

• Linux 2.6.32.13-2.art.x86_64
• MySQL 5.0.77
• Apache ?
• PHP 5.2.13 (Zend: 2.2.0)

namecheaphosting.com (cPanel)

• Linux 2.6.18-194.8.1.el5
• MySQL 5.0.90-community
• Apache 2.2.15
• PHP 5.2.13 (Zend: 2.2.0)

[ryan]

Indeed, htaccess is not automatically updated. It likely never will be given that we would have to bring the filesystem abstraction code into the picture and require FTP auth to get write access. Further, many multisite operators heavily customize their rewrite rules and we'd have to take care not to stomp those customizations. Upgrading MU/multisite imposes a greater burden than upgrading single site WP.

[nacin]

As Ryan explained, we don't update the .htaccess file when running multisite.

The MU .htaccess file, of which there are many variations as it evolved over the years, works fine in 3.0. The old .htaccess files use wp-content/blogs.php, which we do not delete on an upgrade, and you only need to switch to ms-files.php if you choose to do so.

I don't see a bug here. I've ran a few MU-to-3.0 upgrades and have not experienced problems with content loss or image path corruption. The old MU .htaccess file worked fine, though I did end up upgrading them to use ms-files.php and the new .htaccess file.

[gazouteast]

Replying to ryan:

Indeed, htaccess is not automatically updated. It likely never will be given that we would have to bring the filesystem abstraction code into the picture and require FTP auth to get write access. Further, many multisite operators heavily customize their rewrite rules and we'd have to take care not to stomp those customizations. Upgrading MU/multisite imposes a greater burden than upgrading single site WP.

Sorry Ryan - but that's a cop-out. WP already has FTP access for auto upgrades of core, themes, and plugins - and you of all people should know that after the debacle in 2.7.x when the FTP credentials saving got scrambled because of the unpublished need to increase php memory allocation pre-upgrade to 2.7.x

Also, as you know, htaccess reads and activates in a cascade the same as css - last rule read is the one applied. Therefore you could APPEND the new content to the old file and provide an admin page for site admins to debug from.

[gazouteast]

Replying to nacin:

As Ryan explained, we don't update the .htaccess file when running multisite.

The MU .htaccess file, of which there are many variations as it evolved over the years, works fine in 3.0. The old .htaccess files use wp-content/blogs.php, which we do not delete on an upgrade, and you only need to switch to ms-files.php if you choose to do so.

I don't see a bug here. I've ran a few MU-to-3.0 upgrades and have not experienced problems with content loss or image path corruption. The old MU .htaccess file worked fine, though I did end up upgrading them to use ms-files.php and the new .htaccess file.

In which case nacin you have introduced another new bug - the admin screens carry a warning to delete blogs.dir and change to ms-files whilst keeping the public side in maintenance mode and inaccessible - there is no OPTION given, it is a MUST DO action following upgrade.

On a clean 2.9.2 install, auto-upgraded to 3.0, the old htaccess DID NOT "work fine" for me - on 3 servers on two continents. You obviously failed to test something, or had a reversion after testing, which then broke something - why are so many forum threads complaining about this? It it looks like a cow, smells, like a cow, and moos like a cow, then it probably is a cow.

Again - you do NOT need to delete the old htaccess - you could rename it for roll back purposes, or append as I answered to Ryan.

Why are you both obfuscating and avoiding? Is this a path to generating paid support requests? Go read the wp.org forums and you'll see how many people's sites this upgrade has broken.

[gazouteast]

OK Guys - I think the only thing to do now is have a few people cast their eyes over the old and new htaccess content - I can see the differences, but have no idea what they imply.

Please refer back to my original report above, for how the two versions affected the behaviour of the site - I have messed around enabling and disabling bits that look similar but are not, to see if it fixes anything, and it does not.

The "Old" version was from a clean WPMU 2.9.2 install, the "3.0" version taken from a forums post.

# Begin OLD WordPress htaccess
RewriteEngine On
RewriteBase /

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RewriteRule ^(.+)$ $1/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>
</IfModule>
# End OLD WordPress htaccess

The above content is the default within the WPMU 2.9.2 htaccess.txt and is what was present when the site worked under 2.9.2 - it did not work with it under 3.0

I have been completely unable to find either an htaccess template or a generator within the 3.0 download files - I have no idea how anyone arrived at the following v3.0 htaccess, but it is the one some people in the forums are claiming is working for them.

# BEGIN WordPress 3.0
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress 3.0

So - all in all, I am stumped and no further forward with a large part of my site portfolio either broken and bouncing everything as 404 with my Google ratings now thoroughly trashed and some sites about to be delisted in Google, or totally stalled in development because sub-blogs are banjaxed.

[duck_]

Replying to gazouteast:

I have been completely unable to find either an htaccess template or a generator within the 3.0 download files - I have no idea how anyone arrived at the following v3.0 htaccess, but it is the one some people in the forums are claiming is working for them.

See ​wp-admin/network.php, that is what generates the .htaccess file code to use when the Network is first enabled. This is outputs what you have posted as the "3.0 htaccess", one of the important parts (at least it looks like it, not a multisite expert) is the uploaded files line which is different for subdomain installs (line 463):

RewriteRule ^' . ( $subdomain_install ? '' : '([_0-9a-zA-Z-]+/)?' ) . 'files/(.+)
wp-includes/ms-files.php?file=$' . ( $subdomain_install ? 1 : 2 ) . ' [L]' . "\n";

You have posted the subdirectory version of the "3.0 htaccess" file.

[gazouteast]

@duck_ Many thanks, now at least I know where it's created, but cannot make head nor tail of it. The line you highlighted looks nothing like either the 2.9.2 version (that worked) or the version I copied from the forums, possibly that is the problem source for sub-blogs not displaying post content, and for admin pages not listing post details.

I also noticed (the ex WPMU site I'm trying to get working) that I have no Network menu option anywhere, and that the media settings screen does not have the uploads path settings shown in the screen shot at
​http://codex.wordpress.org/Settings_Media_SubPanel

So the question now kicks in that, as this was a WPMU site under 2.9.2 rather than a WP standalone, and was auto upgraded to 3.0 ms, has the update script missed a whole chunk of stuff? I re-ran the updated from Super Admin and from Dashboard just to be sure, but that did not resolve things either.

So, returning to Duck_'s reply - if the version I've grabbed off the forums is for a sub-directory install, what should a DEFAULT multi-site 3.0 htaccess contain, and why is this not documented anywhere (believe me I have searched relentlessly for it) and why is no sample_htaccess_subdom_ms.txt and sample_htaccess_subdir_ms.txt included in the download package?

My original bug statement stands - in relation to htaccess upgrading the package is incomplete, and that incomplete condition has stopped me from further developing, or putting live, a bunch of sites - hence the blocker status I assigned to it.

Back to forum trawling in the hope of finding a full htaccess content for subdomains

[duck_]

Replying to gazouteast:

@duck_ Many thanks, now at least I know where it's created, but cannot make head nor tail of it. The line you highlighted looks nothing like either the 2.9.2 version (that worked) or the version I copied from the forums, possibly that is the problem source for sub-blogs not displaying post content, and for admin pages not listing post details.

That's because I pasted the line of PHP which generates the uploaded files line for the .htaccess file; it will output two different versions of said .htaccess line, one for subdomains and the other for subdirectories. I believe this would be the subdomain version:

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

The other version is exactly the one seen in comment #5. There are a couple of other differences if you read the code from network.php; the full subdomain .htaccess file ouput would be ​this. This ticket appears to be turning into a support thread.

[gazouteast]

Replying to duck_:

Replying to gazouteast:

@duck_ Many thanks, now at least I know where it's created, but cannot make head nor tail of it. The line you highlighted looks nothing like either the 2.9.2 version (that worked) or the version I copied from the forums, possibly that is the problem source for sub-blogs not displaying post content, and for admin pages not listing post details.

That's because I pasted the line of PHP which generates the uploaded files line for the .htaccess file; it will output two different versions of said .htaccess line, one for subdomains and the other for subdirectories. I believe this would be the subdomain version:

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

The other version is exactly the one seen in comment #5. There are a couple of other differences if you read the code from network.php; the full subdomain .htaccess file ouput would be ​this. This ticket appears to be turning into a support thread.

@ Duck - nope - this is not a support thread - this is trying to convince the core devs that they have well and truly screwed up surrounding the htaccess creation in 3.0

This thread contains some classic debugging of the issues above -
​http://wordpress.org/support/topic/412026?replies=28

It also identifies that 3.0's use of /files/ as part of the rewrite path is at the heart of all the issues ... as the rewrite function uses "files" and "file" as reserved use command words, yet WP have introduced them as part of the path.

Ergo - Another bug in WP 3.0 htaccess writing and sub-blog path structures.

[gazouteast]

Duck - your linked code doesn't work - just causes an indefinite loop trying to load the subdomain blog and the page never finishes loading - hope I'm not about to get a warning slap from my hosts for resource abuse by trying it.

[wpmuguru]

Closing. Based on several posts in the support forums, it appears the reporter added the MULTISITE constant to wp-config & renamed tables, etc.