Catchable fatal error Groups when with WPML

Hi,

Thanks for pointing out the issue, will have a look …

Cheers

Thank you, will be waiting. ??

Problem isolated!

Plugin conflict with Press Permit Core plugin.

1. Enable WMPL + Press Permit Core = Catchable fatal error class-groups-post-access.php on line 397
2. Disable WPML + Enable Press Permit Core = Working Appearance > Menu
3. Enable WPML + Disable Press Permit Core = Working Apearance > Menu

Why? Groups does want Press Permit Core? I guess due to similar functions maybe… I think I can just throw away Permit Core.

Hi,

Thanks for the update on that, yes it looks like there’s a conflict … will try to find out where this comes from and if that should be handled within Groups.

Cheers

Hello Plugin authors,

I faced the same issue. While debugging found that there is problem with postid passed on line 114. sometimes instead of postid an object is passed through $arg[0].

Please have check and provide a bug fixed version of group.

Hope my comments will help.

Thanks,
Tushar.

Also to Plugin Authors,

The error goes away when I disable PP Collaborative Editing Pack Version 2.1.34.

I am NOT using WPML.

Hey there, hope you’re well..

Same problem here.

[01-Jul-2015 12:52:30 UTC] PHP Catchable fatal error: Object of class stdClass could not be converted to string in path/to/groups/lib/access/class-groups-post-access.php on line 398

In our special case we use wpDiscuz. If we click the “Load more comments” – Button, we get an error in Chromes Console:

jquery.js?ver=1.11.2:4
POST https://domain.de/wp-admin/admin-ajax.php 500 (Internal Server Error)

And then you find the first message inside the php-error.log.

In our case we need to deactivate Press Permit Core itself to fix the error.

Is this a problem of Groups or of Press Permit ?

Best regards

Hi all,

Many thanks for all the pointers and info. I’ve been able to verify the cause (a constructed object by PP used as context where normally a post ID is expected for determined capabilities).

The only feasible way I see is to shield the map_meta_cap filter hook we use in Groups in case something like that comes along (when it shouldn’t IMHO). I suppose that its author needs that in there to make its thing work, so I’ll rather go this way and have it ready if anything else like that is used by other plugins (this happens in pp_map_meta_cap where an object is constructed and passed as context – inside that function it’s called $_post). I don’t see a justified generic case we should cover, if I’m wrong about that, I’d appreciate any comments.

Anyhow, I will test and release an update for that.

Cheers

Update: Solved the PHP error produced in the cases above in Groups 1.7.1.