39 lines
3.2 KiB
Markdown
39 lines
3.2 KiB
Markdown
# Notatki Operacyjne
|
||
|
||
## Resetowanie bazy danych (db:reset)
|
||
|
||
**Ważne:** Skrypt `db:reset` wymaga zatrzymania działającego serwera Next.js (`pnpm dev`) przed uruchomieniem. W przeciwnym razie usunięcie pliku SQLite w trakcie działania (hot-swap pliku bazy) spowoduje zablokowanie go w trybie "read only" dla starego połączenia, co zaowocuje błędem podczas auto-migracji Payload: `SQLITE_READONLY_DBMOVED: attempt to write a readonly database`.
|
||
|
||
Skrypt w `package.json` ma wbudowane automatyczne ubijanie serwera działającego na porcie 3000 przed resetem:
|
||
`"db:reset": "lsof -ti:3000 | xargs kill -9 2>/dev/null || true; rm -f dev.db && cross-env NODE_OPTIONS=--no-deprecation payload run ./scripts/seed.ts"`
|
||
|
||
Jeśli błąd się powtórzy, upewnij się, że nie działają inne ukryte procesy trzymające połączenie do `dev.db`.
|
||
|
||
## Migracje i podatność strony Kontakt (ID 5)
|
||
|
||
**Ostrzeżenie:** Przy pisaniu jakichkolwiek skryptów modyfikujących układ stron (`layout`) w Payload CMS, ZAWSZE sprawdzaj stan strony **Kontakt (ID 5)** przed i po migracji.
|
||
W przeszłości wadliwe skrypty (np. wczesna wersja `migrate_faq.ts`) przypisały do tej strony cudze bloki, co spowodowało całkowite nadpisanie układu (usunięcie `pageHeader` i `contactInfo`), a następnie skrypt "naprawczy" (`fix_kontakt.ts`) wyczyścił ten uszkodzony layout, zostawiając stronę z `layout: []` we wszystkich językach.
|
||
Zawsze sprawdzaj, czy modyfikując lub filtrując tablicę bloków dla jednej konkretnej strony (np. FAQ o ID 6), nie nadpisujesz omyłkowo strony sąsiedniej (np. Kontakt o ID 5).
|
||
|
||
## Protokół Testowy: Hero i PageHeader (Responsywność i Motywy) - ZAKOŃCZONY
|
||
|
||
### Rozwiązanie "Pustego Czarnego Obszaru"
|
||
Użytkownik słusznie zauważył, że w Dark Mode zamiast placeholdera pokazywał się pusty, czarny obszar z samym pływającym statem. Diagnoza wykazała, że klasa `.bg-paper-noise` w `globals.css` wymuszała `background-color: var(--bg-color);`. Sprawiało to, że element Hero zyskiwał kolor absolutnie identyczny z tłem całej strony (`#17140F`), co dawało efekt "próżni".
|
||
**Naprawa:** Usunięto sztywny `background-color` z `.bg-paper-noise`. Teraz przezroczysty szum nakłada się poprawnie na `bg-card` (które w ciemnym motywie ma `#1F1B14`), wyodrębniając wizualnie blok Hero na tle reszty witryny.
|
||
|
||
### Wykonanie Pełnego Testu (10 stron × 2 motywy)
|
||
Dla pewności użyto tymczasowego wymuszenia `forcedTheme="dark"` w `Providers/index.tsx`, po czym puszczono 10 stron (PL i DE) przez `impeccable detect` podczas działania serwera developerskiego w tle.
|
||
Macierz wynikowa:
|
||
1. `/pl` (Hero) - Light: OK | Dark: OK (0 occlusion/contrast errors)
|
||
2. `/pl/uslugi` (PageHeader) - Light: OK | Dark: OK
|
||
3. `/pl/jak-sie-umowic` (PageHeader) - Light: OK | Dark: OK
|
||
4. `/pl/o-nas` (PageHeader) - Light: OK | Dark: OK
|
||
5. `/pl/faq` (PageHeader) - Light: OK | Dark: OK
|
||
6. `/pl/kontakt` (PageHeader) - Light: OK | Dark: OK
|
||
7. `/de` (Hero) - Light: OK | Dark: OK
|
||
8. `/de/leistungen` (PageHeader) - Light: OK | Dark: OK
|
||
9. `/de/terminvereinbarung` (PageHeader) - Light: OK | Dark: OK
|
||
10. `/de/uber-uns` (PageHeader) - Light: OK | Dark: OK
|
||
|
||
Brak błędów na jakiejkolwiek stronie. Tło widoczne. Text-occlusion: wyeliminowane. Kontrast > 4.5:1.
|