You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a non-root site, something like SITE_URL = "https://example.org/blog/"
I start the development server, e.g., nikola auto -b
My expectation, and my suggestion for this feature request:
My browser is pointed to http://localhost:8000/blog/
The stuff from the output folder is made available below http://localhost:8080/blog/. That means, the post files are served by Nikola's development server under URIs http://localhost:8080/blog/posts/, the images under http://localhost:8080/blog/images/ and so on (assuming standard layout).
If I provide any static html files (which Nikola does not build) that contain absolute links (I'm thinking of <a href="/blog/..." ...>), those links will work seamlessly not only on the production site, but also inside the Nikola development server.
Related Area: (eg. tasks, compilers, configuration, templates…)
This needs change in nikola/plugins/command/auto/__init.py__. I think: Only.
Do you want to contribute this yourself as a pull request? (don’t worry about it if you don’t want to/can’t — someone else can take care of it)
Yes, I have already written code for it (link if available and feasible)
[✔] Yes, I don’t have code ready yet (that’s okay!)
No (that’s okay too!)
I intend to provide a patch after #3722 has been merged.
Does this feature affect backwards compatibility? If yes, in what way?
I'm not here suggesting any change whatsoever to the generation of stuff in output. I only want to change the presentation of that stuff to the local browser via the Nikola development server. So this feature would not affect backwards compatibility, as far as the produced output is concerned.
This proposed change even interacts nicely with livereload (as I found out via the "Better workaround" described below).
Rationale and full description: (why should it be added to Nikola?)
The Nikola development server is more useful, the better it reflects what the production system does.
With SITE_URL = "https://example.org/blog/", Nikola has an important piece of information about the production system that it presently rather ignores.
Quick and dirty workaround
Forget about the Nikola development server for now and use a different web server to serve locally (my machine happens to run an Apache anyway). Disadvantage: No livereload.
Better workaround
Run another local server as a proxy in front of the build-in development server.
For people also using Apache, like I do, this is the config that does the trick, provided you have proxy.load and proxy_http.load both enabled:
This workaround is somewhat deficient for stuff that is generated on the fly by the build-in server, e.g., listings of a directory without index.html file. The links that the build-in server generates (that point at files or subdirectories) do not work through the proxy. If this is implemented, auto-generated directory listing is an area to check.
But, more importantly: This works with livereload. So I conclude livereload would not be affected by this feature, should it be implemented.
The text was updated successfully, but these errors were encountered:
The combination of a non-root SITE_URL and URL_TYPE = "full_path" causes the development server to simply no longer work. The links generated in output are as expected, with leading /blog/, but the development server cannot resolve those links.
Requested Feature: (short description)
SITE_URL = "https://example.org/blog/"
nikola auto -b
My expectation, and my suggestion for this feature request:
http://localhost:8000/blog/
output
folder is made available belowhttp://localhost:8080/blog/
. That means, the post files are served by Nikola's development server under URIshttp://localhost:8080/blog/posts/
, the images underhttp://localhost:8080/blog/images/
and so on (assuming standard layout).<a href="/blog/..." ...>
), those links will work seamlessly not only on the production site, but also inside the Nikola development server.Related Area: (eg. tasks, compilers, configuration, templates…)
This needs change in
nikola/plugins/command/auto/__init.py__
. I think: Only.Do you want to contribute this yourself as a pull request? (don’t worry about it if you don’t want to/can’t — someone else can take care of it)
I intend to provide a patch after #3722 has been merged.
Does this feature affect backwards compatibility? If yes, in what way?
I'm not here suggesting any change whatsoever to the generation of stuff in
output
. I only want to change the presentation of that stuff to the local browser via the Nikola development server. So this feature would not affect backwards compatibility, as far as the produced output is concerned.This proposed change even interacts nicely with livereload (as I found out via the "Better workaround" described below).
Rationale and full description: (why should it be added to Nikola?)
The Nikola development server is more useful, the better it reflects what the production system does.
With
SITE_URL = "https://example.org/blog/"
, Nikola has an important piece of information about the production system that it presently rather ignores.Quick and dirty workaround
Forget about the Nikola development server for now and use a different web server to serve locally (my machine happens to run an Apache anyway). Disadvantage: No livereload.
Better workaround
Run another local server as a proxy in front of the build-in development server.
For people also using Apache, like I do, this is the config that does the trick, provided you have
proxy.load
andproxy_http.load
both enabled:This workaround is somewhat deficient for stuff that is generated on the fly by the build-in server, e.g., listings of a directory without
index.html
file. The links that the build-in server generates (that point at files or subdirectories) do not work through the proxy. If this is implemented, auto-generated directory listing is an area to check.But, more importantly: This works with livereload. So I conclude livereload would not be affected by this feature, should it be implemented.
The text was updated successfully, but these errors were encountered: