Readme.txt changelog parsing issue after replacing Markdown with Parsedown

[dangoodman]

After updating to the latest version in master, I have noticed a plugin changelog is shown incorrectly in the WordPress dashboard.

A regression introduced in this commit: 659be8d

Input:

<...>
== Changelog ==

= 1.1.0 =
* Fix B.

= 1.0.0 =
* Fix A.

Output before:

<h4>1.1.0</h4>
<ul>
    <li>Fix B.</li>
</ul>

<h4>1.0.0</h4>
<ul>
    <li>Fix A.</li>
</ul>

Output after:

<h4>1.1.0</h4>
<ul>
    <li>
        <p>Fix B.</p>
        <h4>1.0.0</h4>
    </li>
    <li>
        <p>Fix A.</p>
    </li>
</ul>

I have found that a "native" wp.org readme parser is available. Wondering if it would be the best option to stick with to keep the compatibility?

[YahnisElsts]

Thank you for the report, I hadn't noticed this regression. It should probably be fixed now.

Switching to another parser is an option, but it could be a time-consuming task. I would prefer to stick to the current implementation unless it turns out to have some hard-to-fix issues.

[dangoodman]

Thank you for the quick update. Works for me.

I'm thinking about adding tests to prevent regressions and change minor things to make sure the response is the same to wp.org API. For now, it looks for me like the ideal way is to keep it exactly the same, byte-to-byte. I understand that a few more or less spaces in the HTML parts, for example, won't hurt anyone. But is this assumption correct in general? For example, won't it break something in the plugin-update-checker counterpart? Do you see any consequences or obstacles going this way?

[YahnisElsts]

In general, this server should produce the same results as wp.org when parsing plugin readmes. Or at least a subset of those results, as this implementation doesn't handle screenshots and possibly a few other things.

However, the update API responses are intentionally different from the wp.org API. Here's why:

• Personally, I found some some of wp.org API design choices unintuitive or inconsistent. For example, some parts of the API call the download URL package and others call it download_link, the plugin update and plugin info APIs return slightly incompatible responses even though the first is really just a subset of the second one's fields, etc.
• I don't want to get stuck trying to emulate a mostly-undocumented API in multiple places. plugin-update-checker has to do it to interoperate with WP core, but the update server is not bound by that constraint.

[dangoodman]

Ok, got it.