This makes sure that overrides for Jekyll.configuration
all have string keys before their first use, particularly
also the "config" and "skip_config_files" options.
Formingo (https://www.formingo.co) is a new service I'm working on that handles form processing for static websites, such as those generated through Jekyll. Adding it to the list of form services because I believe it'd be a helpful resource and alternative to some of the other listed services.
* master: (41 commits)
Fix rubocop offenses on master.
script/fmt: print Rubocop version
Update history to reflect merge of #5030 [ci skip]
rubocop: separate deprecator error messages
Update history to reflect merge of #5031 [ci skip]
Update history to reflect merge of #5032 [ci skip]
rubocop: fix code style
rubocop: fix code style
rubocop: fix code style
Update history to reflect merge of #5024 [ci skip]
Update history to reflect merge of #5025 [ci skip]
utils: check that the object is a hash when merging default_proc
Update history to reflect merge of #5026 [ci skip]
rubocop: refactor modified? method
Add a benchmark for capture vs. assign in Liquid. [ci skip]
Update history to reflect merge of #5027 [ci skip]
Add generator-jekyllized to third party plugins
rubocop: fix code style
rubocop: fix code style
rubocop: fix code style
...
* master: (22 commits)
Update history to reflect merge of #4980 [ci skip]
werdz
Use jekyll-mentions and restructure
Add post about GSoC project.
Update history to reflect merge of #4976 [ci skip]
Amend WEBrick default headers documentation
Update history to reflect merge of #4966 [ci skip]
.rubocop.yml - remove lib/jekyll.rb
lib/jekyll.rb - fix offenses reported by rubocop method set_timezone is ignored using rubocop:disable Style/AccessorMethodName
Update history to reflect merge of #4977 [ci skip]
Update history to reflect merge of #4962 [ci skip]
Update history to reflect merge of #4959 [ci skip]
Fixed typo
Changed github-gem to github-pages
Included installation instructions
Installation instructions for github-pages gem
Added link to windows doc page
Fix inaccurate HTTP response header field name
Minor tweak to fix missing apostrophne
Feedback for flubbed regex and prefer File's directory check
...
* pathawks-readers:
I will chain blocks if I want to chain blocks.
Rubocop: Readers
Rubocop: lib/jekyll/readers/static_file_reader.rb
Rubocop: lib/jekyll/readers/post_reader.rb
Rubocop: lib/jekyll/readers/page_reader.rb
Rubocop: lib/jekyll/readers/layout_reader.rb
Rubocop: lib/jekyll/reader.rb
* pathawks-rubocop/misc:
Fix Page#relative_path so that it consistently does NOT have the prepending slash (previously inconsistent)
Rubocop cleanup for lib/jekyll/layout.rb
Rubocop cleanup for lib/jekyll/plugin_manager.rb
Rubocop cleanup for lib/jekyll/page.rb
* master: (38 commits)
Mention where it came from. [ci skip]
Update history to reflect merge of #4944 [ci skip]
Update history to reflect merge of #4943 [ci skip]
Mention where it came from. [ci skip]
Update history to reflect merge of #4942 [ci skip]
Update history to reflect merge of #4941
External: remove &block arg, use block_given?
Update history to reflect merge of #4936 [ci skip]
lib/jekyll.rb: require document_drop to ease our pain
Sort the results of the require_all glob.
Rubocop fixes
Reset {{ layout }} between each render & merge layout data properly
Add failing test for layout data inheritance bug (#4433)
Add failing test for layout bug (#4897)
Fix tests for plugins in configuration.
Define Drop#each so we can use the new frozen/duping behavior
Don't default 'include' and 'exclude' to an empty array
Fix some minor things in the tests
Freeze configuration defaults & duplicate in deep_merge_hashes if need be.
Remove merge conflicts I forgot to fix.
...
* pathawks-fp/ExcerptDrop:
Rubocop fixes
excerpt drop should give access to document's layout
look up the content methods for drops in a smarter way
Use require_relative
Add ExcerptDrop and remove excerpt's ability to refer to itself in Liquid
Previously you could do, e.g. {{ site | jsonify }}, but with the introduction of Liquid Drops, this didn't work anymore.
This PR adds the ability to render drops as JSON. You can safely run drop.to_json and it should Do the Right Thing.
Filesystems behave differently when performing glob listings.
In my environment, they are listed alphabetically. On my Mac, when asking for a list of files in a directory, those files are returned as a nicely sorted list. Alphabetized, like you'd want them to be. Like you'd expect them to be.
In some environments, quite different from my own, the return of a similar operation is quite random. Perhaps q comes before a, or e before d; the filesystem will choose its order of the day and you, the fare user, tired and weary from work, must bare the brunt of this.
And so, with this commit, I do hereby request that the noble makers of Dir[] provide for us, the downtrodden and ravaged users, some consistency. As a user of Ruby, I shouldn't have to know or consider the behaviour of an individual filesystem here; it should function the same for all filesystems.
Truly yours,
Parker
This process streamlines the creation of new configurations. Creating a new
site will choke if not all the correct options are given.
Configuration.from will ensure the overrides have all string keys and
ensures all the common issues & defaults are in place so a Site can be
created.
A common use:
config = Configuration.from({ 'permalink' => '/:title/' }) # etc
site = Jekyll::Site.new(config)
This commit cleans up rubocop violations for the following files:
test/test_ansi.rb
test/test_cleaner.rb
test/test_coffeescript.rb
test/test_collections.rb
test/test_command.rb
test/test_commands_serve.rb
* Allow users to filter directories by ending their path with "/"
* Allow users to filter with a Regexp, some scenariors can really require it.
* Use Pathutil#in_path? for Symlink verification, it real/expand.
This also requires some downstream work in "jekyll-watch" which at this time is
not very robust, it doesn't recognize the difference either, and should probably
start doing so (what I mean is detecting "/" and using the full path.)
Jade has been moved to Pug https://github.com/pugjs/pug
This was forked from the previous Jade plugin and merged the pug update to maintain the newer version and avoid deprecation usage.
When it comes to bundler it's smart enough to know what to require, and in casees it's not, it's smart enough to accept :require. In most cases when bundler has a LoadError (or otherwise) it's because there is a problem inside of the Gem itself and when this happens, Jekyll will happily let that error slip when it shouldn't, resulting in a badly placed error that is actually wrong. This corrects that so errors can surface properly.
* Link to jekyllrb.com as @parkr suggested.
* Add a few more directions and hints for Github Pages users who have errors.
* Add words that were missing and made stuff make no sense.
This makes the issue template more robust, making check boxes so users can submit and check or check as they go. It also starts using HTML comments so that directions for the users aren't always displayed to us (gotta love Markdown.) And provides the users with more hints on what we would like from them when filing a ticket.
Previously we relied on the Git version of Rubocop so that we could get 2.3+ and TargetVersion support in our .rubocop.yml, they have since updated stable and made this available to the general public.
* master: (58 commits)
Update history to reflect merge of #4792 [ci skip]
Update history to reflect merge of #4793 [ci skip]
Update history to reflect merge of #4804 [ci skip]
Update history to reflect merge of #4754 [ci skip]
Update history to reflect merge of #4813 [ci skip]
Added missing single quote on rsync client side command
Add v3.0.4 and v3.1.3 to the history.
Fixed typo
Add jekyll-autoprefixer plugin
Explicitly require Filters rather than implicitly.
Update history to reflect merge of #4786 [ci skip]
Update history to reflect merge of #4789 [ci skip]
updates example domain in config template
Globalize Jekyll's Filters.
Update JRuby to 9.0.5.0; Drop the double digit test.
Update Rack-Jekyll Heroku deployment blog post url
convertible: use Document::YAML_FRONT_MATTER_REGEXP to parse transformable files
Update history to reflect merge of #4734 [ci skip]
Update history to reflect merge of #4478 [ci skip]
Fix rubocop warning.
...
As it stands Jekyll does not globalize it's filters. So anybody wishing to go
into Jekyll's context to process their own Liquid (say in a plugin) may be taken
aback when they find out that Jekyll's filters are not available.
See: jekyll/jekyll-assets#252.
This commit introduces a where_exp filter, which can be used as follows:
`{{ array | where_exp: "item", "item == 10" }}`
`{{ array | where_exp: "item", "item.field > 10" }}`
`{{ site.posts | where_exp: "post", "post contains 'field'" }}`
`{{ site.posts | where_exp: "post", "post.array contains 'giraffes'" }}`
This permits a variety of use cases, such as reported in: jekyll#4467,
jekyll#4385, jekyll#2787.
It seems that Travis has made available 2.1.10 which is for double digit testing but skipped 2.1.10 (for some reason.) This reverts us back to 2.1.8 so that we can maintain a working build since we are triggering no known bugs in 2.1 at this time.
Update Rake and disable verbosity when running the specs because we have some
deprecated usage (for now -- however, see: jekyll/jekyll#4719) and because
Rouge, and Liquid throw out thousands (probably hyperbolic) of warnigns when the
specs are being ran. We need upstream to fix their problems while we fix ours
or we'll all have a bad day, not that we aren't already.
As it was we assumed that any system that wasn't Windows or OS X must be Linux
but the reality of that can be very unlikely. BSD is popular in some places and
it's not Linux and this would cause an error there. If we do not know the
launcher for a platform we should ship an error and have the user file
a bug if they feel it necessary and skip the launch otherwise.
* origin/master: (65 commits)
Update history to reflect merge of #4703 [ci skip]
Update history to reflect merge of #4712 [ci skip]
Highlight the test code
Update history to reflect merge of #4640 [ci skip]
readded "env=prod"-condition
Update history to reflect merge of #3849 [ci skip]
Update history to reflect merge of #4624 [ci skip]
Update history to reflect merge of #4704 [ci skip]
Update history to reflect merge of #4706 [ci skip]
Checks for link file extension in tests
Updating assets documentation
Fix test teardown for cleaner.
Update history to reflect merge of #4542 [ci skip]
Add explanation of site variables in the example _config.yml
Use double quotes in the gemfile
Add test for creation of Gemfile by 'jekyll new'
Add comment about github-pages
Update history to reflect merge of #4533 [ci skip]
Ensure Rouge closes its div/figure properly after highlighting ends.
Add Site#config= which can be used to set the config
...
This removes the following warnings:
- /lib/jekyll/configuration.rb:151: warning: instance variable @default_config_file not initialized
- /lib/jekyll/converter.rb:12: warning: instance variable @highlighter_prefix not initialized
- /lib/jekyll/converter.rb:24: warning: instance variable @highlighter_suffix not initialized
- /lib/jekyll/converters/markdown.rb:9: warning: instance variable @setup not initialized
- /lib/jekyll/converters/markdown/kramdown_parser.rb:60: warning: instance variable @highlighter not initialized
- /lib/jekyll/frontmatter_defaults.rb:97: warning: shadowing outer local variable - path
- /lib/jekyll/plugin.rb:66: warning: instance variable @safe not initialized
- /lib/jekyll/regenerator.rb:147: warning: instance variable @disabled not initialized
- /test/test_convertible.rb:40: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_filters.rb:154: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_new_command.rb:84: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_site.rb:234: warning: assigned but unused variable - site
- /test/test_site.rb:240: warning: assigned but unused variable - site
- /test/test_site.rb:522: warning: assigned but unused variable - source
- /test/test_tags.rb:153: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:425: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:449: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:496: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:496: warning: instance variable @result not initialized
- /test/test_tags.rb:511: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:773: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:773: warning: instance variable @result not initialized
- /test/test_tags.rb:788: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_url.rb:66: warning: shadowing outer local variable - doc
- /lib/jekyll/url.rb:119:in `escape_path': warning: URI.escape is obsolete
Just because developer are lazy and tools like this is for move forward faster, normally we don't read (it's a fact) and because of that I missed this super important sentence. At least this should help.
After running:
sudo dnf install ruby ruby-devel rubygems nodejs
sudo dnf group install "C Development and Tools"
I was unable to install Jekyll via `gem` due to an error:
The compiler failed to generate an executable file. (RuntimeError) You have to install development tools first.
Taken from the [fedoraproject.org](https://developer.fedoraproject.org/tech/languages/ruby/gems-installation.html) Gem page:
>If you installed all the above, but the extensions would still not compile, you are probably running a Fedora image that misses `redhat-rpm-config` >package. In that case gcc compiler would complain about one of the following:
gcc: error: conftest.c: No such file or directory
gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory
>To solve this, simply run sudo dnf install `redhat-rpm-config`.
After doing so it downloaded, compiled and installed without a problem.
I followed the troubleshooting and came up with `sudo gem install jekyll` unable to generate the binary file because the development libraries were not installed on my system. Per [fedoraproject.org -- Gems](https://developer.fedoraproject.org/tech/languages/ruby/gems-installation.html) this is necessary to install this. The instructions mirror what is listed on that page, but using `yum` instead of `dnf` - which is understandable because RH and CentOS still use `yum`.
PR #2895 merged this in, but there isn't any documentation anywhere for this as far as I can find. All the Stack Overflow answers I could find said it was impossible to push and pop elements from a Liquid array, although that's probably because they were using Shopify's Liquid.
Fixes https://github.com/jekyll/jekyll/pull/4384
Prior to this change, the related posts for the most recently rendered post
stayed set on the `site` object. This could result in pages that showed related
posts even when the page represented an entire collection of posts, such as on
an index page. This change restores the functionality from Jekyll V2.
"Upgrading Documentation" reads to me like "upgrading the documentation" rather than "documentation for upgrading".
There's a link in the site navigation to documentation, but seems worth a mention here, even though the Google option will often bring one to it. 😄
Previously `titleize` used `capitalize!` which has the side effect of
returning `nil` for anything already starting with a capital letter. This
commit changes it to just `capitalize`.
Example, before:
A file "2016-01-01-This-is-a-title-with-Capitals.markdown" would return "Is A
Title With" for `post.title`
Example, after:
A file "2016-01-01-This-is-a-title-with-Capitals.markdown" will return "This Is A
Title With Capitals" for `post.title`
Tests added for `titleize_slug` in test_utils.rb
Fix problem introduced in 67f842546e
References #4525
The Contributor Code of Conduct is now at version 1.3.0 and has several
changes. Many of these are simply wording changes, but an important note
is added that project maintainers must maintain confidentiality when
dealing with any code of conduct violations. Additionally, a note is
added that states violations will be investigated and dealt with in a
way that is deemed necessary and appropriate based on the circumstances.
Signed-off-by: David Celis <me@davidcel.is>
Previously, even if the document permalink was a folder, it would look for
an extension on that. For example, if I have:
permalink: "/new-version-jekyll-v3.0.0/"
the output_ext would be ".0". Now, the output_ext honors the trailing
slash and will report based on the converters instead.
* 'master' of github.com:jekyll/jekyll:
Make our .travis.yml a little easier to maintain.
Update History.markdown to reflect the merger of #4394
Minor spelling error
This reverts a bit of the work @willnorris had made to support
extensionless permalinks. Using the ‘permalink’ front matter will no
longer work as it must allow non-html extensions to be written.
Nearly every day, when I get the report of visitors to jekyllrb.com, I see jmcglone's excellent guide. Reading through it today makes me think it is one of the finest if not _the_ finest guide to getting started with Git, GitHub, and Jekyll in order to publish successfully and happily on GitHub Pages.
@jmcglone, mind if I add this to our GitHub Pages doc page?
The problem last time was that we removed Pry and Pry brings in CodeRay, we were
testing legacy stuff and didn't have CodeRay in our dependencies, which resulted
in those tests failing.
This also quietly announces the intention to move to RSpec by moving the old
test dependencies to ":test_legacy" and is slightly less agressive in it's
organization than before.
* Move step_definitions/jekyll.rb to just step_definitions.rb
* Rename the formatter to Jekyll::Cucumber::Formatter, it's Jekyll's.
* Add some flair; switch to checks!
* Rename env.rb to helpers.rb
* Remove invoked dynamic, it slows down Ruby.
* Remove ObjectSpace which slows down JRuby, we use inheritance now.
* Remove the compat version 9K is Ruby2 by default.
* Removes posix-spawn in favor of Open3#popen3
* Encapsulates all the paths into a single easy class.
* Moves to %r{} to avoid ambiguious warnings per-Cucumber suggestion.
* Starts passing around Pathname to make some actions faster.
* Clean's up some methods to make them easier to read.
* AUTOMATIC: Add "#" between each method.
Occasionally, extra spaces at the end of the YAML front matter prologue are
saved to a file and it goes missing without telling the user why. This
should simply accept those changes without any detriment to the user,
allowing anyone to add as many spaces as they like to the end of their
front matter prologues.
- Trailing whitespace detected
Rubocop: Style/EmptyLines
- Extra blank line detected
Rubocop: Style/EmptyLinesAroundBlockBody
- Extra empty line detected at block body beginning
- Pass &:to_sym as an argument to map instead of a block
- Pass &:capitalize as an argument to select instead of a block
- Pass &:to_s as an argument to map instead of a block
We should handle extend self and module_function on a case-by-case basis because there
are times when extend self is useful, especially when you wish a module to be included but also
available on itself. `module_function` does not allow this.
Move require "jekyll/drops/drop" to "jekyll.rb"
Linux does not read files in alphanumeric order, this can lead to
Jekyll drops not working on Linux because the assumption here is that
the collection drop will be required first.
Linux does not read files in alphanumeric order, this can lead to
Jekyll drops not working on Linux because the assumption here is that
the collection drop will be required first.
* fixup-custom-markdown:
markdown: minor style fixes
Add support for underscores.
Refactor: lib/jekyll/convertor/markdown.rb - tests: no additions/breaks.
The properties of Liquid::Drops are only evaluated when they're asked for
and therefore save computation time. This prevents a lot of GC time cleaning
up objects that are not needed, because they're not created unless requested.
Additionally, this saves time for actual computation of those values because
they can be computed only if needed.
It's funny how much it helps when you only do what is needed. Far less overhead.
* akoeplinger-doctor-permalink-same-case-warning:
Added tests for new jekyll doctor warning
Incorporate code review feedback
Incorporate code review feedback
Add a Jekyll doctor warning for URLs that only differ by case
https://github.com/jekyll/jekyll/pull/4243 updated this link to a jekyll-specific page. This commit adds utm params to the link so we can tell that users came to us from the Jekyll documentation. Among other things, this will help us provide better support to Jekyll users who sign up, since we'll know what site generator they're using.
Add a default charset to content-type on webrick, using Jekyll's
default encoding (or user set encoding) and cleanup servlet removing
unecessary logic that really served no purpose at the end of the
day, we don't need to strictly match Nginx, only be "like it."
This also cleans up the way we set headers and merges that logic
into a cleaner to understand interface that is slightly speedier.
* Add support for SSL through command line switches.
* Add suppport for file/index.html > file.html > directory.
* Add support for custom-headers through configuration.
* Modernize and split up the serve.
* Add a few basic tests.
I have written a liquid filter to make email protection for static websites easy. This plugin contains the `protect_email` filter which encodes email addresses similar to the way GitHub does for the user profiles.
which works the same way as Dir.glob but seperating the input
into two parts ('dir' + '/' + 'pattern') to make sure
the first part('dir') does not act as a pattern.
I have created a Jekyll 3.0-compatible plugin for multilingual websites which is capable of creating multiple translations for one page or post. Beware that this plugin extends the `PageReader` and `PostReader` as well as `Page` and `Document` classes.
- add site post_render hook, which was documented but wasn't being
called
- define documents post_init hook, which was documented but caused an
error when called (fixes#4102)
- add docs for site post_read hook, which was being called but wasn't
documented
- fix container name in example: s/post/posts/
Disable the feature as it's still not 100% working 100% of the time. Feature
can be re-enabled by specifying `full_rebuild: false` in the configuration
Fix the code coverage reporting when using `.bundle` to store my gems in
by having SimpleCov ignore that directory. Use of `.bundle` to store my
gems consolidates things since since that directory also holds the
bundler config file. It also keeps a `vendor` directory out of the
project tree for non-Rails projects. Simplecov was not ignoring that
directory though, which meant that the code coverage numbers I were
seeing locally were wrong (and very frightening). With this change, all
is right with the world once again. 😃
A raw regular expression isn't very expressive, IMHO. Rather than having
people who read this code parse the regular expression to figure out
what it's for, let's give a name. This way, it becomes more obvious what
exactly it is we're doing here.
Following what the documentation specify above for the pretty permalink format (`/:categories/:year/:month/:day/:title/`), it should result for the example to `/2009/04/29/slap-chop/` and not `/2009/04/29/slap-chop/index.html`. Well, at least if I've understood correctly ;-)
When a post does not contain an excerpt_separator, meaning the excerpt
includes the entire post, the excerpt should contain exactly the post
content.
This is desirable both from a correctness standpoint, that the excerpt
should not introduce any new content, and more practically to allow fast
and easy detection of whole-post excerpts in Liquid templates using
`post.excerpt == post.content`. A common use-case is deciding whether
to render "Read More" links on a page containing post excerpts.
This commit does exactly that. It avoids adding additional newlines to
the excerpt content when the excerpt includes the whole post and adds
tests to ensure that this behavior is correct and preserved going
forward.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The first thing new users to Jekyll do is open _config.yml, so this
change adds a simple welcome message to the top of it. Additionally,
it informs the user that the file is not automatically reloaded when
changed, which is a point of confusion for new users.
Related issue: https://github.com/jekyll/jekyll/issues/2302
Non-string input was being missed as a result of poor comparison.
Converting inputs to strings ensure numerical and boolean values are
properly compared.
Fixes#3911.
Add in references to _data format and extension options of .csv, .json,
etc., consistent with _docs/datafiles.md
Signed-off-by: Parker Moore <parkrmoore@gmail.com>
A week ago, I asked @parkr via email if he could add my site here (mostly because I thought it's too cheeky to just propose a file-change). But now he told me that it's better to just do it here:
I'm asking because I spend a huge amount of time and effort on making it great and usefully structured for people who're just getting started with Jekyll. Therefore it's also great as a forked starting-point, if you ask me.
Besides keeping the code clean, I also spend much time on making the site as fast as possible. There's not much CSS in use, the HTML output is minified and images are directly served from the repo (and therefore GitHub's CDN) instead of from third-party services. There's also a lot of "include"-thinking happening for things like embedded Tweets, images or iFrames - which most people just inline in each post.
When making a significant change, I also always make sure to write a few paragraphs about why I exactly did it as a commit message. And when it comes to really big updates, I write entire posts too (explaining all improvements and their benefits to the site's performance/look). Here's an recent example: http://leo.github.io/notes/v2/
I'm definitely sure that many people could get something out of it. Don't you think so too?
Extended documentation on rsync-approach. It also mentions rrsync wrapper script which restricts access for rsync to the server. Based on my blog post here: http://vrepin.org/vr/JekyllDeploy/
Restored previous version of 'Rsync' section and renamed it to 'scp' to reflect the content
Misspelling corrected: authorized_keys, not auhorized_key
Even though JRuby 9K on Travis still apparently points to pre1 we are updating so that when it finally points to stable release we can get those builds, once jruby-head diverges enough again we will re-add it to the list and start testing the next build and move JRuby 9K. Remember though, JRuby support is still experimental.
This enables files such as images and PDFs to show up in the same relative
output directory as other HTML and Markdown documents in the same collection.
It also enables static files to be hidden using defaults from _config.yml in
the same way that other documents in the same collection and directories may
be hidden using `published: false`.
However, because JRuby stable does not support 2.0/21 mode on Travis (reliably as far as I'm aware) we only test on JRuby-head right now because we have dropped support for any EOL Ruby and master contains some code that might or might not fail out on 1.9.
- hooks are registered to symbol owners rather than classes directly
- during registration, add the ability to specify owner as an array to
register the same hook to multiple owners
- add optional priority during registration as a symbol (:low, :normal,
:high)
- implement hooks for collections as they are in octopress-hooks, aside
from post_init
* jaybe-jekyll-patch-1:
Reformat note in pagination docs to use proper HTML. Ref #3467
Clarify pagination file index.html may reside in subdirectory
Update pagination.md - Clarify only index.html
Clarify pagination works from within HTML files
*Note*: Please release a new gem version of jekyll after merging this.
More information at:
http://osvdb.org/show/osvdb/120415
`redcarpet Gem for Ruby contains a flaw that allows a cross-site scripting (XSS) attack. This flaw exists because the parse_inline() function in markdown.c does not validate input before returning it to users. This may allow a remote attacker to create a specially crafted request that would execute arbitrary script code in a user's browser session within the trust relationship between their browser and the server.`
9fc00d08148e707ebb94http://social.schiessle.org/display/b38b1460c2b201329b1f4860008dbc6chttps://gemnasium.com/gems/redcarpet/versions/3.2.3
/cc @parkr @envygeeks
* davidsilvasmith-origin/patch-3:
docs: remove extraneous period from datafiles example.
updated lsi docs
changed the codefile name
forgot a tick around a codefile name
proofed changes
removed personal link
How to access a specific item in the data folder
when the default_proc was being assigned, it failed if it wasn't a Hash. We
expect data to be a Hash everywhere, so let's freak out if it isn't after
reading and applying the fallback.
Fixes#3643.
* chrisfinazzo-upgrading-docs:
Add further fixes to upgrade doc. #3607
Use the new commands
Fix a typo, wrap lines
Remove reference to the watch command
Start working on an upgrade guide for Jekyll 3
When looking for related posts, Jekyll was indexing `Jekyll::Post`
objects, but finding related posts based on `Jekyll::Post#content`. This
caused two problems:
1. Ruby 2.2 will warn on == if <=> throws an exception (and future Ruby
versions will surface that exception). Because `String`s can't be
compared with `Jekyll::Post`s, this warning was appearing all the time
while searching for related posts.
2. LSI won't return a post itself when searching for related posts. But
LSI could never tell that we were searching on a post, since Jekyll
passed post content, not a post object. With this fix, we can remove the
`- [post]` from `Jekyll::RelatedPosts#find_related`.
This is a more accurate fix for #3484.
Clean up the destination modified check in `source_modified_or_dest_missing?` to be easier to read. Note that it can now return `nil` instead of `false` for an unmodified `source_path` and a `nil` `dest_path`, but in a discussion on 706007ead9 we decided that was okay.
When adding a dependency, also add the dependency to the metadata hash.
Addresses part 1 of #3591. Prior to this fix, the regnerator only paid attention the mtime of the first dependency it checked, so for posts/pages with N multiple dependencies (i.e., every layout file used to render them), it continues to regenerate the post/page approximately N times, at which point it's seen all of the dependencies.
Two tests for the regenerator cache clearing changes:
1. Intrusively test that the regnerator.clear_cache actually clears the cache ( in test/test_regenerator.rb )
2. Test that incremental building regenerates files that have changed that previously were unchanged ( in test/test_site.rb )
- Replaced occurrences of #array += with concat
operations.(performance)
- Corrected alignment.
- Removed rebase artifact.
Signed-off-by: Martin Rogalla <martin@martinrogalla.com>
To address part of #3591, clear the regenerator's cache every time the
site is processed. This ensures that the regenerator doesn't incorrectly
believe a file hasn't changed based on stale information.
The documentation has been updated to demonstrate variable parameters for an include.
{% include footer.html param="value" variable-param=page.variable %}
The documentation has been updated to demonstrate variable parameters for an include.
{% include footer.html param="value" variable-param=page.variable %}
This adds docs for two new permalink features coming in Jekyll 3:
- improved default permalinks for pages and collections (#3538)
- support for extensionless URLs (#3490)
Organized the draft, post and layout reader into the *readers* classes.
Fixed all references and ran tests.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
* 'master' of github.com:jekyll/jekyll:
Update history to reflect merge of #3520 [ci skip]
Corrected error message as suggested by @parkr.
Improved clarity of sort nil input error message.
Added test to check on nil input for sort filter.
Sort will now raise error on nil object array input.
After carefully looking at these two methods, as of right now they do not
belong in the reader, as they should also be used by the writer. Thus the
decision was made to move them back into the class containing the source
and dest fields, site.rb.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
Extracted `in_source_dir` from site.rb into reader.rb.
Updated all the references and tests.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
This updates the default permalink style for pages and collections to
match the site-wide 'permalink' setting. If the permalink setting
contains a trailing slash, either explicitly or by being set to
':pretty', then pages and collections permalinks will contain trailing
slashes by default as well. Similarly, if the permalink setting
contains a trailing ':output_ext', so will pages and collections. If
the permalink setting contains neither a trailing slash or extension,
neither will pages or collections.
This impacts only the default permalink structure for pages and
collections. Permalinks set in the frontmatter of an individual page
take precedence, as does the permalink setting for a specific
collection.
Fixes#2691
- Single Quotes
- Fixed Typo's in variable names.
- Removed Redundant Escaping in Regular Expressions.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
This ensures that destination files for HTML posts, pages and
collections always include the proper file extension (as defined by
output_ext) regardless of permalink structure. This allows for URLs
that contain no extension or trailing slash to still result in proper
destination files with .html extensions.
Because this change relies so heavily on output_ext accurately
identifying the extension of the destination file, this change also
removes the feature test that tested support for permalinks with a .htm
extension. In order to support alternate file extensions, a future
patch or plugin will need to modify the output_ext value, at which point
everything else should work as expected.
- Added a test to check if the sort filter will raise the correct
exception on given nil input.
- Improved error message and used "nil" consistently.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
* fabianrbz-remove_adapters_deprecation_warning:
Add minitest/profile to profile 10 slowest tests
Move simplecov_custom_profile to test/ & gate with TRAVIS env
Remove unused groups from simplecov's profile
Removes the following deprecation warning: 'method adapters is deprecated. use profiles instead'
Textile support was removed from jekyll core in #3319, and most of the
tests switched to markdown at that time. This changes the remaining
tests to use markdown as well. The vast majority of the test cases were
testing things in the file name or front matter, so it doesn't really
matter what markup format they use. The one test that was claiming to
test that textile was transformed had actually been moved to markdown as
well, just not renamed.
Fixes#3507
'method adapters is deprecated. use profiles instead'
This warning was showing up because the project was using
the gem 'simplecov-gem-adapter' which uses the old syntax.
* Remove the gem dependency
* Add a profile with the same setup that the gem has
Sort will now throw an error when a nil object array is given as input.
See issue #3491 for more information.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
* delftswa2014-improve-this-page:
Make the .improve callout a light grey.
Put the pencil icon in front of the improve link.
Removed unnecessary margin and simplified padding.
Implemented the "Improve this page" feature. #3495
Created an "Improve this page" link for all the documentation headers. The
feature uses the fa-pencil icon of font awesome. Improvement over #3504(closed).
See issue #3495 for more information.
Signed-off-by: Martin Jorn Rogalla <martin@martinrogalla.com>
Added to the plugin list: jekyll-auto-image. A generator that makes available the first image of a post.
By installing the plugin you will be able to access the first image with {{ @page.image }}. This plugin is useful to Include an image on your list of posts or to set a twitter card for each post/page.
If this '/' is not present, then the second pagination code snippet
under the "Render the paginated Posts" section will have a bug.
Let's say my page 1 is located at host:port/blog/index.html and my
paginate_path setting in _config.yml is "blog/page:num/". The
observation if the paginate_path does not start with a '/' is that the href generated for the page numbers will have 2 'blogs', i.e. for page 2 the href will
incorrectly appear as 'host:port/blog/blog/page2' instead of just
'host:port/blog/page2'.
For a full rebuild, we certainly don't want to *read* from
.jeykll-metadata, but we should still write it. Otherwise, a subsequent
incremental build would have to do a full rebuild again since there is
no metadata file to start from.
Found by @EdMcBane in https://github.com/jekyll/jekyll/pull/3435
The strange regexp we were doing to replace the <pre><code></pre></code>
bits in the Pygments output were wreaking havoc on Rouge output
because Rouge uses <pre>'s to wrap line numbers.
To be consistent, the output from render_* should *not* include
the wrapping <div> and <pre> tags. It should just be what was
inside. We can then wrap it in our own custom tags without using
any regular expressions, as God intended. Death to regular
expressions and HTML manipulation!
This shows people how to kill Jekyll without knowing the PID using `pkill` (you could also do `kill -9 $(pgrep -f jekyll)` but that is just the long way around doing `pkill -f` so it shouldn't be shown in the Jekyll logger but can be documented here for people.
* nitoyon-slugify-new-param:
Remove superfluous Sass declarations.
Move the slugify options out to their own section so as to fix the formatting.
Document the mode parameter of slugify Liquid filter
Add tests for mode parameters of slugify Liquid filter
Add mode parameter to slugify Liquid filter
Conflicts:
lib/jekyll/utils.rb
---> Hadn't added UTF-8 support in nitoyon's PR.
* davidized-collection_yaml_dots:
Move YAML Front Matter regexp into a constant.
Add support for collections documents to have YAML front matter ending in dots.
Conflicts:
test/test_collections.rb
* majioa-devel:
Ensure Post#excerpt_separator always returns a string.
get procedure for default excerpt separator for both cases site and page was moved to the post's specific method :excerpt_separator.
Added per post excerpt_separator functionality, so you are able to specify :excerpt_separator (as well as just :excerpt) key direct inside the post YAML, to make an excerpt based on the value in the post. Tests were also added.
Clarifying what happens if no YAML front matter exists. The current explanation says that Jekyll will generate a file without Front Matter, but it appears this isn't the case.
I'm still not sure if this is the intended behaviour, but this clarifies how it currently works.
specify :excerpt_separator (as well as just :excerpt) key direct inside
the post YAML, to make an excerpt based on the value in the post. Tests
were also added.
Hi there! Interested in contributing to Jekyll? We'd love your help. Jekyll is an open source project, built one contribution at a time by users like you.
## Where to get help or report a problem
* If you have a question about using Jekyll, start a discussion on [Jekyll Talk](https://talk.jekyllrb.com).
* If you think you've found a bug within a Jekyll plugin, open an issue in that plugin's repository.
* If you think you've found a bug within Jekyll itself, [open an issue](https://github.com/jekyll/jekyll/issues/new).
* More resources are listed on our [Help page](https://jekyllrb.com/help/).
## Ways to contribute
Whether you're a developer, a designer, or just a Jekyll devotee, there are lots of ways to contribute. Here's a few ideas:
* [Install Jekyll on your computer](https://jekyllrb.com/docs/installation/) and kick the tires. Does it work? Does it do what you'd expect? If not, [open an issue](https://github.com/jekyll/jekyll/issues/new) and let us know.
* Comment on some of the project's [open issues](https://github.com/jekyll/jekyll/issues). Have you experienced the same problem? Know a work around? Do you have a suggestion for how the feature could be better?
* Read through [the documentation](https://jekyllrb.com/docs/home/), and click the "improve this page" button, any time you see something confusing, or have a suggestion for something that could be improved.
* Browse through [the Jekyll discussion forum](https://talk.jekyllrb.com/), and lend a hand answering questions. There's a good chance you've already experienced what another user is experiencing.
* Find [an open issue](https://github.com/jekyll/jekyll/issues) (especially [those labeled `help-wanted`](https://github.com/jekyll/jekyll/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted)), and submit a proposed fix. If it's your first pull request, we promise we won't bite, and are glad to answer any questions.
* Help evaluate [open pull requests](https://github.com/jekyll/jekyll/pulls), by testing the changes locally and reviewing what's proposed.
## Submitting a pull request
### Pull requests generally
* The smaller the proposed change, the better. If you'd like to propose two unrelated changes, submit two pull requests.
* The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
* Pull request are easy and fun. If this is your first pull request, it may help to [understand GitHub Flow](https://guides.github.com/introduction/flow/).
* If you're submitting a code contribution, be sure to read the [code contributions](#code-contributions) section below.
### Submitting a pull request via github.com
Many small changes can be made entirely through the github.com web interface.
1. Navigate to the file within [`jekyll/jekyll`](https://github.com/jekyll/jekyll) that you'd like to edit.
2. Click the pencil icon in the top right corner to edit the file
3. Make your proposed changes
4. Click "Propose file change"
5. Click "Create pull request"
6. Add a descriptive title and detailed description for your proposed change. The more information the better.
7. Click "Create pull request"
That's it! You'll be automatically subscribed to receive updates as others review your proposed change and provide feedback.
### Submitting a pull request via Git command line
1. Fork the project by clicking "Fork" in the top right corner of [`jekyll/jekyll`](https://github.com/jekyll/jekyll).
2. Clone the repository locally `git clone https://github.com/<you-username>/jekyll`.
3. Create a new, descriptively named branch to contain your change ( `git checkout -b my-awesome-feature` ).
4. Hack away, add tests. Not necessarily in that order.
5. Make sure everything still passes by running `script/cibuild` (see [the tests section](#running-tests-locally) below)
6. Push the branch up ( `git push origin my-awesome-feature` ).
7. Create a pull request by visiting `https://github.com/<your-username>/jekyll` and following the instructions at the top of the screen.
## Proposing updates to the documentation
We want the Jekyll documentation to be the best it can be. We've open-sourced our docs and we welcome any pull requests if you find it lacking.
### How to submit changes
You can find the documentation for jekyllrb.com in the [site](https://github.com/jekyll/jekyll/tree/master/site) directory. See the section above, [submitting a pull request](#submitting-a-pull-request) for information on how to propose a change.
One gotcha, all pull requests should be directed at the `master` branch (the default branch).
### Adding plugins
If you want to add your plugin to the [list of plugins](https://jekyllrb.com/docs/plugins/#available-plugins), please submit a pull request modifying the [plugins page source file](https://github.com/jekyll/jekyll/blob/master/site/_docs/plugins.md) by adding a link to your plugin under the proper subheading depending upon its type.
## Code Contributions
Interesting in submitting a pull request? Awesome. Read on. There's a few common gotchas that we'd love to help you avoid.
### Tests and documentation
Any time you propose a code change, you should also include updates to the documentation and tests within the same pull request.
#### Documentation
If your contribution changes any Jekyll behavior, make sure to update the documentation. Documentation lives in the `site/_docs` folder (spoiler alert: it's a Jekyll site!). If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged, `jekyllrb.com` will be updated.
#### Tests
* If you're creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the `tests` folder, but if you need you can find out about our tests suites [Shoulda](https://github.com/thoughtbot/shoulda/tree/master) and [RSpec-Mocks](https://github.com/rspec/rspec-mocks).
* If it's a brand new feature, create a new [Cucumber](https://github.com/cucumber/cucumber/) feature, reusing existing steps where appropriate.
### Code contributions generally
* Jekyll uses the [Rubocop](https://github.com/bbatsov/rubocop) static analyzer to ensure that contributions follow the [GitHub Ruby Styleguide](https://github.com/styleguide/ruby). Please check your code using `script/fmt` and resolve any errors before pushing your branch.
* Don't bump the Gem version in your pull request (if you don't know what that means, you probably didn't).
## Running tests locally
### Test Dependencies
To run the test suite and build the gem you'll need to install Jekyll's dependencies by running the following command:
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind [GitHub Pages](http://pages.github.com), which you can use to host sites right from your GitHub repositories.
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind [GitHub Pages](https://pages.github.com), which you can use to host sites right from your GitHub repositories.
## Philosophy
Jekyll does what you tell it to do— no more, no less. It doesn't try to outsmart users by making bold assumptions, nor does it burden them with needless complexity and configuration. Put simply, Jekyll gets out of your way and allows you to concentrate on what truly matters: your content.
* [Install](http://jekyllrb.com/docs/installation/) the gem
* Read up about its [Usage](http://jekyllrb.com/docs/usage/) and [Configuration](http://jekyllrb.com/docs/configuration/)
* [Install](https://jekyllrb.com/docs/installation/) the gem
* Read up about its [Usage](https://jekyllrb.com/docs/usage/) and [Configuration](https://jekyllrb.com/docs/configuration/)
* Take a gander at some existing [Sites](https://wiki.github.com/jekyll/jekyll/sites)
* Fork and [Contribute](http://jekyllrb.com/docs/contributing/) your own modifications
* Have questions? Check out [`#jekyll` on irc.freenode.net](https://botbot.me/freenode/jekyll/).
*[Fork](https://github.com/jekyll/jekyll/fork) and [Contribute](https://jekyllrb.com/docs/contributing/) your own modifications
* Have questions? Check out our official forum community [Jekyll Talk](https://talk.jekyllrb.com/) or [`#jekyll` on irc.freenode.net](https://botbot.me/freenode/jekyll/)
## Code of Conduct
In order to have a more open and welcoming community, Jekyll adheres to a
[code of conduct](CONDUCT.markdown) adapted from the Ruby on Rails code of
conduct.
Please adhere to this code of conduct in any interactions you have in the
Jekyll community. It is strictly enforced on all official Jekyll
repositories, websites, and resources. If you encounter someone violating
these terms, please let a maintainer ([@parkr](https://github.com/parkr), [@envygeeks](https://github.com/envygeeks), or [@mattr-](https://github.com/mattr-)) know
and we will address it as soon as possible.
## Diving In
* [Migrate](http://import.jekyllrb.com/docs/home/) from your previous system
* Learn how the [YAML Front Matter](http://jekyllrb.com/docs/frontmatter/) works
* Put information on your site with [Variables](http://jekyllrb.com/docs/variables/)
* Customize the [Permalinks](http://jekyllrb.com/docs/permalinks/) your posts are generated with
* Use the built-in [Liquid Extensions](http://jekyllrb.com/docs/templates/) to make your life easier
* Use custom [Plugins](http://jekyllrb.com/docs/plugins/) to generate content specific to your site
* Learn how the [YAML Front Matter](https://jekyllrb.com/docs/frontmatter/) works
* Put information on your site with [Variables](https://jekyllrb.com/docs/variables/)
* Customize the [Permalinks](https://jekyllrb.com/docs/permalinks/) your posts are generated with
* Use the built-in [Liquid Extensions](https://jekyllrb.com/docs/templates/) to make your life easier
* Use custom [Plugins](https://jekyllrb.com/docs/plugins/) to generate content specific to your site
## License
See [LICENSE](https://github.com/jekyll/jekyll/blob/master/LICENSE).
See the [LICENSE](https://github.com/jekyll/jekyll/blob/master/LICENSE) file.
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
# 1. Use Jekyll
Maintainers of Jekyll should be using it regularly. This is partly because you won't be a good maintainer unless you can put yourself in the shoes of our users but also because you may decide to stop using Jekyll and at that point you should also decide not to be a maintainer and find other things to work on.
# 2. No Guilt About Leaving
All maintainers can stop working on Jekyll at any time without any guilt or explanation (like a job). We may still ask for your help with questions after you leave but you are under no obligation to answer them. Like a job, if you create a big mess and then leave you still have no obligations but we may think less of you (or, realistically, probably just revert the problematic work). Like a job, you should probably take a break from Jekyll at least a few times a year.
This also means contributors should be consumers. If a maintainer finds they are not using a project in the real-world, they should reconsider their involvement with the project.
# 3. Prioritise Maintainers Over Users
It's important to be user-focused but ultimately, as long as you follow #1 above, Jekyll's minimum number of users will be the number of maintainers. However, if Jekyll has no maintainers it will quickly become useless to all users and the project will die. As a result, no user complaint, behaviour or need takes priority over the burnout of maintainers. If users do not like the direction of the project, the easiest way to influence it is to make significant, high-quality code contributions and become a maintainer.
# 4. Learn To Say No
Jekyll gets a lot of feature requests, non-reproducible bug reports, usage questions and PRs we won't accept. These should be closed out as soon as we realise that they aren't going to be resolved or merged. This is kinder than deciding this after a long period of review. Our issue tracker should reflect work to be done.
---
Thanks to https://gist.github.com/ryanflorence/124070e7c4b3839d4573 which influenced this document.
Thanks to [Homebrew's "Avoiding Burnout" document](https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Maintainers-Avoiding-Burnout.md) for providing a perfect base for this document.
**This guide is for contributors.** These special people have contributed to one or more of Jekyll's repositories, but do not yet have write access to any. You may find what is written here interesting, but it’s definitely not for everyone.
So you want to become a maintainer of a Jekyll project? We'd love to have you! Here are some things we like to see from community members before we promote them to maintainers.
## 1. Use Jekyll
You want to maintain Jekyll? Use it often. Do weird things with it. Do normal things with it. Does it work? Does it have any weaknesses? Is there a gap in the product that you think should be filled?
## 2. Help Triage Issues
Watch the repository you're interested in. Join [an Affinity Team](https://teams.jekyllrb.com) and receive mentions regarding a particular interest area of the project. When you receive a notification for an issue that has not been triaged by a maintainer, dive in. Can you reproduce the issue? Can you determine the fix? [More tips on Triaging an Issue in our maintainer guide](triaging-an-issue.md). Every maintainer loves an issue that is resolved before they get to it. :smiley:
## 3. Write Documentation
Good documentation means less confusion for our users and fewer issues to triage. Documentation is always in need of fixes and updates as we change the code. Read through the documentation during your normal usage of the product and submit changes as you feel they are necessary.
## 4. Write Code
As a maintainer, you will be reviewing pull requests which update code. You should feel comfortable with the Jekyll codebase enough to confidently review any pull request put forward. In order to become more comfortable, write some code of your own and send a pull request. A great place to start is with any issue labeled "bug" in the issue tracker. Write a test which replicates the problem and fails, then work on fixing the code such that the test passes.
## 5. Review Pull Requests
Start by reviewing one pull request a week. Leave detailed comments and [follow our guide for reviewing pull requests](reviewing-a-pull-request.md).
## 6. Ask!
Open an issue describing your contributions to the project and why you wish to be a maintainer. Issues are nice because you can easily reference where you have demonstrated that you help triage issues, write code & documentation, and review pull requests. You may also email any maintainer privately if you do not feel comfortable asking in the open.
We would love to expand the team and look forward to many more community members becoming maintainers!
# Helping Out Elsewhere
In addition to maintainers of our core and plugin code, the Jekyll team is comprised of moderators for our forums. These helpful community members take a look at the topics posted to https://help.jekyllrb.com and ensure they are properly categorized and are acceptable under our Code of Conduct. If you would like to be a moderator, email one of the maintainers with links to where you have answered questions and a request to be added as a moderator. More help is always welcome.
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
## Code Review
All pull requests should be subject to code review. Code review is a [foundational value](https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs-b125a13aa292) of good engineering teams. Besides providing validation of correctness, it promotes a sense of community and gives other maintainers understanding of all parts of the code base. In short, code review is crucial to a healthy open source project.
**Read our guide for [Reviewing a pull request](reviewing-a-pull-request.md) before merging.** Notably, the change must have tests if for code, and at least two maintainers must give it an OK.
## Merging
We have [a helpful little bot](https://github.com/jekyllbot) which we use to merge pull requests. We don't use the GitHub.com interface for two reasons:
1. You can't modify anything on mobile (e.g. titles, labels)
2. Provide a consistent paper trail in the `History.markdown` file for each release
To merge a pull request, leave a comment thanking the contributor, then add the special merge request:
```text
Thank you very much for your contribution. Folks like you make this project and community strong. :heart:
@jekyllbot: merge +dev
```
The merge request is made up of three things:
1.`@jekyllbot:`– this is the prefix our bot looks for when processing commands
2.`merge`– the command
3.`+dev`– the category to which the changes belong
The categories match the H3's in the history/changelog file, and they are:
1. Major Enhancements (`+major`) – major updates or breaking changes to the code which necessitate a major version bump (v3 ~> v4)
2. Minor Enhancements (`+minor`) – minor updates (feature, enhancement) which necessitate a minor version bump (v3.1 ~> v3.2)
3. Bug Fixes (`+bug`) – corrections to code which do not change or add functionality, which necessitate a patch version bump (v3.1.0 ~> v3.1.1)
4. Site Enhancements (`+site`) – changes to the source of https://jekyllrb.com, found in `site/`
5. Development Fixes (`+dev`) – changes which do not affect user-facing functionality or documentation, such as test fixes or bumping internal dependencies
Once @jekyllbot has merged the pull request, you should see three things:
1. A successful merge
2. Addition of labels for the necessary category if they aren't already applied
3. A commit to the `History.markdown` file which adds a note about the change
If you forget the category, that's just fine. You can always go back and move the line to the proper category header later. The category is always necessary for `jekyll/jekyll`, but many plugins have too few changes to necessitate changelog categories.
## Rejoice
You did it! Thanks for being a maintainer for one of our official Jekyll projects. Your work means the world to our thousands of users who rely on Jekyll daily. :heart:
Hello! This is where we document various processes for maintaining Jekyll. Being a maintainer for any Jekyll project is a big responsibility, so we put together some helpful documentation for various tasks you might do as a maintainer.
1. [Triaging and issue](triaging-an-issue.md)
2. [Reviewing a pull request](reviewing-a-pull-request.md)
3. [Merging a pull request](merging-a-pull-request.md)
4. [Avoiding burnout](avoiding-burnout.md)
5. [Special Labels](special-labels.md)
Interested in becoming a maintainer? Here is some documentation for **contributors**:
1. [Becoming a maintainer](becoming-a-maintainer.md)
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
## Respond Kindly
Above all else, please review a pull request kindly. Our community can only be strong if we make it a welcoming and inclusive environment. To further promote this, the Jekyll community is governed by a [Code of Conduct](../CONDUCT.markdown) by which all community members must abide.
Use emoji liberally :heart: :tada: :sparkles: :confetti_ball: and feel free to be emotive!! Contributions keep this project moving forward and we're always happy to receive them, even if the pull request isn't ultimately merged.
Mike McQuaid's post on the GitHub blog entitled ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests) is a great place to start. It describes various scenarios in which it would be acceptable to close a pull request for reasons other than lack of technical integrity or accuracy. Part of being kind is responding to and resolving pull requests quickly.
## Respond Quickly
We should be able to review all pull requests within one week. The only time initial review should take longer is if all the maintainers mysteriously took vacation during the same week. Promptness encourages frequent, high-quality contributions from community members and other maintainers.
If your response requires a response on the part of the author, please add the `pending-feedback` tag. @jekyllbot will automatically remove the tag once the author of the pull request responds.
## Resolve Quickly
Similarly, we should aim to resolve pull requests quickly. If a pull request introduces a feature which does not fit into the core purpose or goal of the project, close it promptly with a kind explanation of why it is not acceptable.
Leave detailed comments wherever possible. Provide the contributor with context around why the change you are requesting is necessary, or why the question you are asking is important to resolve. The more context we can clearly communicate to the contributor, the better able the contributor is to provide high-quality patches.
You may close a pull request if more than 30 days pass without a response from the author.
In some cases, review will involve many weeks of back-and-forth. As long as communication continues, this is fine. Ideally, any PR would be capable of resolution within 30 days of it being opened.
## Look for Tests
If this is a code change, are there tests for the updated or added behaviour? Shipping a version with bugs is inevitable, but ensuring changes are tested helps keep bugs and regressions to a minimum.
## CI Must Pass
It is fine to ask a contributor to investigate failures on Travis and patch them up before you begin your review. It is helpful to leave a message for the contributor indicating that the tests have failed and that no review will occur before the tests pass. If they ask for help, take a look and assist if you can.
## Rule of Two
A pull request may be merged once two maintainers have reviewed the pull request and indicated that it is acceptable to them. There is no need to wait for a third unless one of the two reviewers wishes for another set of eyes.
## Think Security
We owe it to our users to ensure that using a theme from the community or building someone else's site doesn't come with built-in security vulnerabilities. Things like where files may be read from and written to are important to keep secure. Jekyll is also the basis for hosted services such as [GitHub Pages](https://pages.github.com), which cannot upgrade when security issues are introduced.
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
We use a series of "special labels" on GitHub.com to automate handling of some parts of the pull request and issue process. @jekyllbot may automatically apply or remove certain labels based on actions taken by users or maintainers. Below are the labels and how they work:
## `pending-feedback`
This label is used to indicate that we need more information from the issue/PR author in order to continue. It may be that you need more info before you can properly triage a bug report, or that you have some unanswered questions about a PR that need to be resolved before moving forward. You can safely ignore any issue with this label, as it is waiting for feedback.
## `needs-work` & `pending-rebase`
These labels are used to indicate that the Git state of a pull request must change. Both are removed once a push is registered (a "synchronize" event for the pull request) and the pull request becomes mergable. Add `needs-work` to a PR if, after your review, it requires code changes. Add `pending-rebase` to a PR if the code is fine but the branch is not automatically mergable with the target branch (e.g. `master`).
## `stale`
This label is automatically added and removed by @jekyllbot based on activity on an issue or pull request. The rules for this label are laid out in [Triaging an Issue: Staleness and automatic closure](triaging-an-issue.md#staleness-and-automatic-closure).
**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
Before evaluating an issue, it is important to identify if it is a feature
request or a bug. For the Jekyll project the following definitions are used
to identify a feature or a bug:
**Feature** - A feature is defined as a request that adds functionality to
Jekyll outside of its current capabilities.
**Bug** - A bug is defined as an issue that identifies an error that a user
(or users) encounter when using current Jekyll functionalities.
## Feature?
If the issue describes a feature request, ask:
1. Is this a setting? [Settings are a crutch](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#settings-are-a-crutch) for doing "the right thing". Settings usually point to a bad default or an edge case that could be solved easily with a plugin. Keep the :christmas_tree: of settings as small as possible so as not to reduce the usability of the product. We like the philosophy "decisions not options."
2. Would at least 80% of users find it useful? If even a quarter of our users won't use it, it's very likely that the request doesn't fit our product's core goal.
3. Is there another way to accomplish the end goal of the request? Most feature requests are due to bad documentation for or understanding of a pre-existing feature. See if you can clarify the end goal of the request. What is the user trying to do? Could they accomplish that goal through another feature we already support?
4. Even if 80% of our users will use it, does it fit the core goal of our project? We are writing a tool for making static websites, not a swiss army knife for publishing more generally.
Feel free to get others' opinions and ask questions of the issue author, but depending upon the answers to the questions above, it may be out of scope for our project.
If the request is within scope, prioritize it on the product roadmap with the other maintainers. Apply the appropriate tags and ensure the right people have weighed in to define the feature's scope and implementation. If you want to be the _best ever_, submit a PR yourself which adds the feature.
## Bug?
### Reproducibility
If the bug has clear reproduction steps, take a minute to try them. If it helps, write a test in our test suite for the scenario which replicates the problem. Can you reliably replicate the issue?
If you can't replicate the issue, post your replication steps which didn't work and ask for clarification from the issue author.
### Supported Platform
Is the author using a supported platform? We support the latest versions of macOS, Ubuntu, Debian, CentOS, Fedora, and Arch Linux.
You may close the issue immediately if the author cannot reproduce the issue on a supported platform. For Windows-related problems, leave a comment letting the user know that Windows is not officially supported, but that they may absolutely continue using the issue to communicate with folks from `@jekyll/windows` to further investigate. Additionally, you can point them to Jekyll Talk (https://talk.jekyllrb.com) as a means of getting support from the community.
If the user is experiencing issues with GitHub Pages or another hosted platform that we cannot reproduce, please direct them to the platform's support channel and close the issue.
### What they wanted vs. what they got
An issue without a clear explanation of what the user got and what they were expecting to get is not an issue we can accurately respond to. If the user doesn't provide this information, please ask for clarification and apply the `pending-feedback` label. This information helps us build test cases such that we do not break the behaviour again in the future. The `pending-feedback` label will be removed automatically once the issue author posts a reply.
Is what they wanted to get something we want to happen? Sometimes a bug report is actually masquerading as a feature request. See the guidance above for handling feature requests.
### Staleness and automatic closure
@jekyllbot will automatically mark issues as `stale` if no activity occurs for at least one month. @jekyllbot leaves a comment asking for information about reproducibility in current versions. If no one responds after another month, the issue is automatically closed.
And Ihaveaconfigurationfilewith"collections"setto"['methods']"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
And Ishouldsee"Collections:<p>Use<code>Jekyll.configuration</code>tobuildafullconfigurationforusew/Jekyll.</p>\n\n<p>Whatever:foo.bar</p>\n<p>Signsarenice</p>\n<p><code>Jekyll.sanitized_path</code>isusedtomakesureyourpathisinyoursource.</p>\n<p>Runyourgenerators!default</p>\n<p>Pagewithouttitle.</p>\n<p>Runyourgenerators!default</p>"in"_site/index.html"
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And the"_site/methods/configuration.html"fileshouldnotexist
Scenario: Rendered collection
Given Ihavean"index.html"pagethatcontains"Collections:{{site.collections}}"
And Ihavean"collection_metadata.html"pagethatcontains"Methodsmetadata:{{site.collections.methods.foo}}{{site.collections.methods}}"
Given Ihavean"index.html"pagethatcontains"Collections:output=>{{site.collections[0].output}}label=>{{site.collections[0].label}}"
And Ihavean"collection_metadata.html"pagethatcontains"Methodsmetadata:{{site.collections[0].foo}}{{site.collections[0]}}"
And Ihavefixturecollections
And Ihavea"_config.yml"filewithcontent:
"""
@@ -24,8 +24,10 @@ Feature: Collections
foo:bar
"""
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
And Ishouldsee"Collections:{\"methods"in"_site/index.html"
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"Collections:output=>true"in"_site/index.html"
And Ishouldsee"label=>methods"in"_site/index.html"
And Ishouldsee"Methodsmetadata:bar"in"_site/collection_metadata.html"
And Ishouldsee"<p>Whatever:foo.bar</p>"in"_site/methods/configuration.html"
@@ -40,11 +42,12 @@ Feature: Collections
permalink:/:collection/:path/
"""
When Irunjekyllbuild
Thenthe_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"<p>Whatever:foo.bar</p>"in"_site/methods/configuration/index.html"
Given Ihavean"index.html"pagethatcontains"Collections:output=>{{site.collections[0].output}}label=>{{site.collections[0].label}}foo=>{{site.collections[0].foo}}"
And Ihaveadefaultlayoutthatcontains"<div class='title'>TomPreston-Werner</div>{{content}}"
And Ishouldsee"Collections:_methods/collection/entries_methods/configuration.md_methods/escape-\+#%20\[\].md_methods/sanitized_path.md_methods/site/generate.md_methods/site/initialize.md_methods/um_hi.md"in"_site/index.html"
Scenario: Collections specified as an hash
Given Ihavean"index.html"pagethatcontains"Collections:{%formethodinsite.methods%}{{method.relative_path}}{%endfor%}"
And Ishouldsee"Collections:_methods/collection/entries_methods/configuration.md_methods/escape-\+#%20\[\].md_methods/sanitized_path.md_methods/site/generate.md_methods/site/initialize.md_methods/um_hi.md"in"_site/index.html"
Scenario: All the documents
Given Ihavean"index.html"pagethatcontains"Alldocuments:{%fordocinsite.documents%}{{doc.relative_path}}{%endfor%}"
And Ishouldsee"Alldocuments:_methods/collection/entries_methods/configuration.md_methods/escape-\+#%20\[\].md_methods/sanitized_path.md_methods/site/generate.md_methods/site/initialize.md_methods/um_hi.md"in"_site/index.html"
Scenario: Documents have an output attribute, which is the converted HTML
And Ishouldsee"Collections:Collection#entries,Jekyll.configuration,Jekyll.escape,Jekyll.sanitized_path,Site#generate,Initialize,Site#generate,"in"_site/index.html"
Scenario: Rendered collection with date/dateless filename
Given Ihavean"index.html"pagethatcontains"Collections:{%formethodinsite.thanksgiving%}{{method.title}}{%endfor%}"
And Ihavefixturecollections
And Ihavea"_config.yml"filewithcontent:
"""
collections:
thanksgiving:
output:true
"""
When Irunjekyllbuild
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"ThanksgivingBlackFriday"in"_site/index.html"
And Ishouldsee"HappyThanksgiving"in"_site/thanksgiving/2015-11-26-thanksgiving.html"
And Ishouldsee"BlackFriday"in"_site/thanksgiving/black-friday.html"
And Ihaveapost/simplelayoutthatcontains"PostLayout:{{content}}"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"PostLayout:<p>Theonlywinningmoveisnottoplay.</p>"in"_site/2009/03/27/wargames.html"
Scenario: Basic site with layouts, pages, posts and files
@@ -75,7 +80,8 @@ Feature: Create sites
|entry3 |2009-05-27 |post |contentforentry3. |
|entry4 |2009-06-27 |post |contentforentry4. |
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"Page:Sitecontains2pagesand4posts"in"_site/index.html"
And Ishouldsee"Noreplacement\{\{site.posts.size\}\}"in"_site/about.html"
And Ishouldsee""in"_site/another_file"
@@ -90,7 +96,8 @@ Feature: Create sites
And Ihavean"index.html"pagethatcontains"BasicSitewithincludetag:{%includeabout.textile%}"
And Ihavean"_includes/about.textile"filethatcontains"GeneratedbyJekyll"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"BasicSitewithincludetag:GeneratedbyJekyll"in"_site/index.html"
Scenario: Basic site with subdir include tag
@@ -99,7 +106,8 @@ Feature: Create sites
And Ihaveaninfodirectory
And Ihavean"info/index.html"pagethatcontains"BasicSitewithsubdirincludetag:{%includeabout.textile%}"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"BasicSitewithsubdirincludetag:GeneratedbyJekyll"in"_site/info/index.html"
Scenario: Basic site with nested include tag
@@ -108,31 +116,35 @@ Feature: Create sites
And Ihavean"_includes/jekyll.textile"filethatcontains"Jekyll"
And Ihavean"index.html"pagethatcontains"BasicSitewithincludetag:{%includeabout.textile%}"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"BasicSitewithincludetag:GeneratedbyJekyll"in"_site/index.html"
Scenario: Basic site with internal post linking
Given Ihavean"index.html"pagethatcontains"URL:{%post_url2020-01-31-entry2%}"
Given Ihavean"index.html"pagethatcontains"URL:{%post_url2008-01-01-entry2%}"
And Ihaveaconfigurationfilewith"permalink"setto"pretty"
And Ihavea_postsdirectory
And Ihavethefollowingposts:
|title |date |layout |content |
|entry1 |2007-12-31 |post |contentforentry1. |
|entry2 |2020-01-31 |post |contentforentry2. |
|entry2 |2008-01-01 |post |contentforentry2. |
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
And Ishouldsee"URL:/2020/01/31/entry2/"in"_site/index.html"
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"URL:/2008/01/01/entry2/"in"_site/index.html"
Scenario: Basic site with whitelisted dotfile
Given Ihavean".htaccess"filethatcontains"SomeDirective"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"SomeDirective"in"_site/.htaccess"
Scenario: File was replaced by a directory
Given Ihavea"test"filethatcontains"somestuff"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
When Ideletethefile"test"
Given Ihaveatestdirectory
And Ihavea"test/index.html"filethatcontains"someotherstuff"
@@ -146,13 +158,48 @@ Feature: Create sites
And Ihavea"secret.html"pagewithpublished"false"thatcontains"Unpublishedpage"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And the"_site/index.html"fileshouldexist
And the"_site/public.html"fileshouldexist
But the"_site/secret.html"fileshouldnotexist
When Irunjekyllbuild--unpublished
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And the"_site/index.html"fileshouldexist
And the"_site/public.html"fileshouldexist
And the"_site/secret.html"fileshouldexist
Scenario: Basic site with page with future date
Given Ihavea_postsdirectory
And Ihavethefollowingpost:
|title |date |layout |content |
|entry1 |2020-12-31 |post |contentforentry1. |
|entry2 |2007-12-31 |post |contentforentry2. |
When Irunjekyllbuild
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"contentforentry2"in"_site/2007/12/31/entry2.html"
And the"_site/2020/12/31/entry1.html"fileshouldnotexist
When Irunjekyllbuild--future
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And the"_site/2020/12/31/entry1.html"fileshouldexist
Scenario: Basic site with layouts, posts and related posts
Given Ihavea_layoutsdirectory
And Ihaveapagelayoutthatcontains"Page{{page.title}}:{{content}}"
And Ihaveapostlayoutthatcontains"Post{{page.title}}:{{content}}Relatedposts:{{site.related_posts|size}}"
And Ihavean"index.html"pagewithlayout"page"thatcontains"Sitecontains{{site.pages.size}}pagesand{{site.posts.size}}posts;Relatedposts:{{site.related_posts|size}}"
And Ihavea_postsdirectory
And Ihavethefollowingposts:
|title |date |layout |content |
|entry1 |2009-03-27 |post |contentforentry1. |
|entry2 |2009-04-27 |post |contentforentry2. |
When Irunjekyllbuild
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"Page:Sitecontains1pagesand2posts;Relatedposts:0"in"_site/index.html"
And Ishouldsee"Postentry1:<p>contentforentry1.</p>\nRelatedposts:1"in"_site/2009/03/27/entry1.html"
And Ishouldsee"Postentry2:<p>contentforentry2.</p>\nRelatedposts:1"in"_site/2009/04/27/entry2.html"
And Ihaveadefaultlayoutthatcontains"By{{'_Obi-wan_'|textilize}}"
And Ihaveadefaultlayoutthatcontains"By{{'_Obi-wan_'|markdownify}}"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"By<p><em>Obi-wan</em></p>"in"_site/2009/03/27/star-wars.html"
Scenario: Sort by an arbitrary variable
@@ -70,38 +73,37 @@ Feature: Embed filters
|Page-2 |default |6 |Something |
And Ihaveadefaultlayoutthatcontains"{{site.pages|sort:'value'|map:'title'|join:','}}"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldseeexactly"Page-2,Page-1"in"_site/page-1.html"
And Ishouldseeexactly"Page-2,Page-1"in"_site/page-2.html"
Scenario: Sort pages by the title
Given Ihavea_layoutsdirectory
And Ihavethefollowingpages:
|title |layout |content |
|Dog |default |Run |
|Bird |default |Fly |
And Ihavethefollowingpage:
|title |layout |content |
|Dog |default |Run |
And Ihavethefollowingpage:
|title |layout |content |
|Bird |default |Fly |
And Ihavethefollowingpage:
|layout |content |
|default |Jump |
|layout |content |
|default |Jump |
And Ihaveadefaultlayoutthatcontains"{%assignsorted_pages=site.pages|sort:'title'%}Theruleof{{sorted_pages.size}}:{%forpinsorted_pages%}{{p.content|strip_html|strip_newlines}},{%endfor%}"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldseeexactly"Theruleof3:Jump,Fly,Run,"in"_site/bird.html"
Scenario: Sort pages by the title ordering pages without title last
Given Ihavea_layoutsdirectory
And Ihavethefollowingpages:
|title |layout |content |
|Dog |default |Run |
|Bird |default |Fly |
And Ihavethefollowingpage:
|title |layout |content |
|Dog |default |Run |
And Ihavethefollowingpage:
|title |layout |content |
|Bird |default |Fly |
And Ihavethefollowingpage:
|layout |content |
|default |Jump |
|layout |content |
|default |Jump |
And Ihaveadefaultlayoutthatcontains"{%assignsorted_pages=site.pages|sort:'title','last'%}Theruleof{{sorted_pages.size}}:{%forpinsorted_pages%}{{p.content|strip_html|strip_newlines}},{%endfor%}"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldseeexactly"Theruleof3:Fly,Run,Jump,"in"_site/bird.html"
And Ihaveaconfigurationfilewith"defaults"setto"[{scope:{path:""},values:{layout:"pretty"}}]"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"THISISTHELAYOUT:<p>justsomepost</p>"in"_site/2013/09/11/default-layout.html"
And Ishouldsee"THISISTHELAYOUT:justsomepage"in"_site/index.html"
@@ -24,8 +25,9 @@ Feature: frontmatter defaults
And Ihavean"index.html"pagethatcontains"just{{page.custom}}by{{page.author}}"
And Ihaveaconfigurationfilewith"defaults"setto"[{scope:{path:""},values:{custom:"somespecialdata",author:"Ben"}}]"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
And Ishouldsee"<p>somespecialdata</p><div>Ben</div>"in"_site/2013/09/11/default-data.html"
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"<p>somespecialdata</p>\n<div>Ben</div>"in"_site/2013/09/11/default-data.html"
And Ishouldsee"justsomespecialdatabyBen"in"_site/index.html"
Scenario: Override frontmatter defaults by path
@@ -48,12 +50,56 @@ Feature: frontmatter defaults
And Ihaveaconfigurationfilewith"defaults"setto"[{scope:{path:"special"},values:{layout:"subfolder",description:"thespecialsection"}},{scope:{path:""},values:{layout:"root",description:"thewebpage"}}]"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"root:<p>infoonthewebpage</p>"in"_site/2013/10/14/about.html"
And Ishouldsee"subfolder:<p>infoonthespecialsection</p>"in"_site/special/2013/10/14/about.html"
And Ishouldsee"root:Overviewforthewebpage"in"_site/index.html"
And Ishouldsee"subfolder:Overviewforthespecialsection"in"_site/special/index.html"
Scenario: Use frontmatter variables by relative path
Given Ihavea_layoutsdirectory
And Ihaveamainlayoutthatcontains"main:{{content}}"
And Ihaveaconfigurationfilewith"defaults"setto"[{scope:{path:"special"},values:{layout:"main"}},{scope:{path:"special/_posts"},values:{layout:"main"}},{scope:{path:"_posts"},values:{layout:"main"}}]"
When Irunjekyllbuild
Then Ishouldgetazeroexitstatus
And the_sitedirectoryshouldexist
And Ishouldsee"main:<p>contentofsite/2013/10/14/about.html</p>"in"_site/2013/10/14/about.html"
And Ishouldsee"main:<p>contentofsite/special/2013/10/14/about1.html</p>"in"_site/special/2013/10/14/about1.html"
And Ishouldsee"main:<p>contentofsite/special/2013/10/14/about2.html</p>"in"_site/special/2013/10/14/about2.html"
Scenario: Use frontmatter scopes for subdirectories
Given Ihavea_layoutsdirectory
And Ihaveamainlayoutthatcontains"main:{{content}}"
And Ihaveaconfigurationfilewith"defaults"setto"[{scope:{path:"_posts/en"},values:{layout:"main",lang:"en"}},{scope:{path:"_posts/de"},values:{layout:"main",lang:"de"}}]"
When Irunjekyllbuild
Then the_sitedirectoryshouldexist
And Ishouldsee"main:<p>enisthecurrentlanguage</p>"in"_site/2014/09/01/helloworld.html"
And Ishouldsee"main:<p>deisthecurrentlanguage</p>"in"_site/2014/09/01/hallowelt.html"
# interface for Jekyll core components to trigger hooks
defself.trigger(owner,event,*args)
# proceed only if there are hooks to call
returnunless@registry[owner]
returnunless@registry[owner][event]
# hooks to call for this owner and event
hooks=@registry[owner][event]
# sort and call hooks according to priority and load order
hooks.sort_by{|h|@hook_priority[h]}.eachdo|hook|
hook.call(*args)
end
end
end
end
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
