[wp-trac] [WordPress Trac] #18660: Enhance rel_canonical function, add filter

[WordPress Trac]

#18660: Enhance rel_canonical function, add filter
-------------------------------------------------+-------------------------
 Reporter:  nathanrice                           |       Owner:
     Type:  enhancement                          |  joostdevalk
 Priority:  normal                               |      Status:  assigned
Component:  Canonical                            |   Milestone:  Awaiting
 Severity:  normal                               |  Review
 Keywords:  has-patch needs-testing 2nd-opinion  |     Version:  3.3
                                                 |  Resolution:
-------------------------------------------------+-------------------------

Comment (by nacin):

 I've applied this patch, merged it with HEAD, and gone over each line of
 code. And I've done this no fewer than four times in the last six weeks. I
 can't bring myself to commit the whole thing at this point, and for two
 main reasons.

  * I think adding rel=canonical to non-singular pages need some very
 careful consideration. get_current_archive_url() sounds like a fantastic
 idea in theory, but it could be damaging to a complicated site pretty
 easily.

  I am worried about how a complicated drill-down URL (say, with multiple
 taxonomies, or a query string, or something else) would end up with an
 improper canonical link. This is perhaps the greatest issue when it comes
 to archive pages, and that's likely the only reason why we stuck to
 singular the first time around.

  * I think the pagination aspects (both rel=canonical respecting
 pagination, and rel=next/prev handling pagination) is much more solid. I
 think it has the potential to cause problems for non-singular pages, but
 probably not as bad as a faulty rel=canonical could.

  However, I am irked that the patch avoids using any API functions for
 creating pagination links, and instead calculates them on their own. I
 understand this is of no fault of the patch — rather, our APIs around
 pagination links (both singular "page" links and archive "paged" links)
 are all over the place.

  There are also a number of filters and hooks scattered about these
 functions, which make me question things like pagination bases and other
 points of customization that could break. I would like to go through these
 functions, potentially in 3.5, and clean them up, and make them obvious
 about what is going on.

 The one thing that seems most safe is a single, targeted patch that adds
 support for singularly paginated items to rel_canonical(). And it is
 getting too late in the cycle to make such changes, so I would rather try
 to do all of this in one effort for 3.5. Sorry, yoast.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18660#comment:27>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software