2.9.2 to 3.0 htaccess not upgrading & breaks image paths
|Reported by:||gazouteast||Owned by:|
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.
- 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.
- 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 18.104.22.168-2.art.x86_64
- MySQL 5.0.77
- Apache ?
- PHP 5.2.13 (Zend: 2.2.0)
- 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)
Change History (12)
- Keywords close added; BUG htaccess 404 images ms-blogs.php blogs.dir.php WPMU 2.9.2 removed
comment:11 wpmuguru — 3 years ago
- Keywords close removed
- Resolution set to invalid
- Status changed from new to closed