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

Gem-based themes #4510

Closed
benbalter opened this Issue Feb 11, 2016 · 35 comments

Comments

Projects
None yet
@benbalter
Contributor

benbalter commented Feb 11, 2016

Similar to what we did with Gem-based plugins, we should introduce the concept of Gem-based themes, making it easier for users to style their content, and hopefully creating a more robust theme ecosystem.

How themes work today

Today, while there are lots of great Jekyll themes out there, the installation process generally involves either forking a repo or copying files into the destination site. The problem with this approach, beyond ease of use and the ability to quickly switch themes, is that there's no good way to downstream subsequent updates (not to mention, from a DRY perspective, the theme's CSS and templates now exist in hundreds or thousands of repos, each with their own versions and edits).

How Gem-based themes would work for users

Find a theme you like? Simply add theme: awesome-theme in your site's _config.yml file. That'll instruct Jekyll to load the Gem-based theme, just like it would any plugin. The theme would be able to register layouts, and its static assets (css, javascript, images, etc.) would be automatically included in the built site. Heck, maybe there's even an {{ asset_include_tag }}, or similar, to include the theme's assets in your HTML. Lets say the theme has a main layout. If you don't like it, simply create a layout in your standard _layouts folder with the same name. At render time Jekyll will first look to the user's layouts and includes, and if one doesn't exist, it'll then look to the theme's. As an added bonus, if you're just using the theme defaults, we've allowed you to better separate content from presentation, as your repo is now almost entirely your own content, with less Jekyll noise getting in your way.

How Gem-based themes would work for theme creators

Themes are just Gems with a defined folder structure, not unlike the Jekyll site itself. The only required file would be the Gemspec itself. Beyond that, you can introduce as many layouts you'd like, in a _layouts folder, the same with _includes. For assets, the _sass folder can automatically be included in sass's include path (meaning the user could just do @import 'awesome-theme' to include your css in there own). We can also define some sort of assets (_assets?) folder, which'll be automatically included as a whole, in the built site. Heck, maybe themes can even be dependencies of other themes (e.g., a vanilla Bootstrap theme might be a dependency of Hyde). We'll probably also want to include a screenshot in a predictable path.

A note on security

From a GitHub Pages perspective, it'd be important to us that themes not be allowed to contain any server-side executable code (e.g., only liquid-based logic). As far as I understand it, the Gemspec isn't executed once the Gem is built. That would allow us to very quickly whitelist a large number of themes for use with GitHub Pages (and would then not have to strictly version each), allowing theme developers to push updates to Rubygems, which would then update the version used by GitHub Pages, without requiring (much) human intervention. If themes need advanced functionality, they can require a plugin (which could go through the existing review process).

A note on conventions

Right now, everyone has their own design patterns. Is it site.title or site.name? site.description or site.tagline? layout: main or layout: default? For themes to be truly fungible, we'll probably want to put out some sort of style guide for themes, describing common design patterns, and how best to implement them in cross-theme ways.

A note on our own theme

