intotheeast-com-content/docs/bugs-and-fixes.md

Bugs & Fixes

Backlog of confirmed bugs with root cause analysis and implementation spec for the fix.

---

BUG-001 — New entry not visible after form submission

Status: fixed 2026-06-18
Reported: 2026-06-18

Symptom

After submitting a new post via /post, the entry page file is created correctly on disk but does not appear in the /tracker feed or in the Grav Admin panel until the cache is manually flushed.

Root cause

Grav's page-tree cache (cache/doctrine/) is not invalidated when add-page-by-form writes a new page to disk. The tracker template uses page.children, which Grav serves from cache — so the new child page is invisible until the cache is cleared.

Workaround (manual)

Run in terminal after each submission:

docker exec intotheeast_grav bash -c "cd /app/www/public && php bin/grav clearcache"

Fix spec

Wire cache-clear into the form process so it happens automatically on every successful submission.

Approach — custom Grav plugin event hook:

1. Create a small plugin user/plugins/cache-on-save/ with one event listener:
   • Listen on onFormProcessed
   • When the form name is new-entry, call $this->grav['cache']->deleteAll() (note: clear() does not exist on Grav\Common\Cache in Grav 1.7)
2. Enable the plugin in user/config/plugins/cache-on-save.yaml

This is the cleanest approach: it fires exactly once per successful submission, requires no changes to post-form.md, and works for any future forms too.

Alternative — disable page cache entirely:

Set cache: { enabled: false } in system.yaml. Simpler but degrades frontend performance; not recommended for production.

Files to create/modify

File	Change
user/plugins/cache-on-save/cache-on-save.php	New plugin, ~30 lines
user/plugins/cache-on-save/cache-on-save.yaml	Plugin manifest, enabled: true
user/config/plugins/cache-on-save.yaml	Runtime config, enabled: true

Acceptance criteria

1. Submit a new post via /post
2. Navigate to /tracker — the new entry is visible immediately, no manual cache flush needed
3. Grav Admin also shows the new page immediately

---

BUG-002 — Stale Twig cache after theme file changes

Status: fixed 2026-06-18
Reported: 2026-06-18

Symptom

After theme template files are added or modified (e.g., creating partials/base.html.twig), Grav's Twig compiled-template cache still holds the old compiled version. Pages that extend the changed file throw 500 errors like "Template partials/base.html.twig is not defined" even though the file exists on disk.

Root cause

Grav caches compiled Twig templates in cache/twig/. When a new file is added, existing templates that reference it don't know to recompile — their cache entries are still valid from their own mtime perspective.

Workaround (manual)

Run after any theme file is added or changed:

docker exec intotheeast_grav bash -c "cd /app/www/public && php bin/grav clearcache"

Fix spec

Disable Twig template caching in development via user/config/system.yaml:

twig:
  cache: false

Acceptable for a single-user dev setup — eliminates both BUG-001's side-effect and this bug entirely. Performance cost is negligible at one-user scale. On production, leave Twig cache enabled (it's fine there because template files don't change at runtime).

Files to change:

File	Change
user/config/system.yaml	Add twig: { cache: false } under development section

Acceptance criteria

1. Add a new theme template file
2. Reload any page — no 500 error, template works immediately without manual cache flush

---

BUG-003 — One post per day limit; silent failure on duplicate date

Status: fixed 2026-06-18 Reported: 2026-06-18

Symptom

Submitting a second post with the same date as an existing entry shows "Entry posted successfully!" but creates no file. The user's post is silently discarded.

Root cause

The add-page-by-form plugin built the page slug from date only (Y-m-d), producing folder names like 2026-06-18.entry. With overwrite_mode: false, if that folder already exists the plugin skips page creation but does not abort — the message process step runs regardless, showing a false success.

Fix

Change the slug template in user/pages/02.post/post-form.md to include time and title:

{{ form.value.date|date('Y-m-d-Hi') }}-{{ form.value.title|lower|regex_replace('/[^a-z0-9]+/', '-')|trim('-') }}

Example: title "Arrived in Tokyo" at 14:30 on 2026-06-18 → 2026-06-18-1430-arrived-in-tokyo

The slug is locked at creation time. Renaming the title afterwards does not change the URL.

Acceptance criteria

1. Submit two posts on the same day with different times or titles — both appear in /tracker as separate entries
2. Renaming a post's title in the frontmatter does not break its URL

---