Make /page/ filterable

[scribu]

It should be easy to change the /page/ part of a permalink, for i18n purposes etc.

[scribu]

Introduce 'pagination_base' filter

[nacin]

If it is for i18n, then we should probably use _x() here and then apply a filter over that.

It may also make sense to also make this a method or property of WP_Rewrite, much like category/tag bases.

[filosofo]

Also, it would be good if all the endpoints were defined consistently, say by calling the add_endpoint method in init. Then at the bottom of init we could pass a reference to the WP_Rewrite object which would allow all such rewrite properties to be manipulated by plugin.

I really do like the idea, sort of hinted at in scribu's patch, of having a consistent API shared between rewrite and link generation for determining link structure.

Since its use is limited to 2 places in core, I'm not sure get_pagination_base would need to be a public function.

[filosofo]

class WP_Structure {

   function get_pagination_base() {}
   function get_post_structure() {}
   function get_category_structure() {}

   ...
   
   function init() {
      $this->rewrite = new WP_Rewrite;
      $this->rewrite->page_base = $this->get_pagination_base();

   }
}

$wp_structure_class = apply_filters('wp_structure_class', 'WP_Structure');
$wp_structure = new $wp_structure_class;

Everything--links, rewrite rules, etc.--all able to be changed easily in one place by extending WP_Structure.

[scribu]

Replying to nacin:

If it is for i18n, then we should probably use _x() here and then apply a filter over that.

I agree, but it might cause trouble when a user switches the localization file, since the permalink rules aren't flushed.

It may also make sense to also make this a method or property of WP_Rewrite, much like category/tag bases.

Agreed.

Replying to filosofo:

Also, it would be good if all the endpoints were defined consistently, say by calling the add_endpoint method in init. Then at the bottom of init we could pass a reference to the WP_Rewrite object which would allow all such rewrite properties to be manipulated by plugin.

I really do like the idea, sort of hinted at in scribu's patch, of having a consistent API shared between rewrite and link generation for determining link structure.

Yeah, the rewrite API needs work. What else is new? :)

I like were you're going with this, but please open your own ticket.

[filosofo]

Replying to scribu:

I like were you're going with this, but please open your own ticket.

I will, but my main point here is that get_pagination_base be marked private. No need to expose a public API for this.

[scribu]

Make pagination_base a private var in WP_Rewrite

[scribu]

In pagination_base.2.diff I've simply made pagination_base a variable in the WP_Rewrite class. It seems consistent with all the rest of the vars.

[TobiasBg]

I like your idea, scribu.

And I suggest not only doing it for /page/, but also for /trackback/ and /comment-page-X/, as they also seem to be hardcoded ​here.

[scribu]

Related: [13717] [13780]

[scribu]

fix canonical redirect and wp_unique_slug()

[scribu]

​pagination_base.3.diff makes redirect_canonical() and wp_unique_slug() aware of $wp_rewrite->pagination_base

[scribu]

Make <!--nextpage--> links use pagination_base

[scribu]

DRY for wp_link_pages()

[scribu]

(In [15582]) Don't hardcode the pagination base. Fixes #12507

[chriscct7]

#18084 was marked as a duplicate.