If we went down this path, the default Jekyll theme (that's bundled with Jekyll), would be pulled out into its own Gem. jekyll new could them simply create the necessary config and folder structure. Heck, maybe jekyll new could even take a theme name and be capable to generate a boilerplate site for any theme.

Thoughts? I Know there's some prior art within Octopress, but think making themes first class citizens of the Jekyll world, like we did for plugins, could go a long way to level up the Jekyll publishing experience, especially for new users.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Feb 11, 2016

Contributor

{{ asset_include_tag }}

The asset_ prefix and {{ asset }} tags are well known in jekyll-assets this will muddy our tags and the include tag is a planned tag for us as users keep asking us to allow merging assets outside of Sprockets. So this further exacerbates that.

We can also define some sort of assets (_assets?)

jekyll-assets uses this folder, I would be pretty angry to see that Jekyll started taking over our well known folder and muddied our meaning of it for it's own purposes further complicating our goals on jekyll-assets because of shallow design.

Contributor

envygeeks commented Feb 11, 2016

{{ asset_include_tag }}

The asset_ prefix and {{ asset }} tags are well known in jekyll-assets this will muddy our tags and the include tag is a planned tag for us as users keep asking us to allow merging assets outside of Sprockets. So this further exacerbates that.

We can also define some sort of assets (_assets?)

jekyll-assets uses this folder, I would be pretty angry to see that Jekyll started taking over our well known folder and muddied our meaning of it for it's own purposes further complicating our goals on jekyll-assets because of shallow design.

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Feb 11, 2016

Contributor

I would be pretty angry to see that Jekyll started taking over our well known folder and muddied our meaning of it for it's own purposes

It looks like the _assets folder is just used for images, fonts, etc. Unless I'm misunderstanding, theoretically, a theme could have an _assets folder, that would work with jekyll-assets, no?

Contributor

benbalter commented Feb 11, 2016

I would be pretty angry to see that Jekyll started taking over our well known folder and muddied our meaning of it for it's own purposes

It looks like the _assets folder is just used for images, fonts, etc. Unless I'm misunderstanding, theoretically, a theme could have an _assets folder, that would work with jekyll-assets, no?

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Feb 11, 2016

Contributor

@benbalter they could, if _assets had images/, fonts/, css/ and others (which if that happened I would be 👍 all the way,) which is something I've been hoping that Jekyll itself would adopt for it's basic processors to that jekyll-assets could be the big brother to Jekyll's own scss and other processors and be a straight up advanced drop in replacement for full on asset management.

Contributor

envygeeks commented Feb 11, 2016

@benbalter they could, if _assets had images/, fonts/, css/ and others (which if that happened I would be 👍 all the way,) which is something I've been hoping that Jekyll itself would adopt for it's basic processors to that jekyll-assets could be the big brother to Jekyll's own scss and other processors and be a straight up advanced drop in replacement for full on asset management.

@parkr parkr added the feature label Feb 16, 2016

@geraldb

This comment has been minimized.

Show comment
Hide comment
@geraldb

geraldb Feb 22, 2016

Hello, if I may add my two cents on themeing. I'd say ideally you can simply "link" in a theme to your site in the theme folder using a git submodule (or low-tech just unpack a theme zip archive). See Hugo or other site builders / generators where it works today. That way you can, for example, install a couple of themes (lets say three) and ideally switch the theme just by changing the theme settings in _config.yml. Bundling up themes into gems would be a nice extra. Keep it up. Cheers. PS: FYI: There's also a related discussion thread titled "What is the future of Octopress Ink?" in the jekyll talk forum.

geraldb commented Feb 22, 2016

Hello, if I may add my two cents on themeing. I'd say ideally you can simply "link" in a theme to your site in the theme folder using a git submodule (or low-tech just unpack a theme zip archive). See Hugo or other site builders / generators where it works today. That way you can, for example, install a couple of themes (lets say three) and ideally switch the theme just by changing the theme settings in _config.yml. Bundling up themes into gems would be a nice extra. Keep it up. Cheers. PS: FYI: There's also a related discussion thread titled "What is the future of Octopress Ink?" in the jekyll talk forum.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Feb 22, 2016

Contributor

@geraldb I like the premise behind what submodule does but I think for the sake of quickness when it comes to new users people should consider subtree instead: https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ it just makes life easier for regular users.

Contributor

envygeeks commented Feb 22, 2016

@geraldb I like the premise behind what submodule does but I think for the sake of quickness when it comes to new users people should consider subtree instead: https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ it just makes life easier for regular users.

@erlend-sh

This comment has been minimized.

Show comment
Hide comment
@erlend-sh

erlend-sh Feb 22, 2016

Contributor

Super psyched about this! Would be a great topic for JekyllConf.

cc @imathis

Contributor

erlend-sh commented Feb 22, 2016

Super psyched about this! Would be a great topic for JekyllConf.

cc @imathis

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Feb 22, 2016

Contributor

I'd say ideally you can simply "link" in a theme to your site in the theme folder using a git submodule (or low-tech just unpack a theme zip archive).

The challenge with submodules, is that there's a high degree of technical complexity involved. I've been using Git for years and I still have to look up the commands each time. Not to mention, it requires you to have Git locally and feel comfortable using the command line.

In terms of subsequent upstream updates, there's no way to semantically version a git submodule, meaning you just have to blinding update to the latest version. And unlike all other dependencies (Kramdown, Rouge, etc.), the theme would have its own upgrade process, independent of bundle update, and in the case of zip files, that gets even more complicated, as you're taking things out of version control completely.

That way you can, for example, install a couple of themes (lets say three) and ideally switch the theme just by changing the theme settings in _config.yml

Yes! This should be possible, with what I described above. You could have multiple themes "installed" by adding them to your Gemfile, and could switch between them by simply changing an option in your config file.

Contributor

benbalter commented Feb 22, 2016

I'd say ideally you can simply "link" in a theme to your site in the theme folder using a git submodule (or low-tech just unpack a theme zip archive).

The challenge with submodules, is that there's a high degree of technical complexity involved. I've been using Git for years and I still have to look up the commands each time. Not to mention, it requires you to have Git locally and feel comfortable using the command line.

In terms of subsequent upstream updates, there's no way to semantically version a git submodule, meaning you just have to blinding update to the latest version. And unlike all other dependencies (Kramdown, Rouge, etc.), the theme would have its own upgrade process, independent of bundle update, and in the case of zip files, that gets even more complicated, as you're taking things out of version control completely.

That way you can, for example, install a couple of themes (lets say three) and ideally switch the theme just by changing the theme settings in _config.yml

Yes! This should be possible, with what I described above. You could have multiple themes "installed" by adding them to your Gemfile, and could switch between them by simply changing an option in your config file.

@geraldb

This comment has been minimized.

Show comment
Hide comment
@geraldb

geraldb Feb 22, 2016

@benbalter The idea is that a theme is just a git repo, that is, a bunch of files and folders. A "normal" user just unpacks an archive in the theme folder. I'd argue that bundling up a theme into a Rubygem is beyond most users skills. The idea is to keep it as simple a possible e.g. just a bunch of files (in a git repo). Using a theme "linked" in with a git module is just an "advanced" option as would be using a "gem". As mentioned above Hugo might be a "real world" model to study (for inspiration) - see https://gohugo.io/themes/installing as are other static or dynamic site builders such as WordPress and others. Anyways, thanks for the consideration and thanks for all the great plugins (avatar, seo, sitemap, feed, etc.) and the GitHub Pages push to Jekyll 3. Keep it up. Cheers.

geraldb commented Feb 22, 2016

@benbalter The idea is that a theme is just a git repo, that is, a bunch of files and folders. A "normal" user just unpacks an archive in the theme folder. I'd argue that bundling up a theme into a Rubygem is beyond most users skills. The idea is to keep it as simple a possible e.g. just a bunch of files (in a git repo). Using a theme "linked" in with a git module is just an "advanced" option as would be using a "gem". As mentioned above Hugo might be a "real world" model to study (for inspiration) - see https://gohugo.io/themes/installing as are other static or dynamic site builders such as WordPress and others. Anyways, thanks for the consideration and thanks for all the great plugins (avatar, seo, sitemap, feed, etc.) and the GitHub Pages push to Jekyll 3. Keep it up. Cheers.

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Feb 22, 2016

Contributor

@geraldb Totally with you, and in what I'm proposing above, themes are just repos, so the above would be possible for those that prefer. The biggest limitation with unpacking an archive is that it requires command-line, or at least local access. Imagine a completely wed-based publishing flow, where you simply choose a theme and start adding content.

Not to mention, there's something to be said for separating content from presentation and DRYing up Jekyll sites. For most users, there's no reason to have a third-party theme cluttering up their site's version control (or to have 30,000 different versions floating around, each with one edit never surfaced upstream).

The other limitation is that archive or submodule based themes are limited to one folder, so while assets (css, javascript) may copy cleanly, things like vendoring layouts and includes do not, as you cannot currently have multiple layout or include folders.

The other advantage of the above is an idea similar to WordPress's template hierarchy, in which I theme can have a default.html, but if I don't like it, I can add my own to my site (not modifying the theme itself), which Jekyll could use instead, still giving me access to includes, other templates, assets, etc.

See where you're coming from, and a big fan of Hugo, I'm hoping the Jekyll theme ecosystem can (and should be) much bigger than one repo would safely allow! 😄

Contributor

benbalter commented Feb 22, 2016

@geraldb Totally with you, and in what I'm proposing above, themes are just repos, so the above would be possible for those that prefer. The biggest limitation with unpacking an archive is that it requires command-line, or at least local access. Imagine a completely wed-based publishing flow, where you simply choose a theme and start adding content.

Not to mention, there's something to be said for separating content from presentation and DRYing up Jekyll sites. For most users, there's no reason to have a third-party theme cluttering up their site's version control (or to have 30,000 different versions floating around, each with one edit never surfaced upstream).

The other limitation is that archive or submodule based themes are limited to one folder, so while assets (css, javascript) may copy cleanly, things like vendoring layouts and includes do not, as you cannot currently have multiple layout or include folders.

The other advantage of the above is an idea similar to WordPress's template hierarchy, in which I theme can have a default.html, but if I don't like it, I can add my own to my site (not modifying the theme itself), which Jekyll could use instead, still giving me access to includes, other templates, assets, etc.

See where you're coming from, and a big fan of Hugo, I'm hoping the Jekyll theme ecosystem can (and should be) much bigger than one repo would safely allow! 😄

@geraldb

This comment has been minimized.

Show comment
Hide comment
@geraldb

geraldb Feb 22, 2016

@benbalter If I may add one more comment:

Yes! This should be possible, with what I described above. You could have multiple themes
"installed" by adding them to your Gemfile, and could switch between them by simply changing an
option in your config file.

I'd argue that keeping the option of just a bunch of files and folders - that you can copy or more "advanced" link into a theme folder will make it easier (in addition to the option for bundled gems) e.g.:

  • GitHub does NOT need to whitelist any themes (less work and more choice) and, thus,
  • Jekyll users can use whatever theme they like - even on GitHub Pages.

See where you're coming from, and a big fan of Hugo, I'm hoping the Jekyll theme ecosystem can
(and should be) much bigger than one repo would safely allow! 😄

I'm a actually a fan of Jekyll (see my little themes collection, for example) ;-) Hugo was just an example. WordPress I'd say is a better example e.g. works the same, that is, without any gems ;-) - just unpack the theme e.g. bunch of files and folders into a "dedicated" theme folder. Of course, Jekyll needs to get updated for theme-ing e.g. so there's a hierachy of lookups for files (if not found in themes/[theme-name] try layouts etc.). PS: Just to make sure - I'm all for using bundled gems for themes - the argument is that it should be an option and just a bunch of files and folders (following a convention - of course - a la WordPress or similar) works too. Just my two cents. Again thanks all your efforts moving Jekyll forward and keeping GitHub Pages up-to-date. Keep it up. Cheers.

