Remove external CSS dependencies from Parsons iframe and use Moodle theme styles

[bpinger]

Problem

The Parsons iframe styling relied on externally loaded and outdated CSS dependencies. This introduced unnecessary CDN dependencies and could lead to inconsistencies with the active Moodle theme.

Solution

• removed external Bootstrap and Font Awesome CSS imports from the sortable stylesheet
• updated the Parsons iframe rendering logic to use Moodle theme-provided styles instead
• synced the minified CSS with the source stylesheet changes

Testing

Tested with:

• Moodle 4.5
• Union Boost Theme

Verified:

• Parsons blocks still render correctly in the iframe
• icons and layout are displayed correctly
• no external CSS dependencies are required anymore
• rendering remains consistent with the Moodle theme

[sangwinc]

Thanks @bpinger for pointing this out, and so helpfully suggesting a fix. We'll merge this into "dev" (rather than master) for testing and the next release once I've had a chance to review it.

@jcopado could you have a look at this proposed change and check it's not problematic at your end?

We already refer to the global $PAGE elsewhere, e.g. here: https://github.com/maths/moodle-qtype_stack/blob/master/stack/cas/castext2/blocks/iframe.block.php#L99

One way or another, we will bring this in-house as you suggest.

[EJMFarrow]

Hi @bpinger - thank you! I'm having trouble testing this, though. I'm getting CORS errors with the fonts.

Hacking https://github.com/moodle/moodle/blob/MOODLE_405_STABLE/theme/font.php to include header('Access-Control-Allow-Origin: *'); fixes it but that's obviously not ideal. It may be my local set up is screwy but I'm wondering if your server is setup to always allow cross origin?

[bpinger]

Hi @bpinger - thank you! I'm having trouble testing this, though. I'm getting CORS errors with the fonts.

Hacking https://github.com/moodle/moodle/blob/MOODLE_405_STABLE/theme/font.php to include header('Access-Control-Allow-Origin: *'); fixes it but that's obviously not ideal. It may be my local set up is screwy but I'm wondering if your server is setup to always allow cross origin?

Hi @EJMFarrow, thanks for the feedback! You’re absolutely right – we hadn’t considered that our configuration automatically handles CORS headers correctly. The issue with the wildcard header is a quick and dirty workaround, and I'm with you that this is not ideal. I’m going to revisit this and attempt to resolve the issue without additional header. I’ll update the pull request accordingly, reflecting your observation and thanking you again for bringing this to our attention.

[aharjula]

I was expecting that response; by default, Moodle does not and has no reason to add Access-Control-Allow-Origin: * to its responses. But those sandbox iframes need it, and it really needs to be * as a sandbox has no origin to match.

Realistically, we cannot force Access-Control-Allow-Origin onto a Moodle install, especially a publicly visible one; it might make all sorts of security scanners excited. The best we could do is to proxy specific pre-listed things through the current corsscripts folder and its PHP header logic. We cannot simply proxy the whole Moodle install; we don't want to give too much information to the sandbox, nor do we want that proxy, which would have to run without authentication, to trigger expensive pages to render. So it would need to be a tightly limited set of largely static content.