PHP

PHP is a multi-purpose scripting language that is particularly well adapted to web development.

Add a help tab to a WordPress Plugin

This is a help tab that can be found on the WordPress admin dashboard, a custom plugin can have also contextual help that can be found on the rightmost part of the admin screen.

Ever since WordPress Version 3.0, every built-in Administration Panel has contained a contextual help section providing additional information to the user on how to navigate the various settings displayed in that admin panel. This helps WordPress keep the main part of the admin panel clear and concise by eliminating unnecessary text that regular users don’t need to see on a regular basis.

https://codex.wordpress.org/Adding_Contextual_Help_to_Administration_Menus

We should use the Screen class to achieve adding the help tab.

This is a concrete class that is instantiated in the WordPress $screen global. It is primarily used to create and customize WordPress admin screens (as of WordPress 3.3).

https://developer.wordpress.org/reference/classes/wp_screen/

An example function to add a help tab using the WP_Screen class.

function my_add_help_tab() {
	$screen = get_current_screen();
	$screen->add_help_tab(
		array(
			'id' => 'hello_dolly',
			'title' => __( 'Hello Dolly' ),
			'content' => '<p>' . Well, hello, Dolly
It's so nice to have you back where you belong
You're lookin' swell, Dolly . '</p>',
		)
	);
	$screen->set_help_sidebar( __( 'Hello Dolly' ) );
}

There are two methods that are used add_help_tab and the set_help_sidebar. The add_help_tab would add the tab button on the screen and also the left-side title and the content.

The set_help_side_bar would add an additional third column.

Upon activation of an Options page or Menu page, use an action hook and use the callback function.

function my_options_page() {
	$my_menu_page = add_menu_page(
		'Hello_Dolly',
		'Hello Dolly',
		'manage_options',
		'wpl',
		'wpl_options_page_html'  // callback function to display the page
	);
	// Add help bar.
	add_action( 'load-' . $my_menu_page, 'my_add_help_tab' );
}

add_action( 'admin_menu', 'my_options_page' );

That’s all to it.

Add a Section on WordPress Settings Page

The primary location to set up settings for various WordPress website parts is the Settings tab in the WordPress Admin sidebar.

Settings Sub-menu

Listed is the sub-menu for Settings Tab, these are:

  • General
  • Writing
  • Reading
  • Discussion
  • Media
  • Permalinks
  • Privacy

Fields can be added to these pages by creating a simple plugin.


The WordPress functions which would be used are:

register_setting() – this would register our additional options.

add_settings_section() – this would be the section belonging to our custom settings field

add_settings_field() – this would be the custom field

First, we need to use a function that would initialize our plugin.

function wpl_settings_init() {
	// register a new setting for "reading" page.
	register_setting(
		'reading',              // $option_group
		'wpl_setting_example',  // $option_name
		array(
			'array',
			/** 'callback',         // $sanitize_callback. */
		),
	);

	// register a new section in the "reading" page.
	add_settings_section(
		'wpl_settings_section',           // $id
		'WPL Settings Section',           // $title
		'wpl_settings_section_callback',  // $callback
		'reading'                         // $page
	);

	// register a new field in the "wpl_settings_section" section, ins.
	add_settings_field(
		'wpl_settings_option1',           // $id
		'Option 1',                      // $title
		'wpl_settings_option1_callback',  // $callback
		'reading',                       // $page
		'wpl_settings_section',          // $section
	);

	// register a new field in the "wpl_settings_section" section, ins.
	add_settings_field(
		'wpl_settings_option2',           // $id
		'Option 2',                     // $title
		'wpl_settings_option2_callback',  // $callback
		'reading',                      // $page
		'wpl_settings_section',         // $section
	);

}
add_action( 'admin_init', 'wpl_settings_init' );

In my example code, I have added two fields, and here are the callbacks.

function wpl_settings_section_callback() {
	echo '<p>WPL Section Introduction</p>';
}

function wpl_settings_option1_callback() {
	$setting = get_option( 'wpl_setting_example' );
	?>
	<input type="text" name="wpl_setting_example[option1]" value="<?php echo isset( $setting['option1'] ) ? esc_attr( $setting['option1'] ) : ''; ?>">	
	<?php
}

function wpl_settings_option2_callback() {
	$setting = get_option( 'wpl_setting_example' );
	?>
	<input type="text" name="wpl_setting_example[option2]" value="<?php echo isset( $setting['option2'] ) ? esc_attr( $setting['option2'] ) : ''; ?>">	
	<?php
}

Here’s the visual output.

That’s all to it. Happy coding.

Optimize Database Performance – Cleaning WP Options Table

We all know WordPress is an application written in PHP and paired with MySQL or MariaDB database. The PHP language reads or writes to the database. This happens on every WordPress request, for example, like the home page that makes up links, content, theme, or plugin, there is always a call in the database.

One database table, in particular, that is overly used on this request is the WP Options table. The WP Options table stores the site data, when this table gets large this will contribute to sluggish response time. Cleaning the WP Options table can improve page generation speed.

Image from https://codex.wordpress.org/Database_Description

This is the only table on the database that is alone or without any table relationship, assuming it would add load if this is linked to another table, a flat table by design. Here is the table definition:

CREATE TABLE `wp_options` (
  `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `option_name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `option_value` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
  `autoload` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'yes',
  PRIMARY KEY (`option_id`),
  UNIQUE KEY `option_name` (`option_name`),
  KEY `autoload` (`autoload`)
) ENGINE=InnoDB;
FieldTypeNullKeyDefaultExtra
option_idbigint(20) unsignedPrimaryauto_increment
option_namevarchar(191)Unique
option_valuelongtext
autoloadvarchar(20)Indexyes

By design, three out of one are indexed properly for an optimized SELECT query.

Removing Transients

Transients are temporary data of plugins and themes stored on the WP Options table. Usually, this has expiration dates but if the plugin has been deactivated or uninstalled the value on the table would remain in the database forever. Transients can be easily identified since a “transient” word can be found in the field option_name. To remove execute a DELETE SQL statement.

DELETE FROM wp_options WHERE option_name LIKE ('%\_transient\_%');

Removing Sessions

Sessions are temporary data that is generated from every user visit. This will be automatically be deleted after thirty minutes of user inactivity but that is not the case all the time. Manual removal is needed to clean up the session’s data.

DELETE FROM wp_options WHERE option_name like '_wp_session_%';

Block IP Addresses in WordPress

There are several reasons that might need to block an IP address from accessing the site. I’ve categorized the reasons in no particular order:

  • Unnecessary traffic
  • Spam
  • Brute Force Attack
  • DDoS Attack

Unnecessary traffic

Usually, this is traffic generated by bots crawling the site, they might be good or bad bots. A bot is considered good when it would adhere or follow what’s on the robots.txt file, the other one would just ignore the contents. There are also some email harvesters, content scrapers, and web extractors. This adds bandwidth and sometimes hinders the loading of the site.

Spam

Spam is unwanted messages, usually on form submissions like contact forms, registration pages, and comment pages. They sometimes become annoying since the query does not come from legitimate users or customers. On server access logs most of them come with a single IP.

Brute Force Attack

A brute force attack is a series of login attempts trying to guess the password. There are many methods of doing this, one is doing all the combinations to log in, another is using a dictionary of known weak passwords. Access to the wp-admin dashboard is really plenty on server access logs.

DDoS Attack

DDoS is an acronym for Distributed Denial of Service. The DDoS attack utilizes several IP addresses that send multiple requests with the aim to exceed the bandwidth and limit access to a website.

Blocking an IP using a plugin

The most sophisticated plugin for securing a WordPress site is Wordfence. Wordfence features a built-from-the-ground-up endpoint firewall and malware scanner to secure WordPress. Wordfence gets the latest firewall rules, malware signatures, and malicious IP addresses from its Threat Defense Feed, so it can keep the website secure. Wordfence is the most robust WordPress protection system today, with 2FA and a suite of additional tools.

Here are other plugins worth considering in blocking IP:

Blocking an IP in Server Configuration

On Apache servers, this can be done by adding Deny keyword on .htaccess

# Block Single IP
Deny from 192.168.254.1

# Block Entire Subnet
Deny from 192.168

# Block using CIDR
Deny from 192.168.254.0/24

On Nginx servers, add access.conf file on Nginx configuration folder.

location / {
   deny 192.168.254.1;
 }

After adding, reload the configuration or restart Nginx.

Blocking an IP by using PHP

Use a PHP snippet to block IP, the best way to put the code on wp-config.php, the server would deny the IP before bootstrapping the core, plugins, and themes.

if ($_SERVER['REMOTE_ADDR'] == '192.168.254.1') {
  header('HTTP/1.0 403 Forbidden');
  exit;
}

Wrapping UP

I think the best method to use is the server configuration and PHP code inclusion. Even if the site is experiencing a DDoS attack, the Server and PHP code can be added instantly.

Installing WP Rocket on Pantheon Platform

Some people do find a hard time installing WP Rocket on Pantheon since it creates files on a write-protect folder set by Pantheon Platform.

The solution was to create a symlink and point to the write permitted folder which is the wp-content/uploads folder.

Please take note that this step is not recommended to be used on any SFTP app but only on the SFTP command line. Since creating symlinks over SFTP have inconsistencies between clients. The process below was tested using MacBook Pro (Mojave), Ubuntu 18.04.4 LTS, and Windows 10 (Release 1909)

  • Create a folder cache and wp-rocket-config on wp-content/uploads folder on DEV first (later would be TEST and LIVE).
  • Remove the wp-content/cache folder. If there is a wp-content/wp-rocket-config folder, remove it also.
  • Create a symlink via the terminal command line.

Note: Be sure that you are in the wp-content folder.

$ ln -s ./uploads/cache cache
$ ln -s ./uploads/wp-rocket-config wp-rocket-config
  • Commit and push the symlink via git.
  • Create the folder cache and wp-rocket-config in wp-content/uploads​ for TEST and LIVE.
  • Commit and deploy code to TEST and LIVE.
  • Activate the WP-Rocket plugin and apply the license code.

Hopefully, this will help users install the WP-Rocket Plugin on the Pantheon Platform.

Happy Coding.