Problem/Motivation

The cl-server module implements the hook_file_url_alter and this breaks the URLs of CSS and Javascript files as it appends the Scheme and HTTP Host to the file URI.

Steps to reproduce

Assuming you have the setup for Component Development using CL Components / CL Server and Storybook-drupal-addon. You can use the example components from cl_components_examples under cl_components.

I am testing it with a Vanilla Drupal 9.4 site with Olivero theme.

1. Run Story book - npm run storybook
2. Open explorer and point to http://localhost:6006 (this should be the link with default settings)
3. The example components will load.
4. Open the network tab and you will see that all the stylesheet and javascript links from the theme (usually with name starting with css_ or js_) are not loading.
5. Click on any one of these links and you will see that the Request URL is malformed like http://localhost:8080/public://css/optimized/css_97htjIvQ15V1EfeTASftshiMIzLS36LIXVDogWwnlWQ.jljVGWN9UpDBDhlOvibVHSAxjCOZonuvT1tJeWFbkHY.css?rjjf8c

Attached files showing the effects of the fixing the files.

Proposed resolution

Update the hook_file_url_alter in cl_server module to make sure the proper file URL is created.

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork cl_server-3314712

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

pavanmalji created an issue. See original summary.

avpaderno’s picture

e0ipso’s picture

Status: Active » Postponed (maintainer needs more info)

Can you confirm you followed the configuration guide for Storybook?

https://git.drupalcode.org/project/cl_server/-/blob/1.x/docs/storybook.md

pavanmalji’s picture

As I had an existing Drupal project, I skipped the Drupal site install. I followed the rest of the steps as described. I am trying to debug the issue but keep circling back at hook_file_url_alter in cl_server module file. I will try the setup from scratch and post the findings.

apotek’s picture

Confirming that we are seeing something similar:

https://foo.com/public:/css/css_zxa1V-vXt55-TF0hf24Omulyjsuhl19p9MPKhITP...

Difference is that for us, there is only one `/` after `public:` whereas poster has two.

But a similarity I can't help but note is that we are both using css aggregation.

  if ($route_name !== 'cl_server.render') {
    return;
  }
  $uri = implode('/', [$request->getSchemeAndHttpHost(), ltrim($uri, '/')]);

I wonder how aggregation changes the $route_name.

As a side note, and as a matter of slightly more readable code, I might patch as follows, but it won't solve the bug.

  if ($route_name === 'cl_server.render') {
    $uri = implode('/', [$request->getSchemeAndHttpHost(), ltrim($uri, '/')]);
  }

deviantintegral made their first commit to this issue’s fork.

deviantintegral’s picture

Version: 1.0.0-rc3 » 1.x-dev
Status: Postponed (maintainer needs more info) » Needs review

We just ran into this one too. It can be worked around by disabling CSS and JS aggregation. However, if we check for the scheme, \Drupal\Core\File\FileUrlGenerator::doGenerateString() will make this absolute and the correct hostname will be used.

I've opened an MR fixing this.

e0ipso’s picture

Status: Needs review » Reviewed & tested by the community

This is a good catch! I didn't anticipate the need to have aggregation on while developing with CL Server on. But I see it's a fair ask.

e0ipso’s picture

Status: Reviewed & tested by the community » Fixed
e0ipso’s picture

Status: Fixed » Needs work

Re-opeining to port to 2.x as well.

e0ipso’s picture

Version: 1.x-dev » 2.x-dev

e0ipso’s picture

Status: Needs work » Fixed
apotek’s picture

Version: 2.x-dev » 1.0.0-rc3
Status: Fixed » Postponed (maintainer needs more info)

Thanks for the quick work on this @deviantintegral & @e0ipso. I'm looking at the fix, and thinking about... what happens to `private://`

It seems what we need, rather than string matching the name of the stream wrapper, a solution that considers the kind of stream wrapper we are dealing with and adjusts accordingly.

We bear in mind too, that public:// is just a convention within Drupal.

I still think the fix is a step in the right direction. I'm just not sure it is complete. I guess we'll see. In any case. thank you for the fix.

avpaderno’s picture

Version: 1.0.0-rc3 » 2.x-dev
Status: Postponed (maintainer needs more info) » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.