Why LaraClassified upgrades need a plan

LaraClassified is a Laravel application, and that shapes everything about how an upgrade behaves. Unlike a flat PHP script where replacing files is usually enough, a Laravel release ships three coupled layers that must stay consistent with each other: the compiled application code under app/, resources/, and vendor/; the environment configuration in .env; and the database schema tracked by the migrations table. A new major version frequently adds columns, renames settings, changes the config/ cache format, and expects a fresh bootstrap/cache. If you overwrite files without running the matching migrations, or you run migrations against an old codebase, the site throws 500 errors and the admin panel becomes unreachable.

On a Managed Cloud Shared Hosting account the constraints are specific. You are an unprivileged user, so you cannot restart PHP-FPM, edit php.ini globally, or run root-level composer builds. What you do control is the document root through File Manager, PHP behaviour through the cPanel MultiPHP/PHP Selector or DirectAdmin PHP version picker, per-directory limits through .user.ini, request handling through .htaccess, and the database through phpMyAdmin. LaraClassified vendors are usually distributed as a pre-built package (the release ZIP already contains a vendor/ directory), which is exactly what you want, because you should not be running composer install on a shared account with capped memory and process limits.

The single most common cause of a broken upgrade is skipping the backup-and-staging step because the update "looked small." LaraClassified point releases often include silent schema changes and cache-format bumps. The safe path treats every upgrade as reversible: capture a complete snapshot, rehearse the upgrade on a disposable copy, then apply it to production only after the copy works. The sections below build that path with account-level tools only.

Full backup before you touch a single file

A LaraClassified backup has exactly two parts, and both must be captured at the same moment so the file version matches the database version. Do the file backup first, then immediately export the database.

Files. In cPanel open File Manager, navigate to the application root (commonly /home/USER/public_html or a subfolder like /home/USER/classified), select all contents, and use Compress to build a single archive named with the date, for example laraclassified-files-2026-09-27.zip. Move that archive out of the web-accessible tree into /home/USER/backups/ so it can never be downloaded by a visitor. In DirectAdmin the equivalent is the File Manager Add to Archive action, followed by moving the ZIP above public_html. Pay special attention to preserving your existing .env, the storage/ directory (which holds uploaded classified images and generated thumbnails), and any custom theme or language edits.

Database. Open phpMyAdmin, select the LaraClassified database, and use the Export tab. Choose the Custom method so you can enable Add DROP TABLE and set the output to a compressed .sql.gz file. Compression matters because the threads and pictures tables on an active classifieds site grow quickly and a plain SQL dump can exceed the browser download timeout. Save this next to your file archive. If your host provides JetBackup or the cPanel Backup Wizard, generate a full account backup as well, but do not rely on it as your only copy; a manual, dated pair gives you a known-good restore point you control.

Record two facts in a text note before proceeding: the current LaraClassified version (visible in the admin footer or in config/app.php) and the active PHP version shown in cPanel MultiPHP Manager or DirectAdmin. Rollback depends on returning to these exact values.

Stage the upgrade on a subdomain clone

Never test an upgrade on the live domain. Build a throwaway clone on a subdomain, upgrade it, and confirm it works before repeating on production. This is the step that turns a scary upgrade into a routine one.

Create a subdomain in cPanel Domains → Create A New Domain (or DirectAdmin Account Manager → Domain Setup / Subdomain Management), for example staging.example.com, pointing to a fresh directory such as /home/USER/staging. Copy the production files into it: extract your backup ZIP there, or use File Manager to copy the live directory. Then create a second database and database user in cPanel MySQL Databases, import your .sql.gz dump into it through phpMyAdmin, and edit the staging .env so APP_URL, DB_DATABASE, DB_USERNAME, and DB_PASSWORD point at the staging values. Update the APP_URL to the subdomain so generated links resolve correctly.

Set the staging directory to the PHP version required by the new LaraClassified release using the PHP Selector — a major upgrade often raises the minimum, so verify the required extensions (bcmath, gd or imagick, fileinfo, intl, mbstring) are enabled there. If the new release ships a larger installer, raise limits for that folder only by creating a .user.ini in the staging root:

memory_limit = 256M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M

Now run the vendor's documented upgrade against staging: upload the new release files over the staging directory, keeping your staging .env and storage/ intact, then trigger the built-in updater. LaraClassified exposes a web installer at /install and an upgrade route; visit https://staging.example.com/upgrade (or the path named in the release notes) which applies the pending database migrations and rebuilds config and route caches. Clear the compiled caches by deleting the contents of bootstrap/cache/ and the storage/framework/cache/, views/, and sessions/ folders through File Manager if the admin still serves stale layouts. Log into the staging admin, post a test listing, upload an image, run a search, and confirm payment settings still load. Only when staging is clean do you touch production.

Apply to production and keep rollback ready

Before uploading anything to the live site, enable maintenance mode so visitors and search engines do not hit half-migrated pages. LaraClassified has an admin toggle under Settings → General → Maintenance; if you cannot reach the admin during the change window, drop a temporary rule at the top of the production .htaccess to hold traffic:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !=YOUR.PUBLIC.IP.HERE
RewriteRule ^(?!maintenance\.html$).*$ /maintenance.html [R=302,L]

That routes everyone except your own IP to a static maintenance.html while you work. Confirm your file and database backups from the first section are present in /home/USER/backups/ — this is your rollback package. Upload the new release files over production exactly as you did on staging, preserving the live .env and storage/. Set the production directory to the same PHP version you validated on staging using MultiPHP Manager. Run the /upgrade route so the migrations execute against the production database, then clear bootstrap/cache/. Remove the .htaccess maintenance block and disable maintenance mode.

If anything fails — a 500 error, missing tables, a white admin screen — do not attempt fixes on the live database. Roll back immediately. Delete the upgraded production files, extract your dated file archive back into the application root, then in phpMyAdmin drop the current database tables and import your .sql.gz snapshot to restore the pre-upgrade schema and data. Revert the PHP version to the value you recorded. Because the file archive and the database dump were captured together, the restored site returns to a consistent working state. Investigate the failure on staging, where a broken database costs nothing. When troubleshooting, read storage/logs/laravel.log and the local error_log in the application directory through File Manager rather than guessing — Laravel writes the exact failing migration or missing extension there. The same disciplined backup-first, restore-cleanly approach applies to any script; our MailWizz database maintenance guide covers complementary phpMyAdmin repair techniques worth knowing before an upgrade window.