philit

Note 03-01-2012: Tried adding a backslash escape in front of the second < character. I did so because the WP post formatting was probably inadvertently recognising ‘<\/p’ character sequence and processing it. Escaping with a backslash stops this. ‘\<\/p’

if (preg_match('/<p>.*\<\/p>/ums', $filestr, $matches))
to
if (preg_match('/<p>.*\<\/p>/ums', $filestr, $matches))

It seemed to work as you can see from the appearance of the external page at “Plugin – Inline PHP – The Backslash Affair in WordPress”

Please note the automatic XHTML correction feature was turned off to get this example working, this played havoc with the normal WP theme structure.
</p>

Fixed sort of

A plugin called Universal Post Manager (UPM) was the culprit, after de-activating it the backslashes were no stripped from posts.

The second advanced inline PHP example worked but not without some WordPress features appearing:

The line
if (preg_match(‘/<p>.*<\/p>/ums’, $filestr, $matches))
after saving becomes
if (preg_match(‘/<p>.*< \/p>/ums’, $filestr, $matches))

If you look carefully at the second line you will see a space has appeared in the </p> HTML delimiter. This changes the search pattern and effects the text returned from the file. HTML paragraph tags outside preg_match are are not interfered with at all.

The net result is that although you can get the file, read its contents, nothing is written out in because there is no instance of < /p> specified in the WP adulterated regexp string

WordPress post formatting is off the hook for backslashes but not for HTML tag processing just yet.