Dublin Library

The Publishing project

Writing Markdown extensions (2): Thoughts and ideas (so far)

Before jumping into writing our own Markdown elements and all the complexity that goes with them, let's stop and see where we are. Markdown rule customization gives you a lot of flexibility regarding customizing built-in rules and elements. It's an all or nothing proposition, either all elements have the attributes you're customizing or you code around to make sure only some do like the link example where we only add attributes to external links. Most of the time, these customizations will be enough, but not always. There may be times when we want an element that is not available on...

Continue reading →

Writing Markdown extensions (1): Customizing renderer behavior

Markdown gives you two options to work with specialized content: You can write it as HTML directly or you can use plugins for your Markdown tools that will produce the same result from some specific combination of text symbols. Until now I've always used HTML for things like figures and video embeds from YouTube or Codepen. It's easier, I've created snippets in VSCode to handle them and my muscle memory already knows the shortcuts and how to write the code by hand. For security reasons this may not always be a good idea, especially if you accept third-party contributions. There's...

Continue reading →

Working with dates in Javascript: The Temporal proposal

The Temporal code is not ready for production, it is still possible but not likely that it'll change in incompatible ways before the final version is added to the ECMAScript specification, and because of that, it shouldn't be used in production until it reaches stage 4 in the TC39 process. However, you can test how it works now and decide if you want to use it in future projects. One of the most infuriating things to do in Javascript is date manipulation. The default Javascript Datehttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/GlobalObjects/Date object is hard to work with. This has lead to a proliferation of third-party...

Continue reading →

Markdown to HTML standalone converter tool

Ever since I started to work with Markdown as my authoring language, I've used Gulp as a conversion tool, when needed. The problem is that gulp-remarkablehttps://github.com/johno/gulp-remarkable/ is poorly documented and has poor support for plugins because of it... I have yet to figure out how to implement the plugins. Using Markdown-ithttps://github.com/markdown-it/markdown-it as my Markdown parser and gulp-markdownithttps://github.com/trwolfe13/gulp-markdownit seems to be more forgiving and easier to use, still no Markdown-it plugins but the standalone tool works fine as we'll describe later. It is not perfect... the leadership of the project leaves a lot to be desired the reason why I'm not...

Continue reading →

Font licensing: What do you get and is it worth it?

Foundries have this insane idea that people creating ebooks can afford the fees that they charge for use in a single format, much less for multiple delivery methods. I have an opinion about font licensing but I'm trying to stay neutral as I analyze different aspects of font usage online The web fonts we need Any use of web fonts requires at least 4 weights for the font used to prevent synthetic bold and italic font faces: - Regular - Italics - Bold - Bold-Italics I normally add 1 additional font and weight, a monospace font at regular weight for...

Continue reading →

Tagging and preparing a Github release

I don't normally do releases of my code. Whatever is on Github is what works and what I use to work with the code. There are times when a release of code at specific development milestones is necessary for example when you'd like people to beta test or when it's ready for a 1.0 release. This is a description of my basic process to commit code and create a tag. I can then go in to Github and create a release based on the tags. Committing code The first step is to commit the code. I use the command line...

Continue reading →

Installing plugins and themes using github-updater

As far as I know, unless you put your themes and plugins in the directories, you can't update themes and plugins through the admin interface, you'll have to delete them and upload them again. git-updaterhttps://github.com/caraya/rivendellweb-wptheme provides a mechanism to update plugins and themes from a Git repository Github, GitLab or BitBucket without having to publish them. Download the plugin and upload it to your WordPress installation or install it directly from your WordPress admin plugin interface. Before we can install our code using the plugin we need to add a header in the style.css header or in the plugin's header...

Continue reading →

Linting WordPress PHP code

One thing I've always tried to do is lint my PHP code as I go when working with WordPress so it won't bite me later if I try to submit the theme or plugin to the WordPress repositories. The best, and as far as I know only, way to efficiently lint PHP code is with PHP Code Snifferhttps://github.com/squizlabs/PHPCodeSniffer and the WordPress ruleshttps://github.com/squizlabs/PHPCodeSniffer to accompany it. The process includes installing PHP Code sniffer, optionally creating a configuration file, and running the code, either from the command line or from an existing build file. Installation Methods There are many ways to install...

Continue reading →

Configuring Vuepress default theme

In the last posthttps://publishing-project.rivendellweb.net/docs-as-code-the-technical-side/ we discussed the basic setup of a barebones Vuepress site. This post will cover some basic details of the theme: the navigation menu and the sidebar. To create the configuration you need to create the directory where Vuepress stores its data. From the root of the site create a .vuepress directory. bash mkdir -p /docs/.vuepress/ Inside the .vuepress directory, create a config.js file. The rest of the work will be done in this file. The first part of the module export declaration defines some basic metadata for the site. The head array will contain a list...

Continue reading →

Docs as code: The technical side

Docs as code is an interesting way to create documentation for software and technical projects. The idea is that we use the same tools to create our documentation that engineers or technical authors use to create their projects. According to Write the Docshttps://www.writethedocs.org/guide/docs-as-code/: Documentation as Code Docs as Code refers to a philosophy that you should be writing documentation with the same tools as code: - Issue Trackers - Version Control Git - Plain Text Markup Markdown, reStructuredText, Asciidoc - Code Reviews - Automated Tests This means the technical writing process follows the same workflows as the rest of the...

Continue reading →