Grav and wordpress on the same server - thoughts, hints, advice?

1

A friend of mine would like to port their Wordpress site onto my server where I run my Grav website, so that they can exploit all the features of Wordpress without paying for their own server. I’m curious to try, but I’m worried that it would be much more complicated than I anticipated.

Since I’ve had a lot of help on this forum before, I thought I’d ask if anyone has any advice, thoughts or tips on the subject, even if it’s not strictly Grav related :slight_smile:

More details:

  • My website
  • Grav installed from zip, with a grav user
  • I’m using Nginx with letsencrypt
  • My Nginx conf file, in /etc/nginx/sites-available/grav:
server {
        index index.html index.php;
        ## Begin - Server Info
        root /home/grav/www/html;
        server_name gobs.eu www.gobs.eu gobs.brussels www.gobs.brussels;
        ## End - Server Info

        ## Begin - Index # for subfolders, simply adjust the rewrite: # to use `/subfolder/index.php`
        location / {
                try_files $uri $uri/ /index.php?_url=$uri;
        }
        ## End - Index

        ## Begin - PHP
        location ~ \.php$ {
                # Choose either a socket or TCP/IP address
                fastcgi_pass unix:/run/php/php7.4-fpm.sock;
                # fastcgi_pass 127.0.0.1:9000;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_index index.php; include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
        }
        ## End - PHP

        ## Begin - Security
        # deny all direct access for these folders
        location ~* /(.git|cache|bin|logs|backups)/.*$ {
                return 403;
        }
        # deny running scripts inside core system folders
        location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|php|pl|py|cgi|twig|sh|bat)$ {
                return 403;
        }
        # deny running scripts inside user folder
        location ~* /user/.*\.(txt|md|yaml|php|pl|py|cgi|twig|sh|bat)$ {
                return 403;
        }
        # deny access to specific files in the root folder
        location ~ /(LICENSE|composer.lock|composer.json|nginx.conf|web.config|htaccess.txt|\.htaccess) {
                return 403;
        }
        ## End - Security

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/www.gobs.brussels/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.gobs.brussels/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot








}
server {
    if ($host = www.gobs.eu) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = gobs.eu) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = gobs.brussels) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = www.gobs.brussels) {
        return 301 https://$host$request_uri;
    } # managed by Certbot



        listen 80;
        server_name gobs.eu www.gobs.eu gobs.brussels www.gobs.brussels;
    return 404; # managed by Certbot








}
2

@gobs : I think this should not be a problem, just create a dedicated Subdomain for the WP Installation, e.g. wp.gobs.eu with root in /home/wp/www/html , config file
/etc/nginx/sites-available/wp and install WP in that Subdomain.
note that I don’t know much about nginx, but I’m sure creating Subdomains with nginx is well documented.
but, to be honest, I do not really understand what you mean with you first sentence: porting a WP Site means for me, the site does already exist elsewhere, right ?
so why porting it to your server, additionally ?

3

@hoernerfranz thank you! That sounds straightforward enough, I’ll try it out and hopefully I don’t have too many problems.

By porting the WP site: I mean that currently my friend has their website on wordpress.com, and so has limited access to features, e.g. modifying themes, hence why they want to port it to my server (to be able to modify themes and avoid paying for a server themselves)

4

ok, porting a website from wordpress.com to be able to modify/enhance things makes sense.
and, as said, doing this in a subdomain of your existing Installation will not interfere with your own site.
just be sure you have access to a mysql instance for WP (Grav does not need one).

5

Quick question - if I had another domain instead of a subdomain, would that complicate matters?

6

no, of course not :smile: - the advantage of a subdomain is usually that it does not create additional costs, as opposed to another domain, which normally has to be booked/paid at extra costs.

7

A lot of what you are worrying about, @gobs, are not problems.

What can be a real pain is Wordpress: migrating it and managing it (if that’s your job). I hosted Wordpress for a client when she got kicked off her shared host because the site was consuming shared resources and we couldn’t find the cause.

Wordpress needs constant updating. Because WP is insecure (it’s very old and a huge target because of its popularity and poor plugins), I didn’t want to do this. I ended up hosting it in a Docker container so it couldn’t (shouldn’t!) compromise other sites on my server. So you might consider security implications on your server if you don’t have some way to isolate WP.

I only agreed to host WP because my client was stuck, I like her and her site, and because we were redeveloping in Grav :slight_smile: Also because I had the Docker solution.

I have another client who needed WP hosting last year. I accepted that too because I have a Dreamhost account where they manage the updates for me and it costs me nothing more, plus they host her email at no cost me either.

You probably need a plugin to make the WP export/import run smoothly.

I think you might be taking on more than you expect but it depends what your arrangement is. The migration is tricky and there will be a stream of issues.

You will gain a renewed appreciation for Grav and flat file CMSs :wink:

8

Hmmm, thanks for the headsup re WP. I think I will try anyway, since if my friend would translate her website into Grav it would also require a lot of work from me (while I like Grav, editing templates etc is quite involved and my friend “does not want to code”, so I would have to make those changes for her).

Thanks for all the advice!

9

@gobs - I can only second what @hughbris wrote about wordpress, and even add some more complaints :smile:.
I have done the transition from WP to Grav long ago and never looked back, see this blogpost.
of course, as stated, the work required for this process can vary from ‘easy’ to ‘really much work’ depending on the situation (plugins, theme…).