Don't reset site.url to localhost:4000 by default

[ashmaroli]

Local tests show that the local preview server is based on config["host"] and config["port"] values..
So even if config["url"] == https://jekyllrb.com, the site will be served at the default setting: //127.0.0.1:4000

This simplifies users' workflow by not having to build the site again with JEKYLL_ENV=production
(unless their templates are designed to render differently for the two ENV vars, which is a different story altogether)

P.S. The above observation was made on Windows. Please confirm for Unix platforms, if possible.

[DirtyF]

As long as default env is development and that in this context we serve on localhost, no matter what is in the config, I'm 👍

[ashmaroli]

@DirtyF Did you give this branch a test-run locally..?

[DirtyF]

@ashmaroli I tested my blog and jekyll's website locally and url equals site.url in feed.xml and robots.txt without having to specify production environment on the command line.

[DirtyF]

@jekyll: merge +minor

[benlk]

If you, like me, have found this ticket while trying to debug absolute_url using the wrong URL under bundle exec jekyll serve, or you have discovered that upgrading to 4.2 broke your local development workflow and have been pointed to https://jekyllrb.com/news/2020/12/14/jekyll-4-2-0-released/ as an explanation that this was a planned change, you will be happy to know that there's a command-line workaround documented in #8541 (comment)

[DirtyF]

@ashmaroli looking back at this change, I don't think it was the right move. 🤷

[benlk]

If conversation is going to be reopened on whether or not this change was the right move, I'll add my two cents:

This simplifies users' workflow by not having to build the site again with JEKYLL_ENV=production
(unless their templates are designed to render differently for the two ENV vars, which is a different story altogether)

When running bundle exec jekyll serve, with asset URLs piped through the absolute_url filter, under Jekyll 4.2, my localhost development site served at http://localhost:4000/ attempts to load assets like images, stylesheets, scripts, fonts and so on via the production URL https://example.com/. If those assets exist on the production server, then they load.

However, this PR's change leads to problems in the following cases:

• images not yet uploaded to the production server do not appear, instead failing with 404s
• stylesheets on prod don't have changes that were made to the http://localhost:4000/ version of the file
• scripts on prod don't match markup served from http://localhost:4000/
• font files fail to load because the production server doesn't supply a CORS header that allows their use on http://localhost:4000/

To avoid the problem of deploying files with http://localhost:4000/ URLs to https://example.com/, my deploy script runs jekyll clean before jekyll build, and then uploads to the production server.

I often run bundle exec jekyll serve with --drafts --unpublished. Even if I changed all my asset URL handling to be relative URLs, I would still jekyll clean to avoid uploading draft or unpublished work to the production site.

This change doesn't help me, and it doesn't really harm me. All it does is change my default local development command from bundle exec jekyll serve to bundle exec jekyll serve --host localhost --port 4000 — it's not a terrible bother, but it took me three hours to find what had changed.

---

Whether or not this change is undone, https://jekyllrb.com/docs/configuration/options/#serve-command-options should be updated to:

• describe the effects of serve upon the variables it treats differently
• state that serve serves from the same build directory used by jekyll build, and encourage users to run jekyll build before deploying files from that directory to a production server.

[evanwill]

I also just don't quite understand the justification for the change.
I thought the purpose of using absolute_url or site.url in templates was that it would be automatically swapped out on jekyll s vs. jekyll build?
The change definitely breaks the majority of my older projects, so I will have to hold them all back at Jekyll 4.1.1 or explain to users that you need to add --port 4001 to revert to expected behavior.

As @benlk mentions, in either case it would be helpful to clarify the documentation.

[ChaelCodes]

Documentation should be updated when major changes like this occur. The variables documentation makes some promises about the behavior of site.url that are no longer true.

[benlk]

I have filed a PR to revert these changes: #8620

Sorry for the delay in getting them to you.