Convert posts using Markdown Block to Markdown in Classic Editor posts?

Markdown in Classic Editor posts when viewed in the Classic editor just straight-up has the Markdown as written

I assume you’re using text view in order to see G’berg/block comments. Presumably markdown appears in the front end as plain HTML, the markdown remains uninterpreted.

We might think the we could still process markdown using React and wp:jetpack/markdown, but resolving dependencies could be difficult. You might end up needing all of G’berg, defeating whatever the reasons are why you’re doing away with it.

Alternately, obtain one of the PHP markdown parser libraries and use it in a callback added to “the_content” filter.

Let me clarify in case my wordy original isn’t communicating the issue: it has nothing to do with how the posts are displayed on the blog, so I assume the_content is irrelevant. All posts whether from Jetpack’s Markdown Block or Jetpack’sMarkdown in Classic Editor display fine. I’m trying to literally convert what’s stored in the database, so that all posts stored in the format generated by Jetpack’s Markdown Block (as described above) get converted to the format of the posts that used Jetpack’s Markdown in Classic Editor (as described above).

I don’t know JetPack very well. Are you saying JetPack stores the proper HTML resulting from your markdown somewhere? So you wish to put this proper HTML in the post’s post_content field, doing away with your original markdown that’s currently there?

That can be done one way or another as long as you know where the proper HTML is saved. There might be some super-duper SQL query to accomplish that for all posts, but it’s beyond my pay grade. I would have to resort to using PHP to loop through posts, getting the proper HTML for the current post, then updating the post’s post_content field with it. This would all need to be custom coded unless you can find a plugin set up to do this for you.

Doing this to all posts in the DB can be time consuming, causing the code to time out. This process likely needs to be done in batches, re-running the same script on a new subset of posts until there are no posts left to process.

Sorry, let me clarify again (I’ll have to sit and reread my original post to see where it’s gone awry): what I’m seeking to do is take what’s stored in post_content for posts that had been written in Markdown Block (that crazy WP tag with the Markdown stuffed inside curly braces, followed by the HTML) and instead on those posts store the Markdown (absent the crazy WP tag wrapper) in post_content_filtered and leaving the HTML in post_content, thereby conforming those posts to how those written in Markdown in Classic Editor are stored.

• This reply was modified 1 year, 2 months ago by Anonymous User 17976131.
• This reply was modified 1 year, 2 months ago by Anonymous User 17976131.

Very well could be poor comprehension on my part. If so, my apologies.

Filtered content in the DB or in the API response? AFAIK it does not exist in the DB, it’s generated dynamically, IOW “filtered”. Unless you know where this filtered field actually exists. API responses are filtered in many ways, so it’s likely we can alter the API response as desired.

Assuming this is feasible, you want the markdown itself without WP artifacts to be the filtered response? That should be possible, I just want to confirm that’s your intention since I’ve already struck out twice in trying to grasp your intention.

My understanding per here is that for Markdown in Classic Editor posts the HTML created from the Markdown is stored in the database column post_content and the Markdown stored in the database column post_content_filtered. The corollary being that for Markdown Block posts the post_content column contains the mashup described earlier, with a specially formatted area containing the Markdown followed by the HTML created from it, and post_content_filtered isn’t used at all.

In the end, I’m trying to figure out a way to convert within the database itself existing Markdown Block posts’ use of post_content into use of post_content and post_content_filtered matching that of posts having been writing in Markdown in Classic Editor.

• This reply was modified 1 year, 2 months ago by Anonymous User 17976131.

I’m at a disadvantage. Even though I have many posts created in the classic editor, the post_content_filtered column is always empty. But I don’t use JetPack and thus there’s no markdown content either. So if you see content in that column it must be due to JetPack itself. I’m unable to examine my own site to better understand what you are trying to do.

In any case, if data exists anywhere, it’s certainly possible to place it elsewhere, assuming the data type (longtext for content) is compatible. But doing so is a remedial action for existing content. You’d still need to modify the processes that save and get data to utilize your new schema for all content, new or existing.

I’ve already briefly described how to move data in the DB. Since the processes that save and get data are JetPack related, I suggest seeking related advice through JetPack’s dedicated support forum where its devs and expert users are in a better position to advise.

Markdown in Classic Editor is a Jetpack thing, yeah, but the Jetpack forum sent me here.

Anyways, I don’t need to do anything other than what I’ve described (although I still don’t know how to accomplish, because manipulating the database is beyond me without a walkthrough; maybe I’ll have to challenge ChatGPT) because once posts written in Markdown Block are changed within the database as described, they’ll just appear to me in Classic Editor just like any post I’ve been writing using Markdown in Classic Editor.

• This reply was modified 1 year, 2 months ago by Anonymous User 17976131.
• This reply was modified 1 year, 2 months ago by Anonymous User 17976131.

You do not need JetPack specific advice to move existing data about in the DB. You do need it in order to have it save new data somewhere different than what it normally does.

As I said, there might be some MySQL query that will do this in one go. That would be a good AI question since I’ve no idea how that might be constructed. If that doesn’t prove fruitful, then PHP could be used to loop through all posts with markdown. With each post’s current data, save it back as you desire. This code will not work correctly, but it illustrates the general idea:

$posts = get_posts();
foreach ( $posts as $post ) {
   $filtered = $post->post_content_filtered;
   if ( ! empty( $filtered )) {
      $post->post_content = $filtered;
      update_post( $post );
   }
}

The principal flaw in this is get_posts() as presented only gets the 10 latest posts. It needs appropriate parameters that gets the posts you want to modify.

Be sure to make a DB backup prior to doing anything that alters data via these suggested methods.

Okay, so, ChatGPT gave me a set of working database queries that successfully does what I want, and then I found an extra thing that needed doing that the Jetpack folks didn’t mention, and got that working, too.

But here’s the final thing I need that we’re having trouble figuring out.

In posts written using Markdown Block, the Markdown itself can look something like this:

All of this is raised near the end of the book, and what struck me here in particular was the juxtaposition of two statements made in proximity to each other.\n\nOn science:\n\n\u003e I carry the coat of science I wear lightly, with an inner lining of humility, as I can see that there is a limit to what even the greatest scientific minds of human history will ever know or understand.

New lines and things like the > to start a blockquote are encoded and everything is smushed together in one long string.

What I can’t figure out: how to unpack all of that so that my post_content_filtered contains a human-readable post in Markdown rather than one giant string with certain characters encoded this way?

Okay, so ChatGPT and I solved this today. If anyone’s ever interested, it involved first running this PHP script to decode the Unicode in Markdown Block posts so the Markdown was human-readable like Markdown in the Classic Editor posts, and then running these database queries to add some post_meta I didn’t know about until today and then put Markdown in post_content_filtered and HTML in post_content. As near as I can tell, nothing has gone wrong.