WordPress and hosting

This FAQ is based on recurring support situations around WordPress, PHP, hosting, mail, security and Linux maintenance.

It is meant to help you recognise a problem quickly, understand likely causes, find the right diagnostic tools and choose realistic next steps. At all2all, we prefer a durable WordPress practice: staying close to WordPress core, using few plugins, choosing maintained themes, relying on open standards, running on modern Debian infrastructure and planning gradual maintenance before emergency repairs become unavoidable.

A PHP update broke the site: where should I start?

Typical symptoms are a white page, an HTTP 500 error, an inaccessible backend, broken menus, PHP errors or pages that no longer load. The usual causes are an old plugin, an obsolete theme, an old page builder, custom legacy code or a PHP extension that is no longer supported.

Start with the Apache/PHP error log, often in logs/error_log or ~/logs/error_log. You can read it through FTP/SFTP, the file manager or Virtualmin. On the shell, use:

tail -50 logs/error_log
tail -f logs/error_log

You can also temporarily enable WordPress debugging in wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Errors will then appear in wp-content/debug.log. The log usually names the plugin, theme or function that fails. Possible fixes include disabling plugins temporarily, switching back briefly to an older PHP version, replacing abandoned components, updating the theme or moving an old EOL hosting account to a recent Debian server with multiple PHP versions.

WordPress reports an obsolete PHP version: what does it mean?

WordPress may warn that the current PHP version is obsolete, no longer receives security updates or is rejected by newer plugins. This usually means the site is still on an old hosting platform, the website itself is very old, or some plugins and themes are not ready for current PHP versions.

Check the current PHP version, the age of the server, plugin update dates and theme compatibility. Recent all2all servers can usually provide several maintained PHP versions side by side, for example PHP 8.1, 8.2, 8.3 and 8.4. That makes transitions easier: test first, update components, replace obsolete code, then switch the production version.

The site has become slow: what should I check first?

Frequent causes are too many plugins, heavy page builders, large images, real-time statistics, complex cache layers, external synchronisations or expensive SQL queries. Every plugin adds code, database calls, background tasks and sometimes external network requests.

Look at what changed recently: a new builder, analytics plugin, security extension, WooCommerce add-on or image tool can be enough. Check PHP logs for repeated warnings, disable unnecessary plugins, simplify the theme, optimise images and use a simple cache. The most maintainable WordPress sites are often close to WordPress core, with few dependencies and a maintained theme.

A WordPress form no longer sends mail: how do I diagnose it?

A form may appear to work while no message arrives, or messages may land in spam. The usual causes are mail() without proper authentication, incorrect SPF/DKIM/DMARC, an old form plugin, SMTP refusal or modern anti-spam filtering.

Check the SMTP settings, mail DNS records, form plugin and possible mail logs. Prefer authenticated SMTP over unauthenticated PHP mail. If mail for the domain has moved away from all2all, tell support so local mail routing can be disabled on our side; otherwise messages generated on the server may still be delivered locally instead of to the external provider.

The site shows a white screen: what is the likely cause?

A white screen is usually a fatal PHP error hidden from the browser. Look first at logs/error_log and, if enabled, wp-content/debug.log. Temporarily renaming wp-content/plugins/ or the active theme directory can help confirm whether a plugin or theme is responsible.

Possible fixes are disabling plugins one by one, switching to a default theme, adjusting the PHP version temporarily or replacing obsolete components. Avoid random reinstallations before reading the logs; they often contain the exact failure.

The site was hacked or redirects: what should I do?

Signs include strange redirects, spam, unknown administrator accounts, modified pages, high CPU use, Google Safe Browsing warnings or unknown files. Contact support@all2all.org first: we can help assess the situation, protect the shared platform and, when needed, create a forensic archive snapshot.

The server infrastructure is managed by all2all; the website, plugins, themes and application code installed in the hosting account remain the customer’s responsibility. In practice, all2all often does more than a minimal suspension: we can put the site in a protected state, inspect logs, identify suspicious processes or files and contact the responsible persons. Cleanup may be done by the customer, a webmaster, or by all2all as paid intervention when availability allows.

