You read a security warning: a component running on your website has a serious vulnerability. A fix is available. You install the update, only to find a blank page, failed orders, or an admin account that can no longer sign in.
A website going down after an update creates two urgent needs: address the security flaw and restore the service. Technical assistance helps you assess both, including what needs testing and how recovery should work if a change fails.
Picture a store running a promotion. Its owner receives an update notification and clicks the button. Minutes later, the catalogue still loads, but payments fail. The original developer is difficult to reach, and nobody knows where the latest backup is kept.
This is an illustrative scenario, not a customer story or a report of a particular incident. It raises a question worth answering before launch: who will help when your finished website needs to change?
I am Dicky Ibrohim. I offer website development and repair services, with direct discussion of your business needs and the scope of the work. If this dilemma sounds familiar, we can discuss your website’s condition, the functions you need to preserve, and support after the repair.
Why security updates are harder to ignore in 2026
In April 2026, NIST reported that CVE submissions during the first three months of the year were almost one-third higher than in the same period of 2025. A CVE identifies a publicly recorded vulnerability. These submissions do not count hacked websites or establish that every website has the same flaws. NIST’s report on CVE growth.
A concrete example came on 21 October 2026, when PHP announced two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, capable of allowing unauthenticated remote code execution. The project urged users to update and issued further guidance on 23 October for a particular combination of settings. Official PHP security advisories.
For a business owner, the useful questions concern your own installation: are its components and settings affected, which update applies, and who will verify that it has been installed? Security news needs to lead to a decision about the system you actually run.
Why can an update break a website?
A website depends on several parts working together. An online store connects its shop application with themes, payment extensions, shipping services, a database, and server software. Changing one part can expose a mismatch elsewhere.
The PHP migration manual, for example, identifies backward-incompatible changes when moving from PHP 8.3 to 8.4 and calls for testing before switching production environments. That is an example of a version migration, rather than evidence that every security update breaks websites. PHP migration documentation.
There is also a difference between applying a fix within the same release branch and moving an application to another branch. The amount of adjustment can differ. The right choice depends on the security advisory, support lifecycle, and application. Selecting the highest version number does not settle those questions.
The table below illustrates possible lines of investigation. A symptom alone does not establish its cause.
| What you notice | What needs investigation | What matters to the business |
|---|---|---|
| A blank page or server error | Error logs, code compatibility, and configuration changes | Unavailable pages and access to administration |
| Products load, but checkout fails | Payment extension compatibility and order processing | Payment status, pending orders, and repeat attempts |
| Pages look normal, but forms stop sending | Message delivery integrations and processing after submission | Enquiries that were never recorded or delivered |
| The admin works, but stock or order status is wrong | Database changes and synchronisation between services | Reliable operational records before reopening the store |
Getting the homepage back is therefore only part of recovery. The functions that take payments and record transactions also need attention.
What should come first when the website is already down?
Record when the problem started, the last change, the symptoms, and which functions still work. Avoid piling on unrelated fixes: that can make the original cause harder to trace. Preserve relevant error logs and the data needed for investigation without posting sensitive records publicly.
If payments or order records cannot be trusted, work with the technical maintainer to restrict the affected functions temporarily. Give customers clear service information through a channel that still works. Whether to pause part of the store or the entire service depends on the failure and its risks.
The maintainer then needs to assess recovery options: repair the affected component, apply a compatible update, or reverse a specific change. The findings determine the order of work. Signs of compromise also require incident handling; installing an update does not prove that an attacker’s access has been removed.
For a WordPress website, you can start the discussion through my WordPress repair service. Where malicious code is suspected, website malware removal needs an appropriate scope of its own.
Rolling back may restore service. What could it bring back?
A rollback reverses a change and can be part of recovery. However, returning to a version with an unfixed vulnerability can restore its exposure too. That decision needs temporary risk controls and a plan to reach a supported version.
Support lifecycles matter here. The PHP project stops supporting branches that reach end of life. Any additional support from a distribution or service provider needs separate confirmation, including the fixes actually available. PHP’s supported-version policy.
For an online store, database recovery needs particular care. Suppose a backup was taken at 9 a.m. and new orders arrived afterward. Replacing the database with that earlier copy without reconciling the changes can remove those newer order records from the store, while the payment provider may still record the transactions.
Those times are illustrative. The point is to account for data that changed after the backup was created. A restore button should not be assumed to reconcile orders, stock, and payments across every service.
What should you test before the next update?
WooCommerce recommends a current backup and testing on staging, a separate environment for trying changes, before updating the live store. Its documentation also notes that some updates involve the database. Official WooCommerce update guidance.
Build a test plan around business needs, with a clear expected result for each check. For the store in our scenario, the owner and maintainer could agree to verify that:
- Customers can select the correct product and variant.
- Shipping charges, discounts, and order totals follow the store’s rules.
- A test payment produces the expected order status.
- Stock, notifications, and admin records reflect the test transaction.
- Customers can submit enquiries and receive the required confirmation.
Configure the test environment so experiments do not charge customers, send real notifications, or trigger shipments. Restrict access and use test data or appropriately masked records. A copy of your store can still contain sensitive information.
Before applying changes to the live website, agree on the maintenance window, who checks the result, and what would require stopping the rollout. Then recheck critical functions in the real environment. Testing reduces uncertainty, with conclusions limited to what was actually tested.
An AI-built website still needs someone who understands it
AI can help create layouts, generate code, and suggest fixes. The difficulty arises when its output goes straight into use without someone understanding the dependencies and consequences of a change.
The UK Home Office’s engineering standard, updated in March 2026, requires suitably qualified and experienced human review before AI-assisted output reaches production. It also retains testing and security expectations. This is a reference for that institution’s practice, rather than a legal requirement for every Indonesian business website. UK Home Office guidance on using AI.
In the store scenario, an AI tool might suggest a change that removes an error message. An engineer still needs to assess whether the change preserves payment records, stock behaviour, and correct access permissions. Removing the error message does not answer those business questions.
This does not mean every AI-built website is poor. Human-written software can also fail when testing and maintenance are missing. You need someone who understands the system, can explain the decisions, and has a defined responsibility for the work. For a closer look at commerce, read about AI-built online stores and engineering oversight.
Make support easy to find before you need it
During an outage, you should not have to guess who manages the server, who built the payment integration, or who holds recovery access. Establish a support route and divide responsibilities before an urgent situation occurs.
The UK Government’s voluntary Software Security Code of Practice includes informing customers about the level of support and maintenance provided. It offers a useful reference for discussing service agreements, without implying that your provider has been certified. GOV.UK software support guidance.
Ask for written answers to the following points before choosing a service:
| What to agree | Why it helps during a failure |
|---|---|
| Support contact, service hours, and escalation route | You know where to report the problem and when it can be handled |
| Responsibility for application and server updates | Tasks do not stall because each party assumes another is doing them |
| Testing and recovery scope | You understand which work is included and its limits |
| Support period, recurring fees, and additional work | You can budget for needs after the initial project |
| Access, documentation, licences, and handover procedure | A future maintainer has a practical basis for continuing the work |
A one-off build can still suit a business with its own technical maintainer ready to take over. Trouble arises when nobody is assigned, while the owner assumes help will always be available.
Changing maintainers also depends on the agreement, platform, and licences. Establish which access, data, documentation, and source code can be handed over. My article on website vendor dependency explains what to consider before commissioning a project.
Repair the existing site or commission a custom website?
If the failure comes from one component that remains supported, a targeted repair may be a reasonable choice. A rebuild becomes worth discussing when updates repeatedly get blocked, important components are no longer maintained, or the original design no longer supports your operations.
A custom website creates room to design functions around your business. For example, a store that approves orders before collecting payment needs that sequence preserved when an integration changes. I can help discuss that requirement within a development scope, including the functions to check at handover.
A ready-made platform may suit standard sales workflows and the management resources available to you. Compare functionality, recurring costs, data access, and support options. Custom systems also depend on components and services that need maintenance.
Source-code access for a new project follows its proposal and licence terms; it should not be assumed to be included automatically. Discuss handover or a change of maintainer before settling the design. If broader changes are needed, read about rebuilding a website that is difficult to update.
Work with Dicky Ibrohim on the problem your business faces
I help you discuss website problems directly, connecting technical choices with the functions your business needs. For an online store, the priority may be checkout and order recording. For a service business, it may be enquiries, bookings, or access for administrators.
From there, we determine whether the work calls for a repair, development of a specific function, or a rebuild. Scope, price, schedule, and further support needs are agreed before work starts. Support availability and response times follow the service agreement; do not assume that every project includes round-the-clock monitoring.
Separate the cost of technical work from recurring needs such as hosting, domains, licences, or other services in use. The purpose of assistance is to give you clearer decisions and a practical route to help, with responsibility defined by the agreed work. No service can guarantee that every future failure or vulnerability will be prevented.
You do not need to understand every error message to begin. Describe what changed and which function is now getting in the way of business. That gives us a useful starting point for discussing the work you need.
Frequently asked questions
Does a website crash after an update mean it was hacked?
Not necessarily. Compatibility, configuration, or data changes can cause failures. The change history and error logs need investigation. If there are signs of compromise, security investigation is needed alongside restoring functionality.
Should I disable every update to keep my store running?
Disabling all updates without a responsible maintainer can leave security fixes unapplied. Set an update policy based on risk and testing capacity, with someone monitoring advisories and handling failures. Any delay needs a reason, temporary risk controls, and a deadline.
Does technical support mean I must buy a monthly plan?
Support may cover a defined piece of work or ongoing maintenance, depending on your needs and the agreement. Establish who handles updates, when help is available, and which tasks cost extra. Support is not automatically included in every project.
Does an AI-built website need to be rebuilt?
AI use alone is not a reason to rebuild. First assess the code, access, components, critical functions, and maintainability. Targeted repairs may be sufficient; a rebuild becomes an option when the obstacles are more fundamental.
What should I send to start the conversation?
Share your website URL, visible symptoms, incident timing, recent changes, and affected functions. Mention available backups or hosting contacts if known. Your first message should contain a summary without passwords, access keys, or customers’ personal data.
