The Wordpress autoupdate feature allows Wordpress to automatically download and install updates on your Wordpress.  It’s one of the best features in Wordpress and usually performs a clean update in a matter of seconds without you having to mess around with your files. One of the downsides of autoupdate is that it does not support SFTP out of the box. There are several tutorials explaining how to recompile PHP to enable SFTP in Wordpress, but the best way to get around this is to bypass using SFTP, FTPS and FTP altogether and assigning the correct permissions to your files so the web server can have write permissions.
Log into your account using SSH and type:

chown apache /var/www/blog -R

Note: Some Linux distros use other users for Apache, like httpd, wwwuser, or wwwdata. Check the User directive in your Apache configuration to make sure you assign the right user to your files.

Be sure to replace the /var/www/blog with the path to your Wordpress installation. And that’s it.  Wordpress should take care of the rest.

This is one of the more annoying bugs in Wordpress. Wordpress is working fine, but when you check the RSS feed you get the following error:

XML Parsing Error: XML or text declaration not at start of entity
Location: http://domain.com/feed/
Line Number 3, Column 1:<?xml version="1.0" encoding="UTF-8"?>
^

The most common explanation for its cause is blank spaces leading and ending the PHP pages caused by editing the theme. There are two solutions for this problem. The first is the easiest and I would recommend trying this first.

Solution 1:

Step 1)

Install the fix-rss-feed plugin. http://wordpress.org/extend/plugins/fix-rss-feed/

Step 2)

Go to Admin > settings > fix RSS Feed

Step 3)

Click on the “Fix wordpress rss feed error” button

This might or might not fix your problem. I have had it work on some themes and it failed on others. If it fails I would recommend the following solution:

Solution 2:

The “Wordpress leading whitespace fix” is slightly more involved than the plugin, albeit a very good solution when the plugin fails. The fix is well documented so I will not bother to repeat the steps here. You can read installation instructions and download from here: http://wejn.org/stuff/wejnswpwhitespacefix.php.html

One of the most common errors after installing WordPress on your hosting account is the “The uploaded file could not be moved” error when trying to upload a file. Typically the error message looks like this:

The uploaded file could not be moved to /var/www/vhosts/domain.com/httpdocs/wp-content/uploads.

This is a common error due to permissions. I got this error fixing a WordPress instalation on another host which, will remain unnamed, for a treasonist family member who does not use ServerGrove, who will also remain unnamed. I did some research and while reading the solutions out there I was amazed to see the amount of posts asking people to chmod 777 their entire wp-content and wp-content/upload directory. Let me say this once: it’s never a good solution to chmod 777 an entire directory.

Let’s analyze the problem to better understand what’s going on. When you create directories either via FTP or via some other method, the directory is owned by the user that created that directory. So when you upload your Wordpress via FTP the directories are owned by your user. Then when we try to upload images via the WordPress admin we are uploading via a web page we are actually uploading via http, and items uploaded through http are owned by the Apache user, master of http. So when the Apache user tried to put a file in the folder owned by your user, Linux steps in and notes there is a permission problem. You cannot put content into a directory owned by another user and spits back the error:

The uploaded file could not be moved to /var/www/vhosts/domain.com/httpdocs/wp-content/uploads.

So, the question rises, why does this happen on some hosts and does not happen on other hosting companies like ServerGrove? Well for one, we are wise, and know that permissions errors are very common and easily avoidable (kind of like acne). The solution lies in the way your shared hosting server is setup, some hosting companies slap the default installations and other wiser ones spend their waking hours fine tuning the servers and making them perform faster and work better for their clients.  Our servers are configured so Apache runs as the same user as your user (a different one for each website), this means that your user and Apache are the same which makes everyone’s life easier. This simple permission error would never happen on our servers and had my weasel family member setup on ServerGrove he would not have had to ask for my help.