If personal data may have been exposed, if fraud or phishing occurred, or if the incident has legal consequences, reporting may be necessary. A forensic archive and a short technical assessment can help document IP addresses, modified files and the likely timeline.

Database connection error: what should I verify?

The message “Error establishing a database connection” usually points to MariaDB/MySQL being unavailable, wrong credentials in wp-config.php, a missing database, corruption or a plugin overloading SQL.

Check the database name, username, password and host in wp-config.php. In Virtualmin, verify that the database and MySQL user still exist. If the error appeared after migration, ensure wp-config.php uses the new database name, username, password and host. Then inspect PHP and database logs before restoring anything.

Image uploads fail: which limits or permissions matter?

Upload errors can come from wrong permissions in wp-content/uploads/, a full quota, PHP limits, image optimisation plugins or cache. Check the upload directory, disk usage and error_log first.

Possible fixes include correcting ownership and permissions, freeing disk space, increasing relevant PHP limits or temporarily disabling image optimisation and cache plugins.

SSL or HTTPS stopped working: what should I inspect?

If the browser shows an insecure connection, an expired certificate or broken HTTPS redirects, check DNS, Virtualmin SSL settings, Let’s Encrypt logs and HTTP to HTTPS redirects. Mixed content can also break the padlock when a page still loads images, scripts or styles over plain HTTP.

When a website has several domain names or aliases, every name included in the certificate must still be active and point to the server. One inactive alias can prevent the whole Let’s Encrypt renewal. Renew the DNS names, remove them from the certificate configuration, or delete the alias domain via Virtualmin if it is no longer needed.

Why does WordPress ask for FTP during updates?

When WordPress asks for FTP credentials to install updates, it usually cannot write files directly. The common causes are wrong file ownership, incorrect permissions or a mismatch between the FTP/SFTP user and the PHP/Apache execution mode.

Check ownership and permissions in wp-content, and avoid mixing files created by different users. Correcting ownership is usually better than giving overly broad permissions.

WooCommerce mails are missing: where can delivery fail?

WooCommerce order mails can fail because SMTP is broken, SPF/DKIM are wrong, a mail plugin is outdated, a queue is stuck or remote providers filter the message. Test ordinary WordPress mail, SMTP authentication and WooCommerce-specific mail settings.

For shops, authenticated SMTP and correct domain records are strongly recommended. Newsletters and bulk mail should not be sent through ordinary shared SMTP.

Some pages or links are broken: how do I rebuild them?

Broken pages, 404 errors, strange permalinks or missing menus often come from .htaccess, permalink settings, cache, SEO plugins or incomplete migration. Regenerate permalinks in WordPress, check .htaccess, empty caches and inspect the Apache error log when you get an HTTP 500 error.

Why do we recommend WordPress sites with few plugins?

Many WordPress sites become hard to maintain after years of accumulated plugins, builders, widgets, premium extensions and CSS/JavaScript layers. One abandoned plugin can block PHP upgrades, security updates or the whole site.

A sober WordPress setup, close to core, with maintained themes and a small number of necessary plugins improves security, performance, maintainability and long-term access to content.

Why are external backups important?

Hosting is not the same as an independent backup strategy. A plugin can delete data, a hack can contaminate local backups, and a wrong change can be replicated before anyone notices.

Keep separate backups, ideally outside the hosting account, with several historical versions. This makes recovery possible even when the hosting account itself is compromised or full.

Can I simply restore an old backup?

Not always. An old backup can already contain the malware, vulnerable plugins or obsolete configuration that caused the problem. Before restoring, check the real backup date, whether the site was already infected, and whether the software in the backup can run safely on current PHP.

Often the backup must be analysed, cleaned, updated and restored gradually rather than copied back blindly.

Why are logs so important?

Many WordPress problems look mysterious until the logs are read. Logs can reveal the plugin name, PHP line number, SMTP error, permission problem or exact incompatibility.

The most useful files are usually logs/error_log and wp-content/debug.log. Before reinstalling or rebuilding a site, read the logs, identify the cause and fix the failing component methodically. A few log lines can save hours of guessing.