Issue with Publicise functionality of Jetpack with latest versions of PN

[kilasuit]

For further background please also see -https://github.com/Automattic/jetpack/issues/11044

I have tried deploying a new site on many occasions to test whether this was an issue with the deployment & whether this was limited to PN or not - I have also deployed another vanilla Wordpress instance as well where the functionality is actually working fine, which makes me think this is a PN issue not a Jetpack issue - however on trying to diagnose further I am unsure of specifics in where I should be looking to attempt further diagnosis.

Any suggestions would be helpful and if needs be I can spin up a test instance in Azure that can be used to further diagnose if needed.

[kilasuit]

I have just updated my issue on Jetpack side @patrickebates

FWIW - I have implemented the suggested possible fixes in https://github.com/ProjectNami/projectnami/issues/237#issuecomment-321665844 with out any success as well as the further comment in that thread by @jherve and restarted the Website and still having this issue.

This is however becoming more time critical as I cannot look to publish the site with this issue so as an aside option I am looking at other similar functionalities that could be used instead of publicise but this would not be my preferred option going forward.

[patrickebates]

Regarding #237 that's what we added the Must-Use plugin into PN for, to set that value. https://github.com/ProjectNami/projectnami/commit/8769db88e01b21a955e2733e5d8ea37aaa2a3f74

I have seen another site which had Publicise active for many years which recently had failures trying to publish new posts. I think it was related to a change in how Publicise operates where it send the data to WP.com rather than posting directly to the social media systems, but we didn't dig any deeper.

[kilasuit]

Looking into the logs of a totally vanilla site there seems to be a fair amount of these

2019-01-20 01:50:03 Error Code: 102 -- Begin Query translation attempt:
INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('jetpack_nonce_1547949002_xpZ6taUvd5', '1547949002', 'no')
2019-01-20 01:50:03 -- Translation result:
INSERT INTO wp_options (option_name, option_value, autoload) VALUES ('jetpack_nonce_1547949002_xpZ6taUvd5', '1547949002', 'no')

or similar being added to translate,log in the site

[patrickebates]

Those entries simply mean that not everything in Jetpack is respecting the function that will call the correct API to write options. Unfortunately Jetpack is notorious for direct DB access when it isn't necessary, and even against their own recommendations.

I disconnected an existing site from Jetpack, then reconnected it and reconfigured the Twitter connection. Seems to be working, based on the fact that it wasn't at all until I performed the reconnect. Kept getting what looked like XMLRPC errors.

[kilasuit]

It's plausible that it's this version of the plugin that isn't working - what version are you running on your site? On another site I run I have this working all ok though the version of Jetpack is quite old and won't update at all it seems from the UI

[jherve]

I have just updated my issue on Jetpack side @patrickebates

FWIW - I have implemented the suggested possible fixes in #237 (comment) with out any success as well as the further comment in that thread by @jherve and restarted the Website and still having this issue.

This is however becoming more time critical as I cannot look to publish the site with this issue so as an aside option I am looking at other similar functionalities that could be used instead of publicise but this would not be my preferred option going forward.

Hey there ! I just swing by this thread to say that you probably wanted to ping @jeherve and not me ;)

[kilasuit]

sorry for the incorrect ping @jherve - that'll teach me to type usernames in future

[patrickebates]

Turns out the site I tested on is running Jetpack 6.2.1 I will try a dev site with 6.9

Also, I've had lots of issues trying to update Jetpack within sites running on Azure Web Apps. The time required to update seems to take longer than the max execution time allowed there. I always upload Jetpack via FTP.

[patrickebates]

Now I'm more confused. Put 6.9 on a dev site, connected it to Wordpress, and now the Sharing section is missing on WP.com to even set up Sharing. On the bright site, there's no error and no translation logs on the dev site, so everything appears to be operating locally as expected.

[kilasuit]

If 6.2.1 works then I may try to go and find that version of the plugin and drop that on the site instead.

This is opposed to the 4.1.1 version that I know works on an older blog of mine.

On the dev site you've just put 6.9 on can you connect the site to your twitter account via the sharing page in the wp-admin sharing page once Jetpack is installed at /wp-admin/options-general.php?page=sharing ??

[patrickebates]

No, and until you provided me with that URL I wasn't aware it might have been moved back to the local installation. With 6.2.1, sharing was configured via the Wordpress.com portal which worked. This might explain why the connected 6.9 site doesn't have Sharing as an option in that portal.

