< within <?php is not escaped for codefilter_prism

Let’s revisit this after #2578695: Use CKEditor on *.drupal.org sites

Drupal.org currently processes autop before codefilter, that is likely to flip around with #2136887: Process code filter before line breaking. Both orderings look like they behave the same way.

<p> tags within <code>, inline or multiline, remain intact.

The problem is:

<?php
return '<p>' . $result . '</p>';
?>

For example:

return '<p>' . $result . '</p>';

This appears to be a bug with Prism. I have fiddled around quite a bit but it seems like prism just doesn't know how to parse these kinds of strings.

There's a bit of noise about this upstream:

https://github.com/PrismJS/prism/issues/887
http://prismjs.com/plugins/unescaped-markup/

It looks like codefilter does the escaping for <code> tags before they get to Prism. I think <?php should behave the same way.

And this effects all tags as far as I can tell, so all < and probably &/etc. should be escaped.

I'm seeing this too: Check out the almost useless change record because the inner HTML being stripped.
https://www.drupal.org/node/2392803

Looking at the HTML output it doesn't look to be an issue with PrismJS in the change record in #9. The markup is filtered before it hits the JS plugin.

This is still a problem for drupal.org.

I just encountered one of my (still open) core Drupal bug reports from two years ago, where the significant parts of my post were lost because of this change in filter. This is the same as what happened to the change notice that @joelpittet mentioned in #9 (which is still as broken as it was last year when he mentioned it).

So we're losing good content here, and it's been that way for more than a year. It's not so much an issue for new content, assuming the poster uses the preview and proofreads the post... But there's a lot of old content out there, documentation pages, issues, etc. which were retroactively broken by this.

EDIT: After reading #11, I realize it IS also a problem for new content - we now have over a year's worth of new content where the content was potentially escaped manually within a <?php block - this new content will now be broken if this issue is fixed. Personally, I plan to use a <code> block instead of escaping stuff within <?php.

@Cameron Tod: You assigned this to yourself - are you working on it still?

I'm not actively working on it. Patches are welcome. I can add it to my queue of things to do but its sadly pretty long right now :/

The code doesn't need to be decoded in prism, which further filters are stripping the p tags and potentially other tags.

Added to and fixed the tests.

Here's an demo of this patch implemented:
https://codefilter-drupal.dev.devdrupal.org/node/2911176#comment-12270626

Looks good to me, same solution as #2694791: <code><em>HTML in code</em></code> is not properly escaped with Prism

Deployed to Drupal.org:

return '<p>' . $result . '</p>';

I haven’t cleared the field cache since I expect another deployment will get it in the next day or two, so existing content won’t be updated immediately.

Any chance of a search and replace on this?

Not likely, figuring out what was intended to be encoded or not is beyond what a straightforward search and replace can do.

Note, the patch in #18 was deployed on Drupal.org two months ago, and has fixed the issue there.

It should be committed to this project so other users of this module get the same benefit!

I've committed and pushed it to the -dev branch.