Skip to:
Content
Pages
Categories
Search
Top
Bottom

the permalinks issue – another way to look at it

  • @synaptic

    Participant

    I just watched this short clip of JJJ on wordpress.tv talking about the permalinks issue:

    that the developers are facing for both bbPress (http://bbpress.org/forums/topic/any-way-to-eliminate-redundancyweirdness-in-permalinks-i-e-forumsforum) and BuddyPress. As JJJ explains, a mistake early on in the dev has ‘painted them in a corner’ and now the way out is complicated because as they try to fix this, they have to consider how that fix will affect the many already existing buddypress sites out there.

    I totally understand their care and concern about existing sites and the conflicts that may occur if a solution is not implemented correctly.

    But what seems to be missing is an equal amount of concern for those people who have yet to deploy a BuddyPress or bbPress and are only given a choice of using what is currently available (the hobbled together mess). Since the relevant ticket has been officially opened on trac, this group has been waiting for a long time with no foreseeable solution on the horizon.

    So I’d like to suggest a potential third way out of this:

    Put out a version of buddypress that does not concern itself with backward compatibility for those who do not have an existing install (so it is NOT an upgrade) but who want to do fresh installs and create new websites and communities.

    Pushing out a solution for them would be much simpler because you would not need to accommodate all manners of backwards compatibility isses. And this ticket of going on 12 months would be closed (sort of):
    https://buddypress.trac.wordpress.org/ticket/4954

    And for those who are on the upgrade path, the devs can continue to work on a fix that would accomodate them.

    This approach would allow for both camps to be happy. In contrast, what’s happening now is that the already deployed buddypresses out there are in effect hampering this feature for those who have not yet deployed buddypress and are going to in the future (fresh new communities).

    I hope my idea was expressed clearly. If not, let me know and I’ll see if I can give it another crack.

    Does that make sense? what do you think?

Viewing 4 replies - 1 through 4 (of 4 total)
  • @johnjamesjacoby

    Keymaster

    It does make sense, and it’s likely what we’ll end up doing, with a dedicated branch on Github to let us make sweeping changes, and take advantage of Git’s improved branch merging tools when it’s time to start brining those changes back into the official development branch.

    @boonebgorges

    Keymaster

    > the hobbled together mess

    Just to push back a little on this one. There are a couple of key ways in which BP’s current permalink router is not ideal (it’s not amenable to caching; it’s not non-pretty-permalink friendly; it’s hard to write unit tests for it; it leaves some slugs difficult to change). Moving toward the WP Rewrite API is a worthwhile project, because improving on these areas are worthwhile things to do.

    However, it’s important not to overstate the problem. The current system works just fine for many thousands of BuddyPress sites. While there would be new efficiencies and configuration possibilities with a new system, it’s unlikely that their absence to date has ever been a dealbreaker for any BuddyPress site. @synaptic or others, I may be wrong about this, and if there are specific ways that the current router is holding you back, it would be very helpful to know more about those details.

    In any case, while it will require a large amount of work to build a new system that’s compatible with the old, it’s not doing any active harm to existing (or new) sites to use the current (perfectly functional) system. So let’s not get too carried away with the idea of forking our own project 🙂

    @johnjamesjacoby

    Keymaster

    What @boonebgorges said.

    BuddyPress’s URI router came from a much older codebase, in a time where BuddyPress was intended to be bolted on top of a WordPress Multisite installation similar to WordPress.com, and not much else. Once that was achieved, we quickly saw the potential in it being something much more powerful (to a larger audience) by quickly iterating away from that original goal, making it work on single-site WordPress, and refactoring the individual components to be less dependent on each other, and only dependent on a core set of common functionality — part of which was the URI router.

    We’ve recently chopped two large pieces out of BuddyPress core and turned them into separate components: Settings and Notifications; and we’ve taken huge strides and helped simplify the getting-started process with making it theme agnostic. Bigger ideas like attachments, permissions, and deeper WordPress integration (both in wp-admin, and it’s API’s) is something we continue to improve with every release. Rewrite rules just so happens to touch every component, every file, and every page request, so it’s a refactor that is going to take several months of architecting before it’s complete (similar to theme compatibility.)

    Basically… we’ll get there, and there is a plan. It’s been said that before creating David, Michelangelo stared at a block of marble for 8 hours a day, for 4 months, before making his first chip into it. Not trying to compare ourselves to prolific artists or anything, but the idea is the same in that we’re all staring at a huge codebase and coming up with our own map of how to approach the problem.

    @synaptic

    Participant

    I’ll let Matt have the last word (jump to 9:13):

    http://wordpress.tv/2014/04/05/matt-mullenweg-wordpress-future/

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘the permalinks issue – another way to look at it’ is closed to new replies.
Skip to toolbar