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]

Here's my results

Vanilla WP site with MySQL, deployed manually to App Service

Publicise connects and iwr command working

PN site deployed via ARM to App Service - PHP set to 7.2

Publicise cannot connect and iwr is not working

PN site deployed manually to Window Server 2016 box with IIS & PHP 7.2

Publicise cannot connect and iwr Not working

PN site that was deployed a long time ago via Azure Deploy to Azure WebApp and recently upgraded to latest PN and JP versions and is on PHP 7.2

Publicise is connected but not working anymore and iwr command Working - confusingly

Now the only difference I could see in the configuration was that on my older site I have this additional plugin

Now I thought that this this functionality was not only included with WP core but also within Jetpack with the Json API feature but I am now doubting this - @jeherve can you comment on this ??

[patrickebates]

I have finally managed to capture an error that might be of interest. 401.3 - Unauthorized by what might be a loopback request to rest_route=/jetpack/v4/connection

You do not have permission to view this directory or page because of the access control list (ACL) configuration or encryption settings for this resource on the Web server.

[patrickebates]

To further complicate things, it appears that the site which the IWR command works on is not able to view or update Settings on Wordpress.com. But the site which the IWR command doesn't work with is able to view and update Settings via Wordpress.com. Starting to think that isn't worthwhile in this effort.

Interestingly, both sites appear to be attempting full syncs with WP.com but neither is progressing. Shouldn't be an issue as each site has at most a few dozen posts & pages.

[kilasuit]

I get the same issue with the full sync's too that neither complete, perhaps this is due to the same underlying error, I don't expect that it would be something else on top of that too or unlikely to be.

I'm unsure as where next to look into this with as it very much feels like an OS level issue. Have you managed to install PN on a Linux OS at all?

[patrickebates]

Yes, though the last time was a couple of years ago when we were involved in trials with the SQL Server team during their NDA period for their Linux release. Worked like a champ once we also worked with their driver team to verify that SQLSRV for PHP was ready for Linux as well. Though we didn't bother with much plugin testing at that time.

To burst your bubble a bit regarding this being an OS level issue, I did deploy vanilla WP with Azure DB for MySQL on a Windows-based Azure Web App and successfully connected social media accounts. Didn't try to publish a post, though.

What's annoying me at the moment is that there is absolutely NO PHP ERROR LOGGING taking place with regards to these failures, even though I have WP_DEBUG set. I have an email from @jeherve asking me to add some logging into the Jetpack plugin itself, so that looks like my next move.

At this point, I think all we need is some error output from exactly where the failure is taking place and we can resolve these issues. Just wish I knew why we aren't seeing it.

[patrickebates]

I might have finally found something useful.
class.jetpack.php function add_nonce isn't respecting JETPACK_DISABLE_RAW_OPTIONS This appears to be the source of the error logs you referenced at the start of this thread.

[patrickebates]

I edited the DB calls to confirm they would write the nonce correctly, and it appears they might have been working already. I can see a nonce written with each attempt to connect to Twitter, but the connection still fails.

Still no error logs.

[jeherve]

I thought that this this functionality was not only included with WP core but also within Jetpack with the Json API feature but I am now doubting this - @jeherve can you comment on this ??

Those are different APIs. That plugin you're using is indeed not necessary anymore; the API and all the endpoints included in that plugin are now part of WordPress core, since version 4.4. The API that ships with Jetpack is a different one; it is made to interact with WordPress.com.

class.jetpack.php function add_nonce isn't respecting JETPACK_DISABLE_RAW_OPTIONS

That could be what's causing issues.

I can see a nonce written with each attempt to connect to Twitter, but the connection still fails.

If you look at the access logs for your site when trying to make that connection, what kind of response do you get?

[kilasuit]

As per the merge above into Jetpack as referenced by @jeherve I will look to integrate the latest version of Jetpack into my site deployment pipeline and give this a test out and see if this completes over the weekend.

[kilasuit]

This no longer affects me as I have migrated from my blogs using Project Nami entirely. Not sure if you want to keep this open or close it @patrickebates