Even worse, no error logs were generated when the connection failed in the same way you described above.

[kilasuit]

So this is then something that they've changed in Jetpack and not something that you can see as being a PN issue?

[kilasuit]

I have FYI dropped back to the 6.2.1 version (I am deploying site completely from code) and pushing a new deployment out now to test with that version.

Thanks for the help in troubleshooting :-)

[patrickebates]

I'm not sure if it is a PN issue or not at this time. I lean towards it being a PN issue, as that's how Jetpack usually goes, but without errors to look at it's going to be next to impossible to track it down.

As I reference above, and in other writings I have done, Wordpress.com (especially their VIP platform) require that plugins do not perform direct DB access and instead use the APIs. But when it comes to their own premier plugins, Jetpack and Akismet, they don't follow their own guidelines. Thankfully someone added the option into Jetpack to force using the Options API, which eliminated most of the PN issues with that plugin.

I can say that at this time the problem doesn't appear to be a database issue, but I am concerned that some function is being triggered which has a setting to suppress error messages. Wouldn't be the first time I've seen that happen with callbacks which may or may not run through XMLRPC.

[jeherve]

Hey everyone! 👋

I am trying to understand what's happening here, let me see if I am getting this right:

• You can reproduce the issue with any new site you create using the latest version of Jetpack (6.9) and the latest version of ProjectNami
• When you were having issues accessing the Sharing settings, the site was actually a local installation of WordPress, without any way to communicate with WordPress.com. (In this case, features like Publicize won't work since they rely on a connection with WordPress.com).
• On any new site, you do not experience any issues when initially connecting the site to your WordPress.com account. You only experience issues when try to use the Publicize feature.
• You do not experience any issues when using Jetpack version 6.2.1. (fwiw I would recommend against using such an old version of the plugin, as you would be missing out on the updates, some of them security-related -- # #, that we've made to the plugin in the past year).

Is that all correct?

If so, we would need more details about the error to better understand what is happening here. The Jetpack plugin includes a "Debug" page that contains some information about your site and its connection to WordPress.com. You can find it by clicking on the Debug link at the bottom of the Jetpack > Dashboard page in wp-admin.

Could you go there, copy the contents of the advanced debug results at the bottom of the page, and send them to us via this contact form so we can dig into it some more. You can mention this Github issue in your email so my colleagues will have more background about the problem.

@kilasuit I know you'd rather continue this conversation here on GitHub, as you mentioned here, and I'll be happy to come back to continue this conversation here once I know more, but for now we would need to have more information about the site to do some more digging, and that information is not something you can share publicly as it contains private details about the site's connection to WordPress.com.

Thank you!

Wouldn't be the first time I've seen that happen with callbacks which may or may not run through XMLRPC.

Right now, Jetpack relies on XML-RPC for almost all communications with WordPress.com. If XML-RPC is not fully accessible, you will experience issues.

[kilasuit]

You do not experience any issues when using Jetpack version 6.2.1. (fwiw I would recommend against using such an old version of the plugin, as you would be missing out on the updates, some of them security-related -- # #, that we've made to the plugin in the past year).

I deployed a new site with version 6.2.1 and still have this exact same issue so it seems not to be just version related however I have another site running a much older 4.1.1. version of Jetpack & older version of PN too where it works fine and is also hosted in Azure too.

Re

Right now, Jetpack relies on XML-RPC for almost all communications with WordPress.com. If XML-RPC is not fully accessible, you will experience issues.

I checked this and all seems to be fine via the troubleshooting that I had done previously,

Re

If so, we would need more details about the error to better understand what is happening here. The Jetpack plugin includes a "Debug" page that contains some information about your site and its connection to WordPress.com. You can find it by clicking on the Debug link at the bottom of the Jetpack > Dashboard page in wp-admin.

Could you go there, copy the contents of the advanced debug results at the bottom of the page, and send them to us via this contact form so we can dig into it some more. You can mention this Github issue in your email so my colleagues will have more background about the problem.

@kilasuit I know you'd rather continue this conversation here on GitHub, as you mentioned here, and I'll be happy to come back to continue this conversation here once I know more, but for now we would need to have more information about the site to do some more digging, and that information is not something you can share publicly as it contains private details about the site's connection to WordPress.com.

I will send through the details via the contact form and mention this issue in there further updates

[kilasuit]

@jeherve - I have sent this through now 👍

[jeherve]

I have another site running a much older 4.1.1. version of Jetpack & older version of PN too where it works fine

What happens if you update Jetpack on that site? Does the problem start happening? If things are still good after you update Jetpack, the next step would be to try updating PN and see what happens. This would allow us to narrow down the issue a bit.

[kilasuit]

I am not confident on that site as it currently stands as the UI does not show that Jetpack can be updated at all, plus this is my list of things that I need to look at updating anyway. this is something that I hope to get some chance to look into in the next week or so as I move the configuration of the site more into a Config and deploy from code way than it is currently set up.

[kilasuit]

@jeherve - I am going to set up a pipeline to deploy older versions of PN and see if this may have been introduced prior to 5.0.2 and update here if Jetpack works on older PN versions as it very well could be a PN issue but I am unable to determine whether it is or not via any of the logs as there's almost no logs there

[kilasuit]

I've started with the 1.9.8 version of PN (so before WP v5) & Jetpack 6.9 and have just kicked off a deployment of this. Will update if that works or not

[kilasuit]

Still getting the same issue - I'm gonna look at logs and see if I can find any reason why this may be happening

[patrickebates]

Even with WP_DEBUG set I'm not seeing any logs generated on my dev system.

I did make note of the URL which is reporting the error "There was a problem creating your connection. Please go back and try again or contact support." Without exposing every parameter, it appears to be on WP.com

https://public-api.wordpress.com/connect/?magic=keyring&action=verify&service=twitter

[kilasuit]

Yes this seems to be the case for me too which makes sense as the Publicise feature links to WP.com account via Jetpack anyway. I also notice that this was not just affecting Twitter accounts but also Facebook too.

FWIW - I am using only the Free version of Jetpack (which says it supports this functionality)

[kilasuit]

@jeherve - I cloned the site and updated Jetpack from 4.1.1 to 6.9 then deactivated and reactivated Jetpack, connected it to WP.com and then tried to set up sharing. it's not possible but does give a new error

Something which should never happen, happened. Sorry about that. If you try again, maybe it will work.

Error code: -10520

[jeherve]

I did make note of the URL which is reporting the error "There was a problem creating your connection. Please go back and try again or contact support." makes sense as the Publicise feature links to WP.com account via Jetpack anyway. I also notice that this was not just affecting Twitter accounts but also Facebook too.

That's all correct. And if your site is not correctly connected to WordPress.com, it would indeed impact all Publicize connections, not just one.

it's not possible but does give a new error

This error indicates connection issues between the site and WordPress.com. Could you now try to disconnect Jetpack from WordPress.com? To do so, click on Jetpack from your site's Dashboard and scroll all the way down where you'll see a link that says "Disconnect from WordPress.com". Click that to disconnect.

To reconnect, click the green button that says "Set up Jetpack" and follow the prompts. Are you able to reconnect?

[kilasuit]

@jeherve - I just did an update to my live site and this has borked the Jetpack install completely. I had to manually remove the Jetpack folder via FTP connection and reinstall the plugin from scratch

[jeherve]

It sounds like the plugin update process didn't complete properly, and some files were missing from your Jetpack install? This can happen sometimes, as discussed here: https://wordpress.org/support/topic/fatal-error-updating-from-jetpack-6-8-1-to-jetpack-6-9/

[kilasuit]

@jeherve - the Jetpack update seems to have worked all ok on my original site where I've done both a PN update and and Jetpack update.

This now seems to limit it to new sites however in the upgrade it failed to properly connect back up initially however WP.com shows that the site is still running on the older version of PN

That aside I still cannot get any new PN site to connect to Jetpack and be able to us Publicise at all and I need this for a new blog site that needs to go live soon. I may have to go live with other similar functionality but this is sub optimal at best especially as I will need a mechanism so similar to Publicise to allow authors to add their own social media options for items that they publish as well as the site's account.

[jeherve]

Did you have the chance to email me a detailed report from a site that failed, so I can take a closer look at what is wrong with the connection?

[kilasuit]

I sent it in via that support form and mentioned this issue so you should have it.

[patrickebates]

I did the same, providing the debug data from one of our dev sites.

[kilasuit]

Also whilst I have been able to connect my older site back up to Twitter and LinkedIn - Publicise has failed to publicise updates via either channel 🤷‍♂️

[kilasuit]

@jeherve - can do you have any updates at all?

[jeherve]

I have asked the folks on my team to let me know when they receive your email. I found a previous exchange with @patrickebates, but nothing from you yet.

Did you get a reply from one of my colleagues at some point? If so, could you let me know your ticket ID?

[kilasuit]

@jeherve previous ticket was 1614272 though not heard from most recent submission

[patrickebates]

I also did not receive anything back from my recent submission

[kilasuit]

I however on reread of all emails got pointed to try hitting this API endpoint once Jetpack was installed on the site which results in a 403 on all of the test sites I have - https://public-api.wordpress.com/rest/v1/sites/<sitename/siteurl>

so for example I run in powershell

invoke-webrequest https://public-api.wordpress.com/rest/v1/sites/mhasl.me

which returns a 403 error

which is pushing me to think that this is something either with Jetpack/WordPress.com talking to PN on Azure Websites as this doesn't seem to happen on a Wordpress Website in Azure (though I am testing further on this)

[jeherve]

previous ticket was 1614272 though not heard from most recent submission

I can't find any more recent email from you in our system. Could you try to email again?

Thank you.

[patrickebates]

Seeing this message at the Contact form link you supplied earlier in this thread...

Support for customers on Jetpack's Free Plan is temporarily closed.

[jeherve]

Yeah, you'd need a paid plan right now. If you don't have a paid plan, could you email the email address you received our previous replies from?

[patrickebates]

@jeherve Please send a DM to ProjectNami on Twitter. Should be able to securely provide email address there.

[jeherve]

I just messaged you there 👍

[kilasuit]

FYI latest Jetpack v7 still has this issue too

[kilasuit]

@jeherve I have just installed PN on a full version of Windows Server 2016, turned off all firewall settings and installed JP v7.1

This seems to be able to enable the publicise feature which narrows this down to an Azure WebApp issue I think - I will dig more and test JP 7.1 on my development instance and see what happens

[kilasuit]

interestingly enough the sharing option in Wordpress.com disappears and reappears based on certain navigation pages that I click though but i still end up getting this issue when I attempt to connect Publicise with Twitter

[kilasuit]

The difference between working and non-working sites is as below

this says to me theres something wrong with Jetpack and how it's connecting to the site after that API call is carried out which isn't something that I can diagnose further I don't think

[patrickebates]

Ryan, I've been able to duplicate your results across a few different sites that I deal with on a routine basis.

Is there anything that these sites that are working vs not working have in common? For example, are the sites which are working originally set up by one method, and the other sites set up a different way? Perhaps some created via the Azure portal and others using our Deploy To Azure or another ARM template?

[kilasuit]

So my original blog site where Jetpack & Publicise was working fine on the older version of Jetpack and this now seems to be not posting any new blogs now via Publicise at all after updating to 6.9 after which I have tried to disconnected Jetpack, reconnected, reconnected all the Publicise connections (which seemed to work ok) but then subsequent posts don't seem to be triggering the Publicise functionality 🤷‍♂️ - this site was originally deployed using your Deploy to Azure Button a long time ago.

Mhasl.me (and minor variations) are all triggered from a slightly modified version of the azuredeploy.json in this repo that does things like get a secret from Key Vault for the db password and switching out some other minor details like site name etc for my dev / test / prod environments. This is all controlled and deployed via Azure DevOps Pipelines.

The only difference in all sites that I've trialled with seems to be PN v vanilla WP - though next on my trial list is WP on Windows Server with MySql (though that will be a tomorrow job)

Deploying a Wordpress Web App (as per the offering the Azure Portal) and then adding Jetpack to that site works, which narrows this down to it being between Jetpack changes / PN or perhaps potentially a windows issue

[patrickebates]

Let me complicate your testing a little bit...

Vanilla WP site with MySQL, deployed manually - working PN site deployed via ARM - not working PN site deployed manually - working

To be perfectly clear, Working is defined at this point as Publicise will connect and the IWR command you listed above works.

On the PN site that isn't working with the IWR command, I can't find anything in the logs at all. I have even enabled full logging features in Azure Web Apps, including failed request tracking, and I can't find anything reporting the 403 errors we are seeing.

Going to manually deploy some more sites over the weekend to try and duplicate these results.