[buddypress-trac] [BuddyPress Trac] #4954: Migrate BP's custom URI parser to use WP's Rewrite API

[buddypress-trac]

#4954: Migrate BP's custom URI parser to use WP's Rewrite API
------------------------------------+------------------------------
 Reporter:  boonebgorges            |       Owner:  johnjamesjacoby
     Type:  enhancement             |      Status:  reopened
 Priority:  high                    |   Milestone:  Up Next
Component:  Route Parser            |     Version:
 Severity:  major                   |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------------------
Changes (by imath):

 * keywords:  trac-tidy-2018 => has-patch dev-feedback
 * status:  closed => reopened
 * resolution:  maybelater =>
 * milestone:   => Up Next


Comment:

 Hi everyone!

 I’m reopening this ticket to suggest a new approach about migrating from
 our legacy URL parser to the WordPress Rewrite API.

 First, I’d like to thank @r-a-y for his work and the time he spent
 building the 3 patches. It helped me a lot to identify the difficulties
 and the potential impacts of such a change. And at the same time I’m
 telling him « sorry » because I chose another road to reach the goal of
 this ticket: I suggest to use the existing BP Component’s methods to add
 rewrite tags, rewrite rules, permalink structures and to parse the WP
 Query for each directory component.

 My idea is to work on this change progressively because, as r-a-y
 explained:

 - a lot of BuddyPress globals such as the current component, item, action
 or action variables are set before the WP Query is parsed.
 - the Member or Group BP Navs  are set before the WP Query is parsed
 - the “late included” files are included before the WP Query is parsed
 too.
 - Some specific features like adding a directory page as the site’s home
 page or making a directory page a sub-page of another WordPress page are
 pretty challenging to maintain.

 I think it would be difficult to add this change without breaking some
 plugins or confusing some users habits with BuddyPress.

 [[Image(https://cldup.com/MYjIfSrbiy.png)]]

 That’s why I chose to use an “experimental” option to our options screen
 and to make the change reversible. I think this would leave the time to
 users to get used to it and to plugin authors to adapt to this new way of
 parsing URLs. Users could experiment Rewrites and eventually inform plugin
 authors they need to fix things and come back to the legacy URL parser.

 [[Image(https://cldup.com/9VNOxf-NEU.png)]]

 Once the user activate this experimental option, the “Pages” tab is
 replaced by a “URLs” one and it’s now possible to edit all directories
 slug and for this first step all the primary nav items of the displayed
 member as shown on the screen capture below.

 [[Image(https://cldup.com/XgBo4_-GTw.png)]]

 If the site’s were using BuddyPress directory pages into one or WP Menus,
 these pages are still there but they now have a different post type
 “BuddyPress directory”. The custom slugs are still saved within the
 post_name field of this post type for directory pages and for the
 navigation I chose to use a post meta.

 [[Image(https://cldup.com/ceGyTVeGSs.png)]]

 If you switch back to the legacy parser disabling the “Custom URLs”
 option: everything is brought back to their previous state.


 [[Image(https://cldup.com/GHTfg03t0O.png)]]


 If you are using Custom URLs, you can now choose Plain permalinks 🙂 Below
 is an example of the User’s profile page.


 [[Image(https://cldup.com/ZveIEMmL1f.png)]]


 I’ve tried to edit as less code as possible and chose to use filters to
 rebuild links (see {{{src/bp-core/bp-core-rewrites.php}}}. You’ll see that
 some parts are quite challenging (eg: the root profiles or Ajax). I made
 sure the few edits I had to make had no impact on the “legacy URL parser
 BP” (Unit tests are still successful).

 There are still a lot of links to check and I think we can improve Ajax by
 only doing the needed “WP” parse for registered BuddyPress ajax actions.
 But you can already have a good preview of the result applying the
 [https://buddypress.trac.wordpress.org/attachment/ticket/4954/4954.patch
 4954.patch].

 What do you think ? What about doing a first step for the 6.0.0 milestone
 ? What about leaving it as an experimental option for 1 or 2 releases
 before deprecating the legacy URL parser ?

 PS: if you want to see how I’ve built the patch step by step →
 https://github.com/imath/BuddyPress/commits/wp-rewrites

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4954#comment:36>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac