Updates, Backups, and Version Control

Updates can apply to dependencies, frameworks, plugins, themes, content management systems, hosting settings, build tools, scripts, forms, and analytics tools.

Updates may include security fixes, bug fixes, performance improvements, new features, and compatibility changes. Updating is important, but updating without testing can create new problems.

Static sites built with tools such as Vite often use packages installed through npm. A simple update process might look like this:

1. Check the current site works.
2. Create a new branch.
3. Update dependencies.
4. Run the development server.
5. Run the build command.
6. Test key pages.
7. Check the deployment preview.
8. Merge only when everything looks correct.

npm outdated
npm update
npm run dev
npm run build

Do not update everything blindly right before you need the site. That is not maintenance. That is summoning.

WordPress sites often include WordPress core, plugins, themes, custom code, a database, and media uploads.

A safer WordPress update process is: back up the site, check what updates are available, update one group at a time if possible, test the homepage, test important pages, test forms, check mobile layout, check admin functionality, and record what changed.

If the site has a staging environment, test updates there first. A staging site is a private copy of the site used for testing before changes go live.

Version control tracks changes to files over time. Git is the most common version control tool used in web development.

Version control helps you see what changed, compare versions, undo mistakes, work on branches, collaborate with others, and connect to deployment services.

However, Git is not always a complete backup. It may not include database content, uploaded media stored elsewhere, environment variables, form submissions, analytics data, hosting settings, or DNS records.

A backup is a copy of important website data that can be restored if something goes wrong. A useful backup is current enough to matter, stored somewhere safe, separate from the live site, restorable, and documented.

A backup that cannot be restored is more of a comforting rumour than a recovery plan.

Static sites need source files, content files, images, public assets, environment variable documentation, deployment settings, domain settings, DNS records, and analytics settings considered. WordPress sites need database, uploads, theme files, plugin files, custom code, and configuration backups. Builder sites may need separate copies of page content, images, product information, theme settings, custom code snippets, app integrations, and account ownership details.

1. Check the site before updating.
2. Make sure a backup or rollback option exists.
3. Update in a controlled way.
4. Test the site after updating.
5. Check important pages and forms.
6. Check mobile layout.
7. Record what changed.
8. Keep notes for next time.

This process works for many types of websites. The details may change, but the thinking stays the same.

A rollback means returning to an earlier working version. Rollback options might include Git commits, deployment history, hosting backups, WordPress backups, manual file backups, or database backups.

Before making major changes, ask: How would I undo this? Where is the last working version? Who has access to restore it? How long would restoration take? What data might be lost?

Rollback planning is not pessimism. It is professional.