shopPRO/.paul/phases/20-category-edit-mojibake-fix/20-01-PLAN.md

phase, plan, type, wave, depends_on, files_modified, autonomous, delegation

phase	plan	type	wave	depends_on	files_modified	autonomous	delegation
20-category-edit-mojibake-fix	01	execute	1		admin/templates/shop-category/category-edit.php	false	off

## Goal Etykiety formularza edycji kategorii (`/admin/shop_category/category_edit/id=X`) pokazują poprawne polskie znaki: "Treść", "Język domyślny", "Tytuł kategorii (h1)", "Wyświetlić podkategorie", "Sortowanie produktów", "Blokuj indeksację", "Opis kategorii (rozwinięcie)" — zamiast mojibake `Treść`, `JÄ™zyk domyĹ›lny`, itp.

Purpose

Mojibake w etykietach UI panelu admina utrudnia korzystanie z formularza. Administrator musi się domyślać znaczenia pól. Naprawia profesjonalny wygląd panelu i poprawia UX uzupełniania kategorii (m.in. SEO).

Output

• admin/templates/shop-category/category-edit.php z poprawnymi polskimi znakami (UTF-8) we wszystkich hardcoded stringach
• Weryfikacja wizualna w panelu admina

Root cause

Plik został kiedyś zapisany z UTF-8 zinterpretowanym jako Windows-1252 i ponownie zakodowanym do UTF-8 (classic double-encoding mojibake). file raportuje "UTF-8 text" bo bajty są poprawnym UTF-8 — tyle że ich znaczenie po dekodowaniu UTF-8 to bezsensowne kombinacje znaków łacińskich (Ä, Ĺ, Ă itp.).

Grep Ä[\x{84}-\x{99}]|Ĺ|Ăł wskazał, że tylko ten jeden plik w całym repo (admin/templates/, templates/, autoload/) jest dotknięty — pozostałe templates mają poprawne UTF-8.

## Project Context @.paul/PROJECT.md @.paul/STATE.md

Source Files

@admin/templates/shop-category/category-edit.php

Clarifications

• Objaw — Mojibake (Ä€„ zamiast ą) w labelkach formularza edycji kategorii → Odpowiedź: potwierdzone — mojibake (double-encoded UTF-8)
• Pola — Nie wiem, sprawdź → Odpowiedź (po inspekcji): WSZYSTKIE hardcoded labelki w pliku category-edit.php (9 wystąpień), żadne inne pliki templates nie dotknięte
• Migracja danych — chodzi o labelki, nie zapisywane dane → Odpowiedź: plan dotyczy tylko hardcoded stringów w pliku PHP. Dane w bazie (mieszane HTML entities w additional_text) — oddzielny issue, NIE w tym planie

Wykryte miejsca mojibake (grep)

Line 10:  Treść                       → Treść
Line 20:  JÄ™zyk domyĹ›lny              → Język domyślny
Line 48:  Opis kategorii (rozwiniÄ™cie) → Opis kategorii (rozwinięcie)
Line 87:  Sortowanie produktĂłw         → Sortowanie produktów
Line 96:  WyĹ›wietlić podkategorie     → Wyświetlić podkategorie
Line 107: JÄ™zyk domyĹ›lny              → Język domyślny (duplikat)
Line 127: TytuĹ‚ kategorii (h1)        → Tytuł kategorii (h1)
Line 159: Blokuj indeksacjÄ™           → Blokuj indeksację

Mapowanie sekwencji (do podmiany):

• ć → ć, Ä… → ą, Ä™ → ę, Ĺ‚ → ł, Ĺ› → ś, Ĺ„ → ń, Ĺş → ź, Ĺľ → ż
• Ć → Ć, Ä„ → Ą, Ę → Ę, Ĺ → Ł, Ĺš → Ś, Ĺƒ → Ń, Ĺ¹ → Ź, Ĺ˝ → Ż
• Ăł → ó, Ă“ → Ó

<acceptance_criteria>

AC-1: Brak mojibake w pliku

Given plik admin/templates/shop-category/category-edit.php po fixie
When uruchomię grep regex `Ä[\x{84}-\x{99}]|Ĺ|Ăł|Ĺ›|Ĺ‚|Ä™|Ä…|ć`
Then nie ma żadnego dopasowania (0 linii)
And plik dalej jest UTF-8 (bez BOM) — sprawdzalne przez `file`

AC-2: Labelki formularza renderują się z polskimi znakami

Given administrator otwiera /admin/shop_category/category_edit/id=10 po deployu
When sprawdza nazwy tabów i etykiet pól
Then widzi "Treść", "Ustawienia", "SEO" jako nazwy tabów
And widzi "Język domyślny", "Tytuł kategorii (h1)", "Sortowanie produktów",
    "Wyświetlić podkategorie", "Blokuj indeksację", "Opis kategorii (rozwinięcie)"
    jako etykiety pól
And NIE widzi `Ä`, `Ĺ`, `Ă` w żadnym widocznym miejscu na tej stronie

AC-3: Brak regresji w innych szablonach

Given fix dotyczy tylko jednego pliku
When uruchomię grep mojibake w admin/templates/ + templates/ + autoload/
Then żaden inny plik nie zawiera mojibake (tak jak przed fixem)
And cała suita PHPUnit (846 testów) pozostaje zielona

</acceptance_criteria>

Task 1: Podmień double-encoded UTF-8 na właściwe polskie znaki admin/templates/shop-category/category-edit.php Wykonaj globalne podstawienia w pliku z mojibake → UTF-8 polskie znaki:

Podstawienia całych słów (najbezpieczniejsze — unikamy fałszywych alarmów z `Ä` w innym kontekście):
  "Treść"                       → "Treść"
  "JÄ™zyk domyĹ›lny"              → "Język domyślny"
  "rozwiniÄ™cie"                  → "rozwinięcie"
  "Sortowanie produktĂłw"         → "Sortowanie produktów"
  "WyĹ›wietlić podkategorie"     → "Wyświetlić podkategorie"
  "TytuĹ‚ kategorii (h1)"        → "Tytuł kategorii (h1)"
  "Blokuj indeksacjÄ™"           → "Blokuj indeksację"

Po wszystkich podstawieniach zweryfikuj greppem że żadne mojibake już nie zostało.

Avoid: globalne sekwencyjne `str_replace` typu `ć` → `ć` bez kontekstu — mogłoby przypadkiem złamać poprawne fragmenty w przyszłości (na razie nie ma ryzyka, ale lepiej trzymać się konkretnych słów).
Avoid: zmiana encodingu pliku (musi zostać UTF-8 bez BOM, CRLF — jak teraz).
Avoid: jakichkolwiek zmian poza podmianami stringów (struktura HTML, logika, imports — bez zmian).

grep -P "Ä[\x{84}-\x{99}]|Ĺ|Ăł|Ĺ›|Ĺ‚|Ä™|Ä…|ć|Ĺ„" admin/templates/shop-category/category-edit.php → 0 dopasowań file admin/templates/shop-category/category-edit.php → UTF-8 text (bez BOM) AC-1 satisfied: plik bez mojibake, dalej UTF-8 Task 2: Weryfikacja braku regresji + odpalenie suity testów (brak modyfikacji — weryfikacja) 1. Powtórz globalny grep mojibake w admin/templates/, templates/, autoload/ — powinno być 0 plików (poza tym fixowanym, który po Task 1 też ma 0) 2. Uruchom suitę PHPUnit: `php phpunit.phar` 3. Sprawdź że nie ma żadnych nowych failów (oczekiwane: 846 OK) grep -rl -P "Ä[\x{84}-\x{99}]|Ĺ" admin/templates/ templates/ autoload/ — brak wyniku php phpunit.phar — exit code 0, 846 tests OK AC-3 satisfied: brak regresji, suita zielona Plik admin/templates/shop-category/category-edit.php z polskimi znakami w UTF-8 (auto-upload FTP wysyła zmianę na shoppro.project-dc.pl po zapisie pliku) 1. Otwórz https://shoppro.project-dc.pl/admin/shop_category/category_edit/id=10 (zaloguj się jeśli trzeba) 2. Sprawdź nazwy 3 tabów: "Treść", "Ustawienia", "SEO" — powinny być po polsku, bez mojibake 3. W tabie "Treść" sprawdź: - tooltip ikony gwiazdki: "Język domyślny" - etykiety pól: "Nazwa kategorii", "Opis kategorii", "Opis kategorii (rozwinięcie)", "Dodatkowy tekst (nad produktami)" 4. W tabie "Ustawienia" sprawdź: "Aktywna", "Sortowanie produktów", "Wyświetlić podkategorie" 5. W tabie "SEO" sprawdź: "Tytuł kategorii (h1)", "Blokuj indeksację" 6. Otwórz inną kategorię (np. id=11) — to samo dla regresji Wpisz "approved" by kontynuować, lub opisz issues

DO NOT CHANGE

• Struktura HTML pliku (tagi, klasy CSS, JS scripts)
• Logika PHP (if/foreach, wywołania Tpl)
• Inne pliki w admin/templates/shop-category/ — nie są dotknięte mojibake
• Encoding pliku (musi zostać UTF-8 bez BOM, jak obecnie)
• Dane w bazie (HTML entities w additional_text to oddzielny issue)

SCOPE LIMITS

• Plan dotyczy TYLKO pliku admin/templates/shop-category/category-edit.php
• NIE skanujemy wszystkich szablonów admina pod kątem mojibake (już sprawdzone — pozostałe OK)
• NIE migrujemy danych w DB (admin uzupełnia ręcznie jeśli ma encje)
• Bez build update package — to robi /koniec-pracy po UNIFY

Przed zamknięciem planu: - [ ] grep mojibake → 0 wyników w category-edit.php - [ ] file potwierdza UTF-8 bez BOM - [ ] Suita PHPUnit 846 zielona - [ ] Human-verify na 2 kategoriach (id=10 i jeszcze jednej) zatwierdzony - [ ] AC-1, AC-2, AC-3 spełnione

<success_criteria>

• 9 wystąpień mojibake naprawionych w 1 pliku
• Brak regresji w innych szablonach
• Suita testów zielona
• Wizualna weryfikacja w panelu admina OK </success_criteria>

After completion: `.paul/phases/20-category-edit-mojibake-fix/20-01-SUMMARY.md`