WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 7 months ago

#13701 reopened enhancement

Full support for middle and little endian permalink structures

Reported by: RevelationTravis Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.9.2
Component: Rewrite Rules Keywords: has-patch needs-unit-tests
Focuses: Cc:

Description

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 20 months ago.
13701.diff (5.7 KB) - added by wonderboymusic 9 months ago.

Download all attachments as: .zip

Change History (29)

comment:1 ryan4 years ago

Apache, IIS? Is multisite enabled?

comment:2 ryan4 years ago

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

comment:3 ryan4 years ago

  • Milestone changed from Unassigned to 3.0

comment:4 nacin4 years ago

  • Keywords reporter-feedback added; archives 404 removed

comment:5 RevelationTravis4 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.

comment:6 ryan4 years ago

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

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

comment:7 ryan4 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.

comment:8 ryan4 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.

comment:9 westi4 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:

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

And links for the archives of:

/month/year/

comment:10 westi4 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.

comment:11 RevelationTravis4 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.

comment:12 gazouteast4 years ago

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

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?

comment:13 wonderboymusic20 months 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.

comment:14 wonderboymusic19 months 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: http://wordpress.org/extend/plugins/big-middle-and-little-endians/

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

comment:15 wonderboymusic19 months ago

  • Milestone Future Release deleted

comment:16 SergeyBiryukov19 months ago

  • Keywords wp3.0 multi-site-too removed

comment:17 nacin19 months 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.

comment:18 nacin19 months ago

  • Keywords needs-unit-tests added

comment:19 scribu19 months 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.

comment:20 scribu19 months ago

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

  1. Write unit tests
  2. Refactor

comment:21 follow-up: wonderboymusic19 months 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.

comment:22 in reply to: ↑ 21 duck_19 months ago

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.

comment:23 wonderboymusic16 months 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: ​http://wordpress.org/extend/plugins/big-middle-and-little-endians/

comment:24 ryan11 months ago

  • Milestone changed from 3.6 to Future Release

wonderboymusic9 months ago

comment:25 wonderboymusic9 months ago

  • Milestone changed from Future Release to 3.7

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

comment:26 nacin7 months 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.

comment:27 helen7 months ago

  • Milestone changed from 3.7 to Future Release

Teeeeeeests?

Note: See TracTickets for help on using tickets.