Making WordPress.org

Change History (7)

#1 @dd32
6 years ago

This feels like something that should be fixed in cores canonical implementation rather than WordPress.org specifically.

Is there already a core ticket for this?

#2 @jonoaldersonwp
6 years ago

Agreed! Can't see anything in there.

#3 @dd32
6 years ago

Looks like most core tickets were closed as duplicates of https://core.trac.wordpress.org/ticket/3451 which seems to have been incorrectly closed :) (edit: so just file a new one..)

Last edited 6 years ago by dd32 (previous) (diff)

#4 @jonoaldersonwp
6 years ago

Ten years. Ouch. Can we fix this on dot org manually / via the theme / via server config in the meantime?
A core ticket ain't gonna happen quickly...

#5 @dd32
6 years ago

A core ticket will probably be fixed much faster than you think - Start on it now, and as soon as it hits trunk it'll be on dotorg.

#6 @jonoaldersonwp
6 years ago

I'm not sure I agree. Assuming that we piggyback this on WP's canonical link/URL logic, there are huge areas and numbers of scenarios where that's not currently used or considered. Addressing all of that is enormous, complicated, and political (because, nobody will just install the damned plugin which fixes it all).

For now, can we just solve this locally, on dot org? Joost has been fighting to solve canonical URL behaviour in core for over a decade, with frankly little progress, and every day which passes we lose equity to our competitors.

#7 @tellyworth
5 years ago

  • Resolution set to reported-upstream
  • Status changed from new to closed

Fixing it here is at least double the work of doing it in core. We need to concentrate on the tickets that we can fix locally. I've reopened the upstream ticket.

Note: See TracTickets for help on using tickets.