March16
If you are like me and occasionally add PHP to blog posts in WordPress I used to use a plugin called Exec-PHP (http://wordpress.org/extend/plugins/exec-php). It was great because I could add PHP right into my posts, adding dynamic user interfaces, HTML forms, etc.
The biggest use I have for it is being able to output things into posts that would normally be filtered, such as IFRAMEs, by using the php function, html_entity_decode:
<?php
echo html_entity_decode("<iframe src='www.google.com'></iframe<");
?>
However, a near fatal flaw with that plugin, is that if you switched to the Visual tab in WordPress, the PHP code vanished! The plugin states that fact at the top of all blog posts as a warning:
Exec-PHP WYSIWYG Conversion Warning. Saving this article will render all contained PHP code permanently unuseful. Even if you are saving this article through the Code editor. You can turn off this warning in your user profile. Ignore this warning in case this article does not contain PHP code.
Read the Exec-PHP documentation if you are unsure what to do next.
This has frustrated me several times, because if I had the Visual tab open on a previous post, and went to one with PHP… gone! Then while setting up a new WordPress site, I was adding plugins and did a search for “php exec”. This came up with a few plugins, one of which was called Inline-PHP (http://wordpress.org/extend/plugins/inline-php/). Just curious, I installed it and could not have been happier! I can put all of my php code in [ exec ] tags which does not get filtered if I go to the visual tab, and as an added bonus, even displays in the Visual tab.
I highly recommend Inline-PHP plugin for any WordPress blogger who integrates PHP code right into their blog posts: http://wordpress.org/extend/plugins/inline-php/.
When I was working with a site hosted with WordPress-MU, using the html_entities_decode method was almost absolutely required, as it seems that WordPress-MU filters a little heavier than the standard version.