Disable `jekyll-feed` (_site/feed.xml) during development

[dataframing]

Hey all, thanks for the amazing library! Just had a quick question/idea for a potential quality-of-life (at least, during development) improvement. Happy to help build a solution here however I can! Fastpages should be fast 😄

---

Is your feature request related to a problem? Please describe. When developing the site via make server, we have a watchmedo command that rebuilds the site entirely. Re-building the website seems to happen almost instantly, but re-building the RSS feed takes ~4-6 seconds (edit: I'm guessing this increases with the number of posts? After creating a few dummy posts it's now at ~12-14 seconds). This latency can be frustrating when you just want to update HTML/CSS/etc.

Describe the solution you'd like Ideally, if I remove the jekyll-feed plugin from _config.yml, we should no longer build feed.xml. I can see why that may be tricky, since you'd have to then figure out what to do with the RSS link in the footer.

Alternatively, maybe it's possible to have a no-feed-during-dev setting in _config.yml. If set to true, we don't build feed.xml. If we push to a PR on master, however, we can have a GitHub action to spot-check that this is intended? I imagine some may be frustrated with how slow it is to build feed.xml during development, but still want to build it when pushing to master.

Describe alternatives you've considered

1. Commenting out the jekyll-feed plugin from _config.yml, as seen in https://github.com/fastai/fastpages/issues/446.
2. Setting post_limit: 0 and excerpt_only: true.
3. Commenting out the jekyll-feed gem dependency from the Gemfile, adding RUN bundle update to the Dockerfile, then re-building the Docker images.

Additional context

• This seems to be an issue on the base minima theme, as well: https://github.com/jekyll/minima/issues/375, https://github.com/jekyll/minima/issues/553
• Other complains about jekyll-feed: https://github.com/github/pages-gem/issues/627

[github-actions[bot]]

Thank you for opening an issue. If this issue is related to a bug, please follow the steps and provide the information outlined in the Troubleshooting Guide. Failure to follow these instructions may result in automatic closing of this issue.

[hamelsmu]

Thanks for raising this. I'm still searching for a way to fix this if anyone has any ideas on how to fix this please let me know

[hamelsmu]

@dataframing does this work?

Setting post_limit: 0 and excerpt_only: true.

I'm thinking I could override post_limit during development mode. Do you want to try that and let me know if it works?

[dataframing]

@hamelsmu Thanks for looking into it! I'm still trying to solve this one, as well.

Setting post_limit: 0 and excerpt_only: true.

I'm thinking I could override post_limit during development mode. Do you want to try that and let me know if it works?

Unfortunately, I've tried that and it doesn't work 😢 It would work as a solution, if/when we fix the underlying feed generation. Does it work on your end?

I've raised an issue with the upstream minima repo here. I'm hoping we can get a bit more insight into this, since it's kinda painful to have this bottleneck during local development 😕

[kiendang]

Ran into the same issue and looks like apart from removing the jekyll-feed gem, monkey patching is the only thing that works. Can confirm neither commenting out - jekyll-feed under plugins: nor setting excerpt_only: true works for me.

My solution is mostly similar to what was suggested in the minima issue, only a little bit different

# frozen_string_literal: true

module JekyllFeed
  class Generator < Jekyll::Generator
    safe true
    priority :lowest

    alias_method :old_generate, :generate

    def generate(site)
      if site.config["feed"]["disable"]
        Jekyll.logger.info "Jekyll Feed disabled"
      else
        old_generate(site)
      end
    end
  end
end

this way I can disable feed by putting

feed:
  disable: true

in _config.yml. This allows me to enable it again just by leaving that out of the config

Another thing I did is create an extra config file for dev, _config_dev.yml and put the feed-disabling config there instead of the main _config.yml, then add --config _config.yml,_config_dev.yml to jekyll-serve. This way _config.yml doesn't need modifying for production.

[netw0rkf10w]

Ran into the same issue and looks like apart from removing the jekyll-feed gem, monkey patching is the only thing that works. Can confirm neither commenting out - jekyll-feed under plugins: nor setting excerpt_only: true works for me.

My solution is mostly similar to what was suggested in the minima issue, only a little bit different

# frozen_string_literal: true

module JekyllFeed
  class Generator < Jekyll::Generator
    safe true
    priority :lowest

    alias_method :old_generate, :generate

    def generate(site)
      if site.config["feed"]["disable"]
        Jekyll.logger.info "Jekyll Feed disabled"
      else
        old_generate(site)
      end
    end
  end
end

this way I can disable feed by putting

feed:
  disable: true

in _config.yml. This allows me to enable it again just by leaving that out of the config

Another thing I did is create an extra config file for dev, _config_dev.yml and put the feed-disabling config there instead of the main _config.yml, then add --config _config.yml,_config_dev.yml to jekyll-serve. This way _config.yml doesn't need modifying for production.

I followed this solution and it seems to disable Jekyll feed. However, I observe that the build time is unchanged (still very high). Not sure if I did something wrong...

[kiendang]

I actually noticed that too. Maybe something else was causing the long build time, but I haven't looked into it.

[hamelsmu]

NB: I am writing this comment on all open issues

Thank you for posting this issue, and I'm really sorry I haven't gotten around to fixing this. All of my time has been focused on nbdev. In the new version of nbdev, we knew that we wanted to include blogging rather than it being a separate project. We realized that Quarto, which the new version of nbdev is built on, is much better than fastpages. Rather than keep this project going, we are recommending that people migrate to Quarto as we think that will be more powerful for users and is a much better tool for blogging.

I've written a detailed migration guide with some tools that will hopefully make the process of switching much easier. Overall I think it will be worth it for users.

My apologies again for not getting to this issue sooner. Will close this issue with this PR https://github.com/fastai/fastpages/pull/657, where we are letting people know that we are deprecating this project. Thanks again for your support and for using fastpages! 🙇🏽