If you inherit a WordPress codebase, regardless of the age of the project, there may be a lot of context that you don’t have as to why certain decisions were made or how things were implemented.
This may include the server, infrastructure used to help power the site or the app, and other contextual information about the environment in which it was running.
This type of information can be server-related information, PHP version, database type, information that’s actually stored in the database especially if you do a database import, and so on.
Ideally, all of this is handed over but that’s not always the case. Anyway, say you attempt to start it up and then when you attempt to start up the application, not only does it not work but it either shows a white screen or displays a message about technical problems with your installation.
There are a lot of nice packages that we can use in our PHP-based projects and if you’re using Composer or GrumPHP, PHPCompatibility is one that I recommend including your projects especially if you’re writing code for something that’s going to run across multiple versions of PHP (that is, on hosts that offer different versions).
This is a set of sniffs for PHP CodeSniffer that checks for PHP cross-version compatibility. It will allow you to analyse your code for compatibility with higher and lower versions of PHP.
When retiring the memberships, I wanted to make sure I was able to maintain the integrity of all of the posts that I’d published simply without the shortcode that comes with RCP.
What started off as a simple plugin to remove the RCP shortcode turned into a plugin to remove all empty shortcodes. I’m opting to open the plugin’s repository so anyone can access it (or contribute issues, code, or create their own fork from it).
At the time of this writing, the plugin is at0.4.0 so there’s not much to expect. But I enjoy reading the what and why other developers do in their projects, so I’m going to do so with Remove Empty Shortcodes.
Anyway, all of the above is still about filtering variables. What about inputs, though? That is, those that come from $_POST or $_GET. It’s possible to use a similar strategy with a different function and different filter set.
But if you understand the basics presented in the last post, then this post will not be very different.
I’ve talked about data sanitization in WordPress in previous posts. This is a topic that’s important not only for those of us working to build solutions for others in WordPress, but also for those who are writing code that will directly interact with a database via PHP.
Sure, there are native WordPress functions to make this process easier, but there are also built-in PHP filtering functions to help with this. Namely filter_var and filter_input and these are things that I think are helpful for PHP developers to know.