From b9df5cdb9c3260c35499df4da6d2be8785b3bcca Mon Sep 17 00:00:00 2001
From: Kyle McCormick <kyle@tcril.org>
Date: Wed, 28 Jun 2023 15:19:22 -0400
Subject: [PATCH] fix: flow `?site_theme` down through Studio container preview

In ~Palm and earlier, all built-in XBlock Sass was included into CMS
(and LMS) styles before being compiled. So, if a site theme was meant to
affect built-in XBlock styling, those changes would be manifested
directly in the base CMS CSS that is included into every single Studio
page. When the user provided the `?site_theme` querystring parameter,
which is intended to allow devs & admins to view Studio through a given
theme, CMS would look up the given theme and serve the corresponding
base CMS CSS, which would affect the built-in XBlocks views (as
expected).

After ~Palm, built-in XBlocks styles are handled more similarly to to
pure XBlock styles, in that they are only requested when CMS tries to
render the block. In Studio, blocks are not rendered by the original
request, but by a subsequent AJAX request to the `/container_preview`
enpoint. Thus, passing the `?site_theme` query parameter to the original
request will apply the given theme to Studio's chrome, but the theme
will _not_ apply to built-in XBlock views, whose CSS is now loaded via
async request.

To fix this, we simply pass Studio's querystring parameters (including
`?site_theme`) along to the `/container_view` AJAX request. This will
cause CMS to correctly serve the built-in XBlock CSS from the theme
specified by `?site_theme`, rather than whatever the current theme is.

Part of: https://github.com/openedx/edx-platform/issues/32292
---
 cms/static/js/views/xblock.js             | 5 +++--
 openedx/core/lib/xblock_utils/__init__.py | 2 +-
 xmodule/assets/README.rst                 | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/cms/static/js/views/xblock.js b/cms/static/js/views/xblock.js
index 2330c9deb51..6b913d5239d 100644
--- a/cms/static/js/views/xblock.js
+++ b/cms/static/js/views/xblock.js
@@ -23,9 +23,10 @@ function($, _, ViewUtils, BaseView, XBlock, HtmlUtils) {
             var self = this,
                 view = this.view,
                 xblockInfo = this.model,
-                xblockUrl = xblockInfo.url();
+                xblockUrl = xblockInfo.url(),
+                querystring = window.location.search; // pass any querystring down to child views
             return $.ajax({
-                url: decodeURIComponent(xblockUrl) + '/' + view,
+                url: decodeURIComponent(xblockUrl) + '/' + view + querystring,
                 type: 'GET',
                 cache: false,
                 headers: {Accept: 'application/json'},
diff --git a/openedx/core/lib/xblock_utils/__init__.py b/openedx/core/lib/xblock_utils/__init__.py
index bb7f78e523f..0910018f604 100644
--- a/openedx/core/lib/xblock_utils/__init__.py
+++ b/openedx/core/lib/xblock_utils/__init__.py
@@ -452,7 +452,7 @@ def xblock_resource_pkg(block):
        ProblemBlock, and most other built-in blocks currently. Handling for these
        assets does not interact with this function.
     2. The (preferred) standard XBlock runtime resource loading system, used by
-       LibrarySourdedBlock. Handling for these assets *does* interact with this
+       LibrarySourcedBlock. Handling for these assets *does* interact with this
        function.
 
     We hope to migrate to (2) eventually, tracked by:
diff --git a/xmodule/assets/README.rst b/xmodule/assets/README.rst
index c63fd5126d3..c87642384f6 100644
--- a/xmodule/assets/README.rst
+++ b/xmodule/assets/README.rst
@@ -1,7 +1,7 @@
 xmodule/assets: edx-platform XBlock resources
 #############################################
 
-This folder exists to contain resources (ie, static assets) for the XBlocks
+This folder exists to contain resources (i.e., static assets) for the XBlocks
 defined in edx-platform.
 
 Concepts