Plugin Directory



See the official homepage for the latest changes and news.

If I could figure out how to use SVN again (I'm a darcs fan) I'll update the trunk here. Sigh...


Run PHP code from your WordPress posts. Drop PHP code into your posts, even mixed with regular HTML, and have it eval()'d at run-time.

Works for WordPress 2.0 and supports Role- and User- based permissions.

Output is buffered to catch echo() statements. You can include() or require() other files and they are processed as expected.

New Features

  • Permission to use runPHP is controlled by Roles and Capabilities
  • Configure those permissions in the new runPHP Options page
  • Also works in your feeds (RSS, RSS2, Atom, & RDF)
  • Better integration with WordPress 2.0 administrative UI
  • Internationalization support ready (no translations other than English exist, yet)
  • Refactored code - friendlier function names, encapsulated in a class

Installation Instructions

  • Download the latest version
  • Unzip the contents (the entire runPHP directory) into /wp-content/plugins/
  • In Options > Writing
    • Turn off "WordPress should correct invalidly nested XHTML automatically"
    • Do not use this with the new visual rich editor
  • Visit the Options > runPHP page once to set which Roles can use this plugin (default is no one)
  • Create a post and select the "run PHP code?" checkbox to enable PHP code to be dropped in to your post
  • I10n support is available only if WP_LANG is defined in your wp-config.php file (An English translation is the only one included right now. You can use POEdit to make your own, though.)

Future Changes

Your feedback will help direct where I spend my time

  • Support for WordPress 2.0 user roles Done!
  • Hiding of PHP code when a post is edited by someone who does not have permission to use the runPHP plugin
  • Better integration / work-around with the new visual rich editor (tinyMCE)
  • Don't rely on phpMarkdown, if I am

Caveats and Gotchas

  • Code executed by runPHP is not in the global scope. It is executed as if it were inside a function block and so you'll need to declare your globals accordingly.
  • I have tested this with PHP Markdown enabled and am probably relying on some of its textflow in parsing a post's content.
  • Yes, I changed the permalink for this plugin. Sorry. But since my host had a hardware failure on the database server, the original article was blown away.

Understanding User Roles

By default, no one has the can_runPHP capability. An Administrator grants the capability to Roles via the Options > runPHP page.

Users with {{Manage Options}} or can_runPHP capabilities can also set whether they want to use runPHP in their profile's personal options section.

A user's personal options will override their Role's options.

In practice, this means that Administrators (the only group with default permission to Manage Options) can set the runPHP ability for Roles and for individual users. Non-administrators granted runPHP privileges may individually select to opt out of using runPHP, but cannot opt back in (unless they also have the Manage Options capability).

I highly recommend getting the Role Manager plug-in for an addition way to manage your Roles' permissions.

Similar plug-ins

  • EzStatic3 allows you to embed other HTML or PHP pages into your WordPress posts - this a little different than what runPHP does
  • PhpExec does pretty much the same thing runPHP is doing, and some people report better luck getting it to work for them.

Development Notes

Update 2006-01-11 Updated to version 2.1

Update 2005-03-18

Finally saw why I couldn't log in here and fixed it. (:

I changed the plugin to use PHP_SELF instead of SCRIPT_NAME. Servers which run PHP as a CGI will often return 'php.cgi' as the SCRIPT_NAME instead of the actual filename the plugin expects.

It took me forever to track down this problem because I forgot I had compiled my own version of PHP for my DreamHost server.

Older Updates

It does a little bit of extra work for WP 1.2.2 to make sure your extra slashes aren't stripped when they shouldn't be. The <code>format_to_edit()</code> function in WP 1.2.2 calls <code>strip_slashes()</code> even though the original slashes within the post were never protected.

WP 1.3 *doesn't* do this, so I've added a simple check (<code>isset($wpdb)</code>) to see if we're in version 1.3 and - if we are not - to add the filter.

There is also a little bit of UI provided by the plugin. In the Advanced Editing mode for posts a checkbox labeled 'eval() Content' appears. Only those posts with that checked will be eval()'d. This saves a little bit of parse time for sites with a lot of posts.

Last modified 12 years ago Last modified on 01/14/06 08:09:37