I’ve noticed in the new version of BuddyPress 1.3 that pages will be used to create the sections of the site such as Members, Activity etc. While this may seem super easy for a user to change the urls, it also breaks the rules of good web development. Pages in WordPress are supposed to be static content, they are not supposed to be used to fake sections just to get a pretty url. I much preferred the original and current method of having all the urls and sections built in the code behind as that’s exactly what they were. If anything, an additional settings page should been added to allow users to change the urls in the admin rather than resorting to using pages to deal with it. There was similar problems with custom post types in WP 3.0 whereby a user to create a fake page to show the posts which is now being fixed in the 3.1 release by having an inbuilt index page.

Think of it this way. Themes are essentially your website, and when a user switches a theme it should reflect as such, so if I switch themes or change plugins the pages I have should reflect, in other words the content shouldn’t be dependant on the theme or plugin. With the new method if a user ditched BP they would have a bunch of fake pages, as they have no content they were used solely to fake the whole url structure which is just bad design.

I really hope someone on the development team reads and takes notice of this post and that others get involved in this discussion because I think BuddyPress has just been ruined with this new approach, if the WP core team can see and fix the problem why has the BP team gone and made the same mistake they did?

[@hnla Participant 13 years, 12 months ago]

Interesting points. Working recently with trunk prompted the same thoughts vis-a-vis disabling BP and being left with a heap of odd pages, but then I simply removed or unpublished those pages.

It would be interesting to hear the comments of the core devs who are :

@jjj
@djpaul
@boonebgorges

[@driz Participant 13 years, 12 months ago]

Yes pages can be deleted, but that’s not the big problem, rather the fact that the plugin uses pages at all to accomplish something so simple. What was wrong with the current system? It’s important to make the software easy, but somethings should be left to the developer of the site and not the admin guy who just writes blog posts, I much preferred changing the URLS in the code behind, but a settings page would be much nicer and slicker than the messy pages.

Here is another point: The pages don’t add that much flexibility anyway as most of the urls are still coded behind e.g. all the urls inside the members directory such as settings, profiles, followers, etc.

I think their should be a proper coded page in the plugin somewhere that has the urls in the system where a developer can go and edit to their hearts content to get the system they want. So for example say I didn’t want the members slug on profiles and just wanted: domain.com/driz/activity, using code behind would give true flexibility instead of using the pages which are for static content and NOT url building!

[@hnla Participant 13 years, 12 months ago]

Not in disagreement necessarily and get your point. I’m interested in this as I don’t know myself why this approach has been adopted (probably should have been paying more attention in those dev chats )

[@modemlooper Moderator 13 years, 12 months ago]

Should be post type. Then BP could use post type templates for output. Create a group post type and it will add URL.

[@driz Participant 13 years, 12 months ago]

@modemlooper

Content types sound interesting as Members, Groups, Forums etc are all types of content. Would be good to hear some input from the main developers and would be good to get this changed before releasing 1.3 and having everyone create fake pages.

[@anonymized-96400 Inactive 13 years, 12 months ago]

I understand the issue, but don’t necessarily find it that much of a problem. Creating a post type just for one page seems to me a bit of overkill, really. Why not just save the ids of the created pages and delete them automatically if BP is getting deactivated?

[@modemlooper Moderator 13 years, 12 months ago]

The reason I suggest something along the lines of post types is to allow adding new “components” so BP would install activity – forums – groups etc content types and then a theme could add it’s own. Allowing more individualized networks. BP could be nothing more than allowing front end editing of post types / components. But this will never happen. From a BP core devs mouth “can of worms”

[@driz Participant 13 years, 12 months ago]

@Travel-Junkie deleting the pages isn’t a problem. Using pages in the first place is the problem. It’s just bad development!

[@anonymized-96400 Inactive 13 years, 12 months ago]

Well, it’s not really rules of web development, it’s more like recommendations and while most of them do make a valid point, it’s wrong to get too hung up about them, if there is a good enough reason to break them. Then it’s not bad development, it’s innovation

[@mrmaz Participant 13 years, 12 months ago]

If you really want to take this where the root of the issue is, the underlying problem is that BuddyPress is actually a theme that has been jammed into the plugin directory and then tightly coupled to what should be multiple plugins (aka components) in one massive package.

I am starting to feel like the only way to restore any kind of reasonable extensiblity of the BP interface it to split it into a theme, and the components into plugins which all adhere to a very strict API defined by the THEME, not a “core” plugin.

Of course this would break every existing install. It would have to be an internal fork that was deemed to be the new way forward.

[@driz Participant 13 years, 12 months ago]

@Travel-Junkie I wouldn’t call it innovation. Using pages for such functionality is a hack.

@MrMaz I like the idea of BuddyPress being split up, but not as a theme, I think it should remain a plugin, but just not so robust.

The problem the WordPress community is making is trying to make it so that literally anybody can build a website with a click of a button. While this may sound good, it means that we have too much automated crap going on and not enough flexible development. I really dislike that BP can be even added from the directory and has a default theme, it would of been much better manually done as a bunch of code you add to your own theme as the bp-template-pack does, and then the core code as a simple plugin. But that’s beyond the scope of this topic. The main problem at the moment is the whole WP model of using pages to fake stuff, when pages are for static chunks of content and nothing else. BP had it nailed before, we just needed more flexibility in the code behind to mess with the URLs more, the pages actually make it more robust than before as it means admins can mess the site up!

[@anonymized-96400 Inactive 13 years, 12 months ago]

Hmm, humor or sarcasm doesn’t seem to get very far in text. I did include that horrible smiley, though…

[@mrmaz Participant 13 years, 12 months ago]

@driz

BuddyPress is already a theme. Look at bp-default. That is a full WP theme that for some reason was bundled with the plugin. There is a huge mess of code devoted to making this setup work. It is nearly impossible to freely modify the templates, even if you roll your own BuddyPress theme, because the javascript is so tightly bound to the ids and classes in the markup.

I don’t think its reasonable anymore to call BP a plugin, since it does not enhance a WP site in the purest sense. It completely takes it over and defines an entirely new set of rules for how to customize the look of your site. That sounds like a theme to me.

If you think about BP as a theme, then the only acceptable ways to solve the issue and stay true to WP is pages or custom post types. This only doesn’t make sense though because BP is made up of many components that should be making their OWN decisions about how they get displayed.

So back to my original point. BP is defining too many rules, and forcing components to adhere to the default theme itself, instead of a theme prototype (which is how WP works). If BP was doing it the “right” way, then this whole issue would be moot, because each component would be deciding how its URL was determined, and the end user could decide if they liked it or not.

I think this is in the scope of the topic because it gets into defining the problem that needs to be solved, which is important before working on a solution.

[@r-a-y Keymaster 13 years, 12 months ago]

MrMaz, the term you’re looking for is “theme framework”. Like Justin Tadlock’s Hybrid or Ian Stewart’s Thematic.

Your argument is similar to Justin’s blog post on why advanced parent themes are not frameworks:

Frameworks? Parent, child, and grandchild themes?

[@driz Participant 13 years, 12 months ago]

So what are the core developers thoughts then? I think it’s important to do something about all this soon as just releasing 1.3 with the whole pages system and then 6 months down the line changing it to something else just sucks.

[@mrmaz Participant 13 years, 12 months ago]

@r-a-y

I am a big fan of Justin’s and have read that particular post several times in the past. I mostly agree with his arguments, but my view is even a bit more extreme, since even when you remove the term “framework” they still box you into an API that is impossible to break out of, which is not developer friendly in the long run.

There are a lot of themes that I think do this on purpose, because it fits their business model

[@boonebgorges Keymaster 13 years, 12 months ago]

I also have found myself torn about using pages for BP directories. In the end, though, I think it’s a compromise that works out for the better in the short- to medium-run, and does not have awful long-term consequences.

In my view, it is a gross overstatement to say that this move ‘ruins’ BP. However, there are a few things about it that are unappealing:
1) It forces the creation of what are, essentially, dummy pages – whatever content you might add to the page through the normal WP editor is totally ignored
2) Related – It uses part of the WP page infrastructure (URLs) without using others (in particular, WP page templates)

Problem (1) is unappealing, but it is mitigated by a couple of points. First, the current system is not a whole lot better. Instead of having ‘dummy’ pages that you can see in the admin (like BP trunk has), the current version of BP has ‘phantom’ pages, so that when BP detects a URL like example.com/groups, it essentially hijacks the page load in order to do its own stuff. This is a bit jarring, and not at all transparent. So there is a trade-off, but it’s not all bad. Second, while the idea that ‘Pages in WordPress are supposed to be static content’ seems right to me in broad strokes, it doesn’t seem to me to be a hard-and-fast rule. Many plugins (gallery plugins, ecommerce plugins, etc) display their content by means of a shortcode that is manually inserted on a page or post, with pages being used for their pretty URLs.

On the other hand, there are some real benefits to directories-as-pages:
A) Easier URLs (as @driz has noted)
Integration into WP 3.0-type menus (this is the big one IMO)

How important are things like (A) and (? For sites maintained by folks with some PHP chops (and organizations with money to pay people with PHP chops), they could be fairly easily accomplished with BP_GROUPS_SLUG, etc, and with some other finagling. But – and this is just a guess – this profile does not match most of the users of BP. Nor should it, necessarily. To the extent that BP can be easy to use and install for people with little technical knowledge, without at the same time making it less flexible from a developer’s point of view, it should be. This change is good for end users, and is no more difficult for developers than the current technique, so it seems like a net win.

Another more theoretical argument for the directories-as-pages move (especially as compared to the new admin panel @driz suggests for changing slugs) is that BP shouldn’t reproduce functionality that WP could provide, unless there is a convincing reason for doing so. Using WP pages for BP directories is a step toward greater BP-WP integration. It’s not perfect (see my problem (2) above) but it is a start.

As for custom post types: It’s likely that at least some of BP’s components will be refactored to use custom post types in the future. When that happens, part of the upgrade script will probably involve removing the dummy pages at issue here. So from the user’s point of view, the transition will be seamless.

I should say that I am in agreement with a lot of the sentiment in this thread about making BP a bit more lightweight, framework-y, and disjointed than the sometimes hulking behemoth it is now. However, that kind of transition can and probably should be gradual (at least more gradual than the 1.3 release).