未加星标

Creating Custom WordPress Administration Pages, Part 4

字体大小 | |
[开发(php) 所属分类 开发(php) | 发布者 店小二04 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

As we begin the final article in the series on creating custom WordPress administration pages in WordPress, I think it's important to reiterate that this is not meant to say we should be circumventingthe Settings API (or any of the native APIs).

In fact, each API has its place, and we obviously use many of them through this code. But there arelikely to betimes where you're working on a custom plugin or custom application and you need to be able to implement a bit of your own custom validation, serialization, routing, and so on.

And that's what we've been doing throughout this series. So as we move forward in completing our plugin, I want to make sure that you understand I'm not advocating circumventing any of the native APIs. I'm advocating using what APIs are available for the requirements of your project.

For Your Review

At this point, I'm assuming you're caught up with the previous articles. If not, you're likely going to have a hard time understanding where we've come from and why we're making some of the decisions we are making as it relates to code.

Furthermore, you're going to miss out on some of the principles we've previously discussed. In short, I recommend catching up and then returning to this article.

Before We Start

With that said (and speaking of requirements),there are just a few more things we need to wrap up as it relates to this plugin.

Specifically, we need to:

retrieve the information from the database validate the information display it on the dashboard display the information on the front-end

Luckily, the majority of the work has been done for us. We've got all of the information we need in the database. At this point, it's a matter of introducing functionality that will do something with that data.

As usual, I assume that you have the latest version of the source code and you're ready to continue with this series adding to it the remaining bit of code.

With that said, let's get started.

Completing the Plugin

Before we begin writing code, I want to make it clear that the code that we're going to write is straightforward, but there's a level of refactoring we may need to introduce once we get to the point of making the information available on both the back-end and the front-end.

That's a good thing, though.

Not only will it give us a chance to think critically about the organization of our code, but it will also expose us to some additional object-oriented techniques that we haven't seen throughout the tutorial series thus far.

With that in mind, let's work to retrieve the information from the database.

Retrieve Information From the Database

Grabbing the information from the database is a simple process. Since we've previously worked with functions like update_option , this should be very easy.

We're going to be working with get_option . It only requires a single argument, and that is the ID or the key that we used to store the information. In our case, that's tutsplus-custom-data . If you want to get creative, you can pass an optional second argument that will be returned if the information isn't found.

For the sake of showing how this can be used, I'll have the function return an empty string so that we have something valid to display to the user (even if it's nothing). The snippet of code for doing this looks like this:

<php
$data = get_option( 'tutsplus-custom-data', '' );

But this raises two questions:

Where does this go (especially if we're going to render this in two places in the plugin)? Shouldn't we validate this information?

We'll look at the first question a little bit later in the tutorial. First, let's talk about validation.

Validate the Information

There's a lot that can be said about validation in WordPress. But to keep this tutorial as straightforward as possible, we're going to talk about input validation. After all, we're dealing with user input via an input element, so it makes sense.

You can read all about it in the Codex , but input validation is often defined as the following :

Data validation is the process of ensuring that a program operates on clean, correct and useful data.

In the last article, we covered the topic of sanitization, which is basically making sure that data is clean before being inserted into the database. Similarly, validation is ensuring that it's clean, safe, and readable for our users.

To that end, it's not enough just to grab the information from the database. We need to validate it, as well. In the case of our plugin, the data is simple enough that it might seem like overkill to validate it; however, the purpose of the exercise is to help develop the mindset for how we need to go about sanitizing, saving, retrieving, validating, and displaying data.

Validation Techniques

And just as is the case with sanitization, WordPress offers some functions that make validation easy, especially as it relates to input validation. In this situation, we can be as aggressive as we like.

In our case, it might be enough just to use esc_attr when rendering the options. If we've permitted users to input any type of HTML, then we may want to use wp_kses .

The latter function may require a tutorial all on its own, especially if you're new to WordPress, so we're going to stick with the former for our purposes.

Deserialization

Earlier in the project, we created a class specifically for saving information to the database. We called this class Serializer . For those who don't recall exactly what it does:

The class defines a function that fires on the admin_post hook and saves the information that's sent to the server. The function verifies that the information is safe to save and the user has permission to save to the database. The function sanitizes the data and writes it to the database.

But we don't want to overload that class with a responsibility that doesn't make sense. And since we're going to be displaying this information on both the options page and the front-end of the site, it would stand to reason that we have a class for deserializing the value and making it accessible to the entire WordPress application.

So in the rootof your plugin directory, create a shared directory and add a file called class-deserializer.php .


Creating Custom WordPress Administration Pages, Part 4

Next, we want our code to be set up so that it:

is based on object-oriented principles retrieves the information for which it's asked validates the information returns it to the caller

To that end, the initial skeleton of the class may look something like this:

<?php
class Deserializer {
public function get_value( $option_key ) {
}
}

It's simple, to be sure. We'll be adding more code to it throughout this tutorial, but remember the single responsibility principle, and this is a class that must be used between two parts of the WordPress application.

Notice that in the code above, we've defined three functions. Let's discuss what each one will do:

get_value will use the incoming option key which, in our case is tutsplus-custom-data , and will return the v

本文开发(php)相关术语:php代码审计工具 php开发工程师 移动开发者大会 移动互联网开发 web开发工程师 软件开发流程 软件开发工程师

主题: WordHTML
分页:12
转载请注明
本文标题:Creating Custom WordPress Administration Pages, Part 4
本站链接:http://www.codesec.net/view/481414.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 开发(php) | 评论(0) | 阅读(37)