One of the things which characterizes WordPress is its broad use of PHP and “PHP-like” variables throughout its template files. These variables have remained unchanged for the better part of a decade since WordPress was developed, and so too has their placement. Since the very first WordPress release, PHP code could only be used in a raw template file which was stored on the server. This was (and is) largely done to protect a website’s security, as it was theorized that allowing PHP code in the body of entries, within a sidebar widget, or even in the body of a dynamic page that was maintained in the WordPress Dashboard, could lead to malicious PHP scripts and variables which would allow for information and identity theft. That is basically still an ongoing problem with including PHP code into things like entries and pages, so users should be aware of that fact before they proceed.
Even with all of the security risks that come along with enabling PHP to be activated within entries and pages, the simple fact of the matter is that these codes and variables are most often used by website administrators to simply perform advanced tasks and display WordPress content in areas where it might be a bit more helpful, albeit a bit less conventional. When entrusted to a website administrator who knows the best practices for site security and information integrity, enabling dynamic PHP code parsing in all aspects of a WordPress site enables truly dynamic and advanced designs and functions that can really give a website the competitive edge over those sites which publish similar content and cater to a similar audience. Here’s how to enable the parsing of PHP code in dynamic website elements using WordPress and a simple plugin.
Step 1: Enabling Dynamic PHP Parsing the Right Way
It’s important to understand that PHP code parsing must be enabled by the installation of a third-party plugin. This type of advanced feature cannot be done by simply editing the “
functions.php” file for a number of reasons. The most important of these reasons is that this file gets overwritten every time a WordPress update is released and installed to the server. That means the ability to parse this PHP would be removed after every update until a user elects to re-edit the “
functions.php” file to enable its parsing once again.
For minor functions, this is not a big deal. For PHP functions, this is a security risk. If it is not able to be parsed on a page, post, or sidebar widget, PHP will be displayed in all of its raw, code-y glory to readers. They’ll be able to use that code to their advantage, compromising a website’s security in the process. When a plugin is used, this ability disappears and the PHP is parsed regardless of whether or not a WordPress update was recently installed.
Furthermore, parsing PHP code “on the fly” in dynamic website elements isn’t something which is either encouraged nor supported by the WordPress development arm, and for this reason any plugins which serve to enable this functionality will be found outside of the typical WordPress Extend gallery of plugins. Rather than go to these websites, the relevant plugin can be found on a developer’s nonaffiliated plugin page. It will work just as well, and perform the same functions, but merely lacks the endorsement of the Automattic team.
Step 2: Getting the Right Plugin and Installing it to the Server
Now that it’s been established that the PHP parsing functionality must be completed by a plugin rather than a “
functions.php” file hack to the WordPress installation itself, and that the plugin must be collected from a site other than the WordPress Extend community, it’s time to make sure that each user gets the right plugin. The plugin can be found here: PHP Exec.
The plugin is provided for download at the site mentioned above in the form of a text file, mostly because web servers don’t typically allow readers to download a PHP file directly. This file must be renamed to a .php file. Typically, the file downloads as “
phpexec.txt.” Changing the file extension to “
php” will solve the problem and the file will be ready to go and act as a typical WordPress Plugin.
phpexec.txt” as been renamed to “
phpexec.php,” it’s time to open up your FTP client and commit the file to the server. Using this FTP client, browse to the following server path where plugins are stored (although any developer installing a plugin this advanced should not need this added direction):
phpexec.php” file can be installed directly into the “plugins” folder and does not require its own containing folder for operation. No other files are required or created for this plugin to work at its highest level. Once it has been uploaded to the plugins folder, the FTP client can be closed. Everything beyond this step will be completed using just the WordPress Dashboard and other tools available via a standard web browser.
Step 3: Activation and General Use of the WP Exec Plugin File
As with any other plugin manually uploaded to the WordPress installation, the “
phpexec.php” plugin functions must be activated manually through the Dashboard. Simply log into the WordPress Dashboard and then browse to “Plugins” in the Dashboard sidebar. There, a complete listing of all uploaded plugins will be listed, with the activated ones listed first. Scroll all the way down to the bottom of the page and search for the uploaded plugin. Click the “Activate” link and wait for the process to complete.
When the plugin has been successfully activated, most of the work is completely finished. The activated plugin requires no added settings or customization on behalf of the user, as it only enables the parsing of PHP. Basically, PHP parsing is either on (with the plugin activated) or off (with the plugin deactivated) and that’s the extent to which users can customize its functions. So, with the plugin activated, what do users do to take advantage of this new PHP parsing ability? And where do they do it?
Step 4: Executing PHP Wherever, Whenever, and However (As Long as it Doesn’t Cause Errors)
Without this plugin installed, WordPress parses PHP code only where it is considered to be “static.” That includes parsing any PHP included with the site’s template files (indeed, all WordPress variables are PHP code), and throughout files like “
functions.php” and other core files within the WordPress installation folders like “
wp-includes.” After the plugin has been activated, all of those locations can still parse PHP code but are now joined by so-called “dynamic outlets.” That includes the WordPress sidebar via the use of customized widgets, the page body content box located on each page’s “edit” panel, and within the body text of every entry posted to the site. Luckily, this PHP parsing ability does not apply to the comment submission form that is appended to most entries published through WordPress, avoiding a major security hole.
The primary motivation for adding the ability to parse PHP code to dynamic outlets like the entry content box is to enable the pulling of WordPress information from the database via standard variables rather than otherwise messy methods. Adding PHP parsing to these fields means that virtually any variable can be executed on the site, including anything that would normally be placed within the WordPress Loop. Remember, all entry content is published within the Loop by default, so a PHP variable placed within an entry body would be treated as just another Loop-dependent variable.
The great thing about publishing PHP code and parsing it in the site’s sidebar widgets is that this can enable all kinds of new content to be treated like a widget, even if the plugin does not support this functionality. It’s important to keep in mind that WordPress plugins did not always ship as “widgets” and they used to require a custom WordPress variable to be placed within the sidebar in order for their content to be displayed.
With the PHP Exec plugin installed with a WordPress installation, site administrators can now create custom widget boxes right alongside those which are produced by their installed plugins. The content in those boxes can be the same custom variables that are supported by plugins which do not yet place their content into widgets. This allows the content to be dragged and dropped freely, just like any other widget, and spares web designers the somewhat awkward challenge of placing static content in the sidebar “on top” of the area where widgets will be placed.
In a sense, enabling the parsing of PHP code throughout the dynamic outlets of a WordPress installation allows advanced WordPress developers and designers to take the site’s functions out of the temples and treat them as dynamic content, bridging the gap between the variable and the reader. That’s an important function, especially as WordPress continues to engage in the transition from a “static” content management system to a more user-friendly, drag-and-drop, dynamic portal for information management.
Step 5: Bug Test, Be Safe and Secure, and Enjoy
After the plugin has been installed and the first bits of PHP code have been placed into dynamic elements like the entry content box or a sidebar widget, it’s time to navigate to the website’s homepage and test the plugin’s output. Be on the lookout for any PHP errors (although these are often user-initiated within the parsed code), and make sure that everything is functioning normally. If the installation has been a success, there will be no discernible difference from the PHP code parsed in a dynamic element and the code which is parsed as part of a WordPress template or “
functions.php” file. If this is case, relax and enjoy the fruits of this hard-fought labor!
- How to Display Content Based on WordPress User Roles
- The WordPress header.php Template File: Do’s and Don’ts of Good Header Design
- Unraveling the Secrets of WordPress’ comments.php
- An Early Look at Full Site Editing in WordPress
- The Challenge of Switching from a Page Builder to the WordPress Gutenberg Block Editor
- When Do You Need a Custom WordPress Gutenberg Block?
- How to Update WordPress Themes and Plugins with a ZIP File
- Signs Your WordPress Website Has Outgrown Its Hosting