fix(postman): hardcode language_id=1 on page-related Postman tests (#35780)

[dsolistorres]

Summary

Same language=-1 class of failure as #35780, surfacing in Experiments_Resource.postman_collection.json this time. CI run 26312707306 hit:

expected response to have status code 200 but got 404
inside "Variants / Keep Content after change Layout to a Specific Variant / Add contetlet into DEFAULT variant"

Server-side diagnosis

ERROR page.PageResource - HTMLPageAssetNotFoundException on PageResource.addContent,
      pageId: f41ac5d4f5a2e854e1d79ea6ca39df27

PageResourceHelper.getPage() looks the page up via:

final Language currentLanguage = WebAPILocator.getLanguageWebAPI().getLanguage(request);
...
APILocator.getVersionableAPI().getContentletVersionInfo(pageId,
        renderContext.getCurrentLanguageId(), ...)

getLanguage(request) falls back to getDefaultLanguage() when no language is on the request — and in this test env that returns the LANG__404 sentinel (id=-1). The page was created in the previous step with languageId=1 (verified in the test bodies), so the (id, -1) lookup misses and the server returns 404.

Fix

Add language_id=1 to the 5 URLs that target page-content endpoints without specifying language. All affected pages are created earlier in the flow with languageId=1 (English), so hardcoding 1 matches the test data exactly — no need for the _getdefault resolver dance here.

Patched URLs:

Section	Test
Variants / Keep Content after change Layout to a Specific Variant	Add contetlet into DEFAULT variant
Variants / Keep Content after change Layout to a Specific Variant	Add Contentlet into a specific variant (already had variantName, now also language_id)
Variants / Add Contentlet on Default Variant after A Specific Variant exists	Add contetlet into DEFAULT variant
Variants / Add Contentlet on Default Variant after A Specific Variant exists	Add Another Contentlet into a DEFAULTvariant
Add Spanish Contentlet inside Variant	Add contetlet into DEFAULT variant

Diff

+33 / −5 — surgical text patches that preserve the file's mixed inline/multi-line array style. Each patched URL got ?language_id=1 (or &language_id=1) in raw plus a matching query array entry, consistent with the other URLs in this collection that already specify query params (e.g. variantName).

Test plan

• JSON validity verified.
• CI verifies — PR Test / Postman Tests - Experiment should now pass.

🤖 Generated with Claude Code

[claude]

Claude finished @dsolistorres's task in 1m 34s —— View job

---

Review

Looks clean. Surgical test-data fix, consistent with the #35780 pattern.

Checks performed

• Diff against origin/main (+34 / −6, two files)
• All 6 /api/v1/page/{id}/content calls in the Experiments collection now carry language_id (4 new + 1 amended + the pre-existing Spanish-variant call)
• Each patched URL's raw, path, and query are kept in sync — Postman won't get conflicting representations
• Verified every patched page id (page_version_keep_contentlet, add_contentlet_default_specific_variant_page_id, page_version_spanish_content) is created earlier in the file with languageId: 1, so the hardcoded 1 matches the test data
• Verified the one call that was intentionally left with a different language (language_id={{spanish_content_another_lang_id}} at line 13096) is the Spanish-variant case adding a Spanish contentlet — correctly NOT touched
• PagesResourceTests.json: the new "languageId":1 is added in the contentlet body, alongside cachettl:0, matching the pattern used by every other page-create body in this repo

Worth a second look

• None of this fixes the underlying server bug. getDefaultLanguage() returning the LANG__404 sentinel (id=-1) when the default-language record is missing is the real defect — this PR just stops test data from depending on it. That's the right call to unblock CI, but if the same env state recurs in another collection, expect more whack-a-mole. Worth a follow-up issue if there isn't one already, so server-side fallback can be hardened (e.g., refuse to return id=-1 from getDefaultLanguage() and force callers to handle absence).
• Hardcoded 1 vs. a collection variable. All other language references in this collection use variables ({{spanish_content_another_lang_id}}). Using a literal 1 is fine because dotCMS always seeds English as id=1, but a {{default_language_id}} variable would be more consistent with the file's style. Not blocking.
• languageId placement in PagesResourceTests.json. Added inside the inner object alongside cachettl:0 — correct. The stray tabs (\t\t) at the end of the object are preserved from the original, so no formatting regression.

No security, correctness, or design concerns. JSON structure is intact.
• branch issue-35780-experiments-page-language

[dsolistorres]

Folded in another instance of the same root cause spotted in CI run 26312707306 — PagesResourceTests.json → Live page cache invalidation / Create Test Page was firing PUT /api/v1/workflow/actions/default/fire/PUBLISH without a languageId in the body. Server defaulted to getDefaultLanguage() (LANG__404, id=-1) → FK violation on insert.

Added "languageId":1 to the body in commit on this branch (single-line diff). PR title updated to reflect the broader 'hardcode language_id=1 on page-related tests' scope so reviewers see this isn't strictly Experiments-only anymore.