Add embedded static editor support#25
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
ignaciogros
left a comment
ignaciogros
left a comment
There was a problem hiding this comment.
Thank you for this great tool, @erseco.
I've been testing with Moodle 4.5.10 using the static editor.
If you add a new activity an click on "Save and display" you go to the activity page, in which you can see the default content. I was expecting to go to eXe to create a new one.
Apart from that, just two details:
The "Edit with eXeLearning buttons" work, but:
- They're visible even when Moodle's "Edit mode" is off.
- The button's too close to the top of the screen when the viewer's full-screen mode's on.
|
I suggest creating a new branch for this and integrating the development into this repository as soon as possible, so it's easier to contribute. |
erseco
dismissed
ignaciogros’s stale review
Thanks for the review.
About “Save and display”, this currently follows Moodle’s usual flow: the activity is created first and then its page is shown. We could make it open eXe directly after saving, but that would require an extra refresh/redirect.
It is also the same flow used when uploading an .elpx, so changing it only for this case would feel a bit inconsistent. I think it is better to keep it as is, even if it means one extra click.
|
Replace inline github-script with the reusable action. The workflow reads blueprint.json, swaps the plugin URL to the PR branch, and passes it to the action which handles the comment lifecycle.
pull_request_target runs the workflow from the base branch, so changes to the workflow file on a PR branch are ignored. Switch to pull_request which runs the version from the PR branch and works for same-repo PRs.
The action now reads blueprint.json directly and auto-swaps plugin URLs for the PR branch. No intermediate github-script step needed.
The GITHUB_TOKEN lacks write permissions on the base repo when the PR comes from a fork. Skip the job entirely in that case.
…ontent to blueprint
Set display=1 (Embed) so content renders inline instead of showing a "Click link to view" download link.
Non-admins see "contact your site administrator", admins see a link to the plugin settings page. Translations added for en/es/ca/eu/gl.
Build the link with target=_top directly in the HTML output instead of passing it through lang strings where Moodle HTML Purifier strips the target attribute.
Remove link button that navigated incorrectly inside iframe. Admin now sees a text message to install from plugin settings.
- Remove unused $cmid parameter from exeweb_editor_error_page() - Remove unused embeddednotinstalled base string (only admin/contactadmin variants are used) - Fix concatenated string definitions on same line
Change the editor install/uninstall UX to match wp-exelearning: - Button text changes to "Installing..." / "Removing..." while running - Spinner with message "This may take a minute..." instead of progress bar - Translations added for en/es/ca/eu/gl
Extract only the origin (scheme + host) from wwwroot instead of using the full URL. The EmbeddingBridge compares message origins which don't include the path, causing "Rejected message from untrusted origin" on deployments with a subpath (e.g. Moodle Playground).
3 participants
This PR keeps the embedded static editor work and also updates the build/release flow: the editor is now fetched dynamically, built into the plugin, and packaged through the new Makefile and GitHub Actions workflows.
@pabloamayab I accidentally closed the previous PR #24 when I did a force-push to clean up the history, so I opened this new one.
I’ve also addressed the issues you reported in the previous PR. Could you please check this one again when you have a moment?
To test the embedded editor on the server, you need to run:
Thanks.