fix(set_ode): refresh entry file metadata on the new revision after online package replacement

[erseco]

Summary

Complements exelearning/exelearning#1740 (which fixes the visible 404 on content/resources/<uuid>.png by generating the webzip in the browser). This PR fixes a separate Moodle-side consistency bug surfaced while investigating mod_exeweb#42: after the first online save, entrypath, entryname and the entry file sortorder kept pointing at the previous revision.

Root cause

set_ode.php extracted the new package into $exeweb->revision but called exeweb_package::get_mainfile() without an $itemid. The default itemid = 0 always missed the freshly extracted files, so:

• entrypath / entryname were never refreshed after the first online save.
• file_set_sortorder() was a no-op for the entry file.
• The activity kept pointing at the previous revision's metadata, while content lived under the new revision.

The embedded editor flow (editor/save.php) already passes the right itemid, which is why embedded mode works. The bug is specific to the online (set_ode.php) entry point.

Changes

• set_ode.php

  • Pass $package->get_itemid() to get_mainfile() so the entry file is detected on the new revision.
  • Persist the new revision plus entrypath / entryname / timemodified / usermodified in a single update_record() call.
  • Defer cleanup of leftover package files until the new revision is fully in place. If anything between the validation and the DB update fails, the previous revision is still recoverable.

• tests/exeweb_package_test.php (new)

  • Regression test exercising expand_package() + get_mainfile() against a non-zero itemid (the actual case for every online save after the first).
  • Demonstrates that calling get_mainfile() without an itemid silently returns false (the regression behind this issue).
  • Verifies that resources extracted from the package end up at the path the served HTML references, and that re-running expand_package() cleans up stale revisions.

Relationship to mod_exeweb#42

The 404 on content/resources/<uuid>.png reported in #42 is fixed on the eXeLearning side by exelearning/exelearning#1740 — the webzip is now generated in the browser (where the live Y.Doc and IndexedDB asset blobs are), and BaseExporter.addAssetsToZipWithResourcePath also writes each asset under its <assetId><ext> literal path so any stale content/resources/<uuid>.<ext> reference still resolves.

This PR does not make that symptom go away on its own. It addresses a separate, real consistency bug in Moodle: keeping the activity's entry-file bookkeeping in sync after every online save so entrypath / entryname / revision don't drift, and so the legacy server-side webzip fallback path doesn't keep stale references either.

Refs: mod_exeweb#42, exelearning/exelearning#1740

Test plan

• composer test (full PHPUnit suite under the bundled Moodle docker image).
• Manual: create an exeweb activity (default template), edit it via eXeLearning Online, save back, refresh the activity in Moodle and confirm entrypath / entryname reflect the new package and the entry file is served correctly.

---

Moodle Playground Preview

The changes in this pull request can be previewed and tested using a Moodle Playground instance.

⚠️ The embedded eXeLearning editor is not included in this preview. You can install it from Modules > eXeLearning Web > Configure using the "Download & Install Editor" button. All other module features (ELPX upload, viewer, preview) work normally.

[erseco]

Follow-up: the actual root cause (broken images served by Moodle when content comes from the Finish to Moodle path) lives on the eXeLearning side and is fixed in:

• fix(platform): generate ode package in the browser before forwarding to Moodle exelearning#1740 -- fix(platform): include images when finishing edit-online to Moodle

The client now flushes pending assets to the server before triggering platformPetitionSet, and the server-side exporter writes each asset under both its resolved path and its <uuid><ext> fallback path so 404s like the one in this issue stop happening even if a stale reference slips through.

This Moodle-side PR (#44) keeps the entry-file metadata and package filearea in sync after each online save, complementing that fix.

[ignaciogros]

Same results in my tests:

I insert an image using the online version, but the image throws a 404 error in Moodle