Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Feature: Add Classic Editor & Standard HTML Support for Post Import/Export (PushMd)

Open
#91 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
php, wordpress
Domain
backend, content

Research direction

Start with Push_MD_Plugin and trace the import/export paths through Push_MD_Markdown_Consumer and Push_MD_Markdown_Producer. Review the named WordPress editor-detection APIs and Push_MD_HTML_Converter requirements. Done means block-editor posts retain Gutenberg behavior while Classic Editor and standard HTML posts convert cleanly in both directions, including metadata and formatting.

Written by the indexing model from the issue text.

Description

Overview

Currently, Push MD assumes all WordPress posts use the Gutenberg Block Editor and wraps content in block comments (e.g., <!-- wp:paragraph -->). On sites or post types where the Classic Editor is active (or where Gutenberg is disabled), importing Markdown yields block-comment markup in plain HTML editors, while exporting classic HTML posts is broken and even simple headings and lists do not convert to clean Markdown.

I understand Gutenberg is much cleaner to implement and HTML can be messy. But a lot of people still use Classic Editor or hand coded HTML.

We should support Classic Editor and non-block post types natively during both import (Markdown → HTML) and export (HTML → Markdown).

Note: I've already implemented this and will be sending a PR soon. Creating this issue for reference.


Technical Plan

1. Editor Detection Strategy
  • Introduce a helper method is_block_editor_enabled( $post_type ) in Push_MD_Plugin:
    • Check WordPress core's use_block_editor_for_post_type( $post_type ) when available.
    • Fall back to checking if register_block_type exists.
    • Provide a filter push_md_use_block_editor allowing developers to override the decision per post type.
2. Markdown Consumer Wrapper (Push_MD_Markdown_Consumer)
  • Wrap WordPress\Markdown\MarkdownConsumer to handle classic editor post targets (because we may not want to modify the vendor components):
    • When block editor is enabled for the target post type: delegate directly to MarkdownConsumer to return Gutenberg block markup.
    • When block editor is disabled for the target post type:
      • Consume Markdown via MarkdownConsumer.
      • Strip Gutenberg block comment wrappers (e.g., <!-- wp:... --> and <!-- /wp:... -->).
      • Remove block-specific CSS classes (wp-block-*).
      • Normalize excess blank lines to output clean standard HTML suitable for the Classic Editor.
3. Markdown Producer Wrapper (Push_MD_Markdown_Producer)
  • Wrap WordPress\Markdown\MarkdownProducer to handle posts without block markup (because we may not want to modify the vendor components):
    • Detect whether content contains Gutenberg blocks (has_blocks( $content ) or fallback delimiter check <!-- wp:).
    • Gutenberg content: Delegate to MarkdownProducer and normalize the output Markdown.
    • Classic/Standard HTML content: Extract post metadata into YAML frontmatter and convert standard HTML into clean Markdown.
4. HTML to Markdown Converter (Push_MD_HTML_Converter)
  • Provide bidirectional conversion and normalization utilities for HTML/Markdown:
    • Convert standard HTML tags (headings, paragraphs, lists, links, blockquotes, inline formatting) into idiomatic Markdown.
    • Handle list items, line breaks, and paragraph spacing cleanly without redundant blank lines.
    • Provide normalization routines for produced Markdown output - for common quirks like extra spaces, non-breaking spaces etc.
Dominant language
PHP
Stars
22
Forks
5
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Automattic/php-toolkit

All issues in Automattic/php-toolkit

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.