• Resolved dmrzzz

    (@dmrzzz)


    I’ve noticed an interesting discrepancy between Prismatic vs vanilla WordPress behavior: if I add a new page, Option (kebab menu) > Code editor and paste the following raw HTML:

    I use?<code><a >perl -ne</a></code> one-liners every day.

    and view the page with Prismatic deactivated, it renders as a hyperlink with monospaced link text, like this:

    I use?perl -ne one-liners every day.

    However, when I activate Prismatic (even with Settings > Prismatic > General : Library = None) and view the same page again, it instead renders the HTML markup for the hyperlink, like this:

    I use?<a >perl -ne</a> one-liners every day.

    (which is not what I want — if I did want that, I would paste my markup into the Visual editor, which would take care of HTML-escaping it with e.g. &lt; behind the scenes so it’s syntactically just text content for the code element)

    The test case above implicitly involves a Classic block, and one might argue that when dealing with Classic blocks it’s my responsibility to invert those tags (placing code inside of a instead of outside) and then everything would be fine. However, it’s also pretty easy to fall into this same trap writing new content using the WP block editor: if I type

    I use perl -ne one-liners every day.

    into a paragraph block, then put backticks around the perl -ne bit to make it inline code, then select just that bit with my mouse and click the Link button (and supply a URL) to make it a hyperlink, I end up with the same constellation of underlying tags — a inside of code — which looks fine in the block editor but not when viewing the page with Prismatic activated. The raw HTML in this case ends up as:

    <!-- wp:paragraph -->
    <p>I use <code><a  data-type="link" data-id="https://perldoc.perl.org/perlrun">perl -ne</a></code> one-liners every day.</p>
    <!-- /wp:paragraph -->

    As a sort of cherry on top, I note that the WP block editor is also perfectly happy to let me select and hyperlink only part of the contents of the code tag (e.g. just the rl) in which case there’s no question of being able to solve it by inverting the tags.

    Thanks in advance for considering what I suspect may be a rather thorny issue…

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Jeff Starr

    (@specialk)

    Thanks again for the detailed report. I will take a closer look and try to resolve any issue for the next plugin update.

    Plugin Author Jeff Starr

    (@specialk)

    Hey I am looking into this now, trying to follow along, but getting stuck on this part:

    “add a new page, Option (kebab menu) > Code editor”

    When I go to create a new page, there is no “Option” or “kebab menu” displayed or available anywhere. I am using latest WordPress and have tried using both Classic and Block editors.

    Plugin Author Jeff Starr

    (@specialk)

    Thanks for explaining (in your other support request). So the issue happens with block editor context. I am familiar with the Options menu, just never heard it referred to as the “kebab menu” before. I will take another look and try to repeat this error on default WordPress.

    Plugin Author Jeff Starr

    (@specialk)

    So I was able to repeat the issue and I think it happens because the plugin or WP block (not sure which) escapes angle brackets when included inside of code tags.

    Best practice is to use code tags only on content that should be considered code. So when you include a hyperlink inside of code tags, it will be considered and rendered as code. Instead, do the converse and wrap the link around your code tags, for example:

    <a ><code>perl -ne</code></a>

    That is semantically correct and always will display correctly regardless of which plugins or blocks etc. you are using.

    I hope this helps, let me know if I can provide any further information.

    Thread Starter dmrzzz

    (@dmrzzz)

    Hi Jeff, I won’t disagree with you about best practice for hand-crafted HTML, but that doesn’t really solve the practical problem, because WP block editor doesn’t help me (much less force me) to follow this best practice when I’m not hand-crafting.

    Here’s a lengthier but perhaps more compelling version of the user story:

    1. Deactivate Prismatic
    2. add New Page “Test Page”
    3. Type this text into a Paragraph block (with no formatting):
      I use perl -ne one-liners every day.
    4. Click and drag the mouse to select the characters perl -ne
    5. In the floating toolbar, click the More icon (looks like a squashed V) and select “Inline code” from the drop-down menu.
      (note that the selection remains selected)
    6. In the floating toolbar, click the Link icon, paste https://perldoc.perl.org/perlrun into the URL box, and press Enter.
    7. Publish, then View the Page. It looks great, exactly as the author intended.
    8. Activate Prismatic, then View the Page again. It now shows the markup for the hyperlink, not at all what the author intended.

    FWIW, comparing browser’s View Page Source on the rendered page from step 7:

    <p>I use <code><a href="https://perldoc.perl.org/perlrun">perl -ne</a></code> one-liners every day.</p>

    vs step 8:

    <p>I use <code>&lt;a href=&quot;https://perldoc.perl.org/perlrun&quot;&gt;perl -ne&lt;/a&gt;</code> one-liners every day.</p>

    demonstrates that it’s definitely the plugin doing the escaping.

    IMO this frontend escaping is unwanted, because when I do need content escaped, WP already does a good job of helping me escape it on the back end without any help from Prismatic. For example, if I type a<b into a Paragraph block, Publish, and View Page, browser’s View Page Source contains <p>a&lt;b</p>, but this is also the internal representation in the database. This vanilla WP mechanism works equally well both inside and outside code tags, and personally I don’t feel any other mechanism is needed. In the event that I do end up with unescaped HTML inside a code tag, I would prefer that Prismatic (like vanilla WP) assume it’s there on purpose and not rewrite it.

    That said, presumably you feel that the frontend escaping behavior inside code tags by Prismatic is desirable in other use cases, or you wouldn’t have implemented it. Would you consider adding a setting to enable/disable it?

    I notice that the settings pages already contain this help text which implies the existence of such a setting: “By default all code contained in code tags is escaped on the frontend.” (emphasis mine, since default implies a way to override said default)

    Thanks again for your consideration!

    Plugin Author Jeff Starr

    (@specialk)

    Thanks for the detailed description, @dmrzzz. I will investigate this further and determine if there is anything that can/should be done on the plugin side of things for the next update.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘hyperlinks inside code tags’ is closed to new replies.