# Changelog All notable changes to Migratico Lite will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [2.6.7] - 2026-06-10 ### CRITICAL FIX: OOM při exportu velkých webů (streaming scan) Reálný test na vyhledejte.cz (330k+ souborů): scan spadl na `FATAL: Allowed memory size of 536870912 bytes exhausted` při ~411 MB. **Příčina:** Seznam VŠECH naskenovaných souborů se držel v jednom poli `$files_list` a ukládal jako jeden `files_scan.json`. Na každém AJAX requestu se celý načetl (`json_decode`), postavila se md5 hash-mapa všech cest, přidaly se nové soubory a celé pole se zase uložilo (`json_encode`). To je **O(N) paměti** a kumulativně **O(N²) práce** → na stovkách tisíc souborů překročí `memory_limit`. Snížení dávek (`scan_files_per_batch`) nepomáhalo, protože kumulativní seznam byl v paměti stejně velký. **Oprava (streaming):** - Seznam souborů se nyní zapisuje **průběžně po řádcích (NDJSON)** do `files_scan.list` a NIKDY se nedrží celý v paměti. - Scan drží jen počítadla (`scanned_files_count`, `scanned_size`) ve stavu; řádky dávky se flushují do souboru v commit bodech (timeout / plná dávka / dokončení). Po neočekávaném killu se soubor ořízne na poslední potvrzený offset. - Globální md5 deduplikační mapa byla odstraněna (sama O(N) paměti); duplicitám brání procházení po adresářích + resume podle `last_processed_file`. - Exportní fáze čte seznam **řádek po řádku od uloženého offsetu** místo načtení celého pole. **Výsledek:** spotřeba paměti je plochá (jednotky MB) bez ohledu na počet souborů, a díky odstranění O(N²) práce je scan na velkých webech i **rychlejší**. ## [2.6.18] - 2026-06-09 ### CRITICAL FIX: FATAL `Call to undefined function wp_mkdir_p()` při extrakci Reálný test na ceskekrimi.cz: DB import proběhl (10859 ok), ale extrakce spadla **hned na prvním záznamu** `files_002.zip`: ``` FATAL: Uncaught Error: Call to undefined function wp_mkdir_p() #0 extract_one_entry() #1 extract_files_chunked() #2 ajax_chunk_import() ``` **Příčina:** Chunkovaný extraktor (`extract_one_entry`, `extract_single_file_streaming`) volal `wp_mkdir_p()` — což je WordPress funkce. Instalátor však běží **samostatně, bez načteného WordPressu**, takže funkce neexistuje → FATAL. `@` operátor nepotlačí "undefined function" fatal. Žádné adresáře (`wp-content`, `wp-includes`, `wp-admin`) se nevytvořily, takže následná kontrola hlásila „adresáře neexistují", přestože ZIP byl v pořádku. (Regrese: původní `extract_files` používal nativní `mkdir()`.) **Oprava:** Přidán fallback shim `wp_mkdir_p()` mezi ostatní WP shimy (vedle `wp_verify_nonce`, `wp_json_encode` atd.) — rekurzivní nativní `mkdir()` s tolerancí souběžného vytvoření přes `is_dir()`. Opravuje všechna 3 volání naráz. ## [2.6.17] - 2026-06-07 ### Refactor: Odstranění mrtvého kódu (legacy streaming + async pipelines) Instalátor obsahoval tři paralelní instalační pipeline; aktivní je jen jedna (chunk-based polling přes `?action=chunk_import`). Legacy streaming a async větve už JS nikdy nevolal. Odstraněny kvůli snížení složitosti a rizika regresí: **Odstraněné AJAX routy:** `start_installation`, `continue_import`, `stream_install`. **Odstraněné metody:** `ajax_start_installation`, `ajax_continue_import`, `ajax_stream_installation`, `perform_installation_async`, `perform_installation_streaming`, `continue_installation_after_db_import`, `continue_installation_streaming`, `import_database_streaming`, `stream_progress`, a nechunkované `import_database`, `extract_files`, `extract_zip_manual`, `verify_zip_contents`, `continue_sql_import_from_file`. **Odstraněno:** vlastnost `$streaming_mode` + MINFO marker blok v `save_progress()`. **Zachováno (sdílí aktivní chunked pipeline):** `extract_single_file_streaming`, `verify_files_extracted`, `update_wp_config`, `update_database_urls`, `create_admin_user`, `verify_database_import`, `ensure_db_connection`. Žádná změna chování aktivní instalace. `php -l` bez chyb. ## [2.6.16] - 2026-06-06 ### CRITICAL FIX: Nekonečná smyčka re-extrakce na 30s hostingu Reálný test v2.6.15 na flakarna.cz: extrakce doběhla (38/38), dorazila na finalizaci — a pak `FATAL: Maximum execution time of 30 seconds exceeded` a celá extrakce se spustila **od nuly**, dokola. K tomu běželo víc requestů paralelně (zdvojené logy). Čtyři propojené příčiny: **1. Shutdown handler přepisoval progress (driver smyčky):** Na FATAL volal `save_progress($phase_for_shutdown='extract', ..., 0%)`. FATAL během finalizace tak vrátil progress na `extract` 0% → další request re-extrahoval všech 38 ZIPů. → Handler teď jen loguje, progress nesahá (resume řídí state soubory). **2. FATAL ve finalizaci (count_files_in_dir):** `verify_files_extracted()` rekurzivně počítal VŠECHNY soubory v obřím `wp-content` (100k+ médií) → přes 30 s. → `count_files_in_dir()` má early-exit cap (600); všechny prahy (<10/<50/<200/<400) zůstávají správné, sken je O(cap) místo O(strom). **3. FATAL v extrakci (atomické extractTo):** `$zip->extractTo($path, $safe_entries)` 600MB ZIPu (`files_003`, 30337 souborů) je atomické a >30 s. → Přepsáno na **per-entry extrakci** s kontrolou time-budgetu po každém souboru; `extract_state.json` ukládá ZIP index I entry index → resume uprostřed ZIPu. Nový helper `extract_one_entry()` (streaming pro soubory >5 MB). **4. Souběh requestů:** Žádný zámek → paralelní polly re-extrahovaly současně. → Přidán `extract.lock` (45s freshness) serializující requesty. **Navíc:** `finalize_installation()` je teď **chunkovaná** — jeden sub-krok (verify → wp-config → URLs → admin) na request, vrací `'continue'`, takže žádný jednotlivý request nepřekročí limit. `@set_time_limit(30)` → `@set_time_limit(0)` (o vypršení rozhoduje 25s budget, ne PHP timer). **Soubory:** `installer/installer.tpl` (verze 2.6.16), `migratico.php`, `README.txt`. ## [2.6.15] - 2026-06-06 ### FIX: Past auto-resume při poškozeném installer-data.json Diagnostika z v2.6.14 odhalila reálnou příčinu zaseknuté extrakce na flakarna.cz: `installer-data.json` byl přepsán zdrojovým souborem (Bug I, starý installer v2.5.14 běžící na serveru) a obsahoval jen cleanup flagy (`migratico_files_deleted`, `migratico_installer_deleted`, ...) — žádné `db_host`. → `CHUNK: ABORT — No configuration data`. **Druhotná past (tohle opravujeme):** Konstruktor přes `has_active_installation()` **násilně přesměroval na Step 4** (auto-resume), kdykoliv existovaly state soubory (`installation_progress.json` / `extract_state.json`). Když ale `installer-data.json` chyběl/byl rozbitý, uživatel se NIKDY nedostal na Step 2 zadat DB údaje: Step 4 → Start → „No configuration data" → dokola. I po smazání `installer-data.json` zůstal uvězněný. **Fix:** `has_active_installation()` nyní vrací `false`, pokud `installer-data.json` nemá `db_host`. Auto-resume se spustí jen s platnou konfigurací; jinak proběhne normální navigace a uživatel může znovu projít Step 2/3 (DB import se přeskočí, extrakce naváže ze `state` souborů). **Workaround pro starší verze:** otevřít `?step=2` explicitně (GET step má přednost před auto-resume). **Soubory:** `installer/installer.tpl` (verze 2.6.15 + guard v `has_active_installation()`), `migratico.php`, `README.txt`. ## [2.6.14] - 2026-06-06 ### Diagnostika: tiché selhání chunk_import během extrakce (stalled extraction) Reálný test v2.6.13 (velký web, 38 ZIPů) dorazil k extrakci, rozbalil `files_002.zip` + `files_003.zip` (2/38), pak `EXTRACT: Timeout after 2/38 ZIPs` a **dál se nic nedělo**. Log neukazoval žádný důvod — po timeoutu přišel další request (`==== Spuštění instalačního skriptu ====`), ale už se nevypsalo `=== CHUNK IMPORT: Start ===`. **Root cause diagnostiky:** `ajax_chunk_import()` měl dvě `return` větve, které **nic nelogovaly**: - Selhání nonce ověření (`Security check failed`) - Chybějící konfigurace (`No configuration data` — prázdný/přepsaný `installer-data.json`) Když JS dostal `success:false`, zavolal `stop()` a přestal pollovat → 6minutová mezera v logu a po každém refreshi (`needs_start: true`) stejný pád. Bez logování nebylo možné rozhodnout, která větev selhala. **Fix (čistě diagnostický, žádná změna chování):** - `ajax_chunk_import()` nyní **vždy** loguje `CHUNK: request received` hned na vstupu, takže "request nedorazil" je odlišitelné od "request dorazil, ale selhal". - Větev nonce: loguje přijatou vs. očekávanou nonce + cestu k token souboru (`sys_get_temp_dir()/migratico-installer-token-*.txt`) — odhalí, jestli hosting čistí systémový temp mezi requesty. - Větev konfigurace: loguje existenci, velikost a klíče `installer-data.json` — odhalí, jestli byl soubor přepsán/smazán během extrakce. **Soubory:** `installer/installer.tpl` (MIGRATICO_INSTALLER_VERSION 2.6.14 + logování v `ajax_chunk_import`), `migratico.php`, `README.txt`. ## [2.6.13] - 2026-05-29 ### CRITICAL FIX: Extrakce přepisuje vlastní state installeru + zrychlení DB importu Reálný test v2.6.12 (1.1 GB DB, 3 ZIPy, 6 hodin běhu) odhalil dva problémy: **Problém 1 — extrakce ničí installer state (CRITICAL):** `$zip->extractTo($extract_path)` extrahoval VŠE bez jakéhokoliv filtrování. Pokud zdrojový web měl v `public_html/` zbylé soubory installeru (`installer-data.json`, `installer-log.txt`, atd.) z předchozího testu, extrakce je rozbalila a **přepsala běžící state** na cílovém serveru. Důsledek: - `installer-data.json` přepsán → "❌ No configuration data" v JSON odpovědi - `installer-log.txt` přepsán → polovinu logu ztratíme - `migratico.php` může být přepsán → installer se shazuje sám - Finalizace nikdy neběží → `wp-config.php` nepřepsán, URLs v DB neaktualizovány **Fix:** - Nový helper `should_skip_extraction($entry_name)` v `installer.tpl` filtruje 9 kritických state souborů + `files_NNN.zip` + `database.zip` na ROOT úrovni archivu. - `$zip->extractTo($extract_path, $safe_entries)` — ZipArchive API podporuje druhý argument se seznamem entries; ten pre-filtrujeme. - Manuální extraction (`extract_zip_manual`) má stejný filter v hlavní smyčce. - Logování: "EXTRACT: files_X.zip - skipping N installer state files". **Problém 2 — DB import 6h vs Duplicator 3h:** - Přidáno `SET SESSION foreign_key_checks = 0` a `SET SESSION unique_checks = 0` do `configure_pdo_session()`. Standardní praktika z `mysqldump` headeru — defer kontrol do commit/restartu, výrazně zrychluje INSERTy do velkých tabulek. - Plné přiblížení k Duplicatoru by vyžadovalo přepis na `mysqli_multi_query` (batch víc statementů jedním network roundtripem) — odloženo do v2.7. ## [2.6.12] - 2026-05-28 ### Fix: Resume po refreshi browseru + dynamický chunk timeout + odolnější JS polling Reálný test v2.6.11 s 1.1 GB DB odhalil tři problémy: 1. **Po refreshi browseru installer vrací na Step 1** i když `db_import_state.json` existuje na serveru. Detekce kroku vůbec nekontrolovala state soubory. - Nový helper `has_active_installation()` v `installer.tpl` detekuje `db_import_state.json` / `extract_state.json` / nedokončený `installation_progress.json` a forcuje `step=4` pro auto-resume. 2. **Pevný `$max_runtime = 25s`** byl příliš konzervativní pro hostingy s `max_execution_time` ≥ 60 s — zbytečně 2× pomalejší import. - Nový helper `get_chunk_runtime()` dynamicky zjistí host limit a využije 90 % (max 55 s). Pro 30s hostingy zůstává bezpečných 25 s. - Aplikováno ve fresh DB importu, continue DB importu i file extraction. 3. **JS polling měl skrytý cap `maxRetries = 200`**, který se počítal i pro úspěšné chunky. U 4+ hodinového importu se polling tiše zastavil. - `installer-progress.js` přepsán — žádný cap na úspěšné requesty, state files na serveru jsou source of truth. Cap zůstává jen na konsekutivní network erroři (30 = ~3 min výpadek tolerovaný). - Watchdog interval (15 s) restartuje polling pokud server nereaguje > 90 s. ## [2.6.11] - 2026-05-26 ### Fix: Odstranění `is_database_imported()`, návrat k state-file-driven logice **Bug G — Překombinované fixy v2.6.8–v2.6.10:** Přidání `is_database_imported()` s hardcoded tabulkami byl špatný přístup. Nepředvídatelné prefixy, parciální import při timeoutu, a nebezpečné mazání state souborů zrušily spolehlivé resume. - Odstraněna `is_database_imported()` — checkovat tabulky v DB je ruleta - Fáze se řídí výhradně z progress souboru (`installation_progress.json`) a state souborů (`db_import_state.json`, `extract_state.json`) - Ponechán `$db_just_imported` flag pro transition Phase 1 → Phase 2 v rámci jednoho requestu ## [2.6.10] - 2026-05-26 ### Fix: Falešně pozitivní detekce naimportované DB (přerušený import) **Bug F — `is_database_imported()` byl příliš optimistický:** Checkoval jen `wp_options`, ale při velkém importu (1.1 GB SQL) se timeout stihl po naimportování jen 22 tabulek. `wp_options` už existoval, ale `wp_users` a `wp_posts` chyběly. `is_database_imported()` vrátilo `true`, `$current_step` se vynutil na `'import_done'`, `db_import_state.json` se smazal — a pak `verify_database_import()` selhala. - `is_database_imported()` teď checkuje 8 kritických tabulek: options, users, posts, postmeta, terms, term_relationships, term_taxonomy, usermeta - Odstraněno nebezpečné mazání `db_import_state.json` — state soubor se maže jen po úspěšném dokončení ## [2.6.9] - 2026-05-26 ### Fix: Nekonečný loop DB importu (DB už byla hotová) **Bug E — DB import se opakoval do nekonečna:** Po fixu v2.6.8 se detekovalo, že DB je už naimportovaná (`is_database_imported()`), `$current_step` se vynutil na `'import_done'`, ale `$needs_db_import` byl stále `true`, protože `db_import_state.json` existoval. Výsledek: proces se pořád vracel k DB importu (`Resuming from line XXXX`) místo přechodu k Phase 2 (extrakce souborů). - Smažeme stale `db_import_state.json` když víme, že DB už je hotová - `$needs_db_import`: podmínka `file_exists($state_file)` platí jen když `!$db_imported` ## [2.6.8] - 2026-05-26 ### Fix: Robustní detekce fáze + resume po pádu **Bug D — Phase 2 extrakce stále přeskočena:** Po dokončení DB importu v jednom requestu se Phase 2 (extrakce souborů) občas přeskočila a šlo se rovnou do Finalize, které hlásilo chybějící soubory. Kořenová příčina: nespolehlivá detekce fáze z `$current_step`. - `is_database_imported()`: Rychlý check existence tabulek v DB — nezávislý na progress souboru - `ajax_chunk_import()`: Na začátku requestu checkne skutečný stav DB a podle toho nastaví `$current_step` na `'import_done'` nebo `'extract'` - `$db_just_imported` flag: Po úspěšném DB importu v TOMTO requestu se Phase 2 vynutí - Shutdown handler: Ukládá aktuální fázi do progress souboru při fatal erroru pro resume ## [2.6.7] - 2026-05-24 ### Fix: Chunkovaná extrakce souborů + shutdown handler pro export i import **Bug A — Extrakce (import):** Extrakce všech ZIP souborů běžela v jednom PHP requestu s `set_time_limit(30)`. Při 59 ZIPech (724 909 souborů) proces umřel po 4-5 ZIPech bez chybové hlášky. - `extract_files_chunked()`: 1 ZIP/request, state v `extract_state.json` - `finalize_installation()`: verify files → wp-config → URLs → admin → cleanup - `ajax_chunk_import()`: 3 fáze (DB import → chunkovaná extrakce → finalizace) **Bug B — Export resume:** PHP `max_execution_time` (60s) zabil první request dřív, než interní timeout check (každých 100 souborů) stihnul uložit stav. Druhý request začal od 0 → duplicitní ZIPy. - `register_shutdown_function()` v `Migratico_Files_Export::export()` uloží stav i při killu - `@set_time_limit(30)` přidáno pro konzistenci **Bug C — Phase 2 extrakce přeskočena:** `$current_step` se načetl před Phase 1, po dokončení DB importu zůstal starý (`''`) → `$needs_extract` = false → extrakce se přeskočila → finalizace hlásila chybějící soubory. Fix: `$current_step = 'import_done'` po úspěšném DB importu. ## [2.6.6] - 2026-05-22 ### Fix: Timeout na 100% souboru blokoval post-import fázi **Root cause:** Když chunk timeout nastal přesně po dokončení poslední řádky SQL souboru, vracel `'continue'` místo `true`. JS pak poslal další request, ale ten už neprovedl post-import fázi (extrakce souborů, update URL, admin, cleanup). **Fix:** - `fresh_sql_import_chunked()` a `continue_sql_import_chunked()`: při timeoutu na EOF (`$bytes_read >= $file_size`) vrátí `true` a pokračuje do Phase 2 - JS fallback: když `success=true` bez `needs_continue` a bez `completed`, pokračuje v pollingu ## [2.6.5] - 2026-05-22 ### WordPress 7.0 kompatibilita + odstranění duplicitního kódu - **Tested up to: WordPress 7.0** — plugin otestován a plně funkční na WP 7 - **Odstraněna duplicita post-import kódu** — `ajax_chunk_import()` nyní volá `continue_installation_after_db_import()` místo vlastní kopie stejné logiky - **Fix:** `$pdo` fallback při přeskoku Phase 1 (když DB import už byl dokončen) ## [2.6.4] - 2026-05-22 ### Fix: Chunk import dokončí celou instalaci (nejen DB) **Problém:** v2.6.3 po dokončení DB importu přesměroval na step 4, ale zbytek instalace (extrakce souborů, update URL, admin účet, cleanup) se nespustil. Instalace zůstala viset na 60%. **Fix:** `ajax_chunk_import()` nyní detekuje fázi instalace: - **Fáze 1:** DB import (když `step` je prázdný/`import_db`/existuje state file) - **Fáze 2:** Post-import (verify DB → extrahovat soubory → ověřit → update config → URL → admin → cleanup) - Po dokončení obou fází: `status: 'completed'`, JS přesměruje na step 4 (finální obrazovka) ## [2.6.3] - 2026-05-19 ### Fix: Kompletní přepis importu na chunk-based polling (konec streaming problémů) **Root cause:** Streaming XHR s `onprogress` je nespolehlivý pro velké importy (1+ GB SQL). Proxy servery buffrují výstup, `onprogress` nefire spolehlivě, watchdog timeouty, fallback polling, retry stormy — spirála hacků která nikdy nefungovala správně. **Řešení:** Inspirováno UpdraftPlus — chunk-based polling: - Každý request zpracuje **25 sekund** importu, pak vrátí **JSON** s progressem - JS okamžitě pošle další request (`fetch()` v cyklu) - **Žádný streaming, žádný `onprogress`, žádný watchdog, žádný fallback polling** - State se ukládá do `db_import_state.json` mezi chunky (stejný formát jako předtím) **PHP změny (installer.tpl):** - Nový endpoint `?action=chunk_import` — vrací JSON: `{success, percent, message, status, needs_continue}` - 3 nové metody: `ajax_chunk_import()`, `import_database_chunked()`, `fresh_sql_import_chunked()`, `continue_sql_import_chunked()` - `max_runtime = 25` místo 300 — každý chunk je krátký a spolehlivý - Lock mechanismus zachován (prevence paralelních importů) **JS změny (installer-progress.js):** - Kompletně přepsáno z 355 řádek na 55 řádek - Jednoduchá `chunkLoop()` funkce: fetch → JSON → update progress → další fetch - `maxRetries = 200` (200 × 25s = ~83 minut, dost i na 2 GB SQL) - Auto-resume při reloadu stránky zachováno ## [2.6.2] - 2026-05-19 ### Fix: JS fallback polling - resume detection + retry storm (konečně) **Kompletní přepracování JS fallback mechanismu.** Předchozí fixy řešily symptomy, ne root cause. **Root cause retry stormu:** - JS `onload` handler (ř. 253) retryoval vždy když `lastPercent > 0` — i když dostal validní progress data z "lock exists" odpovědi - Po skončení "lock exists" requestu se nerestartoval fallback polling → progress zamrznul **Root cause chybějícího resume:** - Když první request po 300s timeoutnul, uložil state do `db_import_state.json` a poslal `MINFO:TIMEOUT` - Ale nikdo neposlouchal — fallback polling byl zastavený, žádný XHR neběžel - Progress zůstal viset na 16% a nic se nedělo **Fix (installer-progress.js):** 1. `onload` handler: retry jen když `result.markers.length === 0` (žádná data = spojení umřelo). Když markery přišly → restartovat fallback polling 2. `startFallbackPolling()`: kontrola `db_import_state.json` — pokud existuje a `!isInstalling` → auto-resume 3. Přidán `resumeCheckInProgress` flag proti race condition (vícenásobné resumy) ## [2.6.1] - 2026-05-19 ### Fix: Installer - MINFO:TIMEOUT způsoboval retry storm (40 req/s) **Problém:** Po 2.6.0 JS začal spamovat server requesty (každou sekundu), protože `MINFO:TIMEOUT` v "lock exists" větvi způsoboval nekonečnou smyčku: - Druhý request detekoval lock → poslal `MINFO:TIMEOUT` - JS `onprogress` handler to zachytil → okamžitě spustil `startStreamingInstall(true)` - Další request → znovu lock → znovu TIMEOUT → znovu retry → **40 requestů za 50 sekund** **Fix:** Větve kde první import stále běží (`elseif file_exists($lock_file)` a `$import_result === 'locked'`) už neposílají `MINFO:TIMEOUT`. Místo toho přečtou aktuální progress z `installation_progress.json` a pošlou ho jako normální `MINFO:` marker. JS fallback polling pak normálně pokračuje. `MINFO:TIMEOUT` zůstává pouze v `'continue'` větvi — tam je správně, protože import skutečně dosáhl timeoutu, uložil state a JS má pokračovat se state filem. ## [2.6.0] - 2026-05-19 ### Fix: Installer - DB connection dying during SQL extraction + progress overwrite **Bug A: "MySQL server has gone away" při configure_pdo_session()** - `perform_installation_streaming()` připojil DB, pak `import_database()` extrahoval SQL ze ZIPu (11+ s) - Během extrakce spojení umřelo (nízký `wait_timeout` na hostingu) - Všech 7 `SET SESSION` příkazů v `configure_pdo_session()` selhalo → `max_allowed_packet` fallback na 1 MB - Import pak běžel extrémně pomalu (2.2% za 5 minut, celkem ~4 hodiny) - **Fix:** Po extrakci SQL a před `configure_pdo_session()` otestovat spojení (`SELECT 1`), při selhání reconnect **Bug B: Progress přepisován na 0% po timeoutu** - `import_database()` uložil progress (např. 16%) a vrátil `'continue'` - Volající (`perform_installation_streaming()` i `ajax_stream_installation()`) volaly `stream_progress('timeout', ..., 0)` → přepsaly progress na 0% - JS fallback polling ukazoval 0% → user si myslel že se nic neděje - **Fix:** Všechna 3 místa kde se handling `'continue'`/`'locked'` — odstraněno volání `stream_progress()`, ponechán pouze přímý výstup `MINFO:TIMEOUT` markeru (nepřepisuje `installation_progress.json`) ## [2.5.9] - 2026-05-19 ### Fix: Installer - Database Import failed (race condition) **Problém:** Import wizard na cílovém serveru havaroval s hláškou "Database Import failed" během prvních 30 sekund, přestože import reálně běžel. **Root cause:** - První streaming request spustil `import_database()` → vytvořil lock, rozbalil SQL, začal importovat - Po ~30s JS poslal druhý request s `continue=1` (auto-resume/watchdog) - `ajax_stream_installation()` zjistil že `db_import_state.json` ještě neexistuje (první request ještě nedosáhl timeoutu) → spustil `perform_installation_streaming()` znovu - `import_database()` detekoval lock → vrátil `'locked'` - `perform_installation_streaming()` **neuměl zpracovat `'locked'`** — měl jen `true` a `'continue'`, vše ostatní padalo do `else` → `stream_progress('error', 'Database import failed')` → `installation_status = 'failed'` - JS viděl `status: 'failed'` → zobrazil chybu, přestože první request normálně běžel dál **Fix:** - `ajax_stream_installation()`: Přidána `elseif ($is_continue && file_exists($lock_file))` větev — pokud continue request přijde když lock existuje ale state file ještě ne, pošle se `MINFO:TIMEOUT` marker (ne error), JS to zkusí znovu - `perform_installation_streaming()`: Přidáno explicitní ošetření `$import_result === 'locked'` → posílá `MINFO:TIMEOUT` místo `error` - `MIGRATICO_INSTALLER_VERSION` synchronizována s `MIGRATICO_VERSION` (2.5.6 → 2.5.9) ## [2.5.8] - 2026-05-17 ### Fix: Resume export - 3 kritické bugy opraveny **Problémy nahlášené uživatelem po 2.5.7:** 1. **DB nedokončená, ale plugin pokračoval na files** - `database.sql` (3.78 MB) existoval jako průběžný soubor, `get_package_data()` ho auto-objevilo a nastavilo `db_file` → JS Resume viděl `db_file` a považoval DB za hotovou (30/104 tabulek). 2. **Ignorování `excluded_dirs`** - při Resume se `excluded_dirs` neposílaly (spoléhalo se na `files_export_state.json`, ale ten při prvním spuštění files stepu obsahuje jen `wp-content/migratico`). 3. **Nerespektování `max_zip_size`** - `package.json` měl `max_zip_size = 100 MB` (hardcoded default), protože create package AJAX neposílal `max_zip_size` a PHP fallback byl 100 MB. **Root cause a fixy:** #### Bug 1: `db_file` detekce nespolehlivá - **Příčina**: `get_package_data()` v `class-migratico-package.php:218-222` auto-objevilo `database.sql` a nastavilo `db_file`, i když `db_export_state.json` stále existoval (export v průběhu). - **Fix**: Pokud `db_export_state.json` existuje, `get_package_data()` NEnastaví `db_file` (soubor je průběžný, ne finální). - **Fix**: `ajax_get_progress` vrací nový flag `db_export_in_progress` (true pokud `db_export_state.json` existuje). - **Fix**: JS Resume kontroluje `db_export_in_progress` - `dbDone = steps.db_export || steps.db_complete || (packageData.db_file && !dbExportInProgress)`. #### Bug 2: `excluded_dirs` ignorovány - **Příčina**: JS Resume posílal prázdný `stepData` (pouze `max_zip_size`). `Files_Export::export()` aktualizuje `excluded_dirs` jen pokud jsou neprázdné. - **Fix**: `ajax_get_progress` načítá `excluded_dirs` z `files_export_state.json` a vrací je v response. - **Fix**: JS Resume posílá `excluded_dirs` v `stepData` pro files step. #### Bug 3: `max_zip_size` nerespektován - **Příčina**: `ajax_create_package` neposílal `max_zip_size` z formuláře, PHP fallback byl hardcoded `100 * 1024 * 1024`. - **Fix**: PHP `ajax_create_package` používá `default_max_zip_size` z nastavení pluginu (`migratico_settings`) jako fallback. **Soubory:** - `includes/class-migratico-package.php` - `get_package_data()`: check `db_export_state.json` - `admin/class-migratico-admin.php` - `ajax_get_progress`: flag `db_export_in_progress` + `excluded_dirs`; `ajax_create_package`: `max_zip_size` ze settings - `assets/js/admin.js` - Resume handler: `dbExportInProgress` check, `excluded_dirs` v stepData **Backward compatibility:** Plná. Balíčky z 2.5.6/2.5.7 jsou správně detekovány. --- ## [2.5.7] - 2026-05-16 ### Fix: Resume export začínal od začátku místo pokračování **Problém:** Když uživatel klikl "Pokračovat" v administraci po přerušeném exportu (timeout/503), plugin místo pokračování od posledního dokončeného kroku začal celý export znovu od `db_table` (index 0) - přepsal hotový `database.zip` a smazal rozpracovaný `files_005.zip`. V `export.log` bylo vidět opakovaný DB export téže databáze s odlišnými daty (různé počty řádků v opakovaných exportech tabulek). **Root cause (3 navazující bugy):** 1. **Nesoulad názvů kroků mezi PHP a JS:** Po dokončení DB exportu PHP ukládalo do `progress.json` klíč `'db_complete'` (`admin/class-migratico-admin.php`), ale JS Resume logika hledala klíč `'db_export'`. Nikdy se neshodly → Resume považoval DB za nehotový → restart. 2. **Špatná cesta v JSON response:** `ajax_get_progress` vrací `{progress: {...}, percentage, status}`, ale JS četl `response.data.steps` místo `response.data.progress.steps`. `steps` byl tedy vždy `undefined` → všechny detekce false → vždy default `'db_table'`. 3. **Hardcoded `max_zip_size = 100 MB`:** Resume ignoroval uživatelské nastavení (např. 500 MB) a vytvářel menší ZIPy. 4. **Stejný nesoulad u installer kroku:** PHP ukládá `'installer_created'`, JS hledal `'installer'`. **Implementované fixy:** #### 1. PHP - sjednocení názvů kroků - `admin/class-migratico-admin.php`: `Migratico_Progress::update_step($package_id, 'db_complete')` → `'db_export'` (konzistentní s `'files_export'`, `'installer_created'`). - `ajax_get_progress` vrací navíc `package_data` (z `package.json`), aby Resume v JS mohl udělat file-based fallback detekci. #### 2. JS Resume - správná struktura, file-based fallback - Čte `response.data.progress.steps` (správná nested cesta). - Detekce hotových kroků kombinuje: - `steps.db_export` (>=2.5.7) NEBO legacy `steps.db_complete` (<=2.5.6) NEBO existence `package_data.db_file` (file-based fallback). - `steps.files_export` pro files step. - `steps.installer_created` NEBO legacy `steps.installer`. - File-based fallback chrání proti situaci, kdy `progress.json` se po fatal erroru nestihl uložit, ale fyzické soubory v balíčku existují. #### 3. JS Resume - správné `max_zip_size` a step data - Načítá `max_zip_size` z `package_data` (uloženo při vytvoření balíčku). - Pro `files` step posílá `max_zip_size` v POST datech (jinak server vezme default 100 MB). - `excluded_dirs` se neposílají - jsou perzistovány v `files_export_state.json` a načítají se ze stavu. #### 4. Diagnostické logování - JS console.log při Resume vypisuje `dbDone`, `filesDone`, `installerDone` flagy pro snadné debugování. **Soubory:** - `admin/class-migratico-admin.php` - rename klíče, `package_data` v response. - `assets/js/admin.js` - oprava Resume `.migratico-resume-export` handleru. **Backward compatibility:** Balíčky vytvořené v 2.5.6 (s klíčem `db_complete`) jsou rozpoznány přes legacy fallback i přes file-based detekci `db_file`. --- ## [2.5.6] - 2026-05-16 ### Fix: Import velkých databází selhával (inspirace UpdraftPlus restorer) **Problém:** U velkých webů (typicky 500 MB+ SQL dump) Migratico tiše selhával - log hlásil "0 errors" ale některé tabulky byly prázdné nebo neúplné. Příčiny: 1. **`max_allowed_packet` overflow** - multi-row INSERT statementy s tisíci hodnotami mohou přesáhnout default MySQL limit 4-16 MB → server statement zruší, PDO vyhodí "MySQL server has gone away" nebo "Got a packet bigger than max_allowed_packet" 2. **Žádný retry při disconnectu** - jednou ztracené spojení = všechny další query selžou, ale Migratico jen logoval warning a pokračoval s mrtvým PDO 3. **OOM riziko** - `fgets()` bez limitu může načíst multi-MB řádek (serializované WooCommerce/Elementor data) → out of memory na sdíleném hostingu 4. **Žádná detekce oversized statements** - tiše selhaly a čítač `failed` se inkrementoval o 1, ale celá tabulka mohla být ztracená **Implementované fixy (inspirace UpdraftPlus `restorer.php`):** #### 1. `configure_pdo_session()` - nastavení session vars na startu ```php SET SESSION sql_mode = 'NO_AUTO_VALUE_ON_ZERO' SET SESSION query_cache_type = OFF SET SESSION max_allowed_packet = 33554432 // pokus o zvýšení na 32 MB SET SESSION wait_timeout = 28800 // 8h SET SESSION interactive_timeout = 28800 SET SESSION net_read_timeout = 600 // 10 min SET SESSION net_write_timeout = 600 ``` #### 2. `get_max_allowed_packet()` - dotaz na skutečný limit Zjistí aktuální `@@session.max_allowed_packet` a podle něj se rozhoduje o splitu. #### 3. Auto-split velkých multi-row INSERT Pokud aktuální buffer + nový řádek by překročil `max_packet - 1024 B`, a aktuální buffer končí na `,` a nový řádek začíná `(`, plugin: - Odřízne poslední `,`, doplní `;`, vykoná fragment - Začne nový fragment se stejným `INSERT INTO \`table\` VALUES ` prefixem (extrahováno regexem z prvního řádku) - Logguje `Auto-split velkých INSERT statements: N× (kvůli max_allowed_packet)` #### 4. `execute_sql_with_retry()` - 3× retry při disconnectu Detekuje hlášky "gone away", "Lost connection", "Error while sending", "Connection was killed" → reconnect PDO (with fresh session config) → retry statement. `$pdo` je předáván **by reference** ať volajicí kód dostane nový objekt. #### 5. Oversized packet abort Pokud single statement > `max_allowed_packet` po splitu nelze nic dělat - logujeme `Oversized statement (X MB > Y MB) - skipping. Table may be incomplete!` místo tichého `failed++`. #### 6. Chunked `fgets($sql_handle, 1048576)` 1 MB max na jeden řádek - prevence OOM. **Soubory:** - `installer/installer.tpl` - 4 nové helper metody, refactor obou import smyček (fresh + continue) **Diagnostika v logu:** ``` PDO session configured for large DB import MySQL max_allowed_packet: 32 MB Imported 50000 statements (45.2%) Auto-split velkých INSERT statements: 12× (kvůli max_allowed_packet) ``` ## [2.5.5] - 2026-04-24 ### Cleanup: odstranění duplicitních kontrol a mrtvého kódu **Změny v `includes/class-migratico-files-export.php`:** - Odstraněna duplicitní kontrola velikosti ZIP v bloku "každých 100 souborů" (~40 řádků) - Po každém souboru se už kontroluje velikost (pre-check + post-check), druhá kontrola byla redundantní - Odstraněn mrtvý kód: "ZAVŘÍT STARÝ ZIP" uvnitř větve kde `$current_zip` je už `null` - Přečíslované komentáře ("2. Zavřít a znovu otevřít..." místo "3.") Žádné změny chování, pouze odstranění redundance po opravách v2.5.2–2.5.4. ## [2.5.4] - 2026-04-24 ### Fix: Detekce zdrojového prefixu selhávala u random prefixů **Problém z reálné migrace:** Zdroj měl prefix `N5cTi_` (random prefix z auto-installeru, časté u Hostinger). SQL export se exportuje abecedně: `N5cTi_actionscheduler_*`, `N5cTi_aiomatic_*`, `N5cTi_cmplz_*`... `N5cTi_options` je daleko za několika desítkami MB plugin tabulek. Detekce skenovala jen 256 KB → nenašla `*_options` → vrátila fallback `wp_` → replace neproběhl → v cílové DB vznikly tabulky `N5cTi_*` místo `wp_*`. **Fix 1 - Export (`class-migratico-db-export.php`):** - Do hlavičky SQL zapsán řádek `-- Migratico-Source-Prefix: N5cTi_` - Importer tak vždy spolehlivě pozná zdrojový prefix, nemusí ho hádat ze skenování statements **Fix 2 - Import (`installer.tpl::detect_source_prefix()`):** - **Krok 1:** Přečíst `Migratico-Source-Prefix` z hlavičky (prvních 4 KB) → nejspolehlivější - **Krok 2 (fallback pro staré balíčky):** Rozšířený scan na 5 MB místo 256 KB + rozšířený seznam core tabulek o `actionscheduler_actions`, `actionscheduler_logs`, `commentmeta`, `term_taxonomy` atd. - **Krok 3 (nouzový fallback):** Prefix z první `CREATE TABLE` / `DROP TABLE` statement (když ani core tabulky nejsou v rozsahu) **Přínosy:** - Random prefixy (Hostinger, Wordfence atd.) nyní správně detekovány - Staré balíčky (bez headeru) pokryty vylepšeným fallbackem - Jasný log: `Detected source prefix: N5cTi_` místo dřívějšího nepravdivého `wp_` ## [2.5.3] - 2026-04-24 ### Fix: Verify DB check - falešně negativní "Tabulka CHYBÍ" **Problém:** Po úspěšném importu 378 192 SQL statements s 0 chybami checker hlásil že `wp_options`, `wp_users`, `wp_posts` CHYBÍ. Příčinou byl `rowCount()` na `SHOW TABLES LIKE`, který není spolehlivý napříč PDO drivery - na některých (Hostinger) vrací 0 nebo -1 i když tabulka existuje. **Fix v `installer/installer.tpl::verify_database_import()`:** - Nahrazen nespolehlivý `$stmt->rowCount()` na `SHOW TABLES LIKE` za `in_array()` nad výsledkem `SHOW TABLES` + `fetchAll()` - Přidán **diagnostický výpis do logu**: aktuální DB (`SELECT DATABASE()`), celkový počet tabulek, prvních 20 názvů tabulek - Pokud tabulky opravdu chybí, checker nyní najde jiné `*_options` tabulky v DB a hlásí reálný prefix jako nápovědu **Přínosy:** - Falešně negativní výsledky eliminovány - Nový log dá okamžitě vědět, jestli tabulky existují (pod jakým prefixem) nebo jestli DB zůstala skutečně prázdná ## [2.5.2] - 2026-04-24 ### Fix: ZIP split - velké soubory způsobovaly ZIP 2x větší než limit **Problém:** Když aktuální ZIP měl např. 400 MB a další soubor byl 600 MB, addFile() ho CELÝ přidal do aktuálního ZIPu (výsledek: 1 GB ZIP při limitu 500 MB). Kontrola velikosti probíhala až PO addFile, kdy už bylo pozdě. **Fix v `includes/class-migratico-files-export.php`:** - Přidán **pre-check před addFile()**: pokud (`current_zip_size` + `file_size`) > `max_file_size` a ZIP už něco obsahuje, zavřít aktuální ZIP a založit nový PŘED přidáním velkého souboru - Velké soubory tak jdou do vlastního ZIP místo přetečení předchozího ### Fix: DB import - "tabulky CHYBÍ" i po úspěšném importu 382k statements **Problém:** Zdrojový web měl prefix jiný než `wp_` (např. `wpzoo_`). Importer měl **hardcoded** `$old_prefix = 'wp_'`, takže: - Prefix replace se neprovedl - Tabulky vznikly s názvy `wpzoo_options`, `wpzoo_users`... - Check hledal `wp_options` → hlásil "CHYBÍ" - Log: "Imported 382144 statements, 0 errors" ALE "Tabulka wp_options: CHYBÍ" **Fix v `installer/installer.tpl`:** - Přidána metoda `detect_source_prefix($sql_file)` - projde prvních 256 KB SQL souboru a najde skutečný prefix podle vzoru `` `xxx_options` ``, `` `xxx_users` `` atd. - Hardcoded `$old_prefix = 'wp_'` nahrazeno voláním detekce - Fallback na `wp_` pokud prefix nelze detekovat - Prefix se loguje pro diagnostiku **Změněné soubory:** - `includes/class-migratico-files-export.php` - ZIP pre-check - `installer/installer.tpl` - auto-detekce prefixu ## [2.5.1] - 2026-04-24 ### Fix: České překlady tlačítek ke stažení **Problém:** - "DB" tlačítko bylo AI translator pluginem (Compliantz apod.) nesprávně překládáno jako "Dvojitá základna" - ZIP soubory byly zobrazeny pouze anglickým názvem souboru (`files_001.zip`) bez českého popisu **Fix:** - Source text `esc_html_e('DB', ...)` → `esc_html_e('Database', ...)` → česky zobrazeno jako "Databáze" - ZIP soubory: label změněn z názvu souboru na `Soubory část 1`, `Soubory část 2` atd. - Původní název souboru zůstává v `title` atributu jako tooltip - Přidány překlady do `migratico-cs_CZ.po` a zkompilován `.mo` **Změněné soubory:** - `admin/views/main-page.php` - button labels - `languages/migratico-cs_CZ.po` + `.mo` ## [2.5.0] - 2026-04-24 ### Fix: Download velkých ZIP souborů (500MB+) **Problém:** Při stahování velkých ZIP (500MB+) vracel server chybu `500 Internal Server Error` kvůli: - Časovému limitu PHP (`max_execution_time`) - Pamětovému limitu (`readfile()` může načíst velkou část do paměti) - Output buffering blokující streaming - Nginx bufferingu **Fix v `admin/class-migratico-admin.php::stream_file_download()`:** - `set_time_limit(0)` - odstranit časový limit - `ini_set('memory_limit', '512M')` - zvýšit paměť - `ignore_user_abort(true)` - pokračovat i po disconnect - `session_write_close()` - neblokovat další requesty - `while (ob_get_level() > 0) ob_end_clean()` - vyčistit VŠECHNY buffery - Header `X-Accel-Buffering: no` - vypnout nginx buffering - Chunked `fread()` 1MB bloky místo `readfile()` s `flush()` po každém bloku - `connection_aborted()` check pro včasné ukončení ### Fix: Český překlad "DB" **Problém:** Tlačítko pro stažení databáze se zobrazovalo jako "dvojitá základna" místo "DB" (AI translator fallback na prázdný překlad) **Fix:** - `languages/migratico-cs_CZ.po`: `msgid "DB"` → `msgstr "DB"` (byl prázdný) - Přeložen .mo soubor **Změněné soubory:** - `admin/class-migratico-admin.php` - stream_file_download() - `languages/migratico-cs_CZ.po` + `.mo` ## [2.4.9] - 2026-04-03 ### UI Fix: Settings page - všechny number inputy **Problém:** Všechny number inputy měly `class="small-text"` (šířka ~50px) - nečitelné pro větší čísla **Fix:** Změna `small-text` → `regular-text` pro všechny number inputy v settings: - Throttle delay (ms) - Batch delay (ms) - Batch size - Large file delay (ms) - Large file threshold (MB) - Default max ZIP size (MB) - Files per batch (Export) - Files per batch (Scan) - Max runtime (seconds) **Změněné soubory:** - `admin/views/settings-page.php` - 9 number inputů ## [2.4.8] - 2026-04-03 ### UI Fix: Settings page - scan_files_per_batch input field **Problém:** - Input pole mělo `class="small-text"` (šířka ~50px) - nečitelné pro větší čísla - HTML validace `max="2000"` blokovala zadání vyšších hodnot **Fix:** - Změna `small-text` → `regular-text` pro lepší čitelnost - Zvýšení `max="2000"` → `max="10000"` pro větší flexibilitu **Změněné soubory:** - `admin/views/settings-page.php` - scan_files_per_batch input **Poznámka:** Pouze UI změna, žádné změny v logice scanu. ## [2.4.7] - 2026-03-27 ### Fixed - **Critical: Installer cleanup:** After successful installation, installer now deletes entire `package_*` directory from `wp-content/uploads/migratico/` - **Admin UI:** Fixed issue where completed package from source site was showing as "In Progress" on newly installed site - **Expected behavior:** After installation, plugin admin should show empty package list (no packages), not incomplete export from source site ### Technical Details - Added deletion of `package_*` directories in `delete_installer_files()` function - Installer now removes all traces of the installation package after successful migration - Clean state for plugin on newly installed site ## [2.4.6] - 2026-03-27 ### Fixed - **Package Status After Import:** Fixed issue where imported package showed "Continue export" status instead of "Completed" - **Automatic Status Detection:** Plugin now automatically detects completed exports based on file presence (DB, ZIP, installer) - **Smart Status Recovery:** When all required files exist but status is 'pending' or 'in_progress', status is automatically corrected to 'completed' ### Technical Details - Enhanced `get_package_data()` method in `class-migratico-package.php` - Added automatic validation: checks for DB file, installer file, and ZIP files existence - If all files present but status != 'completed', automatically updates status and sets completion timestamp - Fixes issue when package is imported to new domain with incomplete status in package.json ## [2.4.5] - 2026-03-27 ### Changed - **Material Design Admin Interface:** Complete redesign of admin interface using Material Design principles - **Google Fonts Integration:** Added Roboto font family and Material Icons - **Enhanced Visual Hierarchy:** Implemented elevation system with proper shadows (elevation-1 through elevation-8) - **Modern Color Palette:** Material Design color system with primary (#1976D2), accent, success, warning, and error colors - **Improved Cards:** All admin cards now use Material Design elevation and rounded corners (8px) - **Gradient Headers:** Table headers now feature gradient backgrounds for better visual appeal - **Status Chips:** Redesigned status badges with animated pulse indicators - **Button Redesign:** Material Design buttons with uppercase text, proper spacing, and hover effects - **Form Inputs:** Enhanced form fields with Material Design focus states and transitions - **Progress Bars:** Animated progress bars with shimmer effect - **Smooth Animations:** All transitions use Material Design cubic-bezier timing function - **Hover Effects:** Interactive hover states on cards, buttons, and table rows - **Typography:** Improved text hierarchy with Roboto font weights (300, 400, 500, 700) ### Technical Details - CSS Variables for consistent theming (--md-primary, --md-elevation-*, etc.) - Responsive grid layout for stat cards (minmax(220px, 1fr)) - Keyframe animations for pulse and shimmer effects - Material Design elevation system for depth perception - Improved accessibility with proper color contrast ratios - No changes to installer wizard (remains unchanged as requested) ## [2.4.4] - 2026-03-22 ### Changed - **README.txt Screenshots:** Updated screenshot descriptions to better reflect actual plugin features - Screenshot 3: "Package List" → "Statistic - Comprehensive website and server diagnostics" - Screenshot 4: "Site Statistics" → "Performance Optimization - Adjust export presets" - Screenshot 5: Added "Scanning Files - Progress bar" - Screenshot 6: Added "Scan Results - Select directories or files to skip" - Screenshot 7: Added "Export package" - Screenshots 8-11: Reorganized installer steps with better descriptions ## [2.4.3] - 2026-03-21 ### Fixed - **SSL Certificate Tip:** "💡 Tip: Použijte https:// pokud máte SSL certifikát" → "💡 Tip: Use https:// if you have an SSL certificate" - **ZipArchive Error:** "PHP rozšíření ZipArchive není dostupné" → "PHP ZipArchive extension is not available" - **Unknown Source:** "Neznámý" → "Unknown" ### Technical Details - Final pass to ensure ALL user-visible Czech texts are translated - Complete English UI for international users ## [2.4.2] - 2026-03-21 ### Fixed - **Welcome Screen:** "Vítejte v instalačním průvodci" → "Welcome to the WordPress migration installation wizard" - **Source Site Label:** "Zdrojový web" → "Source site" - **Progress Messages:** "Import databáze" → "Importing database" (all occurrences) - **Database Verification:** "Kontrola importu databáze" → "Checking database import" - **All UI Text:** Complete translation of remaining Czech texts visible to users ### Technical Details - Fixed all user-facing Czech texts that were missed in v2.4.1 - Code comments remain in Czech (not visible to users) - Complete English UI for international users ## [2.4.1] - 2026-03-21 ### Fixed - **Installer Default Language:** Changed all installer texts from Czech to English as default language - **Step 1:** "Spustit průvodce" → "Start Wizard", "Rozbaluji potřebné soubory" → "Extracting required files" - **Step 2:** "Test připojení" → "Test Connection", "Připojení úspěšné" → "Connection successful" - **Step 4:** All progress messages now in English ("Extracting files", "Importing database", "Connecting to database") - **Completion:** "Všechny instalační soubory smazány" → "All installation files have been deleted" - **Error Messages:** All error and log messages translated to English ### Technical Details - Installer now defaults to English regardless of WordPress language setting - Maintains professional appearance for international users - Consistent with WordPress.org plugin standards ## [2.4.0] - 2026-02-28 ### Changed - **WordPress.org Compliance - Installer Template System:** Renamed `installer/migratico-installer.php` to `installer/installer.tpl` (template file, not executable PHP) - **Template-based installer generation:** Plugin now generates `installer.php` from template during export (same approach as Duplicator plugin) - **Removed ABSPATH definition:** Template no longer defines ABSPATH constant - **Fixed MIGRATICO_INSTALLER_DIR:** Now uses `dirname(__FILE__)` instead of ABSPATH - **HTML output instead of echo:** Replaced `echo '