public_dir option does not seem to work

[fgabolde]

The Dancer2::Config POD documents the public_dir option, but it doesn't seem to do anything.

After looking at the Dancer2::Handler::File code I can't figure out when the Handler object is actually created and registered. In any case, DANCER_PUBLIC seems to work (although undocumented), so it might be an issue of loading the config after the handler is registered.

Steps to reproduce:

$ dancer2 -a MWE::PublicDirDoesNotWork
$ cd MWE-PublicDirDoesNotWork
$ mv public foo
# edit config.yml, add "public_dir: foo"
$ plackup bin/app.psgi
# visit http://localhost:5000 or wherever your Plack::Handler lives: all requests to static assets 404

[plicease]

I think this is the problem:

https://github.com/PerlDancer/Dancer2/blob/master/lib/Dancer2/Core/App.pm#L556

The setting static_handler is dependent on the default public directory existing, so when you move public to foo and change the configuration it correctly changes the public dir but turns off the static handler.

My work around for this was to set static_handler => 1.

[fgabolde]

I see!

That indeed seems likely. It would fit the symptom of working with DANCER_PUBLIC, too.

I'll test your workaround tomorrow at work.

[rleir]

Agreed, the workaround works:
static_handler: 1

I am triaging: should we accept the workaround and close this issue, or would you like to pull? Or leave it open a while?

[fgabolde]

@rleir At the very least, the workaround should be documented before this issue is closed, don't you think?

I can't speak for the devs of course, but I think this should be considered a bug.

If the devs don't have tuits to work on this (it's admittedly not a deal breaker and like you said there's a workaround) I can provide a patch, but it won't be ready any time soon.

[plicease]

I agree with everything @fgabolde said in the previous comment.

[sdeseille]

Hello

I will be happy to update documentation and make pull request to fixe that.
Can I ?

regards

sdeseille

[sdeseille]

I found public_dir entries in Config.pod and Manual.pod. I made test to validate each case described in documentation.

Do you know if their is another place where public_dir is mentioned ?

[sdeseille]

I created branch "update_documentation_about_public_dir" in order to propose the pull request.

[cromedome]

Migration.pod, line 55.

[cromedome]

While the the workaround seems fair, I agree with fgabolde, I think i's a bug that should be fixed.

I looked through things and if I am following right, the default config is built, ConfigReader reads any additional files and merges their contents with the default config. Nowhere is the test for static_handler rerun (validating plicease's observation). My question is, at what point in the ConfigReader is it appropriate to reset that? My gut tells me at the very end of _build_config(), but would anyone else like to weigh in?

Unrelated, there is a TODO at the end of load_config_file() (it's probably mine) regarding merging config files. As this is now handled in _build_config(), I will take the TODO out if I'm ok to fix the static_handler bug.

Anyone have a preference for where the recheck to set that bit should live?

[sdeseille]

Thank you @cromedome . I updated Migration.pod. Would you check my branch before i do pull request ?

regards

sdeseille

[cromedome]

That looks good to me, @sdeseille!

I apologize in advance if you're writing a doc patch for something I end up fixing :) Your changes look good though!

[sdeseille]

Don't worry. I'm happy ;)

[cromedome]

I would like to add a _validate_config() method to Dancer2::Core::Role::ConfigReader that looks for situations like this, where changing one setting from default might require us to alter/check/correct/set another setting. For now, this would be the only case that we are checking for, but it gives us some plumbing in case we run across other instances where this might occur.

Thoughts?

[cromedome]

Forgot to mention, this would get added around _normalize_config() in the existing _build_config() method.

[xsawyerx]

I also agree this is a bug that needs fixing. I'm tentatively adding this to the next milestone. If we can't get around to it, we'll shift it to the next one.

[xsawyerx]

I have a fix for this, but while writing the test, I think I discovered another bug in the code somewhere. I'll try to prepare pull requests for both issues tonight.

[xsawyerx]

Scratch the "two bugs" thing. I have a fix and a test.

[xsawyerx]

Okay the punk show drained me. Patch incoming today.

[xsawyerx]

Alright. Fix provided. This does expose another problem which I'll try to fix as soon as I figure out how.

[xsawyerx]

The fix for this was already applied in the previous version. This can be closed.