Hiya. So, I just did a little debugging on my local machine. I hardcoded the:
$canonical_url = 'https://webzy.gr/';
in function fetch_rendered_html and it works perfectly fine.
The plugin is actually pretty simple: it uses wp_safe_remote_get to do a loopback request to the server, pulls the HTML, and then processes the html back into markdown. If you are not getting any markdown, it’s going to be one of these issues:
1 – your server doesn’t support loopback connections. if the webserver webzy.gr can’t call webzy.gr, then it’s just not going to work. 2 – there is some kind of network interference or security layer within your network that is getting in the way of #1. 3 – it might be working, but it’s cached. It uses transients for any non-logged-in-user — so if you are testing in a private window, you may not be seeing the real results. When you are testing, always be logged into wp-admin.
More thinking: while i’m hesitant to enable Accept: text/markdown content negotiation by default, I agree there are valid advanced use cases, so I’m considering exposing it behind a developer filter. That would let site owners explicitly opt in once they’ve confirmed their cache layer respects Vary: Accept. Do you have the ability to add in your own custom hooks?
Thanks for the suggestion. I agree the Accept: text/markdown pattern is becoming more common for AI-oriented content negotiation, and I did spend some time evaluating it.
At the moment, I’m intentionally not implementing that behavior because I think the operational risk outweighs the upside for a WordPress plugin intended to run across a wide variety of hosting and caching environments.
The plugin currently uses explicit .md routes instead, which are much safer and more predictable from a caching and infrastructure perspective.
Serving Markdown conditionally from the same URL based on the Accept header introduces a number of edge cases:
CDN/cache variation requirements (Vary: Accept)
Reverse proxy compatibility
Cache poisoning or stale cache scenarios
Hosts that ignore or mishandle content negotiation
The possibility of Markdown accidentally being cached and served to normal browsers
On highly cached WordPress sites, especially with Cloudflare, Varnish, Nginx microcache, or aggressive edge caching, this could realistically result in broken page output if misconfigured.
Because of that, I’m currently treating .md URLs plus the existing <link rel="alternate" type="text/markdown"> output as the safer and more deterministic implementation.
I may revisit this later as an optional advanced setting, but I don’t currently feel comfortable enabling negotiated Markdown responses by default.
Good catch. Tables are currently flattened during conversion, which is not ideal for comparison or technical content. I agree this should be handled more explicitly. I’m planning to add Markdown table conversion so <table>, <thead>, <tbody>, <tr>, <th>, and <td> structures are preserved as pipe-table Markdown where possible.
