Jer Clarke

Update: On my bug report to facebook:

https://developers.facebook.com/support/bugs/528062961705144/

They claimed the following:

Looks like your business verification process is not completed. Please complete the business verification process and then try again.

More details can be found here:
https://developers.facebook.com/docs/development/release/business-verification/

Now I have never had a verified business and this plugin has worked for months. They never sent me a notification about this becoming a requirement, despite the many messages they’ve been sending about “Oembed Read”.

I really don’t want to go through this process if I don’t have to, as it’s a hassle and my org has been annoyed in the past by the effects of being in a “business account” or whatever.

My question to those for whom it is and isn’t working: Is your FB “app” in a “verified business”?

Thanks in advance for your answers. I suspect this really isn’t the key issue.

Update: On my bug report to facebook:

https://developers.facebook.com/support/bugs/528062961705144/

They claimed the following:

Looks like your business verification process is not completed. Please complete the business verification process and then try again.

More details can be found here:
https://developers.facebook.com/docs/development/release/business-verification/

Now I have never had a verified business and this plugin has worked for months. They never sent me a notification about this becoming a requirement, despite the many messages they’ve been sending about “Oembed Read”.

I really don’t want to go through this process if I don’t have to, as it’s a hassle and my org has been annoyed in the past by the effects of being in a “business account” or whatever.

My question to those for whom it is and isn’t working: Is your FB “app” in a “verified business”?

Thanks in advance for your answers. I suspect this really isn’t the key issue.

FWIW I’ve created a FB “Bug report” for my issue:

https://developers.facebook.com/support/bugs/528062961705144/

Related issue: https://www.ads-software.com/support/topic/stopped-embedding-instagram-posts/

I already posted my experiences there, but to summarize them:

