Often times in programming, developers find themselves applying practices without knowing their true origin or even why they’re used. The key to becoming a better programmer is to remain vigilant and curious. Make it a habit to not just adopt these practices for their popularity, but to understand them fundamentally for what they are and how they came to be. This blog aims to highlight a few of WordPress’ best practices and analyze them in more detail with the objective that it might benefit everyone. In the wise words of Benjamin Franklin “it is easier to prevent bad habits than to break them.”
Creating a Unique Database Prefix Prevents Hacking
The WordPress database and its tables are the most closely guarded assets of any WordPress website. You are asked to provide a prefix to your database’s tables when you first install WordPress. The database contains the posts, pages, comments, categories, tags, custom fields, users, and site options that make your WordPress site unique. If you are familiar with relational databases such as MySQL and MariaDB, then you are likely familiar with the concept of a command injection. For those unfamiliar, a command injection – the most popular being the SQL injection – is an attack in which the goal is execution of arbitrary commands on a vulnerable application. Creating unique database prefixes makes it harder for outsiders to execute command injections against your WordPress application. Try changing the default prefix from wp_ to something harder to guess, but having semantic value.
Using a Network-path Reference to Eliminate the Need to Switch Network Protocol in Different Environments
Mixed-mode content is the result of using SSL encrypted connections to visit a secure web page that contains content retrieved using a regular HTTP connection. By default, mixed content is blocked in most modern web browsers (or at least generates a security warning), but there are some exceptions. Here’s an example of how to use protocol relative URLs to enqueue jQuery to a theme in WordPress:
wp_enqueue_script( ‘jquery-min’, ‘//code.jquery.com/jquery-3.1.0.min.js’ array( 'jquery' ), null, ‘all’ );
jQuery actually comes with WordPress, so this application in a practical setting would be redundant.
Fixing mixed-mode content is a tedious process, but using protocol relative URLs can help you avoid that headache. If a web page is being viewed through the HTTPS protocol, then it’ll request that asset with the HTTPS protocol, otherwise it will usually request it with HTTP. This prevents that irritating “This Page Contains Both Secure and Non-Secure Items” error message (e.g. in IE), keeping all your asset requests within the same protocol. If you’re really interested, you can find the technical description in the Internet Engineering Task Force’s RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax.
Faster Page Viewing Experience with Apache Configuration File
If you choose to use Pretty Permalinks for your WordPress install, at some point you will have to create an .htaccess file, a server configuration file where you control how your visitors interact with your website. The WordPress documentation will ask you to add, at the minimal:
RewriteRule ^index\.php$ -
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php
However, since Apache 2.2.16, those rewrites mentioned above can be replaced with one single directive, ‘FallbackResource’, with mod_dir enabled, in the main Apache configuration file. This provides the same effectiveness but with less time, and elimination of typos:
FallbackResource /index.php
The WordPress Codex does not explain that these directives do not have to exist in the .htaccess file to work. An easy way to slightly improve the performance of your WordPress website is to move those 4 lines out of your .htaccess file and instead into your Apache configuration file. This ensures that they will not be executed redundantly with every page request hence improving the performance of your WordPress website.