Jekyll: Rendering on a Mobile Part 2


Console app that parses previous blog post files translating MarkDown image constructs to use the image.html include file.

Background

In the previous post on this topic Rendering on a Mobile Part 1, an include file for use with a Jekyll-MarkDown file for rendering images on a phone with a consistent width was presented. This is so that wide images do not force text to be in a narrow column on a phone, when viewed in portrait mode.

Example of the image construct transformation

  • The included page for rendering an image is image.html in /include
  • Example use on a post page:
![activity](/images/activity.png)

… becomes:

{% include image.html imagefile=”/images/activity.png” tag=”QWERTY” alt=”activity” %}

This will render on the as two div tags, only one of which will be viewable depending upon the page width. The first will display the image at its full width on a desktop. The second which is visible on a phone in portrait mode renders it with a set with of 320px.

At issue is that there are many previous posts using MarkDown syntax for images and so there is a need to scan them and translate them to use the include file syntax.

image.html

See Rendering on a Mobile Part 1

The Console App

A C# Console app was written and is available at djaus2/MDImage2Call:

  • Find files in _posts directory using the file mask
var files = Directory.GetFiles("_posts",mask);
foreach (var file in files) {
}

For each file:

  • Read contents as an array of lines.
  string[] lines = File.ReadAllLines(pathToFile);
  count = 0;
  • Iterate through all lines
    • For each line look for the two characters ![ the start of a MD image specification. If found:
      • Find the closing square bracket
        • The string between the square brackets is the image alt text.
      • Check that the next character is an opening bracket
      • Then find next closing bracket.
        • The string between the brackets is the image’s file path.
      • Image found so increment count
      • Replace the MD image construct with the call as above using the filepath and alt text as determined.
        • The tag parameter used is QWERTY with the image number (count) appended.
        • That way each div as written is unique on the page.
        • QWERTY is an arbitrary string but is constant for the app.
      • Actually, a copy of the original line is kept in the file as a MarkDown comment.

Comment

Nb: Links here are to Microsoft Learn.

Explicit string searching and extraction was used making use of string.IndexOf() and string.Substring():

  • IndexOf(): Find next occurrence ![, [, ], ( and )
  • Substring(): extract the image filepath and alt text.
  • String Interpolation is used to create the call to the included file as above using the generated meta-information for the image:

string imageCall = $”{{% include image.html imagefile = \"{filePath}\" tag = \"QWERTY{imgNo}\" alt = \"{alt}\" %}}”;

The Regex class could have been used to do the string processing. I find it quick and dirty to create the string processing as above.

NutsNBolts

  • Before running the app, _posts folder was duplicated to _postsBak
    • Yes, the repository could be used for that purpose
  • _postsTemp was added to .gitignore as were _postsBak and _postsXXX
  • After running the Console app, _posts was renamed _postsXXX and _postsTemp was renamed _posts
    • The site was then run locally to test the modified posts
    • The site was then committed and the published modified files were checked.
    • There was then a need to revert the repository back to the previous commit. 
git clone <repo_url>  #clone your azure (New copy) git repo to local
git checkout <branch>

git reset --hard <commithash> #revert back to a the previous commit
git push --force  #push to remote server
  • Nb:
    • My <branch> was Main
    • The <commithash> is from the previous commit, which can be obtained from, for example, AzureDevOps/Repository/History.
  • The Console app was rerun if all is good against the new copy of the repository.
  • The files in _postsTemp were copied to _posts in overwrite mode.
  • The site was built locally and the modified posts were examined.
  • If all good, the site was again committed to Azure Devops which triggered it being built and published on Azure Storage.

Note that the commit with just the modified posts still exists in the repository but does not interfere with the traceability of posts.

Comment

The method of switching _posts with a folder containing just the current post being created can speed up testing the post when run locally due to quicker builds.

Conclusion

A Console app using explicit string processing can be used as a vehicle when bulk changes are required for previous blog posts.

 TopicSubtopic
  Next: > RPI-Pico-Arduino-AzSDK
   
 This Category Links 
Category:Web Sites Index:Web Sites
  Next: > GPS
<  Prev:   Jekyll