Introduction to 3.3 – part 3

The 3.3 release is getting closer, as you can probably tell from the activity in the bug tracker and in the git repository. While the 3.3 development version is not ready for public testing yet, it’s time to tell you about another new, cool feature coming in 3.3:

Markdown syntax support!

Many of you have asked for a simpler syntax – especially for things like comments and issues, and specifically when it comes to things like adding simple new lines. As most of you probably know, we decided to use the mediawiki (MW) syntax globally when we introduced version 3. This means that all rich text items such as issue descriptions, wiki articles and comments would be written using the mediawiki syntax. However, it’s definitely true that using the MW syntax when composing comments is … well … not necessarily the best option.

Even though this is something I’ve wanted to fix, The Bug Genie still needs to retain the backwards compatibility with everything that has been created in version 3 up until now. So, to solve this, an alternate formatting syntax has been introduced for all rich text items – including wiki articles should you choose to want to use that (more on that later): Markdown. 

3.3 Markdown syntax
3.3 Markdown syntax

Now, markdown is touted as a “more humanly readable” syntax (than what?), and you’ve probably seen it in use already if you’re using Github (note, though, that the markdown syntax in Github is “github flavored” and not totally “markdown standards compliant”). One of the improvements Github made in their specific flavor of markdown was to make every line break count. This means if you press enter in your text box, there will be a line break – which is probably what you meant. It’s not limited to that, though – TBG is using a full-fledged PHP markdown parser (PHP markdown lib) which means you’ll get full support for the regular markdown syntax as well as advanced markdown features.

Of course, to keep up with the advanced features of the wiki, we’ve had to extend the markdown syntax ourselves. Nothing big, but I’ll list the most notable extensions:

  • As mentioned earlier, every line break counts – not as with the mediawiki syntax where only double line breaks counts (and they count as double linebreaks) or having to type “<br>” to get a linebreak.
  • We’ve kept the issue autoparsing – writing “issue #12”, “bug report #1680”, etc. automatically turns into links
  • Links and emails are automatically parsed, but we’ve also kept the category and internal linking syntax – [[Articlename]] and [[Articlename|Link text]] will turn into links to the articles specified

Some of you may still want to use the mediawiki syntax for your rich text content, and some of you may want to use the markdown syntax by default for issues and comments but prefer the more powerful mediawiki syntax for articles. You’ll be happy to know that this can be specified in your profile, and in all cases you can switch the specified syntax for any given item by using the syntax switcher as illustrated at the top.

3.3 Markdown profile settings
3.3 Markdown profile settings


What do you think of the new markdown syntax support? Does it solve your problems? Comment below!


2 thoughts on “Introduction to 3.3 – part 3

  1. Thanks! This, for some reason, is absolutely necessary for me to make good use of an issue tracker. Shorthand markup is much quicker than HTML or WYSIWYG, more readable than no formatting at all. Except there are 230948239048 different types and markdown is the one I wind up using the most so I pretty much get confused by the others and start typing markdown.

  2. Yes this totally solves my problem exactly like I wanted them solved. Here is a post I just put last night on the forum describing my problems with WM syntax not realizing this was here:

    I prefer the GitHub way versus the wiki way for making and managing wiki contributions, corrections, improvements, etc. SO, I am recreating all my wiki pages in GitHub, and providing links to them at the bottom of each Bug Genie Wiki page. When the master GitHub file for a wiki page is improved, I copy and paste the improved text into the Bug Genie Wiki page. This way I feel good allowing anyone to help improve my wiki content using all the collaborative power of GitHub.

    Using GitHub to manage contributions means never having to take away/revert back people’s changes after they made the effort to try and improve wiki content, as is required when using any wiki solution :evil:. The wiki way of collaboration is so harsh.

    The only problem with using GitHub to edit my wiki content is users’ inability to preview their changes in GitHub 😦 (cause, you know, the file contains Bub Genie (MediaWiki) markdown code that GitHub doesn’t recognize as Markdown code).

    I would like to have the option to choose GitHub Flavored Markdown for those wiki pages that my users are editing in GitHub, so that everyone can properly preview these pages in GitHub, or on some of the Markdown editors that allow you to see GitHub markdowned text side-by-side with a preview of it.

    I just spent most of today trying to find a user-friendly editor that would preview Bug Genie Media Wiki flavored markdown text with no luck. Right now, my users have to copy and paste their changes to my wiki pages on GitHub into a sandbox area on my Bug Genie Wiki to preview these changes.

    How I see my request working
    You are given the option to select BugGenie Markdown or GitHub markdown when setting preferences for a wiki page.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.