Recommended way to move installation from local to production server

[_Roy_]

I am about to put my first ProcessWire-powered website onto a live server, and I was searching the website and forum on how to do this. Maybe I used the wrong search-terms, but I did not find anything on how this should be done.

I can obviously just throw all the files on the server through FTP, and put the database in place using PhpMyAdmin. Then change the DB-credentials in config.php and I think it should work, but I don't know what the recommended way is to push a website from your local/dev-environment to a live webserver.

[Peter Knight]

I usually do this and it simplifies things if your local and remote credentials are the same. 
 

1. Turn on errors on your config file to make trouble shooting easier

2. Zip up all your local files and ensure to get your htaccess too

3. Export the local database and import it into the remote plesk server or whatever you’re using

4. Set up remote database credentials 

5. unzip remote files

From that point onwards, I might have some htaccess issues or I might need to look at site logs etc but most of the time it goes smoothly enough.

You’re installing onto a blank site right? 
If there is an existing site in the webspace which you didn’t create, ensure to rename the index.html page

 

 

 

[_Roy_]

Yes, it is a completely new hosting-package.

The error-reporting is a good idea! 

[maximus]

I every time use Duplicator module for transferring website from server to server.

Great solution!

[szabesz]

For a "brand new" host (one I've never used before), I always start with a clean installation of ProcessWire because the installer runs its requirements checks during installation. After successfully installing ProcessWire, I replace all files and the database, adjust the config settings, and then it's ready to go.

[Peter Knight]

@_Roy_ how did it go?

[_Roy_]

@Peter Knight I will report back, the hosting has to be registered, I think somewhere next week.

[Peter Knight]

No probs. Just out of curiosity, who are you hosting with as I recall some hosts have weird setups. I recall GoDaddy in particular caused me issues before. Nothing some htaccess wrangling didn’t fix but a head scratcher at the beginning.

[_Roy_]

It is not going to be one of the big US-based hosting-companies. I'm European, so a EU-based host has my preference as the lower geographical distance will be good for the speeds.

The one I am looking at as the most probable choise is a rather small one that I have previous experience with. The benefit of that one is that I can just send them a message if I need anything, and their responses are always fast and really answer the question. That is something I miss with large companies: direct contact with a person who has the knowledge.

[szabesz]

@_Roy_ Just a quick tip: if mod_security will be enabled and you run into troubles, most of the time the only option is to disable mod_security.

[evan]

Something I've adopted for my PW sites is putting environment-specific DB credentials and configuration in a separate file, /site/config.local.php:

/**
 * Installer: Database Configuration
 * 
 */

$config->dbHost = '127.0.0.1';
$config->dbName = 'db';
$config->dbUser = 'default';
$config->dbPass = 'default';
$config->dbPort = '3306';


/**
 * Installer: HTTP Hosts Whitelist
 * 
 */
$config->httpHosts = array( 'my-local-domain.test');

And then including that file into /site/config.php:

/*** INSTALLER CONFIG ********************************************************************/

// DB Config, Hosts Whitelist
include dirname(__FILE__) . '/config.local.php';

I find this makes it easier to push changes when using version control (i.e. git) across different environments, and keep the credentials and other sensitive information excluded from the repo.

On some managed hosts like Cloudways, you can pull and push DB changes from staging to/from production applications, as well as branch changes from git.  Obviously this doesn't help when you make DB changes locally, though.

Otherwise, I will either export/import the entire DB via the Database Backups module, or Pages Import/Export (under Admin > Modules, Core modules) depending on the kind of changes.

After using Vercel and Netlify for static-based websites, it does make me wish there was a quicker way to push/pull DB changes, but perhaps that extra bit of friction is good so you don't inadvertently disrupt your production data.  Definitely something I can improve in my own workflow!

Managing local/remote image assets

Occasionally I've added this code snippet to /site/ready.php, that allows for your local installation to pull down the asset from prod, which can save you some time.

I'm also generally curious to know more about other folks' deployment strategies – could be a potentially useful thing to collect and make more visible in the PW docs, too.

Edited March 24 by evan

[da²]

My way to upload local site to production is using basic Linux tools. I'm on Windows but with a WSL console running Debian, you have access to all tools.

First I use Ant to synchronize files from my code to a separate local directory (Ant is a set of tools that you use by creating a simple XML describing tasks), I exclude some files or directories (like PW cache and logs...), automatically increment a version number, replace some variables in some files (like site version/build number, debug variables...)...
Then an rsync command send the code to the server.

Deploying a site update is then only executing this script and waiting a few seconds. 🙂

I exclude site config.php because some values change from production server (database credentials, debug=false|true, Stripe identifiers...).

Example of a deploy script (very simple but powerful stuff ^^):

#!/bin/bash

# Directory where Ant project synchronize files.
build_dir=./target/processwire/

echo "=> Executing ANT project..."
cmd.exe /c build-processwire.bat

buildOk=$?

if [ $buildOk -ne 0 ]; then
    echo "ANT build failed, stopping script."
    exit
fi

read -p "Press enter to update PRODUCTION server, ctrl+c to cancel."

echo "=> Copying files to web server..."
rsync -avh --delete-delay --include-from=deploy-includes.txt --exclude-from=deploy-excludes.txt --chown=linux_user_name:linux_user_group -e ssh $build_dir linux_login@server_ip:/var/www/path_to_productionsite/

If this is the first time I deploy this project, or if this is a staging server (not production) and I want to reset database at every deploy, I add this line, it copies my local PW database to the server:

echo "=> Copying database to production"
/mnt/e/xampp_php8.2/mysql/bin/mysqldump.exe --add-drop-database -uDB_local_user --databases database_name | ssh linux_login@server_ip "mysql -uDB_user -pDB_password"

Since Ant project uses files synchronization (and not copy) and rsync does the same, it deploys to server only files that have changed since last deploy, so it's fast and console logs are clear.

If you're interested with Ant XML file, I can show you an example. Same with directories/files I exclude from build, both in Ant and rsync.

EDIT: For the first installation on server, I start with a regular PW install directly on server.

EDIT 2: Script also set the site in maintenance while deploying, displaying a "Maintenance, please come back later" message, with a bit of Apache configuration. It uploads a file at the site root on server, and when this files exists Apache redirects users to a basic HTML page (except for my IP).

Edited Thursday at 03:49 PM by da²