Thread Starter
Li-An
(@li-an)
The answer is simple: yes for all the three.
A question: I use in functions.php
add_action('init', 'my_custom_init' , 90 );
function my_custom_init() {
add_post_type_support( 'snippet', 'wpcom-markdown' );
add_post_type_support( 'comic', 'wpcom-markdown' );
}
Is it still needed for custom post types?
Hello @li-an,
Thanks your answer.
Since your answer is yes, you will need to use similar snippets for other custom post types.
For example, here is how we implement this feature for bbPress:
– https://github.com/Automattic/jetpack/blob/1cbafb5a4381fd19f4a066eda52a399ba034fa4c/3rd-party/bbpress.php#L42-L46
—-
Here is how we check if a specific post type has wpcom-markdown support
https://github.com/Automattic/jetpack/blob/d37c4eca5842ca81a9f0c368fad1b0b83561acef/modules/markdown/easy-markdown.php#L479
Please let us know in case you need further help for this issue.
Thread Starter
Li-An
(@li-an)
@htdat, Well, thanks for your answer. So it seems my code is good but it does not solve at all the problem as it is not directly related.
As a quick aside, if you only want Jetpack for the Markdown feature, you can use it in offline mode, as described here: https://jetpack.com/support/development-mode/
There’s also a plugin you can use for that if you prefer: https://ww.wp.xz.cn/plugins/surbma-jetpack-development-mode/
Ok, coming back to the core of the issue, the markdown should be stored in post_content_filtered and the generated HTML should be stored in post_content (apologies for my earlier reply, I was mistakenly testing with the Markdown Block).
Looking at the post example from your screenshot:
https://www.echodesplugins.li-an.fr/plugins/customizer-reset/
This is a regular post, not a custom post type, so the function above is not required here.
Can you let us know what is saved in post_content for this post? If the HTML is saved there, then it would seem that something on your site may be forcing the site to display post_content_filtered instead of post_content.
I know you already tried deactivating all plugins and switching to a default theme, but perhaps it could be something left over from a plugin or theme after deactivating it.
Can you also check the wpcom_publish_posts_with_markdown option in your wp_options table to make sure that is enabled?
Thanks
Thread Starter
Li-An
(@li-an)
Hello @drawmyface, things have evolved since the initial problem. For some reason, part of the problem is solved as HTML version is now showing frontend… and in editor after saving Markdown version. So Jetpack behaves like other Markdown’s plugins I tested: the content in editor is saved as HTML in post_content AND post_content_filtered. I lose the Markdown’s version after saving content.
1. wpcom_publish_posts_with_markdown is set to 1 in wp…options table
2. HTML is saved in post_content AND post_content_filtered
I made a test with a post created before the problem occured:
post_content in HTML
post_content_filtered in Markdown
AFTER saving
post_content_filtered is now in HTML 🙁
Thanks for the update.
At this point it’s most likely that the conflict is coming from something else that is hooked into post creation/editing, and passes the wrong values to post_content_filtered.
I know you already tried deactivating plugins, but did you try to save the contents of a new draft post between each deactivation and check what is saved in post_content_filtered? You could start with plugins that impact or add data to posts on change, and also performance plugins that might try to ‘optimize’ the database as posts are being updated.
Beyond this, I’m not sure what else to suggest, since we are unable to reproduce the issue, and it’s happening with other plugins too, not just Jetpack.
Let us know if you come across any new findings that might help.
Thread Starter
Li-An
(@li-an)
OK, thanks for your suggestion. I will try. I’m aware it’s a very strange problem and the main reason I posted here is because other people may meet the problem, answer here and it may help to find the reason.
Hi @li-an,
Understandable.
For now, I’m going to mark this thread as resolved.
Thread Starter
Li-An
(@li-an)
Mystery solved. The culprit is https://ww.wp.xz.cn/plugins/remove-special-characters-from-permalinks/. I discovered that a second WP of mine met the same problem so I investigated the common plugins. It’s kinda strange I did not find it immediately but it seems there were distinct problems solved one after the other.
So completely solved. Thanks to all for your help.
Thank you for letting us know what was causing the issue! Glad you got it resolved in the end.
