Ecommercen Docs

Appearance

<div style="display: none;" hidden="true" aria-hidden="true">Are you an LLM? You can read better optimized documentation at /changelog/Changelog.4.104.md for this page in Markdown format</div>

Home | Changelog

Version 4 ​

version 4.104 ​

  • [4.104.0] fix(docker): make integration-compose host port mappings configurable via .env

    • Every ports: declaration under .docker/integration/ is now parameterized through &lt;SERVICE>_EXPOSE_PORT env vars with defaults embedded as ${VAR:-default}, so two developers running stacks side-by-side can avoid host port collisions without git changes. Container-side ports are unchanged — only the host-facing left side becomes overridable, and defaults match the previous hard-coded values so existing .env files keep working.
    • Covers MariaDB (MARIADB_EXPOSE_PORT, default 3306), Vitess backend (VITESS_{MYSQL,DEBUG,GRPC}_EXPOSE_PORT), Redis standalone (REDIS_EXPOSE_PORT) and all six cluster nodes (REDIS_NODE_{1..6}_EXPOSE_PORT), nginx dev + prod (NGINX_EXPOSE_PORT), the Vite dev server (VITE_EXPOSE_PORT), phpMyAdmin (PHPMYADMIN_EXPOSE_PORT), and RedisInsight (REDISINSIGHT_EXPOSE_PORT).
    • Exposing MariaDB's port lets developers connect directly from local tools (TablePlus, DBeaver, mysql CLI, etc.) without exec-ing into the container. .env.example gains a new "Host Port Mappings" section documenting all 15 vars.

  • [4.104.0] fix(catalog): enforce unique product-category links and close all duplicate-write paths (Advisable-com/ecommercen#279)

    • The problem. The shop_product_category_lp junction table had no uniqueness constraint on (product_id, category_id), so duplicate rows could accumulate through any of four independent write paths: insert_categories_lp(), update_categories_lp_batch(), changeProductsCategoryBatch(), and the file-import job AdvInsertProductsFromFile. Several of these paths did not guard against duplicates at all; update_categories_lp_batch() performed a per-pair COUNT query to check for existence, which is racy under concurrent writes.
    • Migration (20260529120000_dedup_product_category_lp_unique.php). Removes all existing duplicate rows by keeping the lowest id per (product_id, category_id) pair via a self-join DELETE. Then drops the old non-unique product_category KEY and adds a UNIQUE INDEX product_category (product_id, category_id) in its place. The index check is defensive: the DROP INDEX clause is only emitted when the index exists, so the migration runs safely on client schemas that may have diverged. down() is intentionally empty (forward-only) — the old non-unique index cannot be meaningfully restored once duplicates have been removed.
    • Adv_product_category_model::linkProductCategory() (new helper). Central idempotent insert using INSERT ... ON DUPLICATE KEY UPDATE product_id = product_id. Chosen over INSERT IGNORE because it silences only uniqueness collisions — FK violations, truncation errors, and other genuine problems still surface. All internal write paths now route through this helper.
    • insert_categories_lp(). Replaced the bare $this->db->insert() call with linkProductCategory() in the per-element loop.
    • update_categories_lp_batch(). Removed the per-pair existence COUNT query (now made redundant by the UNIQUE index + linkProductCategory()) and delegates directly to insert_categories_lp().
    • changeProductsCategoryBatch(). Rewrote the plain UPDATE ... SET category_id = destination with UPDATE IGNORE (skips rows that would collide with an existing destination link) followed by a cleanup DELETE for source rows that could not move. Wrapped in a transaction so the move cannot leave an intermediate state. Added input validation: empty product list, zero/negative source or destination, and source == destination all short-circuit early to prevent phantom (product_id, 0) links.
    • removeAllProductCategoriesAndAssignToOne(). Added the same input validation and wrapped the delete + re-insert sequence in a transaction so products cannot be left with no category.
    • AdvInsertProductsFromFile::insertProductRelations(). Replaced the inline $this->ci->db->insert() with a delegation to linkProductCategory() via the model — mirrors the centralised pattern and eliminates the last independent write path.
    • FakeDataSeed. Switched the seed's junction-table inserts to INSERT IGNORE via a prepared statement so overlapping seed mappings do not trip the new UNIQUE index and abort the seed run.

  • [4.104.0] fix(checkout): converge modern checkout onto the legacy reserve-at-placement stock model — closes overselling window and fixes PayByBank phantom stock loss (Advisable-com/ecommercen#282)

    • The problem. The modern checkout deferred stock reduction to payment confirmation for online payways. This deviated from the legacy anti-overselling model (reserve at placement, restore on cancel) and introduced two defects: (a) an overselling window between placement and gateway confirmation; (b) PayByBank orders (redirect-less but PENDING) had stock reduced at placement yet never restored on cancel — a permanent phantom stock loss on every cancelled PayByBank order.
    • PlaceOrderService. Stock is now reduced at placement for every payway, dropping the redirect === null gate that previously skipped online payways. OrderPaid is dispatched at placement only for immediate payways (status === 'PENDING_ACCEPTED'); deferred payways (online gateways + PayByBank) dispatch OrderPaid later from confirmPayment(), so PayByBank no longer fires a premature paid event at placement.
    • PaymentConfirmationService::confirmPayment(). No longer reduces stock — placement now owns the reservation. Mirrors the legacy set_status('PAID', ignoreStock=true) call and prevents double-decrement for placement-reserved orders.
    • PaymentConfirmationService::cancelPayment(). Now restores stock on cancel, mirroring the legacy set_status('CANCELED', '+') path and the AdvCancelIncompleteOrders cron behaviour. The already-cancelled idempotency guard prevents double-restore.
    • Unchanged. AdvCancelIncompleteOrders continues to restore stock for stuck PENDING orders regardless of origin (abandonment safety net). Per-product negative-stock allowance remains the operator opt-out.
    • Tests. confirmPayment now asserts stock is NOT reduced; cancelPayment asserts stock IS restored; new PlaceOrderService test asserts online payways reserve at placement. Checkout suite 353 green; full Unit suite 3 163 green.
    • Deploy note. This changes when stock is decremented for online payways (now at placement, not at confirmation). Orders placed under the old code but confirmed after deploy will not be double-decremented at confirmation. No end-to-end integration test covers the full placement→confirm→cancel stock flow yet (unit-mock level only).

  • [4.104.0] fix(webhooks): unmatched-order webhook responses changed from HTTP 200 to 404 so payment providers retry on race conditions (Advisable-com/ecommercen#33)

    • The problem. Three REST webhook handlers — vivawallet(), paypal(), and stripe() — returned HTTP 200 {"received":true,"matched":false} when the inbound payload could not be matched to a shop_order row. Payment providers treat 200 as delivery success and stop retrying. A legitimate webhook that arrives before the order row commits (a narrow but real race) was therefore silently discarded: the order stayed unconfirmed and no payment-confirmation email was ever sent.
    • Piraeus and PayByBank already honoured 404 on unmatched orders (provider retries). This change aligns the remaining three handlers with that contract.
    • vivawallet(): after both the shop_order and gift_card_orders lookups miss, the handler now returns 404 instead of 200.
    • paypal(): when no internal order can be resolved from the payload, the handler returns 404 instead of 200.
    • stripe(): now gates on the confirmPayment() / cancelPayment() return value. A checkout.session.completed or checkout.session.expired event returns 404 when the order is unresolved (client_reference_id &lt;= 0) or when the confirm/cancel call returns false. This is the most important case — Stripe has no legacy fallback webhook path, so a dropped confirmation on the REST side would never recover. Unknown event types still return 200 (they are not unmatched-order situations).
    • Tests. Updated unmatched-order assertions in WebhookVivaWalletTest, WebhookPayPalTest, and WebhookRepositoryLookupTest from 200 → 404. Added ->willReturn(true) to Stripe success-path mocks (the handler now reads the return value); flipped orderId &lt;= 0 Stripe cases to 404; added a new Stripe case for the #33 late-commit race (orderId > 0 but confirmPayment returns false → 404). All 73 REST webhook tests pass; Unit suite 3 162 green.
    • Behaviour change visible to providers. Unmatched webhooks now return 404 instead of 200. Providers that implement retry-on-non-2xx (Stripe, Viva Wallet, PayPal, Piraeus, PayByBank all do) will retry, giving the order row time to commit.

  • [4.104.0] fix(webhooks): REST Viva Wallet handler now confirms/cancels gift-card payments (Advisable-com/ecommercen#32)

    • The bug. Webhook::vivawallet() looked up the inbound tran_ticket only against shop_order. Gift-card payments key their transaction ticket off the gift_card_orders table, so a Viva payment confirmed via the REST endpoint silently returned {"received":true,"matched":false} (HTTP 200) and never accepted the gift card — the customer paid but received nothing.
    • Fix. On a shop_order miss the handler now falls back to gift_card_orders by transaction ticket via a new private handleVivaWalletGiftCard() method. Confirmed events run transactionPaymentCreated → set installments → acceptGiftCard; failed events run transactionFailed → cancelGiftCard. This restores parity with the legacy AdvViva::handleWebhook() dual-lookup path.
    • Design note. Gift-card accept/cancel is non-trivial transactional logic (coupon creation + code generation on accept, coupon deletion on cancel) that lives entirely in the legacy gift_card_orders_model. Rather than duplicate fragile coupon logic in the modern layer, the gift-card branch delegates to the proven legacy model — idiomatic because Webhook extends Base_c (a CI controller). Porting that logic to the modern layer is a separate concern.
    • Tests. 5 new WebhookVivaWalletTest cases: payment-confirmed accept path, transaction-failed cancel path, string-event-name fallback, both-lookups-miss → matched:false, unknown-event acknowledges without mutation. Existing unmatched-order tests in WebhookVivaWalletTest and WebhookRepositoryLookupTest updated to stub a null-returning gift-card model (unmatched now means both lookups miss). All 72 REST webhook tests pass; Unit suite 3 161 green.

  • [4.104.0] refactor(checkout): port Viva Payment logging to the modern domain layer (Advisable-com/ecommercen#148)

    • What. The legacy Adv_viva_logging_model (table viva_logging) has been ported to a modern Checkout-domain satellite stack under src/Domains/Checkout/VivaLogging/, closing the last pre-existing legacy-model gap in the Checkout domain. The pattern mirrors the Order/AsapData satellite-table stack.
    • New files. Repository/Entity.php, Repository/Repository.php (table viva_logging), Repository/RepositoryConfigurator.php (BELONGS_TO order on order_id), Repository/WriteRepository.php, Service.php, WriteService.php, ListRequest.php (filters: id, orderId, transactionId).
    • Service contract. Service::getTransactionByOrderId(int $orderId): ?string returns the Viva Wallet transaction id recorded for an order, or null if none exists (the legacy false-on-miss becomes null). WriteService::logTransaction(int $orderId, string $transactionId): ?Entity records a Viva transaction authorized-but-pending (status === 'A') against an order id for later reconciliation — faithful to the legacy insert().
    • Scope. All five services registered in src/Domains/Checkout/container.php. No REST endpoint — this is operational logging, not a domain concern exposed to consumers. The legacy Adv_viva_logging_model and its Adv_checkout caller are left untouched (same dual-track convention as the PayByBank port #163).
    • Tests. 15 unit tests (WriteService + Service including getTransactionByOrderId hit/miss) + 4 integration container-resolution tests guarding the DI registration. Full suite green.

  • [4.104.0] test(webhooks): add unit test coverage for REST and legacy webhook handlers, closing the gap tracked in Advisable-com/ecommercen#34

    • Coverage added. Four new REST webhook test files and two new legacy webhook test files — 90 tests total — now exercise every handler that previously had no test:
      • tests/Unit/Rest/Webhooks/Controllers/WebhookStripeTest.php (11 tests) — real-HMAC signature verification, unconfigured-secret 500, invalid-signature 400, checkout.session.completed/expired confirm/cancel paths, orderId &lt;= 0 no-op, unknown event.
      • tests/Unit/Rest/Webhooks/Controllers/WebhookVivaWalletTest.php (12 tests) — event dispatch, order lookup, confirm/cancel transitions, malformed payload.
      • tests/Unit/Rest/Webhooks/Controllers/WebhookPiraeusTest.php (8 tests) — real-HMAC validation, success/fail notification paths, unmatched-order 404.
      • tests/Unit/Rest/Webhooks/Controllers/WebhookPayByBankTest.php (19 tests) — status mapping, payway-scoped lookup, intermediate-status no-ops.
      • tests/Legacy/Webhooks/AdvVivaTest.php and tests/Legacy/Webhooks/AdvSmartCartTest.php (40 tests combined) — handleWebhook/handle dispatch, payload validation, status transitions via reflection + mocked models.
    • Testability fix (zero production behaviour change). Webhook::stripe() now reads the raw request body via the existing $this->readRawBody() seam instead of calling file_get_contents('php://input') directly — consistent with the other four REST handlers; readRawBody() falls through to php://input in production. This unblocked branch coverage of the Stripe handler.
    • What was already covered. The PayPal REST handler and the legacy AdvJcc and AdvKlarnaPayments handlers had existing tests and are not affected by this change.
    • Suite status. All 129 webhook tests pass; Unit suite (3 141 tests) and Legacy suite (281 tests) remain fully green.

  • [4.104.0] fix(checkout): register PollPayByBankStatus job in the DI container so the cron dispatcher can resolve it (Advisable-com/ecommercen#163)

    • The bug. PollPayByBankStatus — the modern port of the legacy PayByBankGetStatus job shipped in the REST checkout-parity epic (#253) — was never registered in src/Domains/Checkout/container.php. The cron dispatcher (AdvJob) resolves jobs via $container->has($name) ? $container->get($name) : new $name(). Because the job has required constructor dependencies (OrderRepository, PaymentConfirmationService), the new $name() fallback would have caused a fatal error the moment an operator enabled the schedule entry in application/config/jobs.php. The unit test passed throughout because it instantiates the job directly, bypassing the container.
    • Fix. Added $services->set(Jobs\PollPayByBankStatus::class) to src/Domains/Checkout/container.php. The schedule entry stays commented out (operator opt-in); no runtime behaviour change.
    • Tests. New tests/Integration/Domains/Checkout/Jobs/PollPayByBankStatusContainerTest.php asserts the job resolves from the container and receives its constructor dependencies correctly — regression guard against future container re-breaks.

  • [4.104.0] feat(seo): extend faceted-navigation noindex to vendor listing pages

    • Note (post-merge correction). The PHP-side extension — renderVendorListingSeo() extended to variation/attribute filters and called from defaultRender() — was reverted by commit f1aecc6a9 ("Remove the unessesary logic for the no index no follow"). renderVendorListingSeo() is back to tag-only on the vendors() path, matching pre-4.104.0 behaviour. The robots.txt disallow rules and the rel="nofollow" filter-link changes (documented in the category entry below) apply to vendor pages as well (the filter query-string params and the EntryFilter.vue components are shared). PHP-side noindex,nofollow for variation/attribute-filtered vendor pages was not shipped.

  • [4.104.0] feat(seo): stop faceted-navigation filter URLs from bloating the index

    • Problem. Storefront category sidebar filters (product tags, variations, attributes) produce query-parameter URLs (e.g. ?προιοντα-για[]=…) that are near-duplicates of the base category page. Google was crawling and indexing thousands of these combinations, inflating crawl cost and index size with no SEO value.
    • public/robots.txt. Added a User-agent: * block disallowing the six faceted-navigation filter params (the three param pairs from application/config/languages.php: tag_filter_query_string, variation_filter_query_string, attribute_filter_query_string — Greek and English variants, Greek names percent-encoded). Also disallows /search and /*/search result pages. Explicit Allow directives for CSS, JS, image, and font assets are included so Googlebot can still render pages.
    • rel="nofollow" on filter links. Added to the filter anchor &lt;a> element in all three storefront filter Vue components: assets/main/vue/tag/filters/Components/EntryFilter.vue:16, assets/main/vue/variations/filters/Components/EntryFilter.vue:19, assets/main/vue/attributes/filters/Components/EntryFilter.vue:19. Storefront bundle rebuilt at the 4.104.0 release (public/ui/main/js/all-listing-filters.js).
    • Note (post-merge correction). The PHP-side Adv_product_categories.php change — detecting filter params via a shared Adv_front_controller::hasActiveListingFilters() helper and setting dofollow = false at the defaultRender() chokepoint — was reverted by commit f1aecc6a9. Filtered category pages rely on the existing generic setNoFollow() (any querystring → dofollow = false) at the view() path (Adv_product_categories.php:572-573). The hasActiveListingFilters() method does not exist in the codebase.

  • [4.104.0] fix(webhooks): decouple webhook routes from APP_REST_API_ENABLED flag — payment confirmations now always reachable (Advisable-com/ecommercen#31)

    • The bug (critical). All five REST payment-webhook routes (POST /rest/webhooks/{stripe,vivawallet,paypal,piraeus,paybybank}) were declared inside application/config/rest_routes.php, which routes.php conditionally @includes only when APP_REST_API_ENABLED=true. In any deployment where that env flag was absent or false the routes simply 404'd — silently, with no log signal. Stripe and PayPal have no legacy fallback callback path; for those gateways a missed webhook means the order stays unconfirmed and no payment confirmation is sent to the customer.
    • The fix. Extracted the five route assignments into a new application/config/webhook_routes.php and made routes.php @include it unconditionally, adjacent to but outside the APP_REST_API_ENABLED block. The REST routing format ([\FQCN\Class::class, 'method'] arrays) is processed by application/core/MY_Router.php::_parse_routes(), which is always active — only the inclusion of rest_routes.php was ever flag-gated. Pure config-shape change; no behavioural change to any handler.
    • Tests. New tests/Integration/Routing/WebhookRoutesAreAlwaysAvailableTest.php (4 tests / 28 assertions): all five POST routes resolve to Webhook::class with the correct method; routes.php @includes webhook_routes.php at top level and not inside the flag block (verified by a brace-depth parser); rest_routes.php no longer re-declares the webhook routes; siteModeAllowedNamespaces in app.php still covers the Webhook controller FQCN so gateway callbacks are not redirected to /soon or /maintenance in AdminOnly/AdminFrontend site modes. phpunit.xml.dist registers the new tests/Integration/Routing directory.

  • [4.104.0] refactor(webhooks): move raw shop_order queries out of REST webhook handlers into the Order domain repository (Advisable-com/ecommercen#44)

    • What. The three private lookup helpers inside src/Rest/Webhooks/Controllers/Webhook.php — findOrderBySerialAndPayway(), findOrderByTranTicket(), and the supplementary-data lookup inside extractPayPalOrderId() — used to call get_instance()->db directly (raw CodeIgniter query builder against shop_order). They now thin-delegate to two new public methods on the Order domain repository: findBySerialAndPayway(string $serial, string $payway): ?Entity and findByTranTicketAndPayway(string $tranTicket, string $payway): ?Entity. Each method uses the existing Filter Specification pattern consistent with the rest of the Order repository.
    • Why it matters. The controller is now properly unit-testable without a live database — the repository is injected via the constructor and can be mocked. The lookup pattern is canonical (domain repository, not ad-hoc SQL). The existing payway scoping on each lookup is preserved as a security boundary: a webhook event for one payment provider cannot accidentally resolve an order that belongs to a different payway.
    • Scope. src/Rest/Webhooks/container.php updated to wire the new OrderRepository constructor dep. The existing readRawBody() test seam was widened from PayPal-only to also cover Vivawallet and PayByBank so the new repository paths could be unit-tested — production behaviour is unchanged.
    • Tests. 6 new integration tests in tests/Integration/Domains/Order/Order/RepositoryTest.php covering happy path, payway-filter security boundary, and null-on-miss for both methods (19 → 25 tests). New tests/Unit/Rest/Webhooks/Controllers/WebhookRepositoryLookupTest.php (7 tests) asserts the controller calls the repo with the expected payway scope across Vivawallet, PayByBank, and PayPal handlers.

  • [4.104.0] fix(loyalty): loyalty points now awarded for orders delivered by carriers that report English statuses (Advisable-com/ecommercen#276)

    • Bug. AdvAddPointsToCustomerDeliver (and its inline equivalent in Cronjob::addPointsToCustomerDeliver()) queried delivered orders by gtstatus = 'ΠΑΡΑΔΟΜΕΝΟ'. The transporter poller writes the carrier's raw English status string to gtstatus (e.g. 'DELIVERED' for GenikiV2) and then sets gtflag = 1; it never writes the Greek string for those carriers. As a result, every order fulfilled by GenikiV2 — and any other carrier that returns a non-Greek delivered label — was silently skipped by the loyalty awarder. Customers received no loyalty points for those orders.
    • Fix. Both sites replaced the hard-coded Greek status match with 'gtflag' => 1. gtflag is the canonical boolean delivery sentinel set by all carrier branches of the poller regardless of the status vocabulary they use, so it captures every actually-delivered order.
    • Tests. New regression test at tests/Integration/Legacy/Jobs/AdvAddPointsToCustomerDeliverTest.php (2 tests, 5 assertions) covering the fix directly.
    • Flow doc. docs/flows/customer/CF-32-loyalty-points.md step 2 and business rule 12 updated to reflect the gtflag = 1 criterion; the former Known Issues note pointing to this gap removed.

  • [4.104.0] fix(transporter): harden GetOrdersTransferStatus against orphaned and odd carrier data (Advisable-com/ecommercen#275)

    • What. Three pre-existing defensive-coding gaps in the shipment-tracking poller, fixed identically in both the active legacy job (ecommercen/job/libraries/AdvGetOrdersTransferStatus.php) and the modern port (src/Domains/Transporter/Jobs/GetOrdersTransferStatus.php):
      1. Null-provider guard — an orphaned transporters_settings row (settings present, master record deleted) used to read $provider->class_name on null, emitting a recurring PHP 8.1 E_WARNING on every poll for every orphaned row. The guard is now if (!$provider || !$providerSettings) continue;.
      2. Single-checkpoint normalization (Center, EasyMail, CyprusPost, TaxydemaV2) — array_pop($track->Checkpoints->Checkpoint) raised a TypeError/warning when a carrier collapsed the checkpoint to a non-array; replaced with is_array($checkpoints) ? end($checkpoints) : $checkpoints so the single checkpoint is now recorded correctly.
      3. Unmapped-status warning (BoxNow, Skroutz) — $statusLabels[$key] raised an "Undefined array key" warning on unmapped statuses; rewritten as $statusLabels[$key] ?? null. The null-coalescing operator suppresses the warning while persisting the same NULL value as before — zero behavioural change to stored data, preserving the implicit safety margin against a string collision with the loyalty-points sentinel 'ΠΑΡΑΔΟΜΕΝΟ'.
    • Severity correction. Item 1 was originally framed as a fatal "aborts the whole run"; empirically it is a non-fatal E_WARNING under PHP 8.1 (switch(null) matches no case and the provider is skipped). The real cost was log noise, not an aborted nightly poll. AD-33's Known Issues section updated accordingly.
    • Tests. New tests/Integration/Domains/Transporter/Jobs/GetOrdersTransferStatusTest.php regression-guards fix 1 end-to-end (seeds an orphaned-settings row, neutralises other orders so no carrier API is touched, installs a strict E_WARNING handler so the test fails — not just warns — if the null-read regresses). Verified red without the fix, green with it. Fixes 2 and 3 stay inspection-verified (gateway-coupled carrier methods) consistent with the unit suite's documented CI3/network limits.
    • Follow-up. A gtstatus-reader audit done while writing the regression test surfaced #276 — the loyalty-points awarder (AdvAddPointsToCustomerDeliver) matches delivered orders by gtstatus = 'ΠΑΡΑΔΟΜΕΝΟ' without also checking gtflag, so GenikiV2 deliveries that return the English 'DELIVERED' (which the poller writes raw to gtstatus, then sets gtflag = 1) look like a real loyalty miss. Tracked separately.

  • [4.104.0] fix(transporter): correct Speedex 'succcess' typo — delivered orders now correctly set gtflag = 1 (Advisable-com/ecommercen#277)

    • What. getSpeedexTransporterStatus() accessed $speedexConfig->finalVoucherStatusCodes['succcess'] (triple 'c') but SpeedexConfig defines the key as 'success'. The typo caused array_merge(null, $failureCodes) — success codes were silently dropped, so in_array($lastCheckpoint->StatusCode, $finalVoucherStatusCodes) could never match a delivered Speedex order. Every Speedex delivery stayed in the poll loop until gtcount reached 10, wasting 10 API calls per order.
    • Fix. Corrected to ['success'] in both ecommercen/job/libraries/AdvGetOrdersTransferStatus.php:301 and src/Domains/Transporter/Jobs/GetOrdersTransferStatus.php:322. Caught by doc-ba-proofread of AD-33 during the #275 resync.

  • [4.104.0] feat(transporter): port GetOrdersTransferStatus shipment-tracking job to the Transporter domain (Advisable-com/ecommercen#274)

    • What. The legacy AdvGetOrdersTransferStatus cron poller (~602 lines, 15 carrier branches) has been ported to Advisable\Domains\Transporter\Jobs\GetOrdersTransferStatus implementing \JobCommand. All carrier logic, Greek status vocabulary, and runtime behaviour are preserved 1:1; the job's carrier gateways (Advisable\Transporters\*) are reused as-is and per-provider settings now flow through the existing domain TransporterSettingsLoader.
    • Registration. Autowired and registered by FQCN in src/Domains/Transporter/container.php; added to application/config/jobs.php commandOptions. The legacy scheduled entry remains active; a commented modern toggle entry is included alongside it (the PollPayByBankStatus convention — operators flip it when ready).
    • Tests. Unit test added at tests/Unit/Domains/Transporter/Jobs/GetOrdersTransferStatusTest.php. Split out of #163 (the "Payment Status" job bundle). Follow-up #275 tracks three pre-existing defensive-coding issues carried over from the legacy job (intentionally not fixed here to keep the port 1:1).

Notes

  • [4.104.0] REQUIRES php migrator.php migrate:

    • 20260529120000_dedup_product_category_lp_unique — removes duplicate (product_id, category_id) rows from shop_product_category_lp and replaces the non-unique product_category index with a UNIQUE INDEX. down() is forward-only (no rollback).

  • [4.104.0] Faceted-navigation SEO — deployed artifacts:

    • Storefront bundle rebuilt at the 4.104.0 release. rel="nofollow" is present in public/ui/main/js/all-listing-filters.js and adv-listing-used-filters.js.
    • Methods to re-check for client overrides (surviving signals only — PHP chokepoints were reverted, see the feat(seo) entries above):
      • Adv_front_controller::setNoFollow() / setCanonicalUrl() — generic any-querystring dofollow = false; called in category view() (:572-573) and vendor vendors() (:1338-1339).
      • Adv_vendors::renderVendorListingSeo($hasTagQueryString) — tag-filter-only noindex on the vendors() products path (:1121, :1265-1273). Variation/attribute-filtered vendor pages are not covered by PHP at this time.