daux serve doesn't work with custom themes

[danielskeenan]

When using a custom theme not in the vendor/daux/daux.io/themes directory, the resulting page has no stylesheets or javascripts applied or run. The console output also does not show those files being served as it usually does when a default theme is used and the browser requests stylesheets etc.

Custom themes do work when using daux generate, it is only daux serve that does not use them.

[JKingweb]

I was just about to report this, myself. Are you using an equivalent structure to the Daux theme i.e. JavaScript files in a js folder, CSS files in a css folder, etc.? It seems to me maybe the serve script is inferring content type from the containing folder. As far as I can tell it's serving the files, but as text/plain, which browsers honour.

[danielskeenan]

Initially I thought I may have done something wrong, so I tried copying the themes/daux directory (containing the default theme) to my custom theme directory.

Interesting that it looks like it's serving files. I don't know enough about the internals to trace the server process without literally starting at the very beginning of the script, so I thought that by not logging the file it wasn't even getting the request.

[chw502]

It works if you put your theme in C:\Users\<UserName>\AppData\Roaming\Composer\vendor\daux\daux.io\themes. But I found that it doesn't serve image as well....

[onigoetz]

Hi, to successfully use a custom theme you need these things :

1. Create a themes/mytheme folder
2. Create athemes/mytheme/config.json file with at least {} inside (you can check what you can override here : https://daux.io/For_Developers/Creating_a_Theme.html )
3. Set the theme in your documentation's config.json : https://daux.io/Configuration/Html_export.html#page_Themes
4. Run the command with --themes=themes to tell where to look for themes.

If by following this it works, can you tell me what you missed and what I should add/change/clarify in the documentation ?

[jbllm]

Hi, it doesn't work for me following your steps.

Stylesheets in custom themes are served with the wrong mime even if i duplicate the default theme

Resource interpreted as Stylesheet but transferred with MIME type text/plain: "http://localhost:8085/themes/tucano/css/theme-red.min.css".

[danielskeenan]

I concur with @jbllm - following those instructions results in correct content being shown, but with no styles. This message appears in the Chrome developer console:

Resource interpreted as Stylesheet but transferred with MIME type text/plain: "http://localhost:8085/themes/custom/css/theme-red.min.css".

I do want to stress that daux generate has correct behavior (because the theme itself is copied wholesale to the output directory); this is only a problem when using the built-in server with daux serve.

[danielskeenan]

Here's some interesting info that at least seems to be the root cause of the problem, i.e. why only built-in themes are served properly using the built-in web server. Haven't figured out how to fix yet, but maybe these reverse-engineering notes will help.

Stepping through the entire process with the debugger reveals that serving static assets for built-in themes follows an entirely different (and much simplified) code path from custom themes. This is caused by the router script itself. That script causes any file that exists relative to the vendor/daux/daux.io directory to be served unmodified, i.e. Daux isn't even bootstrapped for that specific request. This will include the built-in themes.)

(Side note - the way this check works will also cause a separate bug - if your custom theme is called daux and contains a file with the same path as the built-in theme, that file will not be served from the custom theme directory but from the vendor directory because it exists there! If you only want to make trivial modifications to the built-in theme, be sure it's called something else.)

(Other side note - this also means that the entire documentation tree, processors and everything, is regenerated for each asset request. Probably not really a big deal, since performance while working on docs can't be that bad, but interesting to note nonetheless, as serving a site with a custom theme will be slower than one with the default theme.)

Daux handles custom themes by crafting its own response containing the asset file in question. However, for reasons I can't figure out, \Todaymade\Daux\Server\Server::createResponse() doesn't set the content type correctly, despite attempting to.

[danielskeenan]

This seems to be related to using the deprecated \Symfony\Component\HttpFoundation\File\MimeType\MimeTypeGuesser. The response uses a different guesser, so the ExtensionMimeTypeGuesser is registered in the wrong place. The referenced pull request fixes this issue for me.

[onigoetz]

(Other side note - this also means that the entire documentation tree, processors and everything, is regenerated for each asset request. Probably not really a big deal, since performance while working on docs can't be that bad, but interesting to note nonetheless, as serving a site with a custom theme will be slower than one with the default theme.)

This is on purpose as the serve option is meant for development, production should be done with the generated version. Although that would work for small documentation, it definitely wouldn't with big documentations.