This WordPress site uses the Google Authenticator plugin to provide two-factor authentication (2FA) when logging-in to the administration area. Occasionally I need to temporarily disable 2FA in order to publish posts from the blogging software I use. Traditionally toggling 2FA is achieved from the WordPress backend. This post looks at two alternative methods of doing this locally from the command line.
WP-CLI is the command-line interface for WordPress. It allows you to manage your WordPress site from the command line without using a web browser. I currently use WP-CLI to temporarily disable the WordPress Google Authenticator plugin, create and configure a version of this site to run in a local AMP environment on my Mac and – in conjunction with launchd – periodically change the posts that appear in the slider on this site’s home page.
Comments in WordPress are displayed using the wp_list_comments() function. This function takes many arguments. One of these is callback which takes the name of a defined function that in turn determines what and how comment data is output. If no callback function is given, wp_list_comments() uses a built-in default function.
Several Desktop blog-editing applications use XML-RPC to allow you to manage your WordPress blog. The one I use is MarsEdit.
XML-RPC functionality has been turned on by default since WordPress 3.5 so after updating to WordPress 3.8.2 I was not expecting MarsEdit to report that XML-RPC services are disabled on this site.
Having spent some considerable time and effort cleaning this site after it had been hacked I was determined to make it as secure as I possibly could in an attempt to prevent it happening again.
This is a WordPress site running on an Apache server so one of the numerous measures I implemented was to use HTTP Authentication to password-protect the wp-login.php file.
Many of you will be familiar with the Jetpack plugin. I use Jetpack’s Stats module — previously the WordPress.com Stats plugin — to record and display this site’s page views.
Several Jetpack modules including the Stats module require a connection to an account at WordPress.com where your self-hosted WordPress site is given a unique ID. This unique ID is associated with the site’s domain name. If you change an already connected site’s domain name and reconnect it to your WordPress.com account it is given a new unique ID.
Herein lies the source of a problem I had recently which resulted in the apparent loss of all this site’s stats.
A previous theme I used for this site incorporated For some while this site’s been using the collapsible sidebar lists I described in this post. This method requires manually adding PHP and Javascript to the theme’s code. All a bit clunky really.
I’ve finally completed a plugin which provides the same functionality, but in a far more convenient way. The collapsible lists currently displayed in this site’s sidebar are generated by this plugin.
Like countless other WordPress users I’ve been logging into the installation’s back-end using the admin username I created on day one.
Having read about the recently publicised botnet that uses the admin username for brute force attacks I thought it was time to beef-up my blog’s back-end security.
Some while back I described a method for retrieving and displaying individual post view counts from WordPress.com. Having proved quite popular, I thought I’d wrap this functionality in a simple plugin.
Installing WordPress on a local server environment is fairly straight forward. There are numerous guides to be found on the Internet that’ll walk you through each step.
However, if your local server environment is running on a Mac, the local Apache server may have some difficulty serving WordPress posts and pages resulting in Error 404 Object not found! errors. These errors can often be attributed to the use of custom or so-called pretty permalinks.
Recent Comments