#15360 closed defect (bug) (invalid)
posts_nav_link misbehaves in wpmu->3.0 multisites
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Multisite | Keywords: | |
Focuses: | Cc: |
Description
I have two servers on 3.0.1
Server A is a WPMU upgraded site to 3.0.1
Server B is a 3.0.1 fresh install set up to be multisite.
Same theme code. Same blog import file for both.
When I get enough search results to span multiple pages, these sites output different links on the "Older Entries" link [displayed by posts_nav_link()], and only one of them works (Server B - the fresh install).
Server A link (wpmu upgraded - doesnt work):
http://{site-A-.com}/{site-slug}/{site-slug}/page/2/?s=post&submit=GO
Server B link (fresh multisite - works):
http://{site-B-.com}/{site-slug}/{site-slug}?s=post&submit=GO&paged=2
(Additionally, I don't believe the function ever actually worked correctly on WPMU 2.9.2 either)
Change History (11)
#2
@
14 years ago
With the Default permalink settings, the error does NOT occur.
It does continue to occur with the following settings:
Day and Name
Month and Name
Numeric
Custom: /archives/%post_id%
#3
@
14 years ago
- Milestone Awaiting Review deleted
- Resolution set to duplicate
- Status changed from new to closed
#4
@
14 years ago
- Resolution duplicate deleted
- Status changed from closed to reopened
Re-opening per @nacin because this in fact wasn't a duplicate.
I've also confirmed that the next_posts_link and previous_posts_link generate the same erroneous URLs.
Also, this is on a subdirectory install if that wasn't clear from the sample URLs.
Just let me know if anyone needs more info.
#6
@
14 years ago
- Milestone changed from 3.1 to Future Release
Punting all tickets that are not regressions in 3.1.
#7
@
14 years ago
Some updates!
For starters, this bug only matters on the first page of results, where it repeats the site name in the URL. If you url hack one of the instances out to get to page 2, the links there, for forward and back, work as expected.
I did a bunch more debugging, and believe the problem is here, within get_pagenum_link
right after setting home_root, there are two preg_replace calls on $request.
Here's what happens when it's done right, a la subsequent pages after the first, such as:
http://dev.myschool.edu/jason/page/2/?s=test&x=0&y=0
in get_pagenum_link, before anything with request, request is apparently []
home_root has been defined as jason/
after the first preg_replace on #request it is [page/2/?s=test&x=0&y=0]
after the 2 preg_replaces on request, it is now [page/2/?s=test&x=0&y=0]
When it is done WRONG, a la the first page, here is what is done (url is: dev.myschool.edu/jason?s=test&x=0&y=0)
in get_pagenum_link, before anything with request, request is apparently []
home_root has been defined as jason/
after the first preg_replace on #request it is jason
after the 2 preg_replaces on request, it is now [jason?s=test&x=0&y=0]
hopefully that gives enough info and tees it up for someone who actually knows what's going on to fix :)
let me know if you need more info
I've got a WPMU site that has gone through upgrades from 2.0-ish to 3.0.1. I can't reproduce the error. My links look like your "Server A" links, but work perfectly.