Full support for middle and little endian permalink structures

[RevelationTravis]

This only happened after I switched over to the WordPress 3.0 development version, so I'm inclined to think it's a bug. When I use the traditional wp_get_archives or the dropdown version it shows that posts exist. However, when I click to go to any of those past posts, I only get a 404 Error. This problem is very consistent, happening 100% of the time. Disabling all plugins has no affect on the problem.

The only other information that might be helpful is that I've integrated WordPress into a website that I built and I am using a custom theme that I built. It only has the index.php, single.php, and style.css files.

Again, the wp_get_archives function worked just fine with the exact same setup that I have now prior to switching to the 3.0 version, so I'm not sure what changed.

[ryan]

Apache, IIS? Is multisite enabled?

[ryan]

Did the generated links change, or do they look the same as they did before upgrading?

[RevelationTravis]

I'm using Apache version 2.2.14 and multisite is disabled. I'm not sure yet if the generated links have changed since WordPress version 2.9.2, but I was using a custom permalink. On a hunch, I just changed the settings for the permalink to the default and now everything is working fine. As long as I'm using any of the four preset permalink options (Default, Day and name, Month and name, or Numeric) then it works. However, the custom permalink with the syntax of /%monthnum%/%day%/%year%/%postname%/ will generate a 404 Error as soon as I click on the day with a post in it.

If needed, I can still revert back to the old version of WordPress, but hopefully this information is enough to resolve the bug.

[ryan]

Unfortunately, I cannot reproduce the bug using "/%monthnum%/%day%/%year%/%postname%/".

What are your "WordPress Address" and "Site Address" in Settings -> General?

[ryan]

Nevermind, I can reproduce this. I can reproduce for 2.9 as well though. wp_get_archives() creates links of the form /mm/yyyyy/. Since your permalink structure has a middle endian date format rather than big endian, the big endian links created by wp_get_archives() do not work.

Still investigating.

[ryan]

I'm not sure how this ever worked for you. WP doesn't create the rewrite rules needed to support this. You pretty much have to use big endian dates for the month archive links to work.

[westi]

I can't see how this can have worked either.

We build urls for archives based on the assumption that the day isn't in the middle unfortunately.

With this structure we build rules for:

/month/
/month/day/
/month/day/year/

And links for the archives of:

/month/year/

[westi]

Tested in a clean 2.9.2 install and I see the same issue there.

Moving out of the 3.0 milestone as this is not a regression.

This should be a relatively easy ticket to fix. We just need to generate the correct rewrite rules in this case.

[RevelationTravis]

I'm not sure how I got it to work either, but it was. I think it would be very nice to have the ability to display the formats as month/day/year. A lot of people are used to reading it that way. I did find a work around though, I just used the custom permalink of /%monthnum%-%day%-%year%-%postname%/. The same end result is close enough. I'm not sure if it would be worth it to continue to investigate a fix for using slashes instead of dashes, but I'm sure somebody else will run into this again in the future. Thank you both for taking the time and energy to look into this.

[gazouteast]

Contributory to ​http://core.trac.wordpress.org/ticket/14295

Suspect this is a root (one of several) leading to the above in 3.0

Only the USA uses month-day-year - the rest of the world, including NATO and the UN uses day-month-year or year-month-day-time.

Is 02/12/10 the 2nd of December or the 12th of February? Only one country says it is February. The code needs to go with the majority and let go of the US-centric format as the default. The USA signed the accord that all short dates would be in the format 02 Dec 2010 over 30 years ago, but has never fulfilled on it.

If WordPress can introduce something like capital_P_dangit() then they could also introduce Internationalise_your_dates_dangit() as well .... or would that be unAmerican?

[wonderboymusic]

This one was a doozy. Rewrite in most cases is trying to build rules by taking a list of tokens and looping / accumulating them in order. This doesn't work when we flip the date permastruct on its ear, because "day" can't be out there by himself.

No matter what the endianness of the date, "year" always has to have its own rule, as does "monthnum / year", regardless of order. This requires some if / else intervention in generate_rewrite_rules, which is mighty hard to do completely elegant because a big portion of the method is a ginormous loop.

Patch attached.

[wonderboymusic]

This ticket hasn't gained any steam, so I threw my code into a plugin: ​http://wordpress.org/extend/plugins/big-middle-and-little-endians/

If a core dev wants to pick this up later, they can reopen.

[nacin]

rewrite-archives-by-endianness.diff​ looks pretty good. Renaming this ticket and re-opening.

[scribu]

Do we really want to make the rewrite code more complex than it already is? especially given that the effect is achievable through a plugin.

[scribu]

I mean, it's nice to add features, but we have to pay the technical debt first:

1. Write unit tests
2. Refactor

[wonderboymusic]

In WP_Rewrite:

The main WP_Rewrite function for building the rewrite rule list. The contents of the function is a mix of black magic and regular expressions, so best just ignore the contents and move to the parameters.

I think the contents of generate_rewrite_rules need a broader examination.

Rewrite definitely has flaws - turns out the date_rewrite_rules filter happens after the post_rewrite_rules filter, but guess what? The post rewrites generates date archives as well and are loaded after the date_rewrites in the final rewrite_rules array.

By loaded I mean each of the rules merges in like so: $rewrites[$regex] => $query, which means they can completely overwrite any rule keyed by the same regex - which is why the the code has to be inline in WP_Rewrite to work, otherwise a plugin has to hijack the whole array so date rewrites don't break.

[duck_]

Replying to wonderboymusic:

I think the contents of generate_rewrite_rules need a broader examination.

Yeah.

Rewrite definitely has flaws - turns out the date_rewrite_rules filter happens after the post_rewrite_rules filter, but guess what? The post rewrites generates date archives as well and are loaded after the date_rewrites in the final rewrite_rules array.

I attempted to tackle the duplicated effort of generating date rewrites when calling generate_rewrite_rules() for the post permastructure in #19876. However, it turned out that this walking of the directories was required by a lot of people, see #21020.

[wonderboymusic]

We should take a look at the best way to tackle this, or if anyone still cares (I think we should). I got fairly exhaustive here: ​​http://wordpress.org/extend/plugins/big-middle-and-little-endians/

[wonderboymusic]

Let's decide if we want to get weird in 3.7

[nacin]

Is this testable? Seems like there are some existing query/canonical/rewrite tests. I'd add the needs-unit-tests keyword but it's already on here.

[helen]

Teeeeeeests?