site.safe isn't the right way to set "production" mode

tommyblue commented 12 years ago

I think that using site.safe as flag for production mode isn't the right way to do it.

This only works on Github because it uses --safe when the site is generated. I think that the real purpose of --safe used by Github is a matter of security. This can be false outside it, e.g. on my own server, Heroku or wherever I'm deploying my site and if I want to use a custom plugin (disabled by --safe).

This generates big confusion when migrating from/to github or when developing a generic theme, I think you should find a better way (custom option?) to define a production mode

plusjade commented 12 years ago

@tommyblue you are right about every point. --safe as an environment flag is a hack. Most of JB's features are hacks. The problem is this no native way to set set environment flags automatically that work with GitHub Pages. This is the major point here. If we define a configuration variable via _config.yml then we are forcing the user to have to consciously remember to toggle to 'production' mode when pushing to GitHub, then remember to reset it to development when working locally. Manual user input is always a subpar user experience.

The entire reason why I'm piggybacking off of --safe is because it solves the above problem. It is the only way we can infer that Jekyll is being run by GitHub without any user input. For reference here is what GitHub says they override:

safe: true
source: <your pages repo>
destination: <the build dir>
lsi: false
pygments: true

I do understand the main issue: For users that intend to run custom plugins and deploy to their own setup, we get a collision of usage between disabling/enabling --safe.

However one of Jekyll Bootstrap's core design philosophies is to be 100% compatible with GitHub Pages, for superior convenience. With that in mind, plugins have to take a backseat to GitHub Pages support, quite simply because GitHub does not support any plugins.

I will always be open to suggestions for solving this issue though, as long as it remains compatible with GitHub pages. What do you think?

P.S. The GitHub pages limitation IS a limitation. But that's what JB is built for, that's JB's goal. However not being able to control the development of Jekyll is why I created http://ruhoh.com - it's still in beta but will solve all of the problems we've run into with Jekyll, GitHub Pages, and static blogging. (supports automatic environment variable toggling, like rails, natively).

EDIT: seeing as how GitHub overrides the source directory:

source: <your pages repo>

I might be able to do some regex or something (as permitted by Liquid -_-) to infer the GitHub change. But I'll have to do some due diligence to see that it works in all cases.

tommyblue commented 12 years ago

What about some config like:

JB:
  deploy: github

with some other possible values (heroku, private, etc) to set which kind of deploy will be used?

JB themes should check this value and not site.safe, so user would be free to use custom plugins.

plusjade commented 12 years ago

wont this still have to be set manually? environment flag is used to dynamically set path variables. for example localhost should always have root urls for simplicity. however when pushing to github your path may change based on whether its pushed to a master branch or namespaced in a repo using gh-pages branch. this produces urls that are namespaced by the name of the repo.

so these things should ideally happen automagically based on environment.

plusjade commented 12 years ago

sorry im on mobile. I get what you mean now. specifying a deploy strategy would determine how env works...ill think about this. sounds like it could work!

tommyblue commented 12 years ago

Thanks, I'll wait for your decision :)

nolith commented 12 years ago

I've got the same problem, but I wasn't aware of the custom plugins. In my setup, without any custom plugin, I wrote a custom rake script like this

desc "Generate statically the site"
task :generate do
  require 'jekyll'
  opt = Jekyll.configuration({})
  source = opt['source']
  destination = opt['destination']
  site = Jekyll::Site.new(opt.merge({'safe' => 'true'}))
  puts "Building site: #{source} -> #{destination}"
  begin
    site.process
  rescue Jekyll::FatalException => e
    puts
    puts "ERROR: YOUR SITE COULD NOT BE BUILT:"
    puts "------------------------------------"
    puts e.message
    exit(1)
  end
  puts "Successfully generated site: #{source} -> #{destination}"
end

As you can see I'm changing safe only for deployment generation.

If you can add a deployment destination, like @tommyblue suggested, and add this task into JB replacing safe with something like production; then you can get the current situation checking

(safe && github) || production

In order to avoid any issue to github page users you can default the deployment destination to github

ubershmekel commented 11 years ago

I wanted to use the jekyll-tagging plugin so I can have rss feeds for each tag. Problem was that I need BASE_PATH to work even when safe is false. So right now I can either have plugins or I can have BASE_PATH. A strange predicament IIUC.

Edit - my current solution is to edit manually _includes/JB/setup from this

{% if site.safe and site.JB.BASE_PATH and site.JB.BASE_PATH != '' %}

to this

{% if site.JB.BASE_PATH and site.JB.BASE_PATH != '' %}

bettse commented 11 years ago

I really like @tommyblue's suggestion; I have run into this issue each time I upgrade jekyll-bootstrap on my personal (non-github) account. Each time I have to modify the jekyll-bootstrap code to compensate, which mades me sad.

Twixer commented 11 years ago

I use the same solution as @ubershmekel but finally it's not the best one as it implies to modify the core files of JB ...