Allow asset compilation without `color_schemes` table

Heroku setup with Discourse has been simplified a lot over the development of Discourse (from what I can tell), but at the moment there is a hangup during asset compilation when the database has not been set up.

Is it possible to allow asset compilation when the DB hasn’t been created at all? I see that other assets fail ‘smoothly’, but compilation fails and exits when the color_schemes table hasn’t been created. Is there an easy workaround for this?

Otherwise, it seems like I can temporarily disable color schemes, but I’m not sure how. For now, I’ve been able to get past this by manually changing a few lines in discourse_sass_importer.rb (and now discourse_stylesheets.rb), which is definitely a hack.


1 Like

Anyone? I have the same problem.

In fact this is a bug, not a feature.

Heroku is precompiling assets before the database has been migrated?? Why is it doing that? I don’t understand this scenario.

Heroku doesn’t run migrations for you, so you have to push to Heroku first and then run migrations. However, Heroku will reject your deployment if asset compilation fails, so you get ‘stuck’.

For others in this situation, I was able to get around it with a few changes. In line 51 of discourse_sass_importer I skip the ColorScheme.enabled check:

    if color_scheme = false#ColorScheme.enabled
      ColorScheme.base_colors.each do |name, base_hex|
        override = color_scheme.colors_by_name[name]
        contents << "$#{name}: ##{override ? override.hex : base_hex} !default;\n"
      special_imports[name].each do |css_file|
        contents <<

And then in 106 of discourse_stylesheets.rb:

  # theme = (cs = ColorScheme.enabled) ? "#{}-#{cs.version}" : 0
  theme = (cs = false) ? "#{}-#{cs.version}" : 0

I would love to have a SiteSetting to disable ColorScheme without checking the DB. That would still feel hacky, as I don’t really want to disable ColorScheme, I just want it to fail silently.

I’d be enthusiastic about contributing code for this solution if it’s agreed that it is a good idea.

I’ll look into making a less hacky fix.

Thing is, for Discourse to work correctly we need access to the DB when compiling assets, a lot of CSS can be customised based on data in the database.

We really need a way to communicate this to Heroku deployment system.

cc @rwdaigle


For the css at least, I made a change that skips the precompile if the table doesn’t exist. It can be compiled at runtime during the first request, so it’s safe enough. If there are future dependencies on tables, it will probably break again. Let’s hope that Heroku can change the way this is done.

1 Like

@sam ensure the db migration is run before trying to compile assets · hone/discourse@ce7b081 · GitHub worked for me on first push once you add a redis and database addon.