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
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
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.
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.
Back in July 2011 I noticed a problem with the Jetpack plugin and page navigation. In short, with the Jetpack plugin activated page navigation worked only if I was logged-in as admin. When logged-out page urls were being incorrectly re-written and causing 404 Not Found errors.
Now, some 9 months after having first raised the issue over at the WordPress.org forums member Josh Eaton seems to have found a possible cause.
Having recently switched from SyntaxHighlighter MT to the SyntaxHighlighter Evolved plugin I was unable to get my custom Apache brush I use for .htaccess and *.conf files to work.
While searching for an answer I happened upon a better although seemingly unfinished version of an Apache brush, but still couldn’t get it work. A little further digging and I learnt that I needed to write a plugin to use a custom brush with SyntaxHighlighter Evolved.