| Server requirements | PHP + database, usually exposed admin/login routes. | Static output works on basic hosting. Server rendering or an API needs a supported runtime. | Ordinary static file hosting; no app server needed. |
|---|
| Main advantage | Familiar editor and an existing site you may already own. | Rich interactions, reusable components and complex public catalogs. | Few moving parts; quick delivery and simple recovery. |
|---|
| Maintenance burden | Urgent catch-up, ongoing core/theme/plugin updates and PHP support. | Dependency reviews, lockfile, build security and tested rebuilds. More packages mean more to review. | Keep custom code correct, credentials safe and links current. |
|---|
| Local customer data | Often retained by forms, comments, shops and account plugins. | None required for a static build. Custom APIs and CRMs change the data flow. | None required. A custom form backend changes this assumption. |
|---|
| Important remaining risk | Known vulnerabilities, account takeover, database exposure and injected checkout links. | Build compromise, unsafe custom code, remote scripts and exposed frontend secrets. | Host/domain takeover, unsafe JavaScript and replacement of public files. |
|---|
| Practical verdict | Repair, replace or isolate. A newer payment plugin is not a repair plan. | Reasonable when the interaction justifies the upkeep; publish static files where possible. | A strong default for small showcases and hosted-checkout links. |
|---|