Changing BP_GROUPS_SLUG breaks group wire

[burtadsit]

There are a couple of issues related to this really. In some cases it's related to the $bp->current_component var being used as a part of the $bp global var. The other is $bp->current_component being used to resolve the wire table name.

Both of these relate to the desire to have the wire be a drop in feature for new components. Unfortunately changing BP_GROUPS_SLUG changes the $bp->current_component and changes the $bp->groups->slug.

If either of those are used as part of the $bp global or to resolve the wire table name things break.

I've included a patch that is a solution to the immediate problem but it will not allow the wire to be dropped in to other components. I haven't looked at that issue. Don't have a complete solution.

The real issue is that there is no fixed internal 'name' for groups that is unrelated to the slug used for urls. bp needs to decouple the group slug from it's component name. The component name is 'groups' the pretty url part is the slug.

Anyway, the patch shows the affected spots in the code. I think I got 'em all. I attached the irc debug log with the user just in case I did. I got lost in the code there a couple of times.

[burtadsit]

irc debug log

[burtadsit]

I'm back. Implementing those changes fixes his problem with the group wire but broke the profile wire.

(9:06:09 AM) Westy: would you believe it... now the profile wire has broken... i think it must have been something that was done whe we were changing things.. ??
(9:06:50 AM) Westy: the issue is that you can post and it says that it has been succesfully posted but it is not dispalying the wire messages..??

I don't see how those changes could have broke the profile wire. Any thoughts?

[burtadsit]

Well it seems he's change the BP_MEMBERS_SLUG also. I'm just going to recommend that he change the slugs back to the defaults because this just isn't going to work until the whole issue is resolved.

[burtadsit]

Well, he's up and running with just the 5 mods in the patch file and his custom slugs. The problem with the wire seems to have been related to some other mod during the debug session.

He's running 1.0 with custom member and group slugs and the patch. All is well. This is just a temp workaround though. If another component implements the wire it will break again in the custom component's wire.

[burtadsit]

I'm looking at this and it's all giving me a headache.

To allow components other than groups and profile to have a wire, the wire component can't hard code the table name. It has to be based on the component slug. Which identifies the component. Allowing the component slug to change invalidates the wire component's reliance on the component slug as the table name.

You can have one or the other with the current scheme. You can have wires for each component based on the component slug or you can have variable component slugs. Not both.

I'm back to having components needing a *fixed* component identifier. Which would allow the syntax $bp->{$component_name}->table_name_wire;

I'm thinking something along the lines of:

`
function bp_core_add_root_component( $component_id, $slug ) {

global $bp;

$bp->root_components[] = $slug;
$bp->component_ids[$slug] = $component_id;

}
`

Then this would be possible in bp_wire_new_post():

`
if ( !$table_name )

$table_name = $bp->{$bp->component_ids[$bp->current_component]}->table_name_wire;

`

The current component var can track the component slug and the table names will resolve correctly.

Am I thinking right about this?

[apeatling]

Thanks for looking into this Burt and identifying the problem.

I think the easiest solution would be to add a new setting for each component, something like:

$bp->profile->identifier = 'profile';

That would be set as the same name as the "->profile->" part. That way this is static and we can rely on this always being the same value.

It would then be a case of using that in wire, instead of the slug.

What do you think? It seems simple enough.

[burtadsit]

That would be useful Andy. I still think we need a discovery mechanism. We're back to catch-22 again. I have to know that 'profile' is the identifier for the component to access the component properties. All I know is the slug.

Perhaps:

$bp->profile->id could be used if I know I'm in the 'profile' component.
$bp->components->{BP_GROUPS_SLUG}->id to discover what the component profile is from the slug constant.
$bp->components->{$bp->current_component}->id from the url.

That would allow:

[burtadsit]

Sorry, this isn't the best way to carry on a conversation.

That would allow me to discover the component id when all I know is the slug.

[trcwest]

Heloo...

Basically I stilly have a problemo with the wire displying the post...

1) when NO patch the wire displays posts in PROFILE and NOT it Groups.

2) when patch IS implimented the Profile wire does not display posts but groups wire does.

i went through and it broke when i change line 31 bp-wire/bp-wire-templatetags.php to bp-wire/bp-wire-templatetags.php

now i know that this is becuase i have custom slugs.

What confuses me is when the patch is implimented it kills the profile wire i gues this is because groups has been hardcoded in and doesnt work with the profile slug but why does the profile wire work with the custom members to spotters slug and not with groups to spots slug.

I gues other people will have this issue so is there going to be a fix for it or a work around??

[burtadsit]

Westy, I installed a fresh copy of bp 1.0, turned off all other plugins except bp, applied the patch, changed both BP_GROUPS_SLUG and BP_MEMBERS_SLUG. Works fine with the default bp home and member themes. I can post, view and delete in both profile and group wires.

Must be a theme issue or plugin conflict. I've had problems in the past with google map plugins that use javascript. Specificly a version of jquery that was older than the one wp uses. Conflicts.

All I can tell you is that it works for me.

[trcwest]

ok well then im a bit stuck really...

I have tried with a new skelton theme.. Same issues

I personally dont think that it is a plugin issue or gmaps js conflict as the wire all works on the groups page when patch is implimented..... and not on the profile page

the profile page does not have any gmaps running on it?? ill try dissable the plugins but yeah..

it also can be a plugin issue as without the patch the wire works on profile??

well i will keep sloggin and if you can think of something thne great

[trcwest]

It is definately line 31 bp-wire/bp-wire-templatetags.php

$this->table_name = $bp->{$component_slug}->table_name_wire;

to

$this->table_name = $bp->groups->table_name_wire;

surely the groups thing is what is not dynamically getting the members wire.. thats why when implimented it dies on profile.. ??

IS there a way to have two seperate lines like

$this->table_name = $bp->groups->table_name_wire;

$this->table_name = $bp->members->table_name_wire;

finally i have tried with only the groups custom slug and no members and still the profile wire is broken so i think that proves that it is a patch problem..

i am sorry to keep going on about this but it is important to mee to get it fixed and i dont think its my fault??

[trcwest]

even with all external plugins disabled it is still faulty ??

[burtadsit]

Ok, ya westy was right. I missed a spot for another mod. Here's the patch with all relevent mods. I think. westy has blessed this one.

[burtadsit]

with all mods, don't use the first patch it's missing a fix

[burtadsit]

Includes all previously found issues. Includes a fix for the problem changing the BP_WIRE_SLUG and hardcoded /groups in groups widget

[alierkurt]

wire_patch_three.patch didnt work for me. the problem is with "slug" of groups. when i change it to my own slug, activities doesnt seem. but when i change my slug to "groups" i can see activites in the wire. so any suggestions? i need help too.

[apeatling]

This is a fairly major thing to deal with, so it may have to be bumped to 1.1.

[apeatling]

(rather than a 1.0 point release)

[(none)]

Milestone Wire 1.1 deleted

[apeatling]

(In [1718]) Fixes #723

[apeatling]

Thanks for your hard work on this one Burt.