• Embeds stopped working on my site which runs the plugin
• I went and saw that I was past due on a “Data Checkup”, so I did that and it all passed. (In the other thread people did this step and their embeds started working. From what I can tell this is the intended behavior from Facebook. You have to do the checkup or the app gets disabled, but that should fix it.
• Embeds still didn’t work.
• I then saw the other notifications from FB about doing a full app review to enable the new version of the oEmbed_read ability or whatever it is. The notifications say that this review isn’t required until September, but I figured I should do it now in case it fixed my problem.
• I went through the forms to submit and managed to make it work. They make no sense for our use case, because they assume you’re making an actual app like Candy Crush or something, with app screens inside FB, which is totally irrelevant. What I did to fill them out was to just write over and over what I wanted to do: Embed FB/Instagram in a WordPress site. Where it asks you for a URL with facebook, I literally just put https://www.facebook.com/facebook . That’s extremely stupid but it worked. About 24h later my app review was approved
• So now in the <b>Permissions and Features</b> table of my <b>App Review</b> dashboard, under <b>Oembed Read</b> it says <b>App Review Status: Live</b>. I can’t find any hint anywhere in the dashboard that my app is anything but totally ready for the present and future.
• It still doesn’t work.

I’m getting pretty fed up with FB at this point. These systems are very buggy and unpredictable. I don’t think it’s intentional, I think some switch is in the wrong position for my app and their system just can’t fix it using the settings provided.

<b>JSON Request Results: OAuthException</b>

Here’s the JSON returned by the requests that WP sends for the oEmbed code:

{
"error": {
"message": "(#10) To use 'Oembed Read', your use of this endpoint must be reviewed and approved by Facebook. To submit this 'Oembed Read' feature for review please read our documentation on reviewable features: https://developers.facebook.com/docs/apps/review.",
"type": "OAuthException",
"code": 10,
"fbtrace_id": "AoGtevoV5ezli5Elv831VeM"
}


As you can see, it continues to tell me I need to submit the Oembed Read feature, but I already did that and was accepted. I noticed this error after I had submitted my review, so I’m not sure if it was already showing before I did the “Data Checkup”.

Clearly at this point it’s just innacurate, but I don’t know what to do about it.

How to get the JSON results for your requests: I’m not sure how best to tell you to do this. I do it with a custom logging system I use that adds an error log for every WP HTTP API request that happens on my dev site. It showed me the URL WP was using to request the image, and opening that URL in the browser let me see the error text above. Maybe at some point this plugin could be updated to expose this info to users in the WP editor, so they’d have a hint at why embeds break.

<b>Details of my accepted App Review</b>

For anyone curious, here’s the completed app review, to show I did it and help anyone else who isn’t sure how to answer the stupid questions they ask.

So the app review actually finished within a day or so, and my app is now marked as “Live” under “App Review Status”, BUT it still doesn’t work. I continue to get the same “OAuthException” error I pasted above, 3 days after the app was accepted in both App Review (to avoid the September deadline) and a data checkup.

Starting to wonder if there IS a bug in the plugin. No matter what I do I get the same error.

If I set a completely invalid set of API credentials, I get an error that the account is invalid, so it’s at least differentiating between accounts and probably has identified my account, it’s just wrong about me not having passed the review process.

Related issue:

https://www.ads-software.com/support/topic/facebook-app-review-rejects-my-oembed-url/

In that one someone already tried talking to a support person, and was told to put their app in development mode, which is insane but interesting. Mine is already in development mode and always had been, so this is probably not my issue.

Quick update: It seems like in addition to the “Checkup”, I am also being forced to go through the app approval process mentioned above, even though it’s nowhere near September 7.

The whole interface within Facebook is truly horrible, and it’s very hard to answer the questions in the review request because they are so irrelevant to the oEmbed tools we’re actually using, but I think I got through it.

The reason I think that is the thing I need to do is the JSON results I get from the API calls that the plugin is making.

{
 error: {
  message: "(#10) To use 'Oembed Read', your use of this endpoint must be reviewed and approved by Facebook. To submit this 'Oembed Read' feature for review please read our documentation on reviewable features: https://developers.facebook.com/docs/apps/review.",
  type: "OAuthException",
  code: 10,
  fbtrace_id: "AcDWoE1UtFA4v-0L6C87qCO"
 }
}

Normally you wouldn’t see this, but I logged the URL being requested and checked it manually to see the output.

If anyone is having this issue and can check the equivalent let me know what you find. I don’t trust Facebook at all to get these errors right.

Hey all, I’m wondering how long it took to start working again for you?

On your advice, I went to my developer console and saw that I was also long overdue for one of these checkups.

For anyone else:

– I went to https://developers.facebook.com/
– I went to my Alerts inbox
– I opened an alert about Data Use Checkup
– I clicked START CHECKUP
– I followed the instructions

For those that have it working again:

Did it start working right away? After an hour?

It’s been about 15 mins since I successfully did the checkup, but my Instagram embeds are still failing to load.

Thanks!!!

Image of the admin and everything is a link:

Image of the source code as Chrome sees it:

I have a solution. It’s something we were already doing for other reasons, but an inconsistency in how I was doing made this bug bite me like it’s biting the rest of you, so now here’s some info that might help someone willing to put in some extra legwork.

Basically: This plugin uses the Google Analytics API to fetch data from GA into WP.

By default it does this for two main reasons: On initial setup it does it to authenticate and pull down your list of profiles (sites), so you can pick which site this is from the pulldown menu.

Later, it uses the API to fill the dashboard widget with up-to-date data.

(in my case, I have custom code that does OTHER things with this API, like fetch a list of popular posts or stats for a particular post).

The good thing is that once the plugin is set up with your profile ID, it should keep tracking visits unless you reset the plugin configuration, so lots of people are probably still using this fine and only the widget is broken.

So what’s the problem? The API requires you to set up an “app” in the Google Interface, giving you keys to set up your “app” (this plugin), but the keys this plugin uses have gone bad somehow.

The way Analyticator works with it’s app keys is super simple: The dev set up an app, and they put their keys into the PHP of this WP plugin (near the top of google-analyticator.php:

php
define('GOOGLE_ANALYTICATOR_CLIENTID', '1007949979410.apps.googleusercontent.com');
define('GOOGLE_ANALYTICATOR_CLIENTSECRET', 'q06U41XDXtzaXD14E-KO1hti'); //don't worry - this don't need to be secret in our case

This seems to have worked for awhile, but if you think about it it’s clear there’s risk of a LOT of problems. Want an example? Well my use of the API as described above to pull down extra stats like recently popular post was using too many calls because it was buggy, and ended up making the Analyticator “app” stop working for awhile because Google was throttling that account. I noticed this because my API calls stopped working, but it wasn’t just broken for me, it was broken for EVERYONE who uses this plugin! We all had to wait for Google to take the Analyticator app out of the penalty box just because of my actions on a single website. Not good!

So what’s the solution? Everyone have their own Analytics app and keys.

The immediate problem we’re actually facing is that the Analyticator “app” in Google is currently disabled for sign-in. Nothing we do will fix this. Maybe the developers got email about it and could do something to make it work again, but we are helpless. I don’t know what caused it, but honestly there’s a decent chance that it was the fact that thousands of people were using that “app” to log their sites in (i.e. using this plugin), and that’s not how Google wants those apps to be used. (See the code above, where it says “CLIENTSECRET”, then the developer wrote in a comment “don’t worry”. That’s a bit of a red flag, amirite?)

The way I solved my problem was to create my own app, then hack this plugin to allow me to override the default CLIENTID and CLIENTSECRET keys with my own personal ones. I did it to get around the API call limitations, but it ALSO works to avoid this problem with the blocked app that is breaking the plugin for everyone.

So why can’t I tell you how to make it work? I don’t remember how I created the app.

I’ve just spent like half an hour trying to reverse-engineer my API key and for the life of me I can’t figure it out. I looked through all the screens I could find and used google search and looked in several google accounts, but nothing I find looks like the CLIENTID and CLIENTSECRET that need to be replaced in this plugin.

And, because it’s actually working for me at this point, I am going to give up for now and hope that all these clues I’ve provided will help someone desperate to get this plugin working find the instructions for creating an app and getting the keys that will fix this problem. Good luck!

More notes

– I suspect the real answer for a plugin like this is that it forces you to create your own keys in Google before you can use it. It’s a pain in the butt, but probably necessary. A couple years ago Google Maps plugins like GeoMashup had to go through a similar transition and it was awful, but with a helpful guide from the plugin dev, it’s doable.

– If you manage to get your own app set up and put the keys in, it might still give warnings when you try to authenticate the plugin. Mine gave me a kind of “this app isn’t trusted, use the links below to go through with it anyway” message like you used to get on hacked websites in chrome. If you click the links it will work though, and you can get authenticated!

– Here’s the code you can use at the top of google-analyticator.php to override the definitions for the keys. If you do it this way, then you can just put your own define() definitions with your keys into wp-config.php rather than your copy of the plugin, ensuring you don’t lose your keys if the plugin updates (though you’d have to re-insert this code in the plugin file, which there’s no real way around). I submitted this code as an improvement to the plugin in the past, but clearly it was never implemented. This code is a real improvement to the plugin for all kinds of reasons, but the current situation really makes it shine:

php
/**
 * JERHACK: Check if clientid and clientsecret are defined before defining them so they can be overridden
 */
if (!defined('GOOGLE_ANALYTICATOR_CLIENTID'))
define('GOOGLE_ANALYTICATOR_CLIENTID', '1007949979410.apps.googleusercontent.com');
if (!defined('GOOGLE_ANALYTICATOR_CLIENTSECRET'))
define('GOOGLE_ANALYTICATOR_CLIENTSECRET', 'q06U41XDXtzaXD14E-KO1hti'); //don't worry - this don't need to be secret in our case

• This reply was modified 4 years, 4 months ago by Jer Clarke. Reason: add code fences

Okay to update I have done more testing to confirm that the problem is with the MC backend and not with our plugin setup. The results present a lot of evidence that the plugin is working fine, and even the API seems to think everything is working, but somewhere behind the API requests to join our list are dying on the vine.

Summary

– On a new, local WP site with the plugin installed everything worked fine with a new MC account’s API key
– On that same site, switching to our API key resulted in the same behavior seen on our live site: Submissions receive a “Success” message, but nothing happens and the confirmation email never goes to the requester
– I found the API logs for both accounts and compared them: They match exactly, despite the fact that our live API key doesn’t actually work, while the test one does.

Testing with a test account WORKS

– I set up a vanilla WP site running totally up-to-date WP+Plugins
– Installed the official MC plugin we use on the live site
– Used API key from a small free personal MC account
– Attempted subscription using the form
– Got the confirmation email, confirmed subsciption and the email showed up in the audience (i.e. double-opt-in subscription worked)
– Checked the API logs ( https://us3.admin.mailchimp.com/account/api/ ) of the test MC account and it showed the API calls as successful

Testing with GV API keys FAILS but shows same success messages in API logs

– Tested the same thing on same setup, but with our actual API key from the account that’s causing problems
– Trying to subscribe shows the same success message
– BUT no confirmation email gets sent, subscriber can’t complete subscription, email doesn’t show in Audience
– Reviewing API logs shows the same results as the other API key that worked: The PUT commands are successful.
– Basically all API log fields match in both cases
– Red “X” marks are only there to indicate that the subscribed email wasn’t already in the database, so this is also effectively a success and it matches in both cases if I use a new email when testing the form.

API logs show the same result whether on our site or on my local test site

– I tested both using our API key on the clean local setup and on our live server
– API log results matched exactly regardless of the site where the API key is used

What I take away from this

– The plugin currently works, and is probably working fine on our site
– The API connection between plugin and MC is working on our site
– The API requests themselves using our key are working as far as the API logs are concerned
– SO: It’s at some level behind the API that the requests are ignored.

My guess: This situation with the flag on our account is the cause

– The flag is intended to block us from doing anything suspicious, and specifically to block non-double-opt-in-verification subscriptions
– Despite these requests all using double-opt-in verification, they are getting killed deep inside the MC system
– Because the API isn’t aware of this happening, it returns success messages and confuses the plugin
– This is probably due to the flag feature being relatively new.

What we need now: Confirmation that this is happening, and a fix so we can subscribe users again

The warning messages we got did NOT say we were banned from the API entirely, so someone at Mailchimp needs to get this working again for us!

Thank you for your help.

Below: Screenshot of the two API logs showing how they both succeed even though the second one fails to send confirmation emails

Click to enlarge

• This reply was modified 5 years, 1 month ago by Jer Clarke.
• This reply was modified 5 years, 1 month ago by Jer Clarke.

Thanks for replying so quickly!

Hmmm, that’s an interesting idea, I have a few custom taxonomies and things hardcoded and often use edit_users as a proxy for “pseudo-admin” roles.

But even if that’s the workaround, I think this constitutes a bug in the plugin, because after I untick edit_users and save, the message back from the plugin is Settings saved., despite the fact that at least one of them was totally rejected.

If I wasn’t paying careful attention and testing, I’d think this role no longer had edit_users and meanwhile the users in that role would still have the ability. It really violates user expectations to have a success message when the attempt failed.

It would be great if the plugin identified such failures and showed a big, noticeable warning when the page reloads, so it’s clear that it didn’t work.

This message would ideally also explain why it didn’t work, and give a sense of how to make it work correctly.

In my case, I found the taxonomy in question, and managed to turn off edit_users by removing both the taxonomy management and edit_users at the same time (turning off the taxonomy management on its own ALSO failed, I had to do them both at once).

If it weren’t for your help here, I would have been super unlikely to figure this out. If the plugin had told me “can’t remove because of X taxonomy” (or post type) I would have figured it out quickly (since the taxonomy management cap was an error, and once I was pointed to it, I would want to remove it too).

Thanks again for your quick reply, and for your work on this plugin. We’ve used it for years and it almost always does just what I want. Hopefully this feedback is helpful ??