This situation comes up more often than teams admit: a site build is ready, the client host is restrictive, FTP is slow, and there is no SSH access or useful file manager. In that setup, uploading one ZIP archive and extracting it on the server can be the simplest workable option. The important part is choosing the right PHP approach and not turning a quick fix into an avoidable risk.
If you only need to unpack a release bundle, theme, static export, or image set, the current best default is to use PHP's built-in ZipArchive support first. A browser-based helper can still be useful, but it should be the fallback, not the starting point.
Start with PHP's built-in ZipArchive
On a modern PHP host, ZipArchive is usually the cleanest answer. It is part of PHP's ZIP support, it is well documented, and it lets you keep the extraction logic very small and readable.
<?php
$archive = __DIR__ . '/site-release.zip';
$target = __DIR__ . '/release';
if (!is_dir($target) && !mkdir($target, 0755, true)) {
exit('Could not create target folder');
}
$zip = new ZipArchive();
if ($zip->open($archive) === true) {
umask(0022);
$zip->extractTo($target); // Use "." to extract into the current folder
$zip->close();
echo 'Archive extracted';
} else {
echo 'Could not open the ZIP archive';
}
That is enough for many shared-hosting deployments. It creates a destination folder if needed, opens the archive, extracts it, and closes it cleanly. If you truly want to extract into the current folder, extractTo('.') works, but only do that when you understand the archive structure and are sure it will not dump files into the wrong place.
The umask(0022) line is worth keeping. PHP's manual notes that extracted files and directories otherwise get the widest possible access by default. In other words, permissions are not a detail to leave to chance when you are unpacking directly on a live server.
Check ZIP support before debugging the wrong problem
If ZipArchive is unavailable, the issue is usually server configuration rather than bad PHP code. On Linux, PHP needs ZIP support installed or compiled in. On Windows, the current PHP manual notes that as of PHP 8.2, php_zip.dll must be enabled in php.ini.
If you do have command-line access, a quick check is php -m | grep -i zip. Without SSH, most hosting panels also show enabled PHP extensions. This matters for operations teams and agencies because it tells you when to stop rewriting scripts and start talking to the host or changing the deployment method.
Fallback: use a browser-based unzipper only when you need it
The original article pointed to ndeet/unzipper, and the core idea is still useful. The project is designed for exactly the no-shell scenario: upload unzipper.php, place it in the same directory as your archive, open it in a browser, and extract there. If you are working on a basic shared host with only FTP and PHP, that can save a lot of time compared with pushing thousands of individual files.
But this is where the older advice needs an update. The GitHub repository describes The Unzipper as a beta, and the latest tagged release on GitHub is version 0.1.1 from January 5, 2018. That does not mean it is broken. It does mean you should treat it as a short-lived utility, not as permanent infrastructure.
Practical rule: use a browser-based extractor for a one-off recovery, handoff, or constrained client environment. Do not leave it on the server after the job is done, and do not normalize it as your deployment process.
A safer extraction checklist
- Extract into a dedicated folder first instead of directly into the live web root. That gives you a chance to inspect the result before switching over.
- Make sure the destination is writable by the PHP process. Many failed extractions are really permissions problems.
- Use archives you trust. Once files are extracted on a web server, this is no longer just a file-transfer problem.
- Delete the uploaded archive and any helper script after extraction. Leaving them behind adds risk and confuses the next handoff.
- Keep a rollback path. Even a small site benefits from having the previous version available if the extracted release is incomplete.
For agency teams, one extra point matters: avoid extracting blindly into production when you are not sure how the ZIP was packaged. A nested folder structure, wrong document root, or stray configuration file can turn a five-minute task into an outage. A quick check in a staging folder is usually cheaper than fixing a rushed live deploy.
When this should become a real process
If you are doing this repeatedly, the issue is no longer “how do we unzip with PHP”. The issue is that deployment is still manual. Repeatedly uploading ZIP files to production is usually a sign that the delivery workflow needs one small layer of operational structure: clean packaging, consistent permissions, a safe release path, and a simple rollback option.
That does not require a giant DevOps rebuild. It usually needs a practical setup that fits the host, the team, and the budget. If you want help turning ad hoc uploads into a safer website handoff or maintenance workflow, Greg can help put that process in place without overengineering it.
Need help with this kind of work?
Need a safer deployment handoff? Get in touch with Greg.