Make WordPress Core

Opened 14 years ago

Last modified 5 years ago

#13701 reopened enhancement

Full support for middle and little endian permalink structures

Reported by: revelationtravis's profile RevelationTravis Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9.2
Component: Rewrite Rules Keywords: has-patch needs-unit-tests reporter-feedback
Focuses: Cc:


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.

Attachments (2)

rewrite-archives-by-endianness.diff (5.6 KB) - added by wonderboymusic 12 years ago.
13701.diff (5.7 KB) - added by wonderboymusic 11 years ago.

Download all attachments as: .zip

Change History (30)

#1 @ryan
14 years ago

Apache, IIS? Is multisite enabled?

#2 @ryan
14 years ago

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

#3 @ryan
14 years ago

  • Milestone changed from Unassigned to 3.0

#4 @nacin
14 years ago

  • Keywords reporter-feedback added; archives 404 removed

#5 @RevelationTravis
14 years ago

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.

#6 @ryan
14 years ago

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

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

#7 @ryan
14 years ago

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.

#8 @ryan
14 years ago

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.

#9 @westi
14 years ago

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:


And links for the archives of:


#10 @westi
14 years ago

  • Keywords needs-patch added; reporter-feedback removed
  • Milestone changed from 3.0 to Future Release
  • Severity changed from major to normal
  • Version changed from 3.0 to 2.9.2

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.

#11 @RevelationTravis
14 years ago

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.

#12 @gazouteast
14 years ago

  • Cc gazouteast added
  • Keywords wp3.0 multi-site-too added

Contributory to

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?

#13 @wonderboymusic
12 years ago

  • Component changed from Date/Time to Rewrite Rules
  • Keywords has-patch dev-feedback added; needs-patch removed

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.

#14 @wonderboymusic
12 years ago

  • Keywords dev-feedback removed
  • Resolution set to maybelater
  • Status changed from new to closed

This ticket hasn't gained any steam, so I threw my code into a plugin:

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

#15 @wonderboymusic
12 years ago

  • Milestone Future Release deleted

#16 @SergeyBiryukov
12 years ago

  • Keywords wp3.0 multi-site-too removed

#17 @nacin
12 years ago

  • Milestone set to Future Release
  • Resolution maybelater deleted
  • Status changed from closed to reopened
  • Summary changed from 404 Error for wp_get_archives to Full support for middle and little endian permalink structures
  • Type changed from defect (bug) to enhancement

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

#18 @nacin
12 years ago

  • Keywords needs-unit-tests added

#19 @scribu
12 years ago

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.

#20 @scribu
12 years ago

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

  1. Write unit tests
  2. Refactor

#21 follow-up: @wonderboymusic
12 years ago

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.

#22 in reply to: ↑ 21 @duck_
12 years ago

Replying to wonderboymusic:

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.

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.

#23 @wonderboymusic
11 years ago

  • Milestone changed from Future Release to 3.6

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: ​

#24 @ryan
11 years ago

  • Milestone changed from 3.6 to Future Release

#25 @wonderboymusic
11 years ago

  • Milestone changed from Future Release to 3.7

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

#26 @nacin
11 years ago

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.

#27 @helen
11 years ago

  • Milestone changed from 3.7 to Future Release


#28 @chriscct7
9 years ago

  • Keywords reporter-feedback added
Note: See TracTickets for help on using tickets.