Hello Steven,

could you check if you activated textile on your instance?
You can do this by going to the admin settings and selecting Settings from the side menu and then set Text formatting to Textile.
Once this is activated, you should be able to see the toolbar above the text areas.

Hi Robin.

I’ve been doing more research, and here is what I’ve found:

1. After posting the question above, I found that drop-down, and it was set to “none”. Clicking on the drop down, only “none” is available.
2. I started trying to debug why that field only allowed “none”. After inserting a byebug statement in _general.html.erb for the code that generates the dropdown, I found that Redmine::WikiFormatting::@@formatters was empty.
3. On further investigation, I put in a byebug statement where the formatter is registered (config/initializers/wiki_formatting.rb). Stepping through that, I found that the formatter is registered.
4. Loading the General options page, I see that it allows me to select textile!
5. I selected textile. Upon reload, I am back to the situation as before — none is the only option, and it’s selected. No wiki buttons appear.

I’m not sure why @@formatters becomes empty, that seems odd to say the least. I’m not a ruby/rails developer, just picking up bits and pieces. Have any ideas?

More info:

I put a byebug statement in before @@formatters is set to an empty map, in addition to where the formatter is registered.

It seems the line:

@@formatters = {}

Is being executed after the formatters are initialized, and therefore the formatters go away. I thought this should be done only once. Any idea why this is continually executed?

I changed the initialization of @@formatters to be within each method instead of a global. Still same problem.

It appears that the entire class is being unloaded between calls, so the system must load the class again. Does this make sense?

This has become rather critical, as we cannot use the Wiki without textile actually working. Any thoughts on this?

Does it make any difference at all when you run the code in production mode? How do you run it right now?

RAILS_ENV=production rails server

@Markus Kahl, from your clue I was able to figure this out!

1. I tried your suggestion, and found that none of the assets were being served, with “no route” errors.
2. Looking online, it seems this is a common occurrence, you have to change the configuration for config.serve_static_assets to true.
3. Got me thinking, maybe it’s an issue with this config file.
4. Found this setting in the production.rb file:

  # Code is not reloaded between requests
  config.cache_classes = true

Aha! Sounds like my problem. Changed the setting in the development.rb file to true, and voila!

I really think this should be listed here: https://www.openproject.org/open-source/development/setting-development-environment/

Alternatively, the way the formatters are initialized should be able to withstand this unloading and loading of the formatting class.

Thanks for your help!

Hey, good job! No bother, you figured it all out on your own after all! You are right, the class should not break due to unloading. I wonder why I haven’t noticed this problem myself. Maybe I just haven’t used that feature. I’ll look into to it some more to see if I can fix this.

The default setting of the development.rb configuration (as downloaded from github) was that caching was off. So I’m surprised more developers don’t see this, perhaps it’s just not a major concern.

I am new to ruby and rails, so I didn’t realize how to run the environment in different modes (or that development is the normal mode being run without any extra parameters), running in production mode has sped up things considerably, so thanks for that too!