Editor image issues

[conorriches]

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

• https://editor.raspberrypi.org/en/projects/world-happiness-measures
• https://projects.raspberrypi.org/en/projects/mapping-data

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?

[conorriches]

Working notes

I am not in Thurs or Fri, so I'm writing down where we are up to

Problem 1 - editor not loading on block to text branch

1. Visit https://block-to-text-integration.projects-ui.pages.dev/en/exercises/example-exercise
2. Note that web-component.js loads in dev tools
3. Press "run" and note that p5.js and p5-shim.js fail to load

• it seems that these URLs are https://staging-editor.raspberrypi.org/branches/output_only_wc/shims/processing/p5/p5-shim.js
• instead of https://staging-editor-static.raspberrypi.org/.../shims/processing/p5/p5-shim.js
• QUESTION: should we be on the 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 main

Things tried

• Purging the cache so that the new env var comes through ✅ (Thanks Greg!)
• Updating the path so that the incorrect URL provides the correct file

[grega]

I'm still unclear where the ASSETS_URL env var is being set for this deployment:

editor-ui/src/components/Editor/Runners/PythonRunner/PythonRunner.jsx

Lines 46 to 47 in 00dbfc2

	path: `${process.env.ASSETS_URL}/shims/processing/p5/p5-shim.js`,
	dependencies: [`${process.env.ASSETS_URL}/libraries/processing/p5/p5.js`],

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:

• https://github.com/RaspberryPiFoundation/terraform/blob/d1c71c24ab78be8f89801cf9a1c074e57b198ba1/projects/projects-ui/prod/terraform.tfvars#L24
• https://github.com/RaspberryPiFoundation/terraform/blob/d1c71c24ab78be8f89801cf9a1c074e57b198ba1/projects/editor-standalone/prod/terraform.tfvars#L19

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:

• Added a page rule here which forwards anything on 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 successfully
• Added in a Access-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 returned

These 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.

[sra405]

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
• Due to using a feature branch (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.
• With us switching back to 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 needed

[conorriches]

Cheers 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):

• We managed to find the env var that was set to the 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.
• It then became clear there was an issue (as Scott mentioned above) with the implementation of 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.
• To fix, we instead set the project identifier - this means the project loads both assets and code from 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.
• I'll create a ticket for the assets identifier work

This should explain Problem 1 and Problem 3

[sra405]

CSV issues should now be solved with #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 🤦

[grega]

I've now deleted the temporary page rule and response modifier in Cloudflare (had seen they had already been disabled) 👍

[conorriches]

Closing as I believe this is now resolved, and the constant reloading issue doesn't appear to have persisted

[conorriches]

Thanks all for your input and help with this!