-
Notifications
You must be signed in to change notification settings - Fork 13
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
Leading/trailing slash resiliency #22
Comments
Hi @nixjdm :-)!
I would fix this in core? And maybe here we could make it just work in case leading is missing? |
Thanks @nixjdm, that was very helpful. It's indeed pretty fragile. This worked for me:
and deleting |
Fixing only the trailing slash here makes sense to me. |
Note a few workarounds were needed, discussion on lektor/lektor-atom#22 and issues linked to it.
Note a few workarounds were needed, discussion on lektor/lektor-atom#22 and issues linked to it.
I noticed this looking at #20 (note @rgommers, @goanpeca ). As of 0.3 this plugin / virtual path resolver is not resilient against different formats of supplying source_path (at least) url fragments in the config file.
In my testing with this site and a simplified config and template fragment of
The jinja only correctly resolved with
source_path = /blog
./blog/
,blog/
, andblog
all failed, resulting in a broken rendered template path ofblog@atom/feed
. This shouldn't be so picky. I'm thinking at least the trailing slash should be optional. There may be a good reason to have to pick the presence of a leading slash though (relative v. absolute).At the moment I'm not sure where this should to be addressed; here, core, or partially in both.
The text was updated successfully, but these errors were encountered: