Tags: fabiodalez-dev/Pinakes
Tags
release(0.7.19): land catalog filters (#169), backup (#167), scanner/… …cover (#166), suite (#168) + session fixes into main Merge of feature/catalog-filters (the 0.7.19-rc.4 superset) into main, resolving version.json to the stable 0.7.19. Brings everything EXCEPT the updater supply-chain hardening (which stays on security/updater-hardening, not shipped in this release). README gets the "What's New in v0.7.19" section in this same commit (the version badge is dynamic from version.json). No new migration — schema baseline stays at migrate_0.7.17.sql.
fix(installer): self-heal root .htaccess so routing works with docroo… …t at project root When a site's document root is the project root (a very common cPanel layout) the app relies on the root .htaccess to forward every request to public/. cPanel's File Manager hides dotfiles by default, so after extracting the ZIP users move the visible files into the docroot but leave the hidden root .htaccess behind — which kills routing for every path except "/" and 404s all assets (CSS, logo, plugin assets), the installer's own icons included. Make createHtaccess() write the correct route-to-public/ rules (it previously wrote a public-style "route to index.php" block and, worse, bailed out entirely when ANY .htaccess already existed — e.g. the PHP-directives-only file cPanel auto-generates). It is now idempotent and merge-aware: it preserves existing content (cPanel directives) and appends the routing block only when missing. Also invoke it at installer bootstrap (installer/index.php) so the installer's own assets resolve during installation, fixing the "missing icons" symptom. Verified end-to-end on a real LiteSpeed/cPanel host with docroot at project root: removing the root .htaccess 404s every route; the regenerated file restores /, /catalogo, /accedi, /assets/* and plugin assets to 200.
fix(#143): demote drifted ordine-0 impostors before promoting the pri… …mary The 0.7.16 migration forced the current primary to ordine 0 but left any OTHER publisher that had drifted into the ordine-0 slot untouched. A real install had libro 94 with junction rows 89:0 and 106:0 while libri.editore_id = 106 — after the migration both stayed at ordine 0, so an order-sorted export/display could still surface the wrong primary. Add a demote step before the promotion: push every non-primary ordine-0 row to the book's MAX(ordine)+1 (a materialized derived table, so it stays portable to MySQL 5.7 — no window functions). The impostor survives as a co-publisher and vacates the slot, then the existing promotion makes the real primary the sole ordine-0 row. Verified on the libro-94 case: 89:0,106:0 -> 106:0,89:1, idempotent on re-run, and zero books left with more than one ordine-0 row.
PreviousNext