Copy-pasting every file still optimal way to create Flarum staging environment?

Mand

Hi, I'd like to create a staging environment as the exact copy (mirror) of my live Flarum forum, right now I just want to enable/disable extensions one by one to check if there's one extension conflicting with another and breaking the site, so searching here I found:

clarkwinkelmann Wellwisher if you copy-paste every file, it will work fine just like other software.

Is this still the recommended way or is there a new way that would always keep staging and production in sync therefore eliminating the need to copy-paste every file every time a new extension has been added i.e. in a couple of days as I further develop the forum and add a new extension?

thanks,

clarkwinkelmann

If you have access to Composer on both systems, you can copy every file except the vendor and storage folders.

When you want to sync the extensions, just copy the composer.json and composer.lock from the main website and run composer install on the staging server. This will download the same version of everything without having to copy over the vendor folder.

If you use Flarum.org premium extension you need to run the setup once on the staging server as well, copying the files won't copy the secret token.

Mand

clarkwinkelmann when you say 'f you have access to Composer on both systems' and 'on the staging server.' I'm not planning on copying the files to another server, but to a subdomain on the same server as the live website as in staging.domain.com and domain.com/production. Does the same apply?

Mand

clarkwinkelmann you can copy every file except the vendor and storage folders.

clarkwinkelmann If you are on the same server you can probably copy the entire Flarum folder including vendor

Just to double check as I am on the same server do I not copy the storage folder?
And if you could elaborate why you mentioned vendor and storage folders (as in why/when you would want to copy them and when you wouldn't) that would help me understand how things work a little better please. Thanks in advance again.

clarkwinkelmann

Mand yes, same logic.

If you are on the same server you can probably copy the entire Flarum folder including vendor, this won't take much longer, and the files will be copied locally either way (if you don't copy the folder and run install, the files will be copied from the local Composer cache)

Whether it's the same server or a different server, make sure you are running the same PHP version, both for accurate testing and so the Composer dependencies needed are the same.

Once your dev subdomain is setup, for future syncs you only need to copy the database, avatar files and the new composer json and lock filed, and run Composer install.

dinapolis

clarkwinkelmann you can probably copy the entire Flarum folder

clarkwinkelmann for future syncs you only need to copy the database,

Just trying to understand here, by copying the entire folder this way won't the staging site access / write on the same database as the live site? Doesn't that defeat the point of staging?

luceos

Mand the composer.lock file contains the information what files are supposed to in vendor. Everything in vendor will be downloaded again if you run composer install while a lock file is present.

clarkwinkelmann

dinapolis the only file that needs to be different between the 2 copies of the site is config.php, to point to the separate staging database.

vendor only contains extensions and dependencies, no data. That's why it can either be copied or re-created, it doesn't matter, it's just code downloaded from Packagist in there.

What I meant is that if you already have staging with its own database, you can just update the database with a different dump and it will be reflected on the stating website.

Something to be careful of, if you copy the production database, make sure emails are disabled on the staging server. The database does contain the email driver setting and credentials, so you should set the mail_driver value in the settings table to null or log unless you want to do tests specifically with your email server. You might also want to clear the database jobs queue (if you use it) to not run any pending jobs from production on the staging server.

navindra

So you're using the same database for production and staging? That seems very dangerous to me if so. Any persistent changes you make on staging (including extension changes) will affect production.

This may not help you now, but as a future investment, you may want to look at containerizing your site. Then you can trivially recreate it anywhere... even your localhost. MariaDB has a very nice container that can automatically restore a database from a dump backup file.

clarkwinkelmann

navindra I specifically described copying the database content to a second database.

My recommendation when running an internet-facing staging environment would be to use a completely fresh database without any production data. This will avoid the issues I mentioned about making sure to not process production jobs on the staging server. The data on the staging server could be generated with Fake Data extension.

Only when you cannot replicate an issue you could launch a temporary new instance with a copy of the production database, ideally in a sandbox like you describe.

Ultimately there are no rules, just industry best practices. By being written in PHP+MySQL, Flarum instances can easily be backed up, copied and redeployed.

Always backup your data 😉 Deploying backups in a staging environment from time to time is also a good way to verify they aren't corrupted.

navindra

clarkwinkelmann Ah yes, somehow I missed the last couple of responses of the discussion. Agree with what you said above! I follow very similar methods as you described. If I'm not running the staging stuff on my local laptop, I just use Cloudflare to lock things down by IP.

I don't think I would risk running staging on the same server as production (unless using virtualization).