Preload-application-data not loaded via hashed path but just via /preload-application-data.js

  1. why is this searched for in “/” and not in “/assets/”?
  2. why is it not using the hashed path in first place?

This happens since the upgrade to discourse-2.2.0.beta2~git119.819f090d6a

as a workaround I did:

assets $ zcat preload-application-data-4f43211de8a1f76fb8517554d5f9476615a1073e596b45352abcc0f64a8301d2.js.gz \
  > ../preload-application-data.js

FWIW: i tried with a revert for

but that change did not break it.

But it could be that the original change in

already broke it.

@xrav3nz

3 Likes

I cannot reproduce this on meta or a few other self-hosted instances:

<script src="https://d11a6trkgmumsb.cloudfront.net/assets/preload-application-data-4f43211de8a1f76fb8517554d5f9476615a1073e596b45352abcc0f64a8301d2.br.js"></script>

but your site indeed only links to /preload-application-data.js :thinking: and safe mode didn’t help.

Are you already on a fork of Discourse? What third-party plugins do you have installed?

3 Likes

Darix has a special unsupported install, if we can not reproduce here or on sites using the official docker install this is not a bug

2 Likes
  1. we don’t run a fork. we package the tests-passed branch into an rpm.
  2. we apply the following changes:

I hope this clarifies a bit the differences that you might find in our package.

back to the original problem:

There is one more file that gets loaded from the wrong path /google-universal-analytics.js. Which part of the asset pipeline would normally decide which path to pick for an asset? What does the mapping between unversioned string in the template to the hashed path on disk?

P.S.: the only reason why we upgraded right now was this annoying bug with sidekiq staying in paused mode because of backups. which then broke light boxes for local images and mails.

forgot to mention : only plug-ins which are in the main repos

Can you reproduce any of these issues on our official docker install?

3 Likes

I have an even better finding: on our 2nd instance which has no theme customizations (like our top bar) but otherwise the same RPM, this does not happen. need @Patrick_David around for poking the theme :slight_smile: (he is the boss after all)

to make the confusion even better: just restarted discourse again because some underlying C libraries got updated, and the issue resolved it self. this is highly confusing.