Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assets Broken in Menu Routes when using /kalastatic/prototype #24

Open
soniktrooth opened this issue Dec 9, 2016 · 15 comments
Open

Assets Broken in Menu Routes when using /kalastatic/prototype #24

soniktrooth opened this issue Dec 9, 2016 · 15 comments

Comments

@soniktrooth
Copy link
Contributor

So I've run into a bit of an issue when it comes to serving the css and js through the menu route I set up.

After running some tests it seems that when trying to access a js or css file that is not inside the /themes folder then Drupal doesn't even boot—I get a server level 404. This isn't the case for html files which we are already successfully serving at kalastatic/*.

So I'm figuring there must be some sort of .htaccess type file that id ensuring a super quick 404 on css/js files that it assumes are never going to be a thing (even though we do, in fact, want it to be a thing). I don't see an .htaccess anywhere so I'm guessing this sort of thing is handled in some other manner for D8 and at that point my eyes start to glaze over.

I'm thinking this is a @RobLoach type issue. @RobLoach do you know what's causing this and if so do you think there's a way around it?

For now I'm considering serving Kalastatic from /themes/kalastatic/* just in order to get it working as a stop gap but any other suggestions would be welcome.

@soniktrooth
Copy link
Contributor Author

ok, so I tried prepending the routes with /theme but it still didn't work. It's almost like it knows that it's not a file path.

@soniktrooth
Copy link
Contributor Author

soniktrooth commented Dec 9, 2016

So I stumbled upon web.config which looks like it could be the new .htaccess. And particularly this part of it:

        <rule name="Short URLS" stopProcessing="true">
          <match url="^(.*)$" ignoreCase="false" />
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
            <add input="{URL}" pattern="^/favicon.ico$" ignoreCase="false" negate="true" />
          </conditions>
          <action type="Rewrite" url="index.php" />
        </rule>
      </rules>

@soniktrooth
Copy link
Contributor Author

This makes me think that our paths to css/js files SHOULD be hitting index.php but as far as I can tell it's not. I tried putting a print_r() in the index.php and it never gets fired when visiting a css/js url within the prototype. So basically we need to either work out what's stopping this and reverse it or it may be possible to write a rule in web.config that makes sure any request—regardless of extension—make's it's way to Drupal. This is, however, firmly above my pay grade and I will require the melding of keener minds such @RobLoach and @derekderaps.

@soniktrooth
Copy link
Contributor Author

Had a good jam session with @RobLoach and @derekderaps and aside from some whacky ideas about .kalacss files, we came up with the following solution:

  • enforce the build folder to live at the web root and make sure it's named kalastatic.
  • nest all prototype html files inside a folder called prototype.

With this in place the server will find the css and js files because the url path matches the file path.

This means that a user can't provide a path to Kalastatic in the config and renders the main config page pointless. I am, however, seeing this as a stop gap and I'm hoping @RobLoach will be able to figure out some magic that will enable us to provide server config to override the default behaviour that fast 404s the css and js when it doesn't exist in the file system.

@RobLoach RobLoach changed the title Serving css and js for prototype Assets Broken in Menu Routes when using /kalastatic/prototype Jan 17, 2017
@RobLoach
Copy link
Contributor

RobLoach commented Jan 17, 2017

CSS/JS requests that are 404s are meant to be passed off to the menu router so that kalastatic can deliver it properly. The problem is that nginx reports a 404 before it can get to the menu route.

Workaround has been taken to build out to /kalastatic.

@soniktrooth
Copy link
Contributor Author

soniktrooth commented Jan 27, 2017

@RobLoach @derekderaps I made an interesting discovery today—the pathing issues we’ve been having with Kalastatic D8 may not be a D8 issue after all. I just noticed on progenity that I’m having the same issue when visiting the prototype at http://progmi.dvm/kalastatic/prototype: the index.html file loads but none of the css/js loads. So, as you know PROGMI is a D7 site, so I checked HSA—same deal. Further, I checked http://sprint-progenitycom.at.kalamuna.com/kalastatic/prototype/index.html which works fine. So it would seem to me that this is an nginx config issue that exists on both DVM and whatever fancy thing @RobLoach is using, or probably more to the point, a default ngnix behaviour. I did a bit more digging and pinged @pirog about it and he reports that Kalabox does it's best to mimic Pantheon so I'm going to give it a go over there and see whether or not we have the same issues.

@derekderaps are you able to look into getting DVM to mimic Pantheon's nginx config?

@pirog
Copy link

pirog commented Jan 29, 2017

https://github.com/kalabox/kalabox-app-pantheon/tree/v2.1/app/config/nginx

@hawkeyetwolf
Copy link

Looks like we can customize nginx as needed, just gotta figureo ut the write configs. I'll add it to my list to look at!

@soniktrooth
Copy link
Contributor Author

Thanks for looking at this @derekderaps. Check out @pirog link to see what they are doing in Kalabox. I haven't confirmed yet that it def works on Kalabox but I will report back when I get a chance

@hawkeyetwolf
Copy link

Hmmm, adding in those configs from kalabox didn't seem to make a difference: nginx still won't serve dynamic routes that end in .css and .js. There is another solution, which will be needed in Drupal 8 anyway since it doesn't automatically serve parent path content for non-existent child paths. And the solution is to just read the entire build directory and provide custom routes for each one. Yucky, but necessary.

In D7 land though, I'm just going to go ahead and set Drupal VM's default webserver to Apache, cuz, um, that fixes it!

@soniktrooth
Copy link
Contributor Author

@derekderaps as I mentioned in Slack, adding routes for ALL THE THINGS that isn't necessary anyway for D8 because I've climbed that mountain already.
See:
https://github.com/kalamuna/kalastatic_dot_module/blob/8.x-2.x/kalastatic.routing.yml
https://github.com/kalamuna/kalastatic_dot_module/blob/8.x-2.x/src/PathProcessor/KalastaticPathProcessor.php

The problem doesn't exist on Pantheon or KB so there has to be a way...
giphy-1

@hawkeyetwolf
Copy link

One other note about D7, it only works (with Apache) when Fast404 is disabled. Fast404 essentially does what nginx does by default: for certain filetypes, it detects whether the file exists and skips the whole bootstrap.

@hawkeyetwolf
Copy link

The problem doesn't exist on Pantheon or KB so there has to be a way...

I know "there's a way," I just don't know what the setting is and am not motivated to dive into the devops and figure it out.

@hawkeyetwolf
Copy link

Alrighty, I've switched the default DrupalVM webserver from nginx to apache. You'll need to either destroy and rebuild or (1) ssh into the box and remove nginx from startup (sudo update-rc.d -f nginx disable) and then restart+provision (vagrant reload --provision).

I would say after adding a note about Fast404 in the Kalastatic documentation, this issue can get closed out. @soniktrooth, where do you think is a good place for that note? Would you do the honours?

@hawkeyetwolf
Copy link

Adding a stackoverflow link from @soniktrooth for me to check out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants