Skip to:
Content
Pages
Categories
Search
Top
Bottom

Issues with BP1.3 trunk development version

  • Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    Firstly, congratulations on putting this together – great work! I am very surprised that this is not a more requested feature – hierarchy in groups seems like pretty essential functionality for organising groups!

    However, I wanted to report what happens on BP1.3:

    I am using:
    - BuddyPress trunk development version (v1.3-bleeding)
    - WordPress v3.1.3
    - BP Group Hierarchy v1.1.3

    I am not running any other plugins or custom themes (just using the default BP one) to eliminate any other potential issues – it is a fresh install.

    I was wondering if there was any development planned to get this functioning in BP1.3? The admin menu ’Group Hierarchy’ appears correctly, but I get the following 2 errors on the front-end of the site:

    `Notice: Use of undefined constant BP_GROUPS_SLUG – assumed ’BP_GROUPS_SLUG’ in /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/extension.php on line 369`

    `Notice: Use of undefined constant BP_GROUPS_SLUG – assumed ’BP_GROUPS_SLUG’ in /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/index.php on line 101`

    I also get the following error under the groups tab:
    `Notice: Trying to get property of non-object in /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/classes.php on line 349`

    When clicking on create a group I get the following errors:
    `Notice: Use of undefined constant BP_GROUPS_SLUG – assumed ’BP_GROUPS_SLUG’ in /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/extension.php on line 369`

    `Notice: Use of undefined constant BP_GROUPS_SLUG – assumed ’BP_GROUPS_SLUG’ in /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/index.php on line 101`

    `Warning: Cannot modify header information – headers already sent by (output started at /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/extension.php:369) in /xx/xx/xx/wp-content/plugins/buddypress/bp-groups/bp-groups-actions.php on line 36`

    `Warning: Cannot modify header information – headers already sent by (output started at /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/extension.php:369) in /xx/xx/xx/wp-content/plugins/buddypress/bp-groups/bp-groups-actions.php on line 37`

    `Warning: Cannot modify header information – headers already sent by (output started at /xx/xx/xx/wp-content/plugins/bp-group-hierarchy/extension.php:369) in /xx/xx/xx/wp-includes/pluggable.php on line 897`

    With error reporting turned off, I can create a group, but when it comes to the second step ’2. Group Hierarchy’ there is no options, and the site stops rendering due to the errors mentioned above.

Viewing 25 replies - 1 through 25 (of 25 total)
  • Avatar of David Dean
    David Dean
    Participant

    @ddean

    Support for 1.3 is planned, but I haven’t even had time to look into it. Unfortuately, there isn’t a way around using the `BP_GROUPS_SLUG`.

    Calling the setup_globals function for the groups component, which appears to be where the constant is being defined in 1.3, sets off the built-in group routing process, which is not hierarchy-aware. Unless routing is factored out of this function, the move away from a real constant could make this plugin much more awkward to use in 1.3.

    Avatar of Paul Gibbs
    Paul Gibbs
    Keymaster

    @djpaul

    Now’s the time to test it. Let me know if adding a hook or filter in core would help.

    Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    Hi David, thanks for your quick response – as a WordPress plugin developer myself I understand how tricky it is to keep up with development of a plugin as the platform (WP and BP) develop… especially as there is no financial payment! I understand what you mention in your post – sounds like there could be a major issue there with upgrading the plugin to work on BP1.3

    Also, thanks Paul for dipping in – as always you are a great help, I don’t know where you find the time on-top of you very demanding full-time work;)

    Group hierarchy as provided by this plugin seems to be something that is VERY useful for finer grain control and display of groups – David, I wonder if there is something that could be incorporated into the core to help you as Paul has offered? I’m guessing a simple patch to the core BP code could make your life a-lot easier with the upgrade to BP1.3 and with so few tickets left to complete before it’s release it would be a terrible shame to see this fantastic plugin fall by the way-side.

    I’m going to DM you regarding this as I am willing to offer you some financial support on this potentially. Obviously it is upto you how you feel it is best to tackle this issue, but a suggestion would be to look at submitting a patch to the BuddyPress core rather than heavily recoding your plugin (as you suggest it may not even be possible to get it working on BP1.3).

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    @djpaul: Thank you so much for the offer! I’m flattered that you’d consider altering the core to accommodate this.

    @jonnyauk, @djpaul: I’ve taken a look at 1.3 this morning and it’s possible to adapt hierarchy (at least the routing, which is the key) without any core changes.

    That being said, if there were a way to return a different object to `$this->current_group` on line 96 of `bp-groups-loader.php`, it would make life a lot easier and make things a lot more elegant. As it is, I have to subclass the `BP_Groups_Component` component and then replace its `_setup_globals` function in the `bp_setup_globals` action. This means creating a copy of that function just to change two lines.

    Something like: `$this->current_group = apply_filters(‘groups_get_group_object’, new BP_Groups_Group( $group_id ), $group_id);` would eliminate all of that.

    A filter on BP_Groups_Group::group_exists or on line 93 of `bp-groups-loader.php` would make things really nice, but the issue above is the real headache.

    Avatar of Boone Gorges
    Boone Gorges
    Keymaster

    @boonebgorges

    Is it not possible to hook in late to bp_setup_globals (maybe priority 999) and swap out the current group? That would let you replace the value in the $bp global before the page rendered, without subclassing BP_Groups_Component.

    Another option: Why don’t you filter bp_current_action()? If current component == groups, then return whatever group_id you want. Just a thought.

    If these techniques won’t work, please submit a core patch for your requested filters. I don’t see any reason why such filters shouldn’t be included, if there’s no other way to do it.

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    Unfortunately not. As soon as `BP_Groups_Components` sets up its globals, it also decides whether the path is valid. It will consider the child group name an invalid action variable and send a 404, so there’s no chance to go in and fix it after the fact.

    Using the `bp_current_action` filter (which is awesome, BTW) is a good start, as it will load the correct group. But if you JUST do that, all the nav items on the group page will have the wrong path, since the only way to make the routing work is to tear off all but the last group slug.

    So currently I’m subclassing AND filtering `bp_current_action`. It works fine this way, though. But I’ll submit a patch as soon as I can figure out how to make Eclipse spit one out. :)

    Avatar of Paul Gibbs
    Paul Gibbs
    Keymaster

    @djpaul

    By “path is valid”, do you mean the 404 checks at the bottom of _setup_globals()?

    Avatar of Paul Gibbs
    Paul Gibbs
    Keymaster

    @djpaul

    Not sure if it’s a good idea, but could also do something like:

    `
    $group_class = apply_filters( ‘bp_group_object’, ‘BP_Groups_Group’ );
    $this->current_group = new $group_class( $group_id );
    `

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    I do mean those checks. I think that’s what is responsible for the redirect.

    And that is a really nice idea! That way the default constructor isn’t called if it’s not going to be used.

    Avatar of Boone Gorges
    Boone Gorges
    Keymaster

    @boonebgorges

    Yeah, filtering the class name rather than $this->current_group would probably save some cycles. But we don’t really have a precedent for doing this elsewhere in BP. It’s worth discussing on a trac ticket when you get around to opening one :)

    Avatar of Boone Gorges
    Boone Gorges
    Keymaster

    @boonebgorges

    @ddean BTW, this is sort of off the topic, but it’d be great if you got involved in core development a bit when we start working on 1.4 development. We’ll be shifting groups to a custom post type, which means that we’ll get things like post_parent for free. It’d be great for BP to get your insight regarding how the interface and API around group hierarchy should work, and it’d be great for users of your plugin for the changes in 1.4 to be as backward-compatible as possible. Something to think about!

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    I finally opened a trac ticket (http://buddypress.trac.wordpress.org/ticket/3312) so we can have a more focused discussion. Sorry for the delay. :/

    @boonebgorges: I’d be happy to contribute code and/or experience to core developement! If the feature requests are any indication, there will be lots that people want out of the interface.

    @jonnyauk: there’s a really early test version posted to the WordPress site under branches/1.3-compatible. It throws lots of warnings and plenty doesn’t work, but it will hopefully provide enough to keep working on your site while development continues. Let me know what you think!

    Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    @ddean Wow – thank you so much for getting into this 1.3 issue so quick and putting all that time in, I’ll be testing the 1.3-compatible version as soon as I can. Although I’m reasonable with PHP and know WordPress well – my BuddyPress knowledge goes nowhere near this deep, but i’ll be happy to share with you any worthwhile development. Now we are aware of the structure change in BP1.4, I can consider this for the future structure of the site – really exciting stuff, and news to me!

    I’ve checked out your ticket – http://buddypress.trac.wordpress.org/ticket/3312 – filter looks like a clean way of doing it and would allow 1.3 compatibility much easier for upgrade of your plugin;)

    @boonebgorges @djpaul – that’s exciting to know about BP1.4 (custom post types) – I am always very much in the mind of using the WordPress core wherever possible and what is proposed makes a-lot of sense for the future of BuddyPress, good work guys.

    Avatar of Paul Gibbs
    Paul Gibbs
    Keymaster

    @djpaul

    There goes my Wordcamp Portsmouth talk! Better cancel now ;)

    Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    Sssshh, don’t worry Paul – I won’t tell anyone! Joking apart, I can’t wait to hear your BuddyPress talk at WordCamp Portsmouth UK this year – it’s going to be a fantastic conference;)

    Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    @ddean I’ve tested out the current code from branches/1.3-compatible, it stops the group creation process even with errors sadly with the undefined BP_GROUPS_SLUG constant error.

    Do you have much work to reconfigure the plugin to use the proposed filter in http://buddypress.trac.wordpress.org/attachment/ticket/3312/ – By the sounds of it this is all you need in the BuddyPress core? Thanks again for your work on this, it’s very much appreciated.

    Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    @ddean – Following on from the previous post, I was wondering if you had a chance to look into my previous post – with the patch in-place (new filter) is it now possible to get this plugin working with 1.3? I have had a good look around the code in branches/1.3 compatible, but I’m afraid I’m beyond the limit of my BuddyPress knowledge;(

    Any help would be appreciated – I’m desperate to get this functionality working.

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    @jonnyauk: I’ve been trying to fix bugs and lay the ground work, but haven’t had much time to work on improving 1.3 compatibility yet. Hopefully later today I can get started, and there’ll be something to show for it early next week.

    I’ll keep the 1.3-compatible branch updated and let you know as compatibility improves.

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    @jonnyauk: new version posted to the 1.3-compatible branch. Everything I’ve tested (routing, group creation, the tree) works on 1.3-bleeding, but I hesitate to release it until I can test against 1.2.x as well.

    Have a look and tell me what you think!

    Avatar of Paul Gibbs
    Paul Gibbs
    Keymaster

    @djpaul

    We’ve got the patch into core now; hope it helps

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    Great! That should make things a lot cleaner. :)

    Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    Thanks @ddean – REALLY appreciate you looking into this for me and working on it. I’ll be able to begin testing Thursday (28th) evening hopefully – and have all day Friday scheduled to revisit this project and tie-up loose ends, so I’ll be able to give it a proper test drive then and feedback.

    I talked to a few developers about BuddyPress Group Hierarchy to quite a few active BuddyPress developers during WordCamp Portsmouth UK – and they all agreed it seemed like pretty much essential functionality, and something they were interested in for their own projects.

    During Pauls presentation, he mentioned that the structure is changing to custom post types in BP1.4 (as was let slip earlier in this discussion;) – I’ll be happy to try and contribute the best I can to the ‘upgrade’ process in the future David, but I’m no DB guru. We have plenty of time for this as it’s going to be quite a few months yet before BP1.4 is released.

    I’ll provide all the feedback I can on the new version – and finally thanks Paul, appreciate the patch (I think we are even after the WordCamp *ahem* Site Doctors session mate!). The BuddyPress community reminds me of how the WordPress community was 5 years ago – and is something that I want to contribute to in the future.

    Avatar of louisnorthmore
    louisnorthmore
    Member

    @louisnorthmore

    This sounds great guys! Just what I was looking for and talked to @jonnyauk about. I’ll test too!

    Avatar of Paul Gibbs
    Paul Gibbs
    Keymaster

    @djpaul

    Har har; that session started too early ;). The replacements did a splendid job, by all accounts

    Avatar of jonnyauk
    jonnyauk
    Participant

    @jonnyauk

    I was able to do some testing Friday, but have been looking at this again today… sorry @ddean – it doesn’t seem to be working quite right just yet – but I think we must be nearly there;) It looks like there may be a problem with how you manipulate the URL’s on group creation? I’ve had a look over the code, and it looks good (from what I can interpret!!)… hopefully this will be a simple fix which will get it all working;)

    I’m using:
    - BuddyPress Version 1.5-beta-1 (latest checked out from trunk as of today)
    - WordPress 3.2.1
    - branches/1.3-compatible version of BP Group Hierarchy plugin

    When you click on ‘Create Group’ you get a 404 error with the plugin activated – I’ve double checked the paths and can confirm that the permalink hasn’t changed. You can’t get to the first step of the group creation process.

    - If I paste the URL in ‘/groups/create/step/group-details/’ with the plugin active, the first ‘details’ tab is revealed correctly, and the ‘Group Hierarchy’ tab is there (as step 2, before ‘settings – step 3), but when I fill in the details on the first ‘details’ tab (name, description) and click ‘Create group and continue’, it generates another 404 – the link it is trying to get to is ‘//create/step/group-details’ (notice double slash and also this should be the hierarchy step).

    Sorry to report back the bad news – I’ve tried to be as clear as I can.

    Yup, it all went well @DJPaul thanks – real shame you weren’t around, but no more silly jokes on that one… promise!

Viewing 25 replies - 1 through 25 (of 25 total)

You must be logged in to reply to this topic.