15

6

Hi,

After upgrading to the FB8 beta, I converted our wiki template and CSS to the FB8 style. However, my custom styles in the CSS no longer show up in the editor under Format. How can I get these back?

Interestingly, documents relying on them still render the styles fine.

Fog Creek Case FC1954367

flag

4 Answers

7

Short answer: FogBugz 8 no longer supports the ability to add custom entries to the Format, Font Family, and Font Size dropdowns in the wiki editor.

Longer answer: One of the biggest goals of FogBugz 8 was to give our customers a much-improved wiki experience. As part of that effort, we replaced our own bug-riddled wiki editor with a customized version of CKEditor.

Switching to CKEditor has not only eliminated the vast majority of browser bugs our customers had to deal with in FogBugz 7 and earlier, but has also enabled our customers to edit their wiki pages' HTML source directly (if they so desire). This has been a long-standing feature request and gives our customers a great deal of power when it comes to editing their wiki documents.

An additional benefit of moving toward a third party wiki editor is the ease with which we can apply updates to it as the CKEditor team updates their editor to support new browser features and fixes bugs. We have customized CKEditor in a number of ways in order for it to integrate more seamlessly with FogBugz; however, the more we customize it, the more difficult it becomes for us to apply updates to CKEditor that come from the CKEditor team. Custom fonts and formatting styles is one place where we have decided not to customize CKEditor.

The decision to lose support for custom formatting options in the wiki editor was not made lightly. This is why documents relying on these custom styles continue to look the way they did in FogBugz 7: we made sure to carry forward the custom font, size, and format styles into the new FogBugz 8 default template.

Workaround: The workaround for custom format styles (e.g., p.ExtraPadding {padding: 25px;}), is to edit the HTML source of your wiki article and manually add the necessary class attributes (e.g., add class="ExtraPadding" attribute to the <p> tag). If you look at the answer below this one, you'll also see there is another workaround involving editing the CKEditor configuration to put your custom style back in.

link|flag
2 
 Honestly, that really is terrible. Especially for folks like us that have long ago adopted Joel's method of writing specs with sidenotes etc. Moving from Word to the wiki for specs was only doable because we could use custom styles as an analog for Word's styles. Formatting a technical sidenote manually everytime gets in the way of the authoring process. I'd strongly request a way of consistently applying repeated styles to a wiki doc. – jasonjwwilliams Sep 9 2010 at 19:14
@jason I understand -- see my comment below @DaveJ's post. – Ben Kamens♦ Sep 16 2010 at 18:11
4

For those who are running a stand-alone FogBugz 8 server the solution is quite simple: Configure CKEditor to your needs.

In the Website/ckeditor/config.js file I added the following, before the Formats are set up:

config.format_warning         = { element : 'p' , attributes : { 'class' : 'Warning_Comment' } };
config.format_section_heading = { element : 'h2', attributes : { 'class' : 'Section_Heading' } };
config.format_user_comment    = { element : 'p' , attributes : { 'class' : 'User_Comment'    } };
config.format_info            = { element : 'p' , attributes : { 'class' : 'Info_Comment'    } };
config.format_divider         = { element : 'p' , attributes : { 'class' : 'Divider'         } };
config.format_tags = 'p;pre;user_comment;info;warning;divider;h1;h2;section_heading;h3;h4;h5;h6';

Then you need to add the names of those Formats with a "tag_" prefix to the appropriate language files in ckeditor/lang/*.js, search for "tag_" and insert something like the following at that point (it wont work if you simply insert them at the beginning of the map):

,tag_warning:'Warning',tag_section_heading:'Section Heading',tag_user_comment:'User Comment',tag_info:'Info Comment',tag_divider:'Divider',tag_p:'Normal'

Now I have my custom styles back :-)

link|flag
1

Sorry for the question post - I'm a new user so I don't have enough rep to leave a comment -

This is absolutely ridiculous that you are actually REMOVING features!

The custom styles was the only thing that made the FB7 wiki usable. CKEditor definitely handles styles so I'm not sure your excuse that you don't want to modify it too much makes sense.

link|flag
5 
 Removing features is certainly one of the hardest decisions a development team has to make, but we strongly believe that there are times when a feature's complexity and buggyness (for many users) does not merit its existence. As Dane said above, we make this decision rarely and not lightly, and if tons of users are upset by the lack of custom styles in the WYSIWYG editor we will work hard to find a way to bring them back. – Ben Kamens♦ Sep 16 2010 at 18:11
Rather than custom CSS styles, perhaps styles could viewed as a sort of CKEditor macro. That is, defining a style is the process of selecting the attributes you want (color, bold, font, etc.). Applying a style would then automatically apply all of those attributes with tags as though you were doing it manually in CKEditor. Does that make sense? – jasonjwwilliams Sep 16 2010 at 18:51
That does make sense -- I'll open a case for this and we'll continue to listen to anybody else who finds themselves in need of these custom styles. – Ben Kamens♦ Sep 16 2010 at 20:16
2 
 Is this case opened? I'm unsure where to upvote for CKE macros. – Jared Oct 14 2010 at 20:03
I cannot find the case you refer to either. I want to throw in my frustration at this change as well. For myself, manually making a few edits to the raw HTML is not a problem. However, the rest of my FogBugz users may not be comfortable editing the source directly. I like the decision to go to a more supported editor, but modifying the source in order to get the look and feel you want seems like a step backwards. – Mike Caron Nov 11 2010 at 18:21
show 1 more comment
0

We have another problem with removing the custom paragraph classes. We relied on it not only for formatting, but also for content flagging. There were sections which could easily be marked as an open questtion, and then a very simple script would collect these kinds of different paragrapgs, just to give an idea. I don't see an alternative way to implement this now.

link|flag

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.