Why an extension installer should have a preview

A preview gives an installer a chance to explain the integration it intends to perform. This matters on a billing platform where core files may already contain local changes or hooks from another extension.

A refusal is sometimes the correct result, not a reason to disable the checks.

Review the intended files

Identify which application files, templates and helper classes the package needs. Check how the installer recognizes code already integrated and how it handles an unsupported version.

A shared filename is not proof that its contents match the package author's expected baseline.

Preserve custom work

If an anchor cannot be found, compare the included patch with the actual file. Keep local changes visible during that review rather than replacing the whole file with a copy from another release.

The person maintaining the custom installation should understand which behaviour each added hook enables.

Check more than the first run

A repeatable installer should recognize a completed integration. Where two packages share neutral hooks, installing one should not duplicate the other's additions.

Check syntax before applying PHP changes and retain backups of the files actually changed. The backup location should be recorded privately with the deployment.

Validate the application afterward

Successful integration is not complete functional testing. Check ordinary checkout and invoice handling as well as the extension's own screens and permissions.

The installation preparation guide explains the broader process. Use the downloaded package's README for exact commands and supported versions. A preview reduces uncertainty, but it does not remove the need to understand the application you are changing.