Lunatic59

I don’t have a lot of experience with nginx, but it looks like for Ubuntu Server the user:group remains www-data. For CentOS/RedHat, if he used the defaults it would be nginx:nginx

You can have a read through this to see if it helps.

https://www.digitalocean.com/community/articles/how-to-install-wordpress-with-nginx-on-centos-6–2

Do you know which operating system/version your friend is running? I had problems with installing themes and plugins until I set ownership to the webservice.

on RedHat/CentOS it would be chown -R apache:apache
on Ubuntu i beleive it’s chown -R www-data:www-data

Moving the host is more complicated. As long as the new host is providing similar services then you need to backup your WordPress mysql database, and then create your mysql user on the new host and restore the database there. Then you will simply copy all your files from the old host to the new host, keeping the directory structure the same.

Don’t be surprised if the site will require some tweaking before it works properly.

If all you’re doing is changing registrars for the domain and not the host, then you really only need to make sure that the new registrar is pointing the domain’s A-record (DNS) to the same server.

Backing up any data is always a good idea.

If you are running your original site at https://www.domain.com, why not create a subdomain at blog.domain.com and point it to https://www.domain.com/wordpress/ as it’s root?

Sounds like a permissions issue to me. What kind of server are you running?

I have 3PCs.

PC’s as a rule do not make good servers. PC’s are designed for short periods of high intensity use while servers are built to be on 24/7 for years. To host a single website, you don’t really need much space or power. What you need is reliability and throughput. At a minimum, I would consider putting a RAID1 array in the machine you do decide to use.

For your standard webserver, a dual core CPU with 8GB RAM and 200GB hard drive is plenty. What it should have is a RAID 1 array, preferably RAID 10 using 10K SAS disks, gigabit ethernet and redundant power supplies. And, most importantly, a backup process that stores the backups OFF the server (daily for an active website).

All that said, what you propose is possible and people do it, just be advised that without the right hardware, when your’s fails (and it will fail) you may be SOL and down for a long time.

Only the current registrant can change the ownership of a domain. The third party blog who registered the domain will submit the transfer request with their registrar to whoever your customer wants as their registrar. Once completed your customer will be given access to the domain and all you have to do at that point is to change the A-record to point to the new hosting server’s public IP. (mx record, too if they want email on that domain.)

If the page url changed between versions, you might still be accessing an old cached copy. Try logging out, clear your browser’s cache and then try logging back in.

Sure it’s possible. I do it all the time. The hosting server must have virtual hosting enabled in Apache and the root of the subdomain must be set to the WordPress directory. For example, if it were a LAMP server you’d enter this into httpd.conf

<VirtualHost *:80>
    ServerAdmin [email protected]
    DocumentRoot /var/www/html/wordpress/
    ServerName blog.currentsite.com
    ErrorLog logs/blog.currentsite.com-error_log
    CustomLog logs/blog.currentsite.com-access_log common
</VirtualHost>

As for the FTP problems with the theme, I’d suggest creating a new FTP user specifically for WordPress and setting the root access for that user to the WordPress folder.

Most of those options should be available through the hosting provider’s control panel.

Update…

After the obvious and the not-so-obvious was tried with no success, the next step is to start from scratch.

I blew out the whole installation and removed the user and the database and began again. Obviously I missed something the first time as this time it works perfectly.

Sometimes it’s easier to rebuild than it is to repair. ??

I’m not entirely sure it’s a permissions issue.

I had already set the ownership and the group to apache:apache. I then made the user a member of the apache group. That’s pretty much how I have the WordPress installation setup in /var/www/html and that’s working fine.

I tried creating a new group as you suggested and made both the user and apache members of that group with folder permissions set to 775 and files at 664. I even tried setting everything to 777 temporarily to see if it would work at all. It didn’t.

Here’s the symptoms. I will go to themes>new and select one to install. I am prompted for the ftp password and click proceed. The page begins to refresh, but both the header and the main window remain blank. If I hit refresh it may continue to downloading and then unpacking the package where it will stop.

I’ve checked the error logs and don’t see anything failing, and the xfer log shows files copied to wp-content/upgrade/package.tmp. If I copy the contents of that folder to themes, the themes page says the installation is incomplete … missing style sheet.

I am able to access the site with an ftp client (Filezilla) and install themes and plugins manually. I am also able to upload media through WordPress.

Not sure where to look next.