Now that our site lives in master, may we delete the gh-pages branch to avoid confusion?

How do you feel about changing the name of the gh-pages branch to master?

Since the website is the main (only) thing this repository is tracking, it makes sense to me that it would be the master branch. The gh-pages branch feels like it would be better suited for documentation regarding another project, rather than the primary branch of the project.

Thoughts?

Quero fazer parte desta organização.

Crazy idea: What if we programmatically pulled plugins from GitHub that contained the tag jekyll-plugin?

The following Rake task takes the directory listing (_data/themes.yml and _data/plugins.yml clubbed into a single _data/entries.yml) and downloads each gem into their respective directory

# frozen_string_literal: true

require "rubygems"
require "rake"
require "open-uri"
require "safe_yaml"

task :default do
  entries = SafeYAML.load_file("_data/entries.yml")
  entries.each do |type, list|
    FileUtils.mkdir_p("_data/#{type}")
    list.each do |item|
      begin
        data = open("https://rubygems.org/api/v1/gems/#{item}.yaml").read
        File.open("_data/#{type}/#{item}.yml", "wb") { |file| file.puts data }
      rescue OpenURI::HTTPError
        puts "#{item} does not seem to exist at rubygems.org"
        next
      end
    end
  end
end

The data files can then be used to define the front end..
We can then set up Travis to download these files at a set interval..
Thoughts?

I wonder if we could whip something up that runs when the site is built on CI that verifies that all Gems exist, and URLs don't 404.

Seems like it’d be as easy as adding something to _plugins/

Jekyll supports plugins or themes(in previous version I suppose) like all other CMS. Is there any plan to make it easier to use, like better navigation, detailed plugin landing page?

I'm happy to help on this if Jekyll team is fine with this proposal.

It seems that if spec/plugins_spec.rb fails but HTML-Proofer succeeds, script/cibuild will exit with 0 and cause CI to pass when it should have failed because of spec/plugins_spec.rb.

Perhaps we don't even bother running HTML-Proofer if we find errors before that stage?

I think this site has potential to be a great place to discover gemified Jekyll plugins. The potential I see, however, does not mean it can actually be useful and therefore that we should use it. Any thoughts on this?

needs search functionality (maybe over archive page?)

We should create an entry for each of the official Jekyll team owned plugins

A couple questions/suggestions related to plugin organization:

1. Categories or tags?
   Some of the plugins don't fit easily into single categories. For instance, a plugin that is both a generator and a tag to interact with that generator. I think tags would work well here.
2. Two tag "types", plugin type and purpose?
   Having a hard time thinking up good names for these, but I think it would be good to have two types of tags, one for the plugin type (e.g., tag, generator, other), and one to group the plugin by purpose (e.g., images, code, asset pipeline, performance).
3. Collections?
   I think where people have more than one plugin in a repo it would be good to list each plugin separately but point to the same url. Thoughts?

Right now, we list available plugins in the Jekyll documentation.

We should create an entry on the site for each of these plugins.

Does this seem realistic?

As a Jekyll Plugin Author
I can include information concerning the compatibility of my plugin

Success criteria

• Plugin author receives a notification/PR asking him to specify plugin compatibility
• PR contains informations on how to commit the info to this repository
• compatible: v3 can be specified in the FrontMatter
• compatibility is displayed on the plugin page

Message

Hi ,

We want you to know that Jekyll plugin directory is moving to a dedicated website. The current page on Jekyll documentation will redirect to the plugin directory once we're done with the migration.

In order to help users choose from the listing, it would be nice if as the plugin author you could tell us with which Jekyll versions your plugin has been tested.

In order to do so, pick or add your plugin in the _plugins folder in the repository, edit the FrontMatter and add one of the following values:

compatible: [v2,v3] 

compatible: v2

compatible: v3

Thanks a lot for your help!
With ❤️ from the Jekyll Core Team