WordPress.org

Make WordPress Core

Opened 22 months ago

Closed 22 months ago

Last modified 21 months ago

#21020 closed defect (bug) (fixed)

Use of $walk_dirs for post permastructure is relied upon

Reported by: taropaa Owned by: duck_
Milestone: 3.4.1 Priority: normal
Severity: major Version: 3.4
Component: Rewrite Rules Keywords: has-patch needs-testing
Focuses: Cc:

Description (last modified by duck_)

[19737] for #19876 changed the $walk_dirs parameter in the generate_rewrite_rules() call for posts to be false. Although it fixes some bugs this behaviour was relied upon by some users.

Please take a look at this (in the wordpress forums) for more info: http://wordpress.org/support/topic/permalink-structure-no-longer-works/page/2?replies=38#post-2911028

Attachments (2)

21020.hotfix.diff (877 bytes) - added by duck_ 22 months ago.
21020.diff (2.2 KB) - added by duck_ 22 months ago.

Download all attachments as: .zip

Change History (19)

comment:1 ocean9022 months ago

  • Version set to 3.4

I can confirm this.

Permalink setting: /%post_id%/%postname%/

In 3.3 you could also use domain.com/%post_id%/ which shows the same post as with domain.com/%post_id%/%postname%/. But it doesn't did a redirect.

In 3.4 domain.com/%post_id%/ throws 404.

IMO domain.com/%post_id%/ should redirect too domain.com/%post_id%/%postname%/.

comment:2 ocean9022 months ago

  • Description modified (diff)

comment:3 knutsp22 months ago

The default permalink structure is /?p=123. Do you mean that this does not work, returning a status 404?

@ocean90: When the permalink setting is /%post_id%/%postname%/ I would say that /123/ should give a 404, even when there is a post_id = 123. But it should honour /?p=123 correctly, as this is the deafult, using query parameter p.

comment:4 ericlewis22 months ago

  • Keywords dev-feedback added

This is a result of r19737, which was related to #19876.

duck_22 months ago

comment:5 duck_22 months ago

The summary/description of this ticket doesn't seem to match up with the problem described in the post on the forums (and reiterated in ocean90's comment above).

Although the usage of $walk_dirs = true is accidental behaviour and creates some bugs (see #19876) I guess we might have to revert for 3.4.1 and come up with a fix for the problems described by #19876 in 3.5. Though that would mean re-breaking something that was fixed in 3.4.

The old behaviour can be restored with a filter:

add_filter('post_rewrite_rules', function ($rules) {
    return $GLOBALS['wp_rewrite']->generate_rewrite_rules($GLOBALS['wp_rewrite']->permalink_structure, EP_PERMALINK, false);
});

21020.hotfix.diff is a patch for the hotfix plugin which uses the above filter, but it doesn't do any automatic flushing of rewrite rules.

comment:6 nacin22 months ago

  • Milestone changed from Awaiting Review to 3.4.1

comment:7 follow-up: ocean9022 months ago

  • Keywords reporter-feedback added; dev-feedback removed

The summary/description of this ticket doesn't seem to match up with the problem described in the post on the forums (and reiterated in ocean90's comment above).

I just taked a look on the linked post. So, taropaa?

comment:8 in reply to: ↑ 7 taropaa22 months ago

Replying to ocean90:

The summary/description of this ticket doesn't seem to match up with the problem described in the post on the forums (and reiterated in ocean90's comment above).

I just taked a look on the linked post. So, taropaa?

Hi Dominik,

Maybe my description was a little off. In order to clarify, I had a custom post type which paginates. In order to link directly to a page I would pass the parameter page=2 via an URL query to the page and it would work.

the url would look like: website.com/menu/?page=2 -> wordpress would successfully pass the parameter to the page.
After i upgraded to the WP 3.4, wordpress would do a redirect and the url would get changed to website.com/menu/2/ which means that the page does not get the parameter and can't go to the page 2. (I don't know if anyone noticed but it seems buddypress.org suffers from the same illness)

Just go to http://buddypress.org/extend/plugins/ and try going to page 2 and you will see what I am referring to. The symptoms I describe may be different from what was described in the linked post, but I am pretty sure they have the same root cause.

comment:9 follow-up: ocean9022 months ago

  • Keywords reporter-feedback removed

taropaa, thanks. duck_ will investigate it and will create a new ticket for your issue. We will use this ticket then for the %post_id% stuff.

comment:10 duck_22 months ago

  • Component changed from Permalinks to Rewrite Rules
  • Description modified (diff)
  • Summary changed from Passing query parameters via URL to Use of $walk_dirs for post permastructure is relied upon

comment:11 in reply to: ↑ 9 duck_22 months ago

Replying to ocean90:

taropaa, thanks. duck_ will investigate it and will create a new ticket for your issue.

Created #21028 for ?page=x redirection.

comment:12 nacin22 months ago

  • Severity changed from normal to major

duck_22 months ago

comment:13 duck_22 months ago

  • Keywords has-patch needs-testing added; needs-patch removed

21020.diff is a partial revert of [19737] and [19778]. The change to wp-includes/rewrite.php is the only change that's actually necessary to fix the issue.

Works in some quick tests and performs the same against our canonical tests.

comment:14 SergeyBiryukov22 months ago

I see some reports that http://example.com/uncategorized/ (without the category base) no longer works, which was previously mentioned in #19876 as a collateral effect.

Steps to reproduce:

  1. Set permalink structure to /%category%/%postname%.html.
  2. Install Remove Parents (outdated, but apparently still used) or similar plugin that removes /category prefix directly from links, without touching rewrite rules.
  3. Visit http://example.com/uncategorized/.

In 3.3, a category archive is displayed. In 3.4, you get a 404 error.

Confirmed that 21020.diff fixes the issue.

comment:15 duck_22 months ago

In [21112]:

Set $walk_dirs = true for post rewrite rule generation. See #21020 for trunk.

Partial revert of r19737 and r19778 as some users were relying on this behaviour.

comment:16 duck_22 months ago

  • Owner set to duck_
  • Resolution set to fixed
  • Status changed from new to closed

In [21115]:

Set $walk_dirs = true for post rewrite rule generation. Fixes #21020 for 3.4.

Partial revert of r19737 and r19778 as some users were relying on this behaviour.
Bump database version to force flushing of rewrite rules upon upgrade.

Note: See TracTickets for help on using tickets.