firebrandllc

Hoo boy. Still broken even after updating both plugins to 3.0.2. Same error as before.

PHP Fatal error: Call to a member function parse_api_response() on null in /wp-content/plugins/social-warfare/functions/utilities/share-count-function.php on line 106

Starting to feel bad now, looks like this release was not at all ready for production. Let me know if you guys need any help.

No dice. On my staging environment (multisite) I updated both plugins to v3.0.1 and we’re still seeing a fatal error on any page calling the “social_warfare” function.

PHP Fatal error: Call to a member function parse_api_response() on null in /wp-content/plugins/social-warfare/functions/utilities/share-count-function.php on line 106

Keep in mind many hosts auto-update WordPress plugins, so sending an email telling people not to update just one version, at the same time of the release no less, is not at all helpful or preemptive.

Good luck!

+1 Same issue on production multisite instance. On another single site instance we’re seeing mangled styles but no “Fatal error”. Updated pro and regular versions to 3.0.1, no change. Removed Pro plugin, no change.

Had to disable plugin(s) for both sites.

Please take a look at this as soon as possible.

PHP Fatal error: Call to a member function parse_api_response() on null in /wp-content/plugins/social-warfare/functions/utilities/share-count-function.php on line 106

PHP Fatal error: require_once(): Failed opening required ‘/wp-content/plugins/social-warfare/functions/Social_Warfare.php’ (include_path=’.:/usr/share/php’) in /wp-content/plugins/social-warfare/social-warfare.php on line 28

The plugin that was causing the conflict was an internal plugin which was incorrectly calling switch_to_blog without always calling restore_current_blog on post update, which was causing broadcast to get some unexpected results in a query, which exhibited the bug.

However, if you are on the most up to date version of the broadcast plugin, this
particular issue should not occur, as the developer added stricter type-checking in subsequent versions.

If you are still having this issue, I would suggest turning on debug mode in the broadcast plugin and replicating the issue on a development site, and posting your results in a new support thread, that way we can best help you figure out what’s going on!

Thanks for reaching out Cédric!

Hey. This was actually the fault of another plugin which was causing queries to run on the wrong blog. Nonetheless Edward spent several days working with our development team to help track down the problem.

Great plugin, great support.

Thanks for the excellent help on this!

• This reply was modified 7 years, 5 months ago by firebrandllc.

Sorry for the delay in responding.
Thanksgiving holiday here in the US.

Thanks for the bug report, Kellyjholmes.

The plugin should be including the cxApi.chooseVariation() call. So there’s something wrong here.
Hrm… actually quite confusing since the plugin uses that call to determine which variation to display. If you saw more than the first variation, then it was getting a value from that function.

One way to see if the plugin is working is to check your Real-Time events (Real-Time:Events) in Google Analytics. We fire events of category “Simple Experiment” with an action of “select” when the plugin selects and displays a variation.

• Are you running Google Tag Manager?
• How is your Analytics being set up (coded into theme, plugin, Tag Manager?
• Could you share the URL of your site so I can take a look at what the plugin is generating?

Thanks

• This reply was modified 8 years, 3 months ago by firebrandllc.

We’re not seeing the error on the setting screen, but I put in some checking that should prevent that error in version 2.0.3.

Let me know how it works out.

Just uploaded version 2.0.2 which solves the line 57 issue.
Looking into the admin panel issue

Thanks for the report. Looking into right now.

Excellent bug report!

First some easy stuff:
Make sure both “gaGlobal” and “Event Handler” fields are completely empty in settings.

If you’re comfortable using the browser console, could you run
console.log( window["GoogleAnalyticsObject"])
Hopefully it returns “ga”

And
console.log(typeof(jQuery.scrollDepth))
should return “function” if all is going well.

Ah…
I updated WordPress and plugins on our own site, and didn’t see any events!
Perhaps you’re having the same problem: we filter out our company IP addresses in Analytics. ??

Please let me know.
If you’re still having issues, could you post your URL?

Heh. it looks like you’ve disabled the plugin in that site, so I don’t see the error. ??
I think you’re running the legacy Google analytics?
I can’t dig into MonsterInsights right now, but perhaps there’s something up there.

Is your Analytics actually reporting right now?

Well for sure not happening with 51.0.2704.103 (64-bit)
Updating and checking…

Hrm..
I’m not seeing that error.
I checked our own site which is running the plugin on BrowserStack:

• Win10, Chrome 51
• Win10, Chrome 52
• OSX, Chrome 51
• OSX, Chrome 52

and I’m seeing scroll events in my Analytics real-time events.

Using these cloud-based instances, I can be pretty certain they do not have any pertinent cookies set.

Could you tell me more about your setup?

• Are you using any of the options in the dashboard?
• How is your Analytics loaded? (plugin, theme, Tag Manager)
• If a plugin, which one?
• What version of WordPress?
• Is there a plugin that’s changing which version of jQuery?
• Are you accessing the site over https or http?

could you post a link to your site?
If you’re not comfortable doing that on a public forum you can email me: “lon” and-then-the-at-sign “firebrand.net”

I have a number of questions if you don’t mind.

• Are your running “Universal” or “Classic” Google Analytics?
• Are you running Google Tag Manager?
• How are you setting up your Analytics code? If a plugin, which one?
• Did you try looking at Real-Time events to see if anything is happening?

My initial suspicion is that your Analytics object has been renamed. (Just learned how to properly deal with while debugging another plugin)

Sorry for the confusion.
The “value” is just a placeholder.
The event names are the actual depth values.

If you’d prefer a single scrolldepth event with values being the percentage that triggered the event, we could certainly look into that option.
Let me know.

A common report would be show a pie chart of category “Scroll Depth”
https://imgur.com/6EFl2CH

View post on imgur.com

Sounds like you want separate scrolling reports for different pages?

I looked into the ScrollDepth library, and it is already using all the standard Event fields: Event, action, label, value.

If you’re using Universal Analytics, we could possibly add another field, but then you would need a dashboard UI for mapping that field to the page.

It’s probably simpler to just build this report in Google Analytics.
Create a table for each page you want to report on.

I created an example:

1. Add a new widget to your dashboard
2. Make it a TABLE widget
3. Display the following columns: “Event Label” and “Unique Events”
4. Filter: Only Show Event Category contains “scroll”
5. Filter: Only Show Page Title contains “The title of my Page”

View post on imgur.com

The second filter is how you could specify which page you’re trying to track. In this example, I used page title. But that could be “content group” any other filter.

Does this get you what you need, oblaum?