Skip to:
Content

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#723 closed defect (bug) (fixed)

Changing BP_GROUPS_SLUG breaks group wire

Reported by: burtadsit Owned by:
Milestone: 1.1 Priority: major
Severity: Version: 1.0
Component: Keywords: has-patch
Cc: alierkurt

Description

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.

Attachments (4)

wire_slug_problem.patch (2.6 KB) - added by burtadsit 5 years ago.
wire_slug_problem.txt (12.6 KB) - added by burtadsit 5 years ago.
irc debug log
wire_patch_too.patch (3.0 KB) - added by burtadsit 5 years ago.
with all mods, don't use the first patch it's missing a fix
wire_patch_three.patch (5.4 KB) - added by burtadsit 5 years ago.
Includes all previously found issues. Includes a fix for the problem changing the BP_WIRE_SLUG and hardcoded /groups in groups widget

Download all attachments as: .zip

Change History (24)

burtadsit5 years ago

irc debug log

comment:1 burtadsit5 years ago

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?

comment:2 burtadsit5 years ago

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.

comment:3 burtadsit5 years ago

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.

comment:4 burtadsit5 years ago

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?

comment:5 apeatling5 years ago

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.

comment:6 burtadsit5 years ago

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:

comment:7 burtadsit5 years ago

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.

comment:8 trcwest5 years ago

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??

comment:9 burtadsit5 years ago

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.

comment:10 trcwest5 years ago

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

comment:11 trcwest5 years ago

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??

comment:12 trcwest5 years ago

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

comment:13 burtadsit5 years ago

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.

burtadsit5 years ago

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

burtadsit5 years ago

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

comment:14 alierkurt5 years ago

  • Cc alierkurt added

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.

comment:15 apeatling5 years ago

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

comment:16 apeatling5 years ago

(rather than a 1.0 point release)

comment:17 anonymous5 years ago

  • Milestone Wire 1.1 deleted

Milestone Wire 1.1 deleted

comment:18 DJPaul5 years ago

  • Milestone set to 1.1

comment:19 apeatling5 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [1718]) Fixes #723

comment:20 apeatling5 years ago

Thanks for your hard work on this one Burt.

Note: See TracTickets for help on using tickets.