New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document `--unpublished` flag introduced in 91e9ecf #5959

Merged
merged 1 commit into from Mar 31, 2017

Conversation

Projects
None yet
6 participants
@zyv
Contributor

zyv commented Mar 17, 2017

No description provided.

@zyv

This comment has been minimized.

Show comment
Hide comment
@zyv

zyv Mar 17, 2017

Contributor

AppVeyor failure is not my fault ^__^

features/site_configuration.feature:160  Scenario: Generate proper dates with explicitly set timezone (same as posts' time) ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✘ 
  expected "Post Layout: <p>content for entry1.</p>\n built at 2013-04-09T23:22:00-04:00" not to match /Post Layout: <p>content for entry1.<\/p>\n built at 2013-04-09T23:22:00-04:00/m
  Diff:
  @@ -1,2 +1,3 @@
  -/Post Layout: <p>content for entry1.<\/p>\n built at 2013-04-09T23:22:00-04:00/m
  +Post Layout: <p>content for entry1.</p>
  + built at 2013-04-09T23:22:00-04:00
   (RSpec::Expectations::ExpectationNotMetError)
  C:/projects/jekyll/features/step_definitions.rb:240:in `/^I should (not )?see "(.*)" in "(.*)" unless Windows$/'
  features/site_configuration.feature:177:in `And I should see "Post Layout: <p>content for entry1.</p>\n built at 2013-04-09T23:22:00-04:00" in "_site/2013/04/09/entry1.html" unless Windows'
Contributor

zyv commented Mar 17, 2017

AppVeyor failure is not my fault ^__^

features/site_configuration.feature:160  Scenario: Generate proper dates with explicitly set timezone (same as posts' time) ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✘ 
  expected "Post Layout: <p>content for entry1.</p>\n built at 2013-04-09T23:22:00-04:00" not to match /Post Layout: <p>content for entry1.<\/p>\n built at 2013-04-09T23:22:00-04:00/m
  Diff:
  @@ -1,2 +1,3 @@
  -/Post Layout: <p>content for entry1.<\/p>\n built at 2013-04-09T23:22:00-04:00/m
  +Post Layout: <p>content for entry1.</p>
  + built at 2013-04-09T23:22:00-04:00
   (RSpec::Expectations::ExpectationNotMetError)
  C:/projects/jekyll/features/step_definitions.rb:240:in `/^I should (not )?see "(.*)" in "(.*)" unless Windows$/'
  features/site_configuration.feature:177:in `And I should see "Post Layout: <p>content for entry1.</p>\n built at 2013-04-09T23:22:00-04:00" in "_site/2013/04/09/entry1.html" unless Windows'
@ashmaroli

This comment has been minimized.

Show comment
Hide comment
@ashmaroli

ashmaroli Mar 17, 2017

Member

AppVeyor failure is not my fault

working on a fix..

Member

ashmaroli commented Mar 17, 2017

AppVeyor failure is not my fault

working on a fix..

@zyv

This comment has been minimized.

Show comment
Hide comment
@zyv

zyv Mar 26, 2017

Contributor

@parkr anything else I can do?

Contributor

zyv commented Mar 26, 2017

@parkr anything else I can do?

@DirtyF DirtyF self-assigned this Mar 26, 2017

@oe

This comment has been minimized.

Show comment
Hide comment
@oe
Member

oe commented Mar 27, 2017

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Mar 27, 2017

Member

Why did you choose the frontmatter page?

Member

parkr commented Mar 27, 2017

Why did you choose the frontmatter page?

@DirtyF

This comment has been minimized.

Show comment
Hide comment
@DirtyF

DirtyF Mar 27, 2017

Member

@zyv What do you say about mentioning this in https://jekyllrb.com/docs/drafts/ instead ?

Member

DirtyF commented Mar 27, 2017

@zyv What do you say about mentioning this in https://jekyllrb.com/docs/drafts/ instead ?

@zyv

This comment has been minimized.

Show comment
Hide comment
@zyv

zyv Mar 27, 2017

Contributor

Why did you choose the frontmatter page?

My reasoning was as follows:

  1. published is one of the few pre-defined front matter parameters, and it is introduced on the front matter page; it only makes sense to hint at a directly related option right next to it.
  2. It fits nicely into the narrative and allows to mention related draft functionality for posts which will be described later on.
  3. I was not able to think of a better place for it.
Contributor

zyv commented Mar 27, 2017

Why did you choose the frontmatter page?

My reasoning was as follows:

  1. published is one of the few pre-defined front matter parameters, and it is introduced on the front matter page; it only makes sense to hint at a directly related option right next to it.
  2. It fits nicely into the narrative and allows to mention related draft functionality for posts which will be described later on.
  3. I was not able to think of a better place for it.
@zyv

This comment has been minimized.

Show comment
Hide comment
@zyv

zyv Mar 27, 2017

Contributor

What do you say about mention this in https://jekyllrb.com/docs/drafts/ instead ?

I don't like this idea for the following reasons:

  1. It is my understanding that setting published for posts is deprecated in favor of newer drafts functionality which arguably is better suited for this task, so I feel that mentioning it on the drafts page would be confusing, unless, instead of adding a ProTip, one expands it into a longer discussion of what's the difference between the two, and which one should be used for which purpose.
  2. I would expect to find a mention of --unpublished flag next to the place where published front matter variable for pages is introduced in the first place. It wouldn't occur to me, that I should be looking for it on a page describing drafts functionality for posts.
Contributor

zyv commented Mar 27, 2017

What do you say about mention this in https://jekyllrb.com/docs/drafts/ instead ?

I don't like this idea for the following reasons:

  1. It is my understanding that setting published for posts is deprecated in favor of newer drafts functionality which arguably is better suited for this task, so I feel that mentioning it on the drafts page would be confusing, unless, instead of adding a ProTip, one expands it into a longer discussion of what's the difference between the two, and which one should be used for which purpose.
  2. I would expect to find a mention of --unpublished flag next to the place where published front matter variable for pages is introduced in the first place. It wouldn't occur to me, that I should be looking for it on a page describing drafts functionality for posts.
@zyv

This comment has been minimized.

Show comment
Hide comment
@zyv

zyv Mar 27, 2017

Contributor

Having that said, I'm just trying to clarify my line of thinking to you guys. If you are still unconvinced and would like to have it documented differently, that's certainly fine with me, as long as it gets documented at all. Thank you for considering my patch!

Contributor

zyv commented Mar 27, 2017

Having that said, I'm just trying to clarify my line of thinking to you guys. If you are still unconvinced and would like to have it documented differently, that's certainly fine with me, as long as it gets documented at all. Thank you for considering my patch!

@DirtyF

This comment has been minimized.

Show comment
Hide comment
@DirtyF

DirtyF Mar 27, 2017

Member

a longer discussion of what's the difference between the two, and which one should be used for which purpose.

@zyv AFAIC I use YFM published: false to unpublish pages or posts already published whether I use _drafts before I publish a post for instance.

What's your use?

Member

DirtyF commented Mar 27, 2017

a longer discussion of what's the difference between the two, and which one should be used for which purpose.

@zyv AFAIC I use YFM published: false to unpublish pages or posts already published whether I use _drafts before I publish a post for instance.

What's your use?

@zyv

This comment has been minimized.

Show comment
Hide comment
@zyv

zyv Mar 28, 2017

Contributor

@DirtyF yes, that's they way I see it too.

What's your use?

In our case, we use Jekyll as a CMS, and in addition to what you already described, the published flag is used as a drafts system for pages, plus to mark 'special' pages like documentation showcasing various components available to the editors. For development builds that go out to the staging system, I set --drafts --unpublished, so that editors can preview how pages currently in progress are really going to look like after the go through Jekyll, and for release builds I remove these flags, and the draft pages & posts are dropped from the live version accordingly.

Contributor

zyv commented Mar 28, 2017

@DirtyF yes, that's they way I see it too.

What's your use?

In our case, we use Jekyll as a CMS, and in addition to what you already described, the published flag is used as a drafts system for pages, plus to mark 'special' pages like documentation showcasing various components available to the editors. For development builds that go out to the staging system, I set --drafts --unpublished, so that editors can preview how pages currently in progress are really going to look like after the go through Jekyll, and for release builds I remove these flags, and the draft pages & posts are dropped from the live version accordingly.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Mar 31, 2017

Member

@jekyllbot: merge +docs

Member

parkr commented Mar 31, 2017

@jekyllbot: merge +docs

@jekyllbot jekyllbot merged commit 2014709 into jekyll:master Mar 31, 2017

1 of 2 checks passed

continuous-integration/appveyor/pr AppVeyor build failed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

jekyllbot added a commit that referenced this pull request Mar 31, 2017

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