I grew up on Central California’s Pacific coast, along the Monterey Bay. It’s an awesome place to grow up if you love the ocean, and I do.
From an early age I remember body surfing at the Asilomar with my older cousin. In those endless days, happily bobbing in the frigid Pacific waters among the sea weed and the sea lions, I learned to make the most out of every wave my beach sent me.
As I think back now, I realize those waves and that beach also taught me a good deal about making the most out of everything life sends me.
Here’s seven life lessons I learned growing up body surfing:
If you miss a wave, don’t worry, another will be along soon enough.
Sometimes you have to miss a good wave if you want to catch an even better one on the horizon.
It takes real work to get into position to catch the right wave and ride it to the end.
Some waves will thrash you pretty bad, but they are usually the most fun.
If you get swept out by the tide, remain calm, change direction slightly (parallel to the beach), and swim back to where you were last in good water.
For my Jekyll blog, I want to give readers a typical river of news1 list of post titles with teasers. I also want readers to be able to paginate through past posts, via a series of pages listing ten posts per page.
When readers click on a “Read more” link in a post teaser, I’d like them to go to the full post text, starting from the last point they read, which is typically not at the top of the post.
Here’s how I used Jekyll’s template system to get exactly the feature-set I want.
For my pagination feature I add these variables and values to my Jekyll _config.yml file.
paginate: 10
paginate_path: "blog/page:num"
The paginate variable set to 10 tells Jekyll to list ten posts per page.
The paginate_path tells Jekyll what URL structure to use when generating each page in the paginated series.
The settings above tells Jekyll to create URLs like: /blog/page2/, /blog/page3/, etc.
You can change these patterns to fit your own blog structure.
For example, the value posts/page-:num would generate a URL pattern like, /posts/page-2/.
Page one of my blog is my homepage, so I must tell Jekyll to render the first page in its pagination series differently from the other pages. Jekyll provides snippets to render paginated posts. In my case I needed to use the second code snippet on the page which handles the “page one edge-case.”
Teasers (AKA Excerpts)
Jekyll’s default post excerpts behavior is to use the first paragraph of a post as the post’s excerpt/teaser. It does this by grabbing the first block of text from the beginning of the post to the first excerpt_seperator it finds.
The excerpt_seperator is a Jekyll variable which may be set in the _config.yml file.
By default its value is:
excerpt_separator: "\n\n"
For my teaser feature I set the value to:
excerpt_separator: <!–break–>
The separator value could be almost anything. In order to change it from using the first line break, I chose to use the same separator as Drupal2. (Helpful because I migrated my content from Drupal.)
The change gives me two advantages right away:
I control exactly where my excerpt breaks in my post (using an html comment which is not rendered directly to the reader)
I can create short status-like posts which use the full post content in the post listings (by not adding the <!–break–> to the post body)
If I need anything beyond the two options above, I can always override automatic excerpts by adding excerpt to my post’s YAML Front Matter like so:
title: "How I Added Teaser and Read-more Functionality to My Jekyll Blog on GitHub Pages"
excerpt:
<h3>Add a Custom Excerpt to Your Post</h3>
<p>Find out how!</p>
For my Jekyll blog I want to add a table of contents to some of my larger posts so readers have an overview of the post content and may click links to jump to sections which interest them most. I’d like Jekyll to automatically generate the markup for the table of contents based off the headers in the post.
Here’s how I set up Jekyll to get my table of contents (toc) feature.
Configuration
By default, Jekyll on Github pages is configured to use Kramdown to parse and convert Markdown1 to html format for blog post pages. Jekyll’s markdown conversion option is set in the _config.yml file like this:
When the auto_ids option is set, all headers will appear in the table of contents as they all will have an ID. Assign the class name “no_toc” to a header to exclude it from the table of contents.
My action step to configure Jekyll to get my table of contents feature was to change nothing. :)
Implementation
Implementing the auto table of contents feature is almost as easy as the necessary configuration.
Here are the steps to add the toc:
Add an ordered or unordered list to the content body at the point you want the table of contents to appear
Add the following snippet immediately below the list: {:toc}2
Jekyll (using Kramdown as its converter) will replace the list with a toc automatically generated from the headings in the content
Here’s the markup I use to add tocs to my posts:
* TOC
{:toc}
The number of items in the list and the content of the items do not matter, because they will be replaced by the toc when the content is parsed.
I’m happy to have found this useful auto table of contents built right into Jekyll. If you have a Jekyll blog, I recommend trying it out if you haven’t already.
As Drupal developers and users we share our software with a community of 630,000+ other users and developers (http://drupal.org/about). We have entered into a great social contract. We trust each other that our core and contributed code will work as they are supposed to. With the scale of the community and the scale of the code base there will be some exception. The introduction of a testing framework into Drupal has significantly helped reduce those exceptions and provide the community and clients with confidence in the quality of Drupal.
Drupal 7 has seen major benefits from embracing the testing framework.
[Testing] has significantly enhanced the way core is developed and made it possible to make major API enhancements with confidence.
– http://drupal.org/simpletest
Software testing in Drupal benefits developers, client stakeholders, and end-users. This short series of posts is written for these audiences. In this series we will do some basic exploration together into the why, what, and how of software testing as it relates to Drupal web development. Throughout the series the reader will find links to resources for further review. This first post in the series examines the question of, “Why test software?”
As a general rule of thumb, any content which requires one of the following, is a candidate for its own content type:
discrete fields, not used often or at all in other pieces of content
business logic unique to the piece of content ( access requirements, section placement, workflow)
major layout or page structure differences in the presentation layer
different uses or discrete conceptual differences ( a blog page and a page content type may be excactly the same, be tagged the same, but require content contributors to think of them and their uses differently)
list separation requirements such as: a block of just Company news and a block of just department News
Now there are always exceptions and other ways to meet the same functional requirements. The last item above, for example, would likely be best met via taxonomy. Others functionality may be developed using context.