Since WordPress 3.5 this option (XML-RPC) is enabled by default, and the ability to turn it off from WordPress dashboard is gone.
Add this code snippet for use in functions.php:
// Disable use XML-RPC
add_filter( 'xmlrpc_enabled', '__return_false' );
// Disable X-Pingback to header
add_filter( 'wp_headers', 'disable_x_pingback' );
The best thing to do is disable xmlrpc.php functions with a plugin rather than delete or disable the file itself. The file itself will be replaced on WordPress core updates, while a plugin will keep it disabled after core updates and if you change themes.
See https://wordpress.org/plugins/search.php?q=disable+xml-rpc for different plugins. They all have ...
When you have the ability to block it via your web server's configuration, @Charles' suggestions are good.
If you can only disable it using php, the xmlrpc_enabled filter is not the right way.
Like documented here:
it only disables xml rpc methods that require authentication.
Instead use the ...
For the extreme minority that are hosting WordPress in IIS, you could use the IIS URL Rewrite module to do similar htaccess-like restrictions. The example below assumes the true client IP is coming in the X-Forwarded-For header, the known whitelist IP is 55.55.555.555, and that you want to respond with an HTTP 404 to non-whitelist IPs.
On the Edit Post page, click the Screen Options dropdown in the upper right hand corner. Enable the "Author" meta box. Now, on your main edit post page, you'll find the author box, where you can simply select who the author of the post is from a drop down menu.
After looking a little further I found an article on the Webmaster forums page. It has nothing to do with your hosting provider as I earlier suggested. It is 100% Google. The reason is to assist webmasters in protecting their sites by keeping up to date services.
They need to make a few improvements since each time I've received a notification it has been ...
I have been using a plug-in (Backup Buddy) to achieve my transfers.
It is not free but it does a great job of moving the from a dev (local) server to a live site.
Back up your entire WordPress installation. Widgets, themes, plugins,
files and SQL database - the entire package! Just like your laptop or
there are quite a few threads on here about this topic ... just look at these examples:
Database synchronization between dev/staging and production
I would also recommend you read Mark Jaquith's post on Local and Dev Tip's.
This is a rather clean-cut answer in my opinion, but each to their own and of course there will be varying opinions on this. The WordPress.com blog hosting service offers one major feature that self-hosted installations managed by WordPress newbies don't have: great security. It's no secret that a self-hosted WordPress installation can be a lot of work ...