Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
In WordPress: Creating Custom Widgets and Plugins with PHP, Drew Falkman teaches PHP developers how to create custom functionality for WordPress 2.0 through 3.0 using widgets and plugins. This course starts by installing and setting up WordPress 3.0 on both Mac and Windows, then provides an in-depth look at tasks related to these WordPress add-ons: installing and administering, building and customizing, creating editable options and database tables, working with posts and pages, and utilizing jQuery and AJAX. There are also tutorials dedicated to promoting a widget or plugin, adding security, and localizing the interface. Exercise files are included with the course.
WordPress--like any other web software--is subject to attacks. It's public and available, so it's important to take into consideration and not build plugins that will leave anyone who uses them vulnerable. The good thing about WordPress is that there are a lot of security things that are built into it already, so we don't even have to worry about it. However, there are still a few things that we need to consider. The main vulnerability in any site is basically when we process dynamic data, that is data that can be submitted from the user either via a post or by a get, so in a URL or in a form. Security on the web site is primarily a data sanitation issue.
SQL injection, which is basically appending deleterious SQL code in a variable, can be dangerous, and there is a lot of ways around it. Earlier we looked at the browser detector plugin where we're inserting data in the database, and you remember we use the Insert method of the WTB object. This is the safe insert because it parameterizes the items that come in that are dynamic. In this case, it was entering this USER_AGENT and enforcing as a string. What that will do is make sure that this string will go in as a string and will be entered into the database.
So that way if someone were to append offensive SQL on it, this would actually just put the SQL onto a database instead of running it through the database engine. One way to do it when you are not using insert or update--which are both safe--is to use this special prepare statement. Usually, we are going to use this on Select statements that do things like filtered searches. But in this case, I am just going to show you how to do it instead of this insert statement so you get an idea. Basically, the first step that you need to do is call the prepare method of the wpdb.
This will essentially set up a safe query for you, and what you do is you structure it like this. You put your SQL, so INSERT INTO in this case, and then we will use our table_name, which we have already setup right here. So INSERT INTO table_name, and then we'll say SET user_agent =, and then you start appending on different values. So in this instance, I am putting a percent sign, the number one, and then I am specifying the type of data--in this case a string.
Now if I had other variables, I would just say percent sign two and put the type of data, either a float or a decimal number. But since I am only using one, that's all I need to do in this instance. After that, in the order that they were entered, you then put the values you want to enter into the database. So in this case, I am using _ SERVER, 'HTTP_USER_AGENT'. If I had additional ones, I would add them here separated by a comma, but in this case, I only have one.
So this will essentially create and prepare a script for me. Then in the next line, I can go ahead-- looks like I forgot a concatenation here. Notice how I get this red x that tells me something is wrong. So now I am going to say wpdb, and now I can run the query, and I am just going to pass the SQL that I generated using the prepare statement. So I want to first save that into a variable. So I am going to it $safe_sql, and now I can just pass this directly into my query, and then now I have a safe query.
So this is considered a best practice. In fact, if you ever are doing a select statement that requires you to use dynamic data, you pretty much must use this methodology. Another way that we can practice security is by essentially stripping data that goes through. There is a special kind of attack that's called the cross site request attack, and the way that we can get around these is by cleansing the data as it comes through. If you remember, we created a widget before, called simple widget, that allowed an admin user to enter information, a body, and a title and submit it.
Well, since they are entering data and submitting it, then we probably want to clean it before it goes into the database. We were using the widget API for this, by extending the WP_Widget class, and then implementing the widget method, the form method, and we are using the built-in update method to handle the updates. Well, in this instance, I am going to override the update method, because I want to filter it before it goes into the database. The update method takes two arguments: new instance and old instance.
New instance will have the information that the user entered, and old will have what originally existed. So the first thing I am going to do is I am going to create a variable called instance, and I am just going to set it equal to the old_instance. That way I am secure in that I am not adding anything from what the user entered in yet. Now I can add what the user would have entered bit by bit. So first I am going to enter the title. So instance title equals.
I am going to use the special PHP function called strip_tags which will just remove any HTML tags, and I am going to strip it from $new_instance title. So now I'll have it clean, because there is no reason why the user should put any kind of tags into the title. In the body, however, we do want to allow some HTML. Fortunately, WordPress has the special method called wpkses that will allow you to essentially filter out every tag except for the ones you specify.
Now there is a very specific way that you specify what's allowed. I create a variable that is going to be what's allowed, and I declare it as an array. It's an associative array, so I create a number of different tags so that are available, and if there are any attributes of those tags I want to allow, then I specify those inside of the tag, so this is what it looks like. I am going to allow the a tag, and for each of these items, I want to set an array.
If I didn't want to allow any attributes of the a tag, then I would simply declare an empty array, and that will be good. However, I do want to allow the href tag so that they can make a link and the title tag so that it can be a nice link that shows you the hover. So what I do then is I put my attributes inside of this array. So I say href, and again, it gives you the ability to granularly go in each one. But for each of these I am just going to declare an empty array, because there won't be any child elements of them.
So, href is allowed and title is going to be allowed, and again, just an empty array. And that's it. And then I am going to add the ability so the user can use br tags. But since I am not going to allow any child attributes or elements of that, then I can go ahead and just declare an empty array. Another one will be strong so they can bold things, and again, no child elements or attributes and emphasis, if they want to italicize anything.
So this is essentially specifying what would be allowed. Now, in order to clean it up, I use my instance variable, and I'll set the body equal to, and then I'll call wp_kses. And from the new instance, I'll get the body--so that's the text to be scrubbed-- and then I specify what is allowed.
If you don't want to allow anything, you can just pass an empty value into here. And finally, part of this whole update methodology is I am going to return the new instance with the scrubbed properties. So let's go ahead and log in to our administrator. Let's check the Plugins page and make sure that this widget is activated-- It's the Simple Widget--and we can see it is because it gives us the Deactivate option.
So let's look at the widgets, and let's grab our simple widget, and let's drop it into this sidebar. So notice we have this title, and we have the body. Let's enter something like "Welcome on Thursday," "It's a nice day." Hopefully you are more creative than that. Notice it's saved it fine, and it works fine, and if I go to the front-end of the web site, I'll be able to see this: Welcome on Thursday.
If the user, however, tries to enter some kind of tag in here, and submit it, it removes the tag, right? Because tags aren't allowed, so that strip tags method does that. If in the body they try and enter a tag however, the a tag should be allowed, as well the br tag; however, if they try and do a div, that shouldn't be allowed.
You can also check to make sure certain protocols that are accepted using this kses, http, gopher--things like that. So WordPress has a number of methodologies built-in for cleaning data and trying to ensure that only trusted and allowed information goes into the database, and is use in the WordPress environment.
Find answers to the most frequently asked questions about WordPress: Creating Custom Widgets and Plugins with PHP.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.