Closed conorriches closed 1 month ago
I am not in Thurs or Fri, so I'm writing down where we are up to
web-component.js
loads in dev toolsp5.js
and p5-shim.js
fail to load
https://staging-editor.raspberrypi.org/branches/output_only_wc/shims/processing/p5/p5-shim.js
https://staging-editor-static.raspberrypi.org/.../shims/processing/p5/p5-shim.js
output_only_wc
branch? I recall hearing we should be using main
and that the editor_output_wc
branch isn't meant to be merged as the equivalent work has already been done in mainI'm still unclear where the ASSETS_URL env var is being set for this deployment: https://github.com/RaspberryPiFoundation/editor-ui/blob/00dbfc27d95434d24d30f8eab0ce7c344d58d644/src/components/Editor/Runners/PythonRunner/PythonRunner.jsx#L46-L47
But yes can confirm that I am seeing the result as being https://staging-editor.raspberrypi.org/...
rather than https://staging-editor-static.raspberrypi.org/...
Despite these two values:
As with Conor's note above, I'm also confused with exactly what the output_only_wc
branch is and where it's deployed to (and should it not be main
?)
In order to unblock, I've done two things:
https://staging-editor.raspberrypi.org/branches/output_only_wc/*/processing/p5/*
to https://staging-editor-static.raspberrypi.org/branches/output_only_wc/$1/processing/p5/$2
- this allows p5.js and the shim to be loaded successfullyAccess-Control-Allow-Origin: *
response header here, as even when loading the p5 and shim JS using the redirect above, there was a CORS error being returnedThese are of course a bit heavy-handed and not meant to be long-term fixes by any means, but do allow https://block-to-text-integration.projects-ui.pages.dev/en/exercises/example-exercise to be run successfully eg.
Just wanted to pop a couple of quick responses here initially:
ASSETS_URL
is set in the web component build pipeline, its a little too implicit for my liking but I've never had time to sort it but here it's being set for prod with all other builds falling back to the default value.ASSETS_URL
is needed for the the editor web component to obtain the correct custom libraries and shims. This wasn't needed when we had the interface in the same app as the editor React application because it defaults to the root of the host app but now we're exclusively using the web component its needed all the time.output-only-wc
was a feature branch used to add the required behaviour for the block to text alpha (PR here), it wasn't productionised as is but rather done incrementally, but we've since found out things like the asset-identifier
doesn't work. Other than that all the functionality should be in main
output-only-wc
) that predated the editor web component separation the ASSET_URL
wasn't set in this build so it'll try and source the Skulpt libraries and shims from the apps root.main
- must've been a manual change because projects-ui using the same web component for the projects x editor integration pages (set in tf here) - the ASSET_URL
is not an issue so the page rules aren't neededCheers both!
Just a note after working with @sra405 today (Scotts message above literally just came through while typing, so I'll try to be concise):
output_only_wc
thus causing the wrong URLs. This change wasn't reflected in Terraform, so setting this to the default value and rebuilding on GitHub via GitHub actions set the correct URLs.asset-identifier
; despite working originally, somehow this functionality hasn't remained functional as hoped. This meant the project doesn't load images, hence the image errors.bridge-prototype
project, with the code immediately being overwritten by the code provided. The aim of separating code and asset loading was to not have to overwrite anything which should make things simpler and more predictable in the future. However it's not essential.This should explain Problem 1 and Problem 3
CSV issues should now be solved with https://github.com/RaspberryPiFoundation/editor-ui/pull/1062 - this appeared initially to be image issues however only impacted specific projects, it turned out these were loading in data or files that weren't properly attached to the DOM for Skulpt to pickup from the shadow DOM 🤦
I've now deleted the temporary page rule and response modifier in Cloudflare (had seen they had already been disabled) 👍
Closing as I believe this is now resolved, and the constant reloading issue doesn't appear to have persisted
Thanks all for your input and help with this!
Background
When working on the Block to Text editor, it was noticed images weren't loading which prevented progress through the steps.
Problems
Problem 1 - editor not loading on block to text branch
PROBLEM SOLVED - Scott identified env var and rebuilt
As a precursor to all of this, it was noted the editor doesn't load on the block-to-text-integration preview branch
This is due to a CORS error, it seems that the API images route won't allow the domain. Yesterday, I (Conor) updated the ALLOWED_ORIGINS env var to include this domain and rebuilt on staging, but the error persists
Problem 2 - images not loading on production
PROBLEM IDENTIFIED - CSV issue
Scott found these two URLs where images aren't loading
Problem 3 - images referenced by local name
LIKELY SOLVED - linked to problem 1
Locally, when everything is set up and running, and run Step 7 on block to text (local url), I noticed that the editor was asking for
dog.webp
which resolved to a localhost URL, instead of requesting this image from editor-api, which would return a rails active storage URL. There is a new environment variable (ASSETS_URL='https://staging-editor-api.raspberrypi.org/'
) but this didn't seem to do the trick.For some reason this requests the image name instead of the image URL
Problem 4 - editor can constantly reload
Magda has an issue locally where the editor constantly reloads. @magdalenajadach mind filling this bit in on any symptoms?