Revert #7253: "Don't reset site.url to localhost:4000 by default"

[benlk]

This is a 🐛 bug fix.
I have not run the CI suite.

Summary

When running with bundle exec jekyll serve and no other options, the absolute_url filter will now use the local server URL instead of the URL from the config (like benlk.com) when that URL is the default localhost:4000.

Context

This PR is designed to fix the regression introduced in #7253 and described in my comments there: #7253 (comment)

If you don't want to check the links, here's a summary:

• Don't reset site.url to localhost:4000 by default #7253 changed the behavior of jekyll serve to use the site URL from the site's config when serving a local development version of the site, if the localhost host and port were not explicitly specified. This meant that site.url and the absolute_url filter would use the production URL when generating and serving the site locally. The documentation on jekyllrb.org was not updated to reflect this change in behavior, so people who innocently ran jekyll serve and expected assets to load from their local development server would instead see:
  • images loaded from the production server, or 404 if not present on the production server
  • stylesheets loaded from the production server without changes from edits made locally, or 404 if not present on the production server
  • scripts loaded from the production server without changes from edits made locally, or 404 if not present on the production server
  • font files failing to load from production servers not configured to allow CORS requests for font files from localhost:4000, or 404 if not present on the production server
• That change did not affect cases where the local server URL was explicitly set via bundle exec jekyll serve --host localhost --port 4000 to be localhost:4000, or when it was set to be any other combination of hosts or ports. That change only affected the default jekyll serve, which is the local development action recommended in the Jekyll docs.

This PR does update documentation with the recommendations from discussion in #7253

Reverts #7253

[benlk]

Before merging, this PR should also update the usage docs https://github.com/jekyll/jekyll/edit/master/docs/_docs/usage.md to describe the intended use of build and serve in their default configurations, and how to override those configurations to account for the use that #7253 wanted to satisfy.

[mattr-]

Before merging, this PR should also update the usage docs https://github.com/jekyll/jekyll/edit/master/docs/_docs/usage.md to describe the intended use of build and serve in their default configurations, and how to override those configurations to account for the use that #7253 wanted to satisfy.

I agree with this comment. Is this something you'll do soon? It doesn't seem productive to do anything else with this PR if it's not complete.

[benlk]

@mattr- It's something that I'd prefer to leave to a maintainer, but I can draft some language and add it to the PR if you'd like.

[mattr-]

@mattr- It's something that I'd prefer to leave to a maintainer, but I can draft some language and add it to the PR if you'd like.

I would appreciate it if you would draft some language and include it in the PR. Thanks! ❤️

[benlk]

@mattr- I've updated the docs in this PR to better differentiate between build and serve; I'm open to revisions in the language: b298914

However, this doesn't address the latter part:

and how to override those configurations to account for the use that #7253 wanted to satisfy.

Is the current admonition to see the full list of commands and build options okay for that purpose?

For a full list of options and their argument, see Build Command Options.

[mattr-]

@jekyllbot: merge +fix