# Static Site Limitations

This document describes WordPress features that cannot be fully replicated
in a self-contained, static HTML/CSS/JavaScript website. For each feature
it explains what the original WordPress site did, what the static version
does instead, and what alternatives exist if the full behaviour is required
in the future.

---

## 1. Contact Form — Server-Side Submission

### Original WordPress behaviour
The contact form was powered by the **Contact Form 7** plugin. On
submission, the plugin handled the request server-side: it validated
the input, applied CSRF protection, and delivered the message to
`info@medicheks.com` via WordPress's configured SMTP mailer. The visitor
received an on-page confirmation message without leaving the site.

### Static behaviour
The static form collects the visitor's name, email, and message, then
constructs a `mailto:` URI and assigns it to `window.location.href`.
This opens the visitor's default email client with all fields pre-filled,
allowing them to review and send the message themselves.

### Limitations
- **Requires a configured email client.** Visitors who use webmail only
  (Gmail in a browser, Outlook Online, etc.) and have no desktop mail app
  configured will see nothing happen, or will be prompted to choose an app
  they do not have.
- **No server-side delivery confirmation.** The site cannot know whether the
  visitor actually sent the email or closed their mail client.
- **No spam filtering.** Contact Form 7 includes honeypot and reCAPTCHA
  support; the static fallback has neither.
- **No file attachments or conditional logic.** Advanced form features are
  not available via `mailto:`.

### Recommended alternatives

| Solution | How it works | Effort to integrate |
|---|---|---|
| **[Formspree](https://formspree.io)** | Change `<form action="https://formspree.io/f/{id}">` — submissions are delivered to your inbox via Formspree's servers | Low — change one HTML attribute |
| **Netlify Forms** | Add `netlify` attribute to `<form>` — works automatically when hosted on Netlify | Low — requires Netlify hosting |
| **[EmailJS](https://www.emailjs.com)** | Call `emailjs.send()` from JavaScript — no server code required | Low-Medium — add JS SDK and template |

---

## 2. Newsletter Subscription

### Original WordPress behaviour
A newsletter subscription input (likely powered by a Mailchimp for WordPress
plugin or a WooCommerce extension) collected visitor email addresses and
stored them in the WordPress database, then forwarded new subscribers to a
Mailchimp audience list via the plugin's API integration.

### Static behaviour
The newsletter input field is present in the footer to preserve the visual
layout. It displays a notice informing visitors that the subscription feature
is not currently active. Submitting the field has no effect.

### Limitations
- Email addresses entered into the field are not collected or stored.
- There is no server endpoint to receive or forward subscription requests.
- Visitors cannot opt in to communications through the static site.

### Recommended alternatives

| Solution | How it works | Effort to integrate |
|---|---|---|
| **Mailchimp embedded form** | Mailchimp generates a self-contained `<form>` snippet that posts directly to Mailchimp's servers — no backend required | Low — replace field with Mailchimp snippet |
| **[ConvertKit](https://convertkit.com) inline form** | ConvertKit provides a JS-embeddable inline form with the same zero-backend approach | Low — paste embed code |

Both options are free at low subscriber counts and require no server-side
changes to the static site.

---

## 3. Blog / Dynamic Content

### Original WordPress behaviour
The WordPress site included a blog section where posts could be created,
edited, scheduled, and published through the WordPress admin dashboard.
Posts were stored in the MySQL database and rendered dynamically on request,
with category/tag archives, pagination, and RSS feeds generated automatically.

### Static behaviour
No blog section has been included in the static conversion. All content is
hard-coded HTML. There is no CMS backend, no database, and no mechanism to
add or update posts without editing `index.html` directly.

### Limitations
- Adding new content requires a developer to modify source files and
  redeploy the site.
- No post archives, categories, tags, RSS feed, or pagination.
- No search functionality across posts.
- Non-technical editors cannot update content without developer assistance.

### Recommended alternatives

| Solution | Approach | Effort |
|---|---|---|
| **Headless CMS (Contentful, Sanity, Prismic)** | Authors edit content in a CMS dashboard; a build step generates static HTML from the CMS data | Medium — requires a build pipeline |
| **Static site generator (Eleventy, Hugo, Astro)** | Markdown files are the source of truth; the generator produces static HTML at build time | Medium — restructure project around the generator |
| **Simple hosted blog** | Use a free Medium or Substack blog and link to it from the static site | Low — no code changes |

---

## 4. Admin Dashboard / Content Management

### Original WordPress behaviour
Every piece of site content — headings, body text, images, team member
details, service descriptions — was stored in the WordPress database and
editable via the WP Admin panel (`/wp-admin`). Non-technical team members
could log in and update content through a visual interface without touching
any code.

### Static behaviour
All content is hard-coded directly into `index.html`. Updating any text,
swapping an image, or adding a team member requires opening the HTML file
in a text editor, making the change, and re-uploading the file to cPanel.

### Limitations
- No visual editor for non-technical users.
- Risk of accidental markup breakage during manual edits.
- No revision history or rollback capability.
- No multi-user editing with permissions.

### Recommended alternatives

| Solution | Approach | Effort |
|---|---|---|
| **Headless CMS** | Connect Contentful, Sanity, or DatoCMS; content editors update the CMS; a CI/CD step rebuilds and deploys the static files | Medium-High |
| **Static site generator with data files** | Store content in YAML/JSON files; Eleventy or Hugo reads them at build time and generates HTML — editors update data files instead of HTML | Medium |
| **Git-based CMS (Netlify CMS / Decap CMS)** | A UI layer over a Git repository; editors commit content changes through a browser interface without touching code | Medium — requires Git hosting and Netlify or similar |

---

## 5. SEO Plugin Features

### Original WordPress behaviour
The site likely used **Yoast SEO** or **RankMath**, which provided:
- Dynamic XML sitemap generation (`/sitemap.xml`, `/sitemap_index.xml`)
- Automatic JSON-LD structured data (Organization, LocalBusiness,
  BreadcrumbList schemas)
- Open Graph and Twitter Card meta tags on every page
- Canonical URL management
- Breadcrumb navigation with schema markup

### Static behaviour
The static `index.html` includes hand-coded `<meta>` tags for title,
description, Open Graph, and Twitter Card. JSON-LD for Organization and
LocalBusiness is included as a `<script type="application/ld+json">` block
in the document `<head>`. A static `sitemap.xml` can be created manually
and placed in the project root.

### Limitations
- The XML sitemap must be created and updated manually whenever the
  structure of the site changes.
- JSON-LD is static; it will not update automatically if business details
  (address, phone, opening hours) change — `index.html` must be edited.
- No per-page Yoast analysis or SEO score dashboard.

### Impact assessment
For a **single-page site**, the impact is minimal. Yoast's main advantage
is per-page optimisation across large multi-page sites. A well-crafted
static `<title>`, `<meta name="description">`, and JSON-LD block on a
single-page site achieves equivalent search-engine visibility. Ensure the
following are present and accurate before going live:

```html
<title>Medicheks Colombo — Medical Centre, Colombo 05</title>
<meta name="description" content="…">
<meta property="og:title" content="…">
<meta property="og:description" content="…">
<meta property="og:image" content="…">
<link rel="canonical" href="https://www.medicheks.com/">
```

---

## 6. Analytics

### Original WordPress behaviour
Google Analytics was integrated via the **MonsterInsights** plugin, which
injected the GA tracking script automatically on every page and provided a
reporting dashboard inside the WordPress admin panel.

### Static behaviour
No analytics script is included in the static site by default. This is a
deliberate decision: adding Google Analytics (GA4) without a corresponding
cookie consent mechanism would likely violate GDPR/PECR in most jurisdictions
and Sri Lanka's Personal Data Protection Act.

### Limitations
- Without a tracking script, there is no visitor data, traffic source
  information, or conversion tracking.
- There is no equivalent to the MonsterInsights in-WordPress dashboard.

### Recommendation
Add GA4 tracking **after** implementing a cookie consent banner. The
minimum required steps are:

1. **Register a GA4 property** at [analytics.google.com](https://analytics.google.com)
   and obtain a `G-XXXXXXXXXX` measurement ID.

2. **Add the gtag.js snippet** to the `<head>` of `index.html`:

   ```html
   <!-- Google Analytics 4 — add only after consent banner is in place -->
   <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
   <script>
     window.dataLayer = window.dataLayer || [];
     function gtag(){ dataLayer.push(arguments); }
     gtag('js', new Date());
     gtag('config', 'G-XXXXXXXXXX');
   </script>
   ```

3. **Implement a cookie consent banner** before activating the snippet.
   Lightweight options include [CookieYes](https://www.cookieyes.com),
   [Osano](https://www.osano.com), or a custom banner that sets a consent
   cookie and conditionally loads the GA snippet.

4. **Verify deployment** using the GA4 DebugView and browser developer tools
   to confirm events are firing correctly.

---

*Last updated: July 2025*