geraldb commented Feb 22, 2016

@benbalter If I may add one more comment:

Yes! This should be possible, with what I described above. You could have multiple themes
"installed" by adding them to your Gemfile, and could switch between them by simply changing an
option in your config file.

I'd argue that keeping the option of just a bunch of files and folders - that you can copy or more "advanced" link into a theme folder will make it easier (in addition to the option for bundled gems) e.g.:

  • GitHub does NOT need to whitelist any themes (less work and more choice) and, thus,
  • Jekyll users can use whatever theme they like - even on GitHub Pages.

See where you're coming from, and a big fan of Hugo, I'm hoping the Jekyll theme ecosystem can
(and should be) much bigger than one repo would safely allow! 😄

I'm a actually a fan of Jekyll (see my little themes collection, for example) ;-) Hugo was just an example. WordPress I'd say is a better example e.g. works the same, that is, without any gems ;-) - just unpack the theme e.g. bunch of files and folders into a "dedicated" theme folder. Of course, Jekyll needs to get updated for theme-ing e.g. so there's a hierachy of lookups for files (if not found in themes/[theme-name] try layouts etc.). PS: Just to make sure - I'm all for using bundled gems for themes - the argument is that it should be an option and just a bunch of files and folders (following a convention - of course - a la WordPress or similar) works too. Just my two cents. Again thanks all your efforts moving Jekyll forward and keeping GitHub Pages up-to-date. Keep it up. Cheers.

