Support and Updates

Support resolves issues faster when the email contains the product, domain, and the step where everything stopped. The phrase "it does not work" without a URL and log becomes a lottery. An admin screenshot is more useful than emotion; a Fatal Error line from the log is more useful than a screenshot of a white screen.

Below is how to write requests and update without killing config and user files. For timeframes and scope, see SLA.

What to attach to a request

• Microscript product name and archive version if it is shown in the package or account.
• Page address (URL) and what you expected to see.
• Steps: "opened /install, entered database details, clicked next".
• Error text from the browser or from error_log / PHP-FPM log. No database or root passwords.
• PHP version and hosting type: shared Beget/Timeweb, VDS with Nginx, local MicroServer.

Do not send a full 200 KB phpinfo "just in case". The PHP branch and module list are enough when the issue is requirements. Requirements: PHP/MySQL.

What to check before a ticket

1. Database connection: MySQL error.
2. HTTP 500 / white screen: 500 error.
3. Uploads and permission denied: chmod.
4. Cron does not run: cron.
5. Environment suitability: hosting / VDS.

Half of emails are closed by these manuals without waiting for a reply. That is normal and not embarrassing.

Script update

Before replacing files:

• Database dump and uploads archive: backup.
• Copy of connection config and local changes.
• Understanding which folders the release must not overwrite: upload, custom, .env, according to readme.

A typical safe path: unpack the new release next to the current one, move config and user content, switch document root, or carefully copy files over while excluding user directories. After deployment, open the home page, account, one form writing to DB, one file upload, and payment if present.

If the update used "upload zip to root and confirm" in a panel, keep your own backup anyway. Provider autobackup does not always store what you need.

Access for investigation

If access is requested, create a temporary admin user, FTP/SFTP, or SSH read-only where possible. Change passwords after the work. Do not publish credentials in open threads.

Local reproduction

Many bugs are faster to catch on a copy: MicroServer, dump import: phpMyAdmin, host: *.loc. If it does not reproduce locally, write that in the ticket too; it is useful data.

Moves and migrations

Changing servers is not an "update", although people often mix them. Checklist: migration, dump: MySQL migration. SSL after migration: SSL.

After support replies

Do what was requested once and carefully: php-cli path, config line, PHP version. If it does not help, send a new log with a timestamp after the change. "Still not working" without a new fact stretches the chain again.

Hardware uptime and alerts like "site went down at night" are better kept on your side: monitoring. Clean installation if you choose to reinstall: installation.

How not to write

• "Nothing works urgently!!!!" without a URL.
• A full desktop screenshot where the error text is unreadable.
• Root password in the email subject.
• Five unrelated product questions in one paragraph.
• A year-long quoted thread with no summary of what is broken now.

Short and factual messages are read faster. Emotion is allowed, but facts are still required.

Update: common failure

New files were uploaded over the old ones, config.php was overwritten, and the site showed Access denied / 500. Treatment: restore the config from backup, do not recreate the database. That is why config is copied separately before unpacking the archive. Permissions after uploading from root on VDS: chmod.

The second failure is updating code while forgetting SQL migrations from the release readme. Logs mention missing columns. Read the package changelog before clicking "replace all".

Channels and language

Write to the channel specified for your product/license. Changing the topic every two messages splits the ticket. One incident, one correspondence frame. SLA documents: SLA.

When server access is requested

Prepare an SSH key or temporary password, site path, database name, and admin-panel access. You do not always need to give the whole hosting panel password if SFTP and admin access are enough. Revoke access after the ticket closes, especially if it is shared root.

On shared hosting, temporary FTP and an error screenshot may be enough. On VDS without FPM logs, a 500 investigation is nearly blind: 500 error, stack: Nginx.

Parallel changes

While a ticket is being handled, do not change the PHP version, migrate DNS, or upload another "maybe it fixes it" archive without saying so. Otherwise we are fixing a different state. If you must do it, write: "in parallel I changed PHP to 8.3".

After closure

Confirm that the ticket scenario now passes. If it was closed and failed again an hour later, send the new fact and log, preferably in the same thread. Monitoring helps catch regressions: uptime. A backup after a successful fix is a good rollback point: backup.

Mail, SSL, and hosting are often adjacent manuals, not bugs: SSL, hosting, cron. Clean installation: installation.

If you attach contradictory facts, for example "PHP 8.2" in the email and a phpinfo screenshot with 7.4, we first verify the environment and then the code. Version selectors in Beget/Timeweb/ISPmanager can be changed on the wrong domain. State which URL the phpinfo belongs to. For local bugs, say that it is MicroServer/OpenServer, not production: local server. A reproduction dump should omit unnecessary personal data, and admin passwords should be changed after import. Database and 500 errors should be checked against manuals before a ticket if the log already makes the cause obvious: MySQL, 500. Work scope and timing: SLA.