SynHi

Introduction

In writing posts like ‘What a difference a character makes’ (www.elearningworld.org/what-a-difference-a-character-makes), I’ve been describing code, which on its own as plain text can be difficult to read as the structure and form are not immediately apparent. This is where ‘Syntax highlighters’ (https://en.wikipedia.org/wiki/Syntax_highlighting) come in. Previously I’ve done this within the posts using screenshots, but recently the EnlighterJS plugin was added (wordpress.org/plugins/enlighter) to eLearningWorld and I updated all of my posts that contain code. This means that you’re now able to copy the code as you need using the plugins functionality.

My Foundation theme (moodle.org/plugins/theme_foundation) also has syntax highlighting functionality, as I wanted the student to be able to visualise the code their educator had written for them. This I see as especially important in a more technological world, where learning software engineering is a valuable skill. However it is restricted to the theme, what if you use another theme? Having completed ‘MoodleBites for Developers’ levels one and two courses (www.moodlebites.com/mod/page/view.php?id=24546 and www.moodlebites.com/mod/page/view.php?id=19542) I was inspired to write a ‘filter’ (https://docs.moodle.org/en/Filters) to solve this problem as I’d not written one before.

And so I’ve created ‘SynHi’ (github.com/gjb2048/moodle-filter_synhi), a syntax highlighting filter, which in this post I will describe and explain the initial process of getting a plugin published on Moodle.org.

Disclaimers

Firefox® is a registered trademark of the Mozilla Foundation – www.mozilla.org/en-US/foundation/trademarks/policy.

Ubuntu® is a registered trademark of Canonical Ltd – ubuntu.com/legal/intellectual-property-policy.

Moodle™ is a registered trademark of ‘Martin Dougiamas’ – moodle.com/trademarks.

Other names / logos can be trademarks of their respective owners. Please review their website for details.

I am independent from the organisations listed above and am in no way writing for or endorsed by them.

So what does it do?

When the filter is ‘active’ then any ‘pre’ or ‘code’ tag (www.w3schools.com/tags/tag_pre.asp / www.w3schools.com/tags/tag_code.asp) within a course, module or block within the ‘Course context’ (docs.moodle.org/en/Context) will be highlighted, for example, this label:

What you need to write as attributes within the tags depends on the ‘engine’ being used. The filter currently comes with two which are chosen by the administrator:

being: EnlighterJS (github.com/EnlighterJS/EnlighterJS – Mozilla Public License 2.0 (MPL-2.0)) and SyntaxHighlighter (github.com/syntaxhighlighter/syntaxhighlighter – MIT licensed). The latter needs a ‘class’ attribute telling it what language the code is in, such as:

<pre class="brush: java">

And that’s all it does! However, each ‘engine’ does have a set of its own styles to change the look of the highlighting, which can also be set by the administrator. This then gave way to the thought ‘How will the person changing the style setting know they are happy with the style?’. Traditional Moodle settings save the value and everywhere for everyone that the setting affects are affected. But what if the style could be previewed? Would that not be a good thing….

A bit more advanced than I’d intended

So I set about writing a custom admin setting (docs.moodle.org/dev/Admin_settings) that would react to the changes in the ‘engine’ and ‘style’ settings on the page and display a preview using sample code that the administrator could type in. After a few wrong turns, I eventually came up with this:

Which uses AJAX (en.wikipedia.org/wiki/Ajax_(programming)) to request that the server create markup that can replace a placeholder on the page with the new example. This it does using a Mustache template (docs.moodle.org/dev/Templates) with an ‘iframe’ having the engine’s CSS and JS within it so that it is self contained on the page.

Thus it is possible to see the look and effect of the engine on code before the settings are saved.

Publishing on moodle.org

Once you have completed the code and created a tag for it (git-scm.com/book/en/v2/Git-Basics-Tagging), which you can see here: github.com/gjb2048/moodle-filter_synhi/releases where I’ve turned the tags into ‘releases’, and exported that version as a zip file (as can be provided github.com/gjb2048/moodle-filter_synhi/releases/tag/V3.7.0.2), then you can take that file and use it to publish the plugin on moodle.org (docs.moodle.org/dev/Plugin_contribution). When you’ve logged in with your account, go to ‘moodle.org/plugins’ and you should see ‘Register a new plugin’ in the menu:

Now you can begin the process using the steps provided:

where I’ve manually filled in the ‘Frankenstyle’ name (docs.moodle.org/dev/Frankenstyle), that we will have already created when we first started the code and created the Git repository. Then I’ve uploaded the ‘zip’ file, checked its licence (click on the uploaded file to see), then stated the supported Moodle versions.

Pressing ‘Continue’, we can complete more information about the plugin:

this screen is really helpful as some of the information comes from the zip file and therefore this confirms that the file was read and understood. Finishing with ‘Register a new plugin’ we get:

which confirms that the plugin has been registered, how many other plugins are in the queue. This also means that you’ll get a CONTRIB tracker issue (tracker.moodle.org/browse/CONTRIB-8229) emailed to so you can follow / comment on the review process. In the description of the issue will be a reminder of the URL your plugin has in the plugins database, in this case ‘moodle.org/plugins/filter_synhi’, but only you and Moodle HQ will be able to view its contents until it is approved. I strongly advise that you get a Tracker account and understand how to use it (docs.moodle.org/dev/Tracker_introduction).

We can additionally fill in other information, some of which is mandated and reported at the top of the screen if missing.

Conclusion

Please do try the filter on a test server. You can get your copy from: github.com/gjb2048/moodle-filter_synhi/releases. I hope to make another post with progress and information on the approval process when this happens, at the moment the queue is quite long, 46 plugins, and could currently take up to 86 days (moodle.org/plugins/queue.php).

• About
• Latest Posts

Gareth Barnard

Developer at HRDNZ

Gareth is a developer of numerous Moodle Themes including Essential (the most popular Moodle Theme ever), Foundation, and other plugins such as course formats, including Collapsed Topics.

Latest posts by Gareth Barnard (see all)

• Moodle 4 Security – A Review – 16th April 2024
• A little bit #fab – 16th March 2024
• Static framework – 16th February 2024