fix(demo): fix PrestaShop container-network post-install fatal on PS 9

[norbert-kulus-blockydevs]

Summary

Follow-up to #1369. A live re-test of the merged #1369 fix — full teardown + fresh rebuild from a clean checkout, PrestaShop 9.0.2 — surfaced two bugs in docker/prestashop/post-install-lib/40-configure-container-network.php that broke the container's boot entirely (the wrapper's set -e turned a PHP fatal into a hard container exit, code 255):

1. ShopUrl::getShopUrls() returns ShopUrl objects under PrestaShop 9, not arrays — $row['domain'] threw Cannot use object of type ShopUrl as array, aborting the post-install script and killing the prestashop container. This is exactly the risk flagged in the fix(demo): unblock one-command Docker demo boot + PrestaShop networking (#1368) #1369 review (idempotency-guard shape assumption), except it's a hard boot-break rather than a silent duplicate-row issue.
   • Fix: replaced with a direct Db::getInstance()->getValue(...) existence check (matches the ObjectModel/legacy-bootstrap style this script and its 20-set-default-currency.php sibling already use).
2. Db::getValue() appends its own trailing LIMIT 1 internally (via getRow()); the query's own explicit LIMIT 1 doubled it into ... LIMIT 1 LIMIT 1 — a SQL syntax error (exit 255 again). Caught on the second reproduction attempt after fixing (1).

Verification

Full from-scratch reproduction: tore down all previously-built demo containers/volumes/images, rebuilt the images, and reset both the PrestaShop file volume and its MySQL database to force a true clean install (not just a container recreate).

• Post-install now logs: * ShopUrl added for domain 'prestashop' (id_shop=1) / * App-tier containers can now reach the shop at http://prestashop
• ps_shop_url carries both the operator's main localhost:18080 row and the new non-main prestashop row; PS_CANONICAL_REDIRECT=0.
• prestashop container status: running, exit code 0 (previously exited 255).
• From the api container: fetch('http://prestashop/api/') → 401 (reached, no redirect) — previously a 301/302 back to the canonical localhost domain.
• Also re-verified the rest of fix(demo): unblock one-command Docker demo boot + PrestaShop networking (#1368) #1369 end-to-end on the same clean boot: migrate exits 0 automatically via the .env-sourced OPENLINKER_CREDENTIALS_ENCRYPTION_KEY (no manual key insertion needed), mysql reaches healthy without the prior healthcheck race, UI login succeeds with no CORS error, and the fix(allegro,web): advertise OfferManager sub-capabilities so bulk wizard shows Allegro category params #1370 Allegro manifest fix is present in the rebuilt web bundle.

Test plan

• bash -n docker/prestashop/post-install/40-configure-container-network.sh — OK (unchanged wrapper).
• Live boot from a clean checkout as described above — prestashop stays up, post-install succeeds, webservice reachable from the app tier by service name.

🤖 Generated with Claude Code

[norbert-kulus-blockydevs]

Tech Lead Review

Note: this is a single review pass (running the standard /pr-review + /tech-review checklist together), not two separate consolidated reviews.

Context

This PR touches docker/prestashop/post-install-lib/40-configure-container-network.php, README.md, and docs/one-command-demo-setup-guide.md - all demo/infra tooling outside libs/core, apps/api, and apps/web. The hexagonal-architecture, naming, and TypeScript rules in docs/engineering-standards.md don't apply to this PHP install script or shell/docs snippets; the review below is scoped to correctness, safety, and consistency with the existing legacy-bootstrap scripts in the same directory.

Both fixes are well-verified: the PR description documents a full from-scratch reproduction (fresh volumes + fresh DB) with concrete before/after evidence (container exit code, ps_shop_url row content, webservice probe response). Root-caused correctly:

• ShopUrl::getShopUrls() returns a PrestaShopCollection of ShopUrl objects under PS 9 (confirmed against PrestaShop 9.0.2 source), so the old $row['domain'] array access was a real fatal.
• Db::getValue() -> getRow() does append its own trailing LIMIT 1, so a second explicit LIMIT 1 in the query text would indeed double up into a syntax error.

Findings

[SUGGESTION] - docker/prestashop/post-install-lib/40-configure-container-network.php (existence-check block)

The chosen fix drops from the ObjectModel API down to a hand-built raw SQL string (Db::getInstance()->getValue(...) with manual pSQL() escaping and backtick-quoted identifiers). A smaller, more idiomatic fix was available: ShopUrl::getShopUrls() still returns a PrestaShopCollection of ShopUrl objects, so the original loop only needed $row->domain / $row->domain_ssl instead of $row['domain'] / $row['domain_ssl'] - a two-token change with the exact same idempotency semantics. That would have stayed consistent with the sibling script's documented convention (20-set-default-currency.php explicitly uses Currency::getIdByIsoCode(), an ObjectModel accessor, not raw SQL) and avoided introducing manual SQL construction into a script that otherwise has none. Not blocking - pSQL() is applied correctly and CONTAINER_DOMAIN is a compile-time constant, so there's no real injection risk today - but worth a note for whoever revisits this script next.

[SUGGESTION] - docker/prestashop/post-install-lib/40-configure-container-network.php (same block)

The raw SQL string literals use double quotes (`domain` = "...") rather than single quotes. PrestaShop's own core SQL (see ShopUrl::setMain() in the same class, and the rest of the codebase) consistently uses single-quoted string literals. Under a sql_mode that includes ANSI_QUOTES, double quotes are treated as identifier quotes rather than string delimiters, which would silently break this query. MySQL 8's default sql_mode doesn't include ANSI_QUOTES so this isn't an active bug, but switching to single quotes would match PrestaShop's own convention and remove the latent portability risk.

Positive observations

• The inline comment block added above the fix clearly documents both root causes (the object-vs-array return type change and the double-LIMIT 1) with enough detail that a future maintainer hitting a similar PS-version-upgrade fatal will recognize the pattern immediately.
• pSQL() escaping is applied even though the interpolated value (CONTAINER_DOMAIN) is a hardcoded constant, not user input - good defensive habit regardless.
• The .env recipe fix (README.md + docs/one-command-demo-setup-guide.md) correctly identifies both the duplicate-key issue and the GNU/BSD sed -i portability trap, and replaces it with a portable grep -v | > .env + echo >> .env two-liner that needs no sed at all.

Final Assessment

Summary: A well-verified, narrowly-scoped follow-up to #1369 that fixes two real boot-breaking bugs in a PrestaShop 9 post-install script (an object/array type-shape mismatch and a doubled SQL LIMIT 1), plus a documentation fix for the .env key-generation recipe. The reproduction and verification described in the PR body is thorough (full teardown, fresh volumes, fresh DB, explicit before/after evidence). The only feedback is that the SQL-existence-check fix could have stayed closer to the file's existing ObjectModel-only style instead of introducing raw SQL - not a defect, just a missed opportunity for a smaller diff.

Merge Readiness: Approve - ready to merge as-is.

Priority fixes: None blocking. The two SUGGESTION items above are optional follow-ups, not required before merge.

[norbert-kulus-blockydevs]

Addressed both review suggestions in f729a4c.

Both SUGGESTION findings on 40-configure-container-network.php fixed by the same change: reverted the idempotency check from the raw Db::getInstance()->getValue(...) SQL string back to ShopUrl::getShopUrls(), using object property access ($row->domain / $row->domain_ssl) instead of the array access ($row['domain']) that caused the original PS9 fatal. This:

• stays consistent with the sibling script's ObjectModel-only convention (matching 20-set-default-currency.php's Currency::getIdByIsoCode() style), and
• removes the raw SQL entirely, so the double-quoted string literal / ANSI_QUOTES portability concern no longer applies (there's no hand-built SQL left in this block).

Verified against a live PrestaShop 9.0.2 demo container (not just php -l): confirmed ShopUrl::getShopUrls() returns a PrestaShopCollection of ShopUrl objects in this build (source-checked), then ran the patched script directly against the running container - it correctly detects the already-registered prestashop shop_url row via property access and exits 0 idempotently, same as before.

Also double-checked the .env key-recipe fix isn't affected by this change and still produces exactly one OPENLINKER_CREDENTIALS_ENCRYPTION_KEY= line (verified with a throwaway .env.example copy) - that's the piece the migrate service depends on to boot, and it's untouched by this commit.