Map view not working with BuddyBoss Wall

[Brian]

I cannot get Events Calendar Pro map view to work with the BuddyBoss Wall plugin. The spinner, spins forever and no pins show up on the map.

It works fine with BuddyBoss Wall is deactivated.

What would cause this and how would I/you debug it? Thanks.

BuddyBoss Theme 4.1.9
BuddyBoss Wall 1.1.5
Events Calendar 3.9.1
Events Calendar Pro 2.92
BuddyPress 2.2.2.1
WordPress 4.1.1
disabled all other plugins

Not working:
http://buddyboss.clusterinteracti.netdna-cdn.com/wp-content/uploads/2015/04/map-view.png

Working:
http://buddyboss.clusterinteracti.netdna-cdn.com/wp-content/uploads/2015/04/map-view-working.png

[Barry]

I’m sorry you’re hitting up against difficulties, Brian: would it be possible to get a link to a live example of the problem, even if that is only on a basic test site?

[Brian]

Hmmm. Not really because this is a dev site on my local machine. I can send you the plugin if that helps.

[Barry]

Sure, we can take a quick look (though I can’t offer any guarantees). Please feel free to upload a .zip of the plugin to your website or a service like Dropbox then provide the download link by private reply 🙂

[Brian]

This reply is private.

[Barry]

So map view (and map view pagination) continues to work when I activate both plugins: are there any further set up steps I’d need to run through? I did for instance position a BuddyBoss Wall widget on the map view page, again there was no issue.

If a particular setup process/configuration is required to see this we can still take a look – but I’d ask that you do this on a publicly accessible test site so we can take a look at it in situ 🙂

[Brian]

This reply is private.

[Barry]

Hi Brian,

It worked perfectly as you said, and then I figured out what broke it.

Just change the line in wp-config.php from
define(‘WP_DEBUG’, false);
to
define(‘WP_DEBUG’, true);

That is odd!

Again, I’m unable to replicate locally so perhaps there’s another factor at work here. If you switch to a clean installation – running just our plugins and BuddyPress/the wall plugin (and add nothing else) – do you still hit this with WP_DEBUG set to true?

If not, perhaps we can isolate some other setting that might be impacting?

[Brian]

Hi Berry,

That’s exactly what I did here:
http://acropedia.brianswebstudio.com/events/map/

That is a clean install with just those plugins and the Twenty Fifteen theme with WP_DEBUG set to true.

As you can see from visiting that link, map view is broken.

[Barry]

Within your wp-config.php file can you add (next to your WP_DEBUG definition):

define( 'SCRIPT_DEBUG', true );

Then let me know when it’s in place? This will make it easier to track the chain of events.

[Brian]

This reply is private.

[Barry]

Thanks Brian, that helped!

(Thanks also for offering login credentials, however our current policy is not to accept login credentials that would give us even limited administrative access.)

It seems the breakage is because an error message is being inserted into some data which one of our map view scripts depends upon. In production of course you should not have WP_DEBUG/WP_DEBUG_DISPLAY on and this won’t happen there, but it would certainly be a problem when developing and testing.

However, I believe the problem’s source is actually BuddyBoss Wall itself:

• When WordPress’s plugins_loaded action fires – which is quite early on in the lifetime of a request – some BuddyBoss Wall logic runs
• Amongst other things, BuddyBoss_Wall_Plugin::setup_actions() is called and this tries to determine various things about the status of the current visitor
• Following the chain of events along, BuddyPress’s bp_setup_current_user() function is called which complains about being accessed so early – triggering the warning notice which is being injected into the data our own map view requires

So this ultimately is stemming from code in BuddyBoss Wall and it is probably worth pursuing this with the authors of that plugin – since it targets BuddyPress it ought to follow along with the best practices of that plugin and, as it stands (and I believe this is actually a general WordPress best practice), causing the user object to be initialized before $wp->init() is something of a “no no”.

Does that help here?

[Brian]

Yes, thank you Barry. You have been most helpful.

I will pass this information on to BuddyBoss developers in the hopes it can be resolved quickly.

Marking this as resolved for now.

Best,
Brian

[Barry]

Great, hopefully they can take it from here 🙂

What I’ll do at this point is close the topic (since it has been marked as resolved) but if you need anything further from our side for this issue please simply create a fresh topic and link back to this one to give some context to whichever team member takes it on.

Thanks again!

[Author]

Posts