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

Make template site easier to customize #2268

Merged
merged 1 commit into from May 5, 2014

Conversation

Projects
None yet
5 participants
@benbalter
Contributor

benbalter commented Apr 27, 2014

Used the new template site (which is awesome) for the first time. It should be a lot easier to customize right off the bat, especially for new users who may not be as familiar with Jekyll. A few things I noticed:

  • Asset URLs were hard coded to domain root, making it impossible to use on GitHub Enterprise, project pages, etc.
  • Text was hard coded in footer, with no clear explanation of how to change it. Moved to variables and made a note that they can be changed in _config.yml
  • Pages lived in about/index.html, rather than simply using a pretty permalinks
  • Header nav hardcoded pages
  • Use the default markdown processor

Three questions:

  1. Worth adding a Gemfile with Jekyll in it so that the site's ready to go?
  2. Should we add a readme to the folder so (e.g., like Rails does)?
  3. What's the preferred design pattern for prepending asset URLs with the proper path in production, but not locally?

/cc @jglovier (the template's great!)

title: Your awesome title
email: your-email@domain.com
description: "Write an awesome description for your new site here. You can edit this line in _config.yml. It will appear in your document head meta (for Google search results) and in your feed.xml site description."
baseurl: "http://yourdomain.com"

This comment has been minimized.

@parkr

parkr Apr 27, 2014

Member

Let's use url here. baseurl is very special:

s.mount(options['baseurl'], WEBrick::HTTPServlet::FileHandler, destination, fh_option)

This comment has been minimized.

@benbalter

benbalter Apr 27, 2014

Contributor

One reason baseurl may be appealing, is because I can preview this locally via bundle exec jekyll serve --watch --baseurl="", whereas if it were an arbitrary key, I'd have to do --config=_config.yml,_config_dev.yml or similar.

Edit as is, jekyll serve won't work as expected out of the box, so likely a horrible idea.

This comment has been minimized.

@parkr

parkr Apr 27, 2014

Member

Using baseurl:

# locally, _config.yml contains the base URL:
# baseurl: witness
$ jekyll serve -w
# Now go to http://localhost:4000/witness
$ open http://localhost:4000/witness
# Make changes, commit, push up.
$ git push
# view site at http://parkr.github.com/witness
$ open http://parkr.github.com/witness
#
# Use baseurl to homogenize experience, to be "as close as possible" to
#   Pages or to wherever you happen to be deploying that is not at a root.
@parkr

This comment has been minimized.

Member

parkr commented Apr 27, 2014

My answers to your questions:

Worth adding a Gemfile with Jekyll in it so that the site's ready to go?

It isn't necessary to have a Gemfile, so I'd probably say we don't need this.

Should we add a readme to the folder so (e.g., like Rails does)?

Boilerplate readme's make me :rage4: I always hated that Rails bundled a readme.

What's the preferred design pattern for prepending asset URLs with the proper path in production, but not locally?

We should create a liquid tag for this:

<link href="{% full_url css/screen.css %}" rel="stylesheet">
<!-- outputs http://example.org/my/baseurl/css/screen.css -->

<a href="{% full_url about.html %}">About</a>
<!-- outputs http://example.org/my/baseurl/about.html -->

full_url would join site.url, site.baseurl, and the input.

@benbalter

This comment has been minimized.

Contributor

benbalter commented Apr 27, 2014

tag or filter? page.url | full_url feels more right to me absolute_url feels ever more righter.

@mscharley

This comment has been minimized.

Contributor

mscharley commented Apr 27, 2014

From a liquid perspective, a filter sounds right, but from a user
perspective a tag feels better in my opinion. +1, this needs to happen in
one form or another though
On 28/04/2014 9:16 am, "Ben Balter" notifications@github.com wrote:

tag or filter? "about.html" | full_url feels more right to me absolute_urlfeels ever more righter.


Reply to this email directly or view it on GitHubhttps://github.com//pull/2268#issuecomment-41512732
.

@parkr

This comment has been minimized.

Member

parkr commented Apr 27, 2014

tag or filter?

@benbalter Definitely a tag. Filters don't get access to the context IIRC, so no way to access site configs.

@parkr parkr added this to the 2.0 milestone Apr 27, 2014

This was referenced Apr 27, 2014

@parkr

This comment has been minimized.

Member

parkr commented May 1, 2014

@benbalter How would you like to proceed on this? Would you like to use absolute_url, or would you prefer to go a different route? Want to release another RC tomorrow.

@benbalter

This comment has been minimized.

Contributor

benbalter commented May 1, 2014

Does absolute_url exist?

@parkr

This comment has been minimized.

Member

parkr commented May 1, 2014

Does absolute_url exist?

I created it in #2270.

@benbalter

This comment has been minimized.

Contributor

benbalter commented May 1, 2014

👍. I likely wont have a chance to update the branch prior to the RC, but if it's an easy enough switch, feel free to attack the branch directly. 😄

@jglovier

This comment has been minimized.

Member

jglovier commented May 1, 2014

It should be a lot easier to customize right off the bat, especially for new users who may not be as familiar with Jekyll.

🤘 ❤️ 💥

What's the preferred design pattern for prepending asset URLs with the proper path in production, but not locally?

We should create a liquid tag for this:

+1 for tag.

parkr added a commit that referenced this pull request May 5, 2014

@parkr parkr merged commit d42ced5 into master May 5, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@parkr parkr deleted the template-fixes branch May 5, 2014

parkr added a commit that referenced this pull request May 5, 2014

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.