Updating WorkUp Safely
0

The Golden Rule

Never update without taking a fresh backup first. Check the backup guide and take a full backup (database + the files folder) now, before you even finish reading this guide. Every step below assumes you already have this backup ready.
1

How to Update Depending on How You Got the Files

There are two common ways to have a copy of WorkUp on the server: via Git, or by uploading files manually. The method determines how you update.
1

If the Project Is Linked to Git

cd /var/www/html/WorkUp
git status   # Make sure there are no unsaved local changes
git pull origin main

git pull automatically pulls all new changes and merges them into the existing files. If a "conflict" message appears, stop and ask for help before continuing — this means the same file was modified both locally and in the new update.

2

If You Upload Files Manually (Without Git)

Do not replace the entire folder all at once! Some files must never be touched because they contain your own settings:

Never replace these two files with new versions: includes/config.php (your database credentials) and .htaccess (your server's include_path). Also do not touch the files/ folder (real employee photos and attachments).

Only upload the actual files/folders that changed in the update (whoever sent you the update usually tells you which ones), via FileZilla or scp, explicitly excluding the files above.

2

Does the Update Require a Database Change?

Good news: most features in WorkUp are built to "create their own tables automatically" on first use (internal functions called ensureSchema) — you don't need to run any SQL command manually in most cases. But if the update comes with a file named something like update.sql, or explicit instructions saying "run this query," execute it like this:
3

Running a Database Update File (Only If Explicitly Instructed)

mysql -u workup_user -p workup < update.sql

Do not run this command "just in case" without a reason — only when you know for certain that a database update file is included with the new version of the code.

3

A Quick Test After Every Update

4

Before You Declare "Done," Try This

Open the login page (abma and empma) and make sure it displays normally.
Log in with a real account and browse one or two main pages.
Watch the Apache error log while browsing: sudo tail -f /var/log/apache2/error.log
Open the mobile app and make sure it still connects normally (especially after any update that touches api/ files).
4

Rollback Plan

Ran into a problem after the update? No need to panic. Here's how to go back to the last working version.
5

Rolling Back Depending on the Method Used

With Git: go back to the last point that was working (a previous commit):

git log --oneline -5   # View the last 5 updates and each one's ID
git reset --hard previous_commit_hash

With manual upload: if you kept a copy of the old files before replacing them (it's always best to take a copy before any manual update), re-upload it as it was.

In both cases: if the update touched the database, restore the database backup you took before the update (see the restore guide).

5

Checklist Before Any Update

You took a full backup (database + files) before starting.
You know exactly which files must not be replaced (config.php, .htaccess, files/).
You know whether the update requires running an additional SQL file or not.
You picked a quiet time for the update (not during peak employee usage hours).
You know how to roll back if a problem appears.
A good update is a boring update: a backup, a calm update, a quick test. No surprises.
Updates WorkUp