When I go to WordCamps, I get this question a lot: “Why do you have the PHP Code Widget still in the directory?”
There’s a good answer for that, but first let me explain why I made the thing in the first place.
If you examine the history of that plugin, you’ll find that it was submitted almost 10 years ago. Back then, widgets were new. Most people using WordPress had hardcoded sidebars in their themes. Changing the sidebar meant changing the theme. Widgets aimed to replace that with draggable objects. The Widget plugin was still a plugin, and not in core, but headed there.
The PHP Code Widget was created to make it easy and simple and fast to migrate from a hardcoded sidebar to a widget based one. You could take your existing code in the sidebar file, paste it into the widget, and then you had a movable widget that you could easily use.
Obviously, this was not meant for long term usage. The goal was to get widget support rapidly in your theme, with the expectation that as new widgets came out, you could replace your old code with newer, shinier, well supported, widgets.
The reason the plugin is still in the directory is because it still fills a need for some people. If I removed it, then they would fulfill that need in worse ways. It does not take much searching to find snippets of code, with bad advice saying to just pop it into your theme’s functions.php file, and voila, now all your Text Widgets run PHP code. That snippet actually exists. It’s a terrible idea, for obvious reasons.
The PHP Code Widget is less terrible than the alternatives.
But it’s still terrible.
And yes, it bothers me that it is one of the top 150 plugins. Storing PHP code in your database and then running it is just dumb. Don’t do that. Code should live in the right place, and that place is not the database.
So, in an effort to reduce the usage of the PHP Code Widget, here’s one way to stop using it, if you still are.
Getting rid of the PHP Code Widget
Step 1:
Get the PHP Code that you are using from the Widget, copy it into a text editor, save it somewhere for safe keeping.
Step 2:
You’re going to make a new plugin. You can call it whatever you like, but I recommend naming it specific to the site you’re making it for. If I was making a plugin for this site to hold widgets, then I’d call it “Ottopress Widgets” or something to that effect.
How to make a new plugin:
(Note: You can use Pluginception for this instead, if you like. That one I’m not ashamed of, it’s a very handy tool.)
a. Make a directory in /wp-content/plugins named after your plugin, like /wp-content/plugins/ottopress-widgets
b. Make a PHP file in there named the same. Like ottopress-widgets.php.
c. Edit that file, and add this header to the top of it:
<?php
/* Plugin Name: Ottopress Widgets*/
Lovely. We’ve made a new plugin. It doesn’t do anything, yet, but here’s some more code to add to the plugin. This is largely copy-paste, and then you edit it to fit your specific circumstances
Step 3:
add_action( 'widgets_init', 'ottopress_widget_register' );
function ottopress_widget_register() {
register_widget( 'Ottopress_Widget' );
}
class Ottopress_Widget extends WP_Widget {
function __construct() {
$class = 'widget_ottopress';
$name = 'Ottopress Widget';
$widget_ops = array('classname' => $class, 'description' => $name);
$control_ops = array('width' => 400, 'height' => 350);
parent::__construct('', $name, $widget_ops, $control_ops);
}
function widget( $args, $instance ) {
extract($args);
echo $before_widget;
echo '<h2 class="widget-title">Ottopress Widget</h2>';
echo "<div>Here's my custom stuff.</div>";
echo $after_widget;
}
}
I named this widget “Ottopress Widget” by way of example. In the first few lines of code, you’ll want to change these to your own naming scheme. It’s important that names be unique, which is why I recommend naming things using your site’s name. Unlikely for there to be interference that way.
The $class and $name variables you should also change. The class is used in the HTML that the widget produces, so you can refer to it via CSS. The name is simply used for display purposes on the widgets editing screens.
Step 4:
Finally, the meat of the code you want to edit is here. I’ll point it out specifically.
function widget( $args, $instance ) {
extract($args);
echo $before_widget;
echo '<h2 class="widget-title">Ottopress Widget</h2>';
echo "<div>Here's my custom stuff.</div>";
echo $after_widget;
}
This is the code that shows the widget on your site itself. Now, this one is just hardcoded to show the normal before and after code (these are set by the theme, so these should always be there), and then it has a little hardcoded bit there where it echo’s out a title and a div that says “Here’s my Custom Stuff”.
If you’re migrating from the PHP code widget, well, here’s where you migrate it to. You can drop your code from the PHP Code widget here and, you know, do whatever you were doing in the widget before, just now in an actual custom widget, in your own custom plugin. No more storing the code in the database. Just activate the plugin and replace the PHP Code widget with this one.
If you need more widgets because you were using it in multiple places, then simply repeat the process. Paste that whole class in there, only give it a different class name and other info, then put in your other code. You can have as many widgets as you like, they just have to all be named differently. Simple.
Note that this widget has no settings screen of any kind. Why would it? You’re controlling the code directly, no need for settings, presumably. If you want to go on and make your widget smarter and more complex and have settings, well, there’s other tutorials for that.
If this reduces the usage of the PHP Code Widget, well, I’ll be a happier person.