@0xdevalias

This comment has been minimized.

Show comment
Hide comment
@0xdevalias

0xdevalias Feb 22, 2016

I really like the idea of gem-based themes, so long as there is still the option to overwrite the files we want to customize (something along the lines of drupals base/subtheme)

It also gives more incentive to users to submit PR's to fix bugs/add features to the theme rather than it being buried in a million different incompatible repo's.

0xdevalias commented Feb 22, 2016

I really like the idea of gem-based themes, so long as there is still the option to overwrite the files we want to customize (something along the lines of drupals base/subtheme)

It also gives more incentive to users to submit PR's to fix bugs/add features to the theme rather than it being buried in a million different incompatible repo's.

@fmaida

This comment has been minimized.

Show comment
Hide comment
@fmaida

fmaida Feb 23, 2016

IMHO two nice additions would be:

Each theme and every asset and partial html file used to render the theme should reside in the same folder. Basically I'm suggesting to drop "_include" and "_layouts" folders and the index.html in the root folder of the website, and use instead a "_themes" folder. Inside the _themes folder you should have one subfolder for each theme

For example:

Default theme --> jekyll-test/_themes/default
Alternative theme --> jekyll-test/_themes/alternative

Every partial / include file should reside in a subfolder inside the theme folder. You could decide for example that every theme folder MUST have an _include folder, and that everytime Liquid finds a {% include %} tag, the included file should be picked up from that folder.

