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.
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.
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.
I never did get to the bottom of the issue I was having with the Jetpack plugin and page navigation in WordPress. So, it seemed I would either have to do without site statistics provided by the Jetpack plugin or this site would have to forego page navigation.
I’ve been using site statistics provided WordPress.com for some time. The popular posts widgets in the sidebar and on single post pages rely on these statistics to display this site’s most viewed posts and pages.
I’ve currently disabled page navigation on this site as it appears to be broken. While I can’t be 100% certain, the culprit appears to be the Jetpack plugin I use that incorporates WordPress.com Stats.
Although I rarely use the search option on my site I noticed that my Contact page was being included in the search results. Not only did this seem pointless, it also looked strange slap-bang in the middle of the results page.
Recent Comments