Start with the files. Finish with a working website.

Do not upload or edit the package immediately after downloading it. First confirm what the product requires and create a safe working copy.

Before installation, review the product page and any README or documentation file for required technology. A product may require some combination of:

When a requirement is unclear, ask before purchasing or deploying the product.

1. Download the complete archive using the product or protected order link.
2. Save the original ZIP in a secure backup location.
3. Create a new folder for the working project.
4. Extract every file and folder into that location.
5. Confirm that the extraction completed without an error or missing-file warning.
6. Open the README, documentation, or installation file before changing the source.

Do not upload the ZIP itself unless the product documentation specifically instructs you to use an installer that accepts ZIP packages.

File names vary by product, but a package may contain:

The product description is the authoritative list of what should be included. Demo images or third-party services may be shown in a preview without being licensed for production use.

Follow the product-specific installation instructions. A typical server-based template uses this sequence:

1. Prepare a local or staging environment.
2. Create the required database when applicable.
3. Import the supplied schema or run the documented migrations.
4. Copy or upload the project files while preserving the folder structure.
5. Create the local configuration file from the supplied example.
6. Enter database, base URL, email, or service settings.
7. Apply the required writable-folder permissions.
8. Open the documented entry page and complete any installer steps.
9. Remove or protect installation files when instructed.

Static HTML products may require only file upload and path verification. Framework or application products can require dependencies, command-line tools, build steps, environment files, or database migrations.

Test the unmodified product before adding custom features. This establishes whether the original package works in your environment and makes later problems easier to isolate.

• Set the correct public base URL or application URL.
• Configure database credentials outside publicly served files when supported.
• Change default administrator credentials immediately.
• Set the production environment or debug mode correctly.
• Configure the site name, tagline, branding, email, and timezone.
• Use HTTPS for production websites and secure cookies where supported.
• Review file permissions and remove unnecessary write access.
• Confirm error logs are available but not publicly downloadable.
• Use test or sandbox payment credentials until checkout is verified.
• Back up the files and database before major configuration changes.

Make one category of changes at a time and test after each group. A practical order is:

1. Site name, logo, colors, and typography.
2. Page copy, navigation labels, and contact information.
3. Images, icons, videos, and other media.
4. Products, services, categories, or database content.
5. Layout adjustments and component styling.
6. Forms, email, payments, maps, analytics, and APIs.
7. Custom features and structural code changes.

Use version control or dated backups so a broken change can be compared and reversed. Keep a short record of customized files, database changes, and external integrations for future maintenance.

Preview media may be supplied for demonstration only. Review the package credits and third-party licenses before using any image, font, icon, video, logo, or brand asset in production.

Compress media for the web, provide meaningful alternative text, and avoid placing private or licensed client assets in public sample files.

Complete a launch review on the production environment, not only on the local computer.

• Open every public page and administrator page you intend to use.
• Test navigation, buttons, downloads, filters, forms, and search.
• Verify mobile, tablet, laptop, and large-screen layouts.
• Test current versions of the browsers your audience is expected to use.
• Confirm database writes, emails, uploads, and protected files.
• Use test transactions before enabling live payment credentials.
• Confirm success, failure, cancellation, and expired-access states.
• Check titles, descriptions, canonical URLs, robots settings, and social previews.
• Enable HTTPS and remove public development tools, installers, test files, and debug output.
• Create a full file and database backup before announcing the launch.

Never overwrite a customized production website with a new template archive without comparing the versions. An update can replace your code, settings, content, or database changes.

1. Back up the production files and database.
2. Read the new version notes and changed-file list.
3. Extract the update into a separate folder.
4. Compare the clean old version, your customized version, and the new version.
5. Apply required database migrations in a test environment first.
6. Merge the update into a staging copy rather than overwriting production.
7. Retest every affected page, form, integration, and administrator action.
8. Deploy only after the staging version is stable and another backup exists.

Product purchases do not automatically promise every future update. Review the individual product page for the current version and available update information.

When troubleshooting, return to a clean extracted copy and reproduce the problem with the fewest possible changes. This helps determine whether the cause is the original package, the environment, configuration, or a later customization.

A complete support request is easier to investigate. Include:

• The product name and version.
• The order number when the product was purchased.
• The exact page, file, feature, or installation step involved.
• The complete error message and relevant log entry.
• The steps needed to reproduce the problem.
• Your platform, software, browser, PHP, database, or hosting version.
• Whether the issue occurs in a clean unmodified copy.
• A screenshot that does not expose private information or credentials.

Support does not require your PayPal password, complete card number, private API secret, database password, or administrator password. Remove those details before sharing logs or screenshots.