I'm thinking about a themes folder structured this way:

[ _themes ]
    |-- [ default ]
        |-- [ _include ]
            |-- partial01.html
            |-- partial02.html
        |-- [ _assets ]
            |-- [ images ]
                |-- image01.jpg
                |-- image02.jpg
            |-- [ css ]
                |-- style.css
            |-- [ js ]
                |-- script.js
        |-- _config.yml
        |-- default.html
        |-- index.html
        |-- page.html
        |-- post.html
        |-- ...

Each theme subfolder should contain another _config.yml where you could store some preferences that would help defining how that theme should be rendered by Jekyll.

For example, during the next holidays you could decide to set an option to change the look of the theme... for example by setting this:

# This is the theme configuration file, located at jekyll-test/_themes/default/_config.yml

# Ho ho ho! It's christmas!
festive_look: True

and Jekyll and the theme author could use that parameter to display some festive images (dunno... an image of santa claus riding his sled with the reindeers that flies up in the air on the background of the website... some christmas decorations here and there...)
When the holidays are over you could simply turn that option to false, rebuild the pages and turn the site back to its previous look.

I'm sorry for my bad english... I hope that you'll understand anyway what I'm trying to explain...

fmaida commented Feb 23, 2016

IMHO two nice additions would be:

Each theme and every asset and partial html file used to render the theme should reside in the same folder. Basically I'm suggesting to drop "_include" and "_layouts" folders and the index.html in the root folder of the website, and use instead a "_themes" folder. Inside the _themes folder you should have one subfolder for each theme

For example:

Default theme --> jekyll-test/_themes/default
Alternative theme --> jekyll-test/_themes/alternative

Every partial / include file should reside in a subfolder inside the theme folder. You could decide for example that every theme folder MUST have an _include folder, and that everytime Liquid finds a {% include %} tag, the included file should be picked up from that folder.

I'm thinking about a themes folder structured this way:

[ _themes ]
    |-- [ default ]
        |-- [ _include ]
            |-- partial01.html
            |-- partial02.html
        |-- [ _assets ]
            |-- [ images ]
                |-- image01.jpg
                |-- image02.jpg
            |-- [ css ]
                |-- style.css
            |-- [ js ]
                |-- script.js
        |-- _config.yml
        |-- default.html
        |-- index.html
        |-- page.html
        |-- post.html
        |-- ...

Each theme subfolder should contain another _config.yml where you could store some preferences that would help defining how that theme should be rendered by Jekyll.

For example, during the next holidays you could decide to set an option to change the look of the theme... for example by setting this:

# This is the theme configuration file, located at jekyll-test/_themes/default/_config.yml

# Ho ho ho! It's christmas!
festive_look: True

and Jekyll and the theme author could use that parameter to display some festive images (dunno... an image of santa claus riding his sled with the reindeers that flies up in the air on the background of the website... some christmas decorations here and there...)
When the holidays are over you could simply turn that option to false, rebuild the pages and turn the site back to its previous look.

I'm sorry for my bad english... I hope that you'll understand anyway what I'm trying to explain...

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 2, 2016

Does GitHub Pages support submodules?

ghost commented Mar 2, 2016

Does GitHub Pages support submodules?

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Mar 2, 2016

Contributor

Does GitHub Pages support submodules?

In some cases. See https://help.github.com/articles/using-submodules-with-pages/

Contributor

benbalter commented Mar 2, 2016

Does GitHub Pages support submodules?

In some cases. See https://help.github.com/articles/using-submodules-with-pages/

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 2, 2016

Neat. Then people using GitHub Pages (AKA Jekyll in safe mode) can just use folders and submodules as themes. Other users can also use Gem-based themes.

ghost commented Mar 2, 2016

Neat. Then people using GitHub Pages (AKA Jekyll in safe mode) can just use folders and submodules as themes. Other users can also use Gem-based themes.

@benbalter

This comment has been minimized.

Show comment
Hide comment
@benbalter

benbalter Mar 2, 2016

Contributor

Then people using GitHub Pages (AKA Jekyll in safe mode) can just use folders and submodules as themes. Other users can also use Gem-based themes.

To be clear, I'm looking to make Gem-based themes widely available on GitHub Pages (to avoid having to use copy 🍝 or resorting to adding submodules via command line).

Contributor

benbalter commented Mar 2, 2016

Then people using GitHub Pages (AKA Jekyll in safe mode) can just use folders and submodules as themes. Other users can also use Gem-based themes.

To be clear, I'm looking to make Gem-based themes widely available on GitHub Pages (to avoid having to use copy 🍝 or resorting to adding submodules via command line).

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 2, 2016

+1 on letting themes have a _config.yml, you could then support theme extending (e.g. a theme called base and an extension of that theme containing theme: base in its _config.yml)

ghost commented Mar 2, 2016

+1 on letting themes have a _config.yml, you could then support theme extending (e.g. a theme called base and an extension of that theme containing theme: base in its _config.yml)

@miklb

This comment has been minimized.

Show comment
Hide comment
@miklb

miklb Apr 6, 2016

I believe there is some prior art in regards to this and what was planned for Octopress 3. There even seems to be a working(?) theme-as-gem genesis-theme

Maybe @imathis could shed some light on how far he got on the work on this?

miklb commented Apr 6, 2016

I believe there is some prior art in regards to this and what was planned for Octopress 3. There even seems to be a working(?) theme-as-gem genesis-theme

Maybe @imathis could shed some light on how far he got on the work on this?

@ezekg

This comment has been minimized.

Show comment
Hide comment
@ezekg

ezekg May 13, 2016

Hey guys, loving the idea of having themes be installable via gems.

But the theme documentation is very confusing as it is now. I was searching everywhere trying to find a gem-based theme (even searching https://www.google.com/#q=jekyll+theme+filetype:gemspec) until I realized that this is still in discussion.

Can we update the documentation with a disclaimer and possibly link to common places users can find themes right now? I still don't really know where to look to find an easily installable theme.

ezekg commented May 13, 2016

Hey guys, loving the idea of having themes be installable via gems.

But the theme documentation is very confusing as it is now. I was searching everywhere trying to find a gem-based theme (even searching https://www.google.com/#q=jekyll+theme+filetype:gemspec) until I realized that this is still in discussion.

Can we update the documentation with a disclaimer and possibly link to common places users can find themes right now? I still don't really know where to look to find an easily installable theme.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr May 13, 2016

Member

@ezekg This feature is unreleased and I believe no one has created a compatible theme. So you're coming up empty because there's nothing to find yet. 😄 🔜

Member

parkr commented May 13, 2016

@ezekg This feature is unreleased and I believe no one has created a compatible theme. So you're coming up empty because there's nothing to find yet. 😄 🔜

@parkr parkr closed this May 13, 2016

@parkr parkr reopened this May 13, 2016

@ezekg

This comment has been minimized.

Show comment
Hide comment
@ezekg

ezekg May 13, 2016

@parkr, I still think the documentation should be updated until this feature is actually released. It's really, really confusing for newcomers as it is now. 👌

ezekg commented May 13, 2016

@parkr, I still think the documentation should be updated until this feature is actually released. It's really, really confusing for newcomers as it is now. 👌

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks May 13, 2016

Contributor

@ezekg that's part of a larger problem unrelated to this.

Contributor

envygeeks commented May 13, 2016

@ezekg that's part of a larger problem unrelated to this.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr May 13, 2016

Member

I still think the documentation should be updated until this feature is actually released. It's really, really confusing for newcomers as it is now. 👌

@ezekg There is no documentation yet so you can bet we will write some! 😄 see #4891

Member

parkr commented May 13, 2016

I still think the documentation should be updated until this feature is actually released. It's really, really confusing for newcomers as it is now. 👌

@ezekg There is no documentation yet so you can bet we will write some! 😄 see #4891

@ezekg

This comment has been minimized.

Show comment
Hide comment
@ezekg

ezekg May 13, 2016

@parkr, what do you mean there's no documentation? The section on themes is live on the Jekyll docs: https://jekyllrb.com/docs/themes/. As it is now, it's telling you to do something that isn't even supported yet. It was definitely confusing for me and prompted me to search for themes installable via Rubygems.

But maybe I'm just misunderstanding and what's outlined in the docs isn't what's being discussed here. I thought it was related but it doesn't look like it from @envygeeks's response. My bad.

Edit: I see that in #4891, you're aware of the issue. Fair enough. Still might want to add a disclaimer if you're going to publish docs on a feature that isn't fully released. 😜

Anyways, thanks for the info and links!

ezekg commented May 13, 2016

@parkr, what do you mean there's no documentation? The section on themes is live on the Jekyll docs: https://jekyllrb.com/docs/themes/. As it is now, it's telling you to do something that isn't even supported yet. It was definitely confusing for me and prompted me to search for themes installable via Rubygems.

But maybe I'm just misunderstanding and what's outlined in the docs isn't what's being discussed here. I thought it was related but it doesn't look like it from @envygeeks's response. My bad.

Edit: I see that in #4891, you're aware of the issue. Fair enough. Still might want to add a disclaimer if you're going to publish docs on a feature that isn't fully released. 😜

Anyways, thanks for the info and links!

@parkr parkr closed this in 6a2ffba May 13, 2016

@0xdevalias

This comment has been minimized.

Show comment
Hide comment
@0xdevalias

0xdevalias May 13, 2016

Should this be reopened, as that commit doesn't really fix this?

0xdevalias commented May 13, 2016

Should this be reopened, as that commit doesn't really fix this?

@pathawks

This comment has been minimized.

Show comment
Hide comment
@pathawks

pathawks May 13, 2016

Member

Should this be reopened, as that commit doesn't really fix this?

That's a different issue.

Member

pathawks commented May 13, 2016

Should this be reopened, as that commit doesn't really fix this?

That's a different issue.

@0xdevalias

This comment has been minimized.

Show comment
Hide comment
@0xdevalias

0xdevalias May 14, 2016

@pathawks Different issue?

This issue is now Closed.

parkr closed this in 6a2ffba 11 hours ago

6a2ffba

Add note about being unreleased to the Themes documentation.
Fixes #4510.

0xdevalias commented May 14, 2016

@pathawks Different issue?

This issue is now Closed.

parkr closed this in 6a2ffba 11 hours ago

6a2ffba

Add note about being unreleased to the Themes documentation.
Fixes #4510.

@pathawks

This comment has been minimized.

Show comment
Hide comment
@pathawks

pathawks May 14, 2016

Member

The title of this issue is Gem-based themes. The fact that documentation is synced with master instead of stable is a very real problem, but that is a different issue. It is also being discussed in #4891

I’m not saying it’s not a problem, only that it is a bigger/different problem than this issue. 👍

Perhaps a new issue should be opened re: website being out of sync?

Member

pathawks commented May 14, 2016

The title of this issue is Gem-based themes. The fact that documentation is synced with master instead of stable is a very real problem, but that is a different issue. It is also being discussed in #4891

I’m not saying it’s not a problem, only that it is a bigger/different problem than this issue. 👍

Perhaps a new issue should be opened re: website being out of sync?

@0xdevalias

This comment has been minimized.

Show comment
Hide comment
@0xdevalias

0xdevalias May 14, 2016

@pathawks I know what the title of THIS issue is. And I am saying that THIS issue became CLOSED automatically based on the wording in the above mentioned commit.

0xdevalias commented May 14, 2016

@pathawks I know what the title of THIS issue is. And I am saying that THIS issue became CLOSED automatically based on the wording in the above mentioned commit.

@haslinger

This comment has been minimized.

Show comment
Hide comment
@haslinger

haslinger May 15, 2016

It seems, that the _assets folder didn't make it in the code as it is also not in the docs. Is there a different way to include assets (i.e. images, javascript files, fonts) into the gem?

Update: I got directed to #4595 => There isn't. So waiting for 0.2 to be able to create my first theme.

haslinger commented May 15, 2016

It seems, that the _assets folder didn't make it in the code as it is also not in the docs. Is there a different way to include assets (i.e. images, javascript files, fonts) into the gem?

Update: I got directed to #4595 => There isn't. So waiting for 0.2 to be able to create my first theme.

@thisguy07

This comment has been minimized.

Show comment
Hide comment
@thisguy07

thisguy07 May 15, 2016

Who are all u guys
On May 15, 2016 2:20 AM, "Stefan Haslinger" notifications@github.com
wrote:

It seams, that the _assets folder didn't make it in the code as it is also
not in the docs. Is there a different way to include assets (i.e. images,
javascript files, fonts) into the gem?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#4510 (comment)

thisguy07 commented May 15, 2016

Who are all u guys
On May 15, 2016 2:20 AM, "Stefan Haslinger" notifications@github.com
wrote:

It seams, that the _assets folder didn't make it in the code as it is also
not in the docs. Is there a different way to include assets (i.e. images,
javascript files, fonts) into the gem?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#4510 (comment)

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr May 15, 2016

Member

@haslinger Not at the moment, no! But we want to add that soon.

I'll push my commit up to jekyllrb.com later today. Sorry for the confusion!

Member

parkr commented May 15, 2016

@haslinger Not at the moment, no! But we want to add that soon.

I'll push my commit up to jekyllrb.com later today. Sorry for the confusion!

@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo May 22, 2016

Contributor

See #4891.

Contributor

chrisfinazzo commented May 22, 2016

See #4891.

@Joshfindit

This comment has been minimized.

Show comment
Hide comment
@Joshfindit

Joshfindit Sep 29, 2016

One thing that's really grinding my gears (full disclosure: I'm biased against gem-based themes right now, but I do see the logic and the positive possibilities):

Doing jekyll serve, then making a change to a theme file does not rebuild the site.
Being able to effortlessly iterate was huge when I first discovered Jekyll, and now there is much more friction.

Joshfindit commented Sep 29, 2016

One thing that's really grinding my gears (full disclosure: I'm biased against gem-based themes right now, but I do see the logic and the positive possibilities):

Doing jekyll serve, then making a change to a theme file does not rebuild the site.
Being able to effortlessly iterate was huge when I first discovered Jekyll, and now there is much more friction.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Sep 29, 2016

Member

@Joshfindit We are working on this in Jekyll 3.3. The various theme directories (_includes, _layouts, _sass and in 3.3, assets) behave as though they were a Jekyll site. Plop some posts or pages in your theme project as if it were a Jekyll site, run jekyll serve and everything should work great. The example subdirectory was something we decided was a bad idea after noticing this exact issue.

Member

parkr commented Sep 29, 2016

@Joshfindit We are working on this in Jekyll 3.3. The various theme directories (_includes, _layouts, _sass and in 3.3, assets) behave as though they were a Jekyll site. Plop some posts or pages in your theme project as if it were a Jekyll site, run jekyll serve and everything should work great. The example subdirectory was something we decided was a bad idea after noticing this exact issue.

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