Stats module of Jetpack causing core dump file

Ok, it’s 48h without any core.x file now. So I think we can consider solved this issue.

I have dome some tests without the Audio plugin (I deleted it because I don’t need of it anymore) and I discovered that WordPress itself does not crash with that code but it will IF Jetpack plugin is enabled. So, something inside Jetpack is still evaluating (wrongly) the code:
<p align="center">[audio:file.mp3]</p>

Emanuele

I tried inserting this into a post on a test site of mine, and the shortcode wasn’t rendered or processed.

Do you happen to use another shortcode plugin on your site?

Thanks!

I have WP-Syntax (https://it.www.ads-software.com/plugins/wp-syntax/) installed.
What do you think? What’s strange is that if I disable Jetpack (I updated again to the last version) that code is harmless to me too.

Jeremy, I deleted the Wp-Syntax plugin (I left the code/pre text blocks to be just monospaced with no syntax highlight). The crash is still there with WordPress 4.5.1 and Jetpack enabled.
If needed, the website is: https://www.dreamsworld.it/emanuele/

Emanuele

That’s really weird, I can’t seem to reproduce the issue at all on my end. I’m not sure what’s causing the trouble on your end, especially since Jetpack stopped interacting with audio Shortcodes a long time ago.

Could you try to deactivate the Shortcode Embeds module in Jetpack settings, and let me know if it changes anything?

It’s already deactivated. Actually, I have tested the code into another two WordPress installations (both with Jetpack enabled). One of these is hosted on the same server and account. None crashes with that code (!).

I have then – once again – tried to deactivate all the plugins except from Jetpack with no success. The code is evaluated as long as Jetpack is on.

That’s really strange. As you already know, I deleted and installed back again Jetpack when we were trying to figure out the root reason of those core dump files.

The compontents enabled on my Jetpack installation are:
– Advanced Distribution
– Manage (via WordPress.com)
– Monitor
– Protect
– Pubblicize
– Site Stats

Emanuele

That’s really weird indeed. Could you maybe try to reinstall WordPress itself on that site, and see if it helps?

I did it already one week ago:

2. reinstall WordPress (via FTP, I deleted and re-installed everything into the /wp-includes, /wp-admin and / folder).

I have already updated the theme to the latest version.

Emanuele

hm. I’m afraid I’m out of ideas at this point. The only thing we haven’t tried is switching to one of the default themes, like Twenty Fifteen. If that doesn’t help either, I’m not sure where to look next, since we can’t seem to reproduce anywhere but on that site.

Yes, I don’t have any ideas too. I just tested (install & activated) Twenty Sixteen theme with no success: if I insert that code in a post, that page will not be rendered and a 500 error will be raised, no matter the theme I am using.

Actually I am not using that (obsolete) code anymore but is really curious how all of this is still happening.

Emanuele

Could you try to remove your current version of Jetpack from that site, and replace it with this version instead?
https://github.com/Automattic/jetpack/archive/rm/audio-shortcode.zip

This version includes a patch that removes all vestiges of the audio shortcode from Jetpack:
https://github.com/Automattic/jetpack/pull/3759

Let me know how it goes.

I am using your version and, this way, WordPress doesn’t crash but the code disappear (is not shown as plain text).

If, I insert this code on the text editor (not the WYSIWYG one)
<p align="center">[audio:file.mp3]</p>
I will have (on HTML code):
<p align="center"></p>
As if the audio tag is stripped off.

Emanuele

I am using your version and, this way, WordPress doesn’t crash

Great! I’m glad to hear we’re making progress!

the code disappear (is not shown as plain text).

That’s not caused by Jetpack I’m afraid. This is mostly Core’s post editor removing the shortcode because it doesn’t match the expected audio shortcode formatting:
https://codex.www.ads-software.com/Audio_Shortcode

It might be best if you ran a search and replace for that pattern, and switch to using Core’s audio shortcode formatting for all those audio files. You can use a plugin like Better Search And Replace to do that:
https://www.ads-software.com/plugins/better-search-replace/

Let me know how it goes.

I am already using the new shortcode format. I am still here just for the sake of clarity. I am curious to discover the reasons of this bug. I don’t think is WordPress core to be stripping that code because in other 2 blogs I own, that text is printed as plain text and I think it has happened during your tests too.
What does this Jetpack version do differently from the official one?

Emanuele

I don’t think is WordPress core to be stripping that code because in other 2 blogs I own

From what I understand, you only have Jetpack left on that site, is that correct? You used to have the Wp-Syntax plugin installed on that site, but you deactivated it earlier.

There is nothing left in Jetpack that interacts with the Audio shortcode, so I’m not sure what else could be stripping the code at this point. Could you try to deactivate Jetpack, and see if the shortcodes get stripped?

What does this Jetpack version do differently from the official one?

Here are the details of the patch:
https://github.com/Automattic/jetpack/pull/3759/files

1. We previously loaded this file on your site, but only if you used the Shortcode Embeds plugin and if your version of WordPress was equal or less than 3.6-z. That file is now empty. However, since you use a recent version of WordPress, that wasn’t the issue in your case.
2. Whenever you use the Sharing, Publicize, or Related Posts modules, we run a tool that looks through your post content, and extract meaningful meta data from the different elements in your posts: images, videos, galleries, shortcodes. We previously looked for meta data about audio files, through the Audio shortcode. That patch stops Jetpack from doing that, and that’s what’s solving your issue. Our tool doesn’t try tog et meta data about your custom formatted audio shortcodes anymore.

that text is printed as plain text and I think it has happened during your tests too.

Correct.