Generator plugins broken by new cleanup behavior #268

andyfowler opened this Issue Jan 17, 2011 · 14 comments


None yet
9 participants

Any generator that writes files directly to the output directory is broken as of commit c1ed790 -- this includes the sample generator code in the wiki. It's not clear how a generator should specify that the files it creates are 'whitelisted'.

molte commented Jan 30, 2011

I am experiencing this issue too.

Any file that is created by a generator will be marked as obsolete and deleted even though it has just been created.

Same here. Good to know I'm not alone with this problem …
Any advice welcome.

molte commented Feb 3, 2011

Creating a Ruby file in the "_plugins" folder with the following contents works for me, though I haven't run it against the test suite:

module Jekyll
  class Site
    def process

@molte -- nice workaround, although I hope this isn't the long-term solution. In my case, I'm compiling LESS.js files, and with this workaround, they're all regenerated each run.

molte commented Feb 5, 2011

Of course you could also entirely remove the self.cleanup line and then setup the generator to only regenerate/recompile if the source file has been modified by including something like this in your generator:

def generate(site)
  if modified? File.join(site.source, "foo"), File.join(site.dest, "bar")
    # Execute the generation ...

def file_timestamp(path)
  File.exist?(path) ? File.mtime(path).to_i : 0

def modified?(input_path, output_path)
  file_timestamp(input_path) != file_timestamp(output_path)

You can actually fix this by doing site.static_files << index after performing index.write(site.dest), where index is the GeneratorObject. I tried using site.pages instead of site.static_files, but I ended up getting Liquid Exceptions. Of course, I would still integrate @molte's suggestion.

I've also updated the sample code in the wiki.

I think that updated example in the wiki isn't right - "index" isn't anything at that point in the code.

Sorry about that, it should be "f". I just took index from a plugin I wrote for my installation.

If it's still broken, I can provide a complete working example, it just wont be the specific one the wiki uses.

The working example may be good - even with that it looks like it's busted on the latest version of jekyll - it tries to call #destination on whatever is passed into static_files

I've updated the example, although it might not be the simplest. It generates category index files, which people might find useful.

I ended up using a custom implementation of StaticFile that didn't actually do anything during the write phase, but since it existed in site.static_files, the output wouldn't get cleaned away. See


parkr commented Apr 14, 2013

Site#cleanup depends upon the site having created the list of files. The better option would be for Generators and the like to add the files they generate to the Site's file manifest and to remove those files from the chopping block.

Why doesn't this affect the pagination plugin?


pathawks commented Apr 23, 2013

I have absolutely no idea why my file is created during generation, and then deleted during cleanup. site.dest, 'feeds/posts', 'full.xml' ), 'w') do |f|

site.static_files <<, site.dest, 'feeds/posts', 'full.xml')

I can't find any documentation relating to this at all.


parkr commented May 18, 2013

Our pagination generator is an example of getting around this. In your generate method, add your pages to site.pages and boom-she-boom you're good to go.

parkr closed this May 18, 2013

jekyllbot locked and limited conversation to collaborators Feb 27, 2017

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