An update that went through is not yet a site that works. After every run we check that the home page opens, that the store takes orders and that nothing has disappeared — only then is the run closed.
A white screen after an update, a plugin conflict, a cart that stopped taking orders, PHP errors after the host changed the version. Intermittent bugs are a case of their own — the ones that refuse to repeat on demand. We look for the cause instead of working around the symptom.
A backup before every change on production, file change monitoring, malware removal and cleaning up after a break-in. For sites that ended up on warning lists, also getting them to a state where a review can be requested.
Finding the real cause of slow loading: hosting, uncompressed images, too many plugins, code added by a page builder. Plus migrations to newer PHP versions and moves to another server, with certificates and redirects.
After every run you know what was done and what needs a decision. No fixed hour packages — we bill what was actually done.
On the sites we look after, updates are run by a server cron rather than the WordPress scheduler that depends on traffic. After an update the automation walks the store the way a buyer would — home page, product page, cart, checkout — and stops before payment, so it creates no orders. File changes are watched with checksums.
We wrote it up in detail, including what broke along the way.
A plugin updated itself and broke the cart · the host changed the PHP version and the site threw an error · someone clicked something in the builder and the layout fell apart · the site takes fifteen seconds to load · unfamiliar code appeared in the files · the contact form stopped sending email.
Ongoing care of the agency's client sites: work on servers over SSH, updates, file change monitoring, malware removal, migrations to PHP 8.x. Communication in English, reporting to the agency, no contact with their end client.
The update system with a store check after each run was built here and works on the sites we look after. We also write our own plugins — three of them are public in the WordPress directory, with automated tests.
See the plugins →
The address and a description of the symptom are enough. If you have access to the admin panel and the hosting, send that too — it speeds up the diagnosis.
Within a few hours we write back: what is going on, how long the fix takes and what it costs. Where possible, a fixed price.
A one-off fix ends with a working site and an explanation of the cause. Ongoing care means runs with a report, and contact when something happens.
No. We take one-off fixes: a white screen after an update, a cart that stopped taking orders, PHP errors after the host changed the version. Ongoing care is a separate option, not a condition.
No. The address is enough — we will check what it runs on. We take over sites built with page builders, on off-the-shelf themes, on blocks and hand-coded.
With no fixed hour packages. We agree on scope and bill what was actually done, with a report after every run.
Yes, that is a common case. We start from the logs and the conditions the bug appeared in, and look for the cause instead of working around the symptom. Where needed, we add temporary logging to catch it next time.
Yes, and that is how it works here: a server cron runs the updates, then an automated check confirms the site and the store still work and sends a report. We wrote it up in notes from the implementation.
Send the address and describe what is happening. We will write back with what we see and how long the fix takes.
Describe your problem →Or by email: info@asymetria.com.pl