Weekly wp_get_archives has invalid link (link for month instead of year)

[filipac]

If you call wp_get_archives function with type set to weekly, the resulted link contains two parameters: m => year, w => week.

This results in unwanted behaviour, as you get a month like 2023 which is invalid.

The link should contain ?y={year}&w={week}.

If you call wp_get_archives function with type set to weekly, the resulted link contains two parameters: m => year, w => week.
This results in unwanted behaviour, as you get a month like 2023 which is invalid.
The link should contain ?y={year}&w={week}.

Trac ticket: https://core.trac.wordpress.org/ticket/59027

[SergeyBiryukov]

Thanks for the ticket! Some history here:

• [24] introduced the ?m=$arc_year line along with the get_archives() function itself.
• [273] adjusted the formatting to use sprintf().
• [3878] moved the logic to wp_get_archives() and deprecated get_archives().
• [37530] replaced sprintf() with add_query_arg().

[filipac]

@SergeyBiryukov huh, 20 years and no other user noticed? so strange :D

[NekoJonez]

That is a really old bug indeed.
Since this isnt a regression introduced in 6.3, this will be for 6.4.

But well spotted. And yeah, sometimes small issues fly under the radar and especially when code is being enhanced, sometimes we don't check if the actual code we are enhancing contains a bug.
Besides, I think its a small thing thats quick to glance over.

Anyhow, it will be fixed in 6.4 :D
(Is this a record for longest standing bug ever in WP?)

[hellofromTonya]

This ticket was discussed during today's 6.4 post-beta 1 scrub.

@costdev brought up a potential BC (backward-compatible) break of changing m to y. This is a valid concern when considering how to move this bugfix forward.

As @joemcgill pointed out:

Definitely needs some deep research and added unit tests, if possible to ensure this doesn't break again in the future.

If there is truly a BC concern, this one might benefit from being in the early early alpha phases of a major release.

I'm marking this one with 2nd-opinion to denote it needs

• Thorough historical review.
• Consideration of how to deal with a BC break.
• If this one should be moved into early alpha phase.

[oglekler]

This ticket was discussed during bug scrub.

Due to possible side effects that it may have, it should be an early ticket and I am rescheduling it to the next milestone.

Add props: @mukesh27

[audrasjb]

As per today's bug scrub, we decided to move this ticket to milestone 6.6 to give it more time to be tested.

[davidbaumwald]

Since this has been punted a bit for a few majors, moving his to Future Release. Also removing early as I'm not quite sure it's needed.

Once the proper deep-dive on this is complete and a path forward is laid out, it can be moved into a specific milestone by an owner.