Silent Sentinels
A learning project during my apprenticeship with Viget.
Sorry to say, but there is no live version of this project. If you wish to check this project out, feel free to email me and I’ll spin something up behind a password lock.
Iâve had a very light experience with CMSs in the past. For one of my classes we worked with creating WordPress themes. There wasn’t any intense logic. We just made blog posts editable, with an index page of posts, and all within a custom theme. The extent of each WordPress setup varied to each personâs interest, but this primarily was it. Albeit being a small project, what annoyed me about the templating structure within WordPress was the syntax involved:
Random post loop syntax from WordPress Codex
<?php while (have_posts()) : the_post(); ?>
<div class="post">
<h2 id="post-<?php the_ID(); ?>">
<a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>">
<?php the_title(); ?></a></h2>
<small>
<?php the_time('F jS, Y') ?>
<!-- by <?php the_author() ?> -->
</small>
</div>
<?php endwhile; ?>
Learning the above hard to read WordPress template code can prepare you for anything. But if youâre looking for the best developer experience, itâs definitely Craft. Just check this basic loop below.
Entry loop (Craft uses âentriesâ instead of usual âpostsâ syntax from Craft documentation
{% for entry in craft.entries.section('blog').find() %}
<article>
<h2><a href="{{ entry.url }}">{{ entry.title }}</a></h2>
{{ entry.body }}
<p>Written by {{ entry.author }} on {{ entry.postDate|date('M d, Y') }}</p>
</article>
{% endfor %}
The examples are not exact correlations, but I think itâs agreeable that the second TWIG syntax that Craft uses is easier to digest.
One of the highlights of working with Craft is using Twig. According to its website, Twig is âlike an alternate syntax for PHPâ. Personally, Twig definitely reads better than straight-up PHP like the above examples demonstrate.
The Setup
This Craft project was part of Vigetâs apprenticeship program in which I was their front-end development apprentice for 10 weeks. The project was done with the goal of learning Craft CMS and making sure I was coding with web standards in mind.
Before the code
To begin my mentor had me plot out the different types of pages to their corresponding Section types in Craftâs backend. And then figure out all corresponding fields on a page to a field type in Craft. Here are some pictures regarding that process:

After figuring out the different Craft section types, I proceeded to spend some time understanding Craft.
Making sense of Craft
Every CMS describes page and content types in different ways, Craft is not different, but personally, I found understanding Craftâs terminology easier than other systems. Especially since it abstracts the complicatedness of pure PHP with Twig.
In Craft, sections define containers for your content. Editable content is defined in Craft as entries.
Craftâs section types are:
- Singles: âone-offâ types of content (about page or a homepage)
- Channels: similar content like a blog
- Structures: more complex content
Using Craft toggles to dictate alternate versions of things
- show option in craft,
- then show correlation in code
K.I.S.S. and D.R.Y.
Being used to Jekyll templating and the storing of partials, it took me awhile to get used to doing these kind of things with Craft/Twig. Eventually, separating different blocks of content with their specific CMS logic made sense. Here’s short example of a matrix block in Craft that was separated to a partial:
{% switch block.backgroundPosition %}
{% case 'left' %}
{% set backgroundPosition = 'background__img--left' %}
{% case 'right' %}
{% set backgroundPosition = 'background__img--right' %}
{% case 'center' %}
{% set backgroundPosition = 'background__img--center' %}
{% endswitch %}
<section class="timeline__block quote-image">
<div class="timeline__block__inner wrapper section-padding">
<blockquote>
<span class="blockquote-leads">
{{ block.leadIn }}
Above you can see the logic that’s hooked up with the CMS. If the user clicks one of the below buttonsâŠ

⊠then
switch
Also a late addition to the project was the use of macros to clean image handling better. I was creating so many image sizes for different viewports that it got to a point where I needed to separate the logic to a macro in Craft, which is like a reusable function. Below is a macro for creating a source in a <picture>
element.
{% macro pictureSource(image, sizeObj, minOrMax, media) %}
<source srcset="{{ image.first().getUrl(sizeObj) }}"
media="({{ minOrMax }}-width: {{ media }}px)"
>
{% endmacro %}
Accessibility
Accessibility was something new that I never intentionally thought of when going through a project. The only accessibility practice that I knew before doing this project pertained to writing text in `alt` attributes. This project I focused on the interactions a user would have with navigating the site and made it keyboard accessible with JS and some HTML `tab-index` attributes.
The navigation became an issue for me for tablet to mobile sizes as it was triggered through a hamburger menu. The specific issue pertained to keeping the tab focus on the items of the nav menu despite the whole site being present on the DOM. **ex: **User tabs and opens the fullscreen navigation but as they keep tabbing, the focused element is not visible as it’s on an element not visible and behind the navigation.
The solve was to trap focus within the navigation, but provide easy exits with the keyboard.

Learning something new
As this was a learning project, I took a leap and learned two rad new things that Iâll be incorporating into projects in the future. The use of Intersection Observer API + Smoothscroll.
Intersection Observer API
Or as I like to call it, the IO-API. Iâm trying very terribly hard to coin it that way. So far only I am the only sayer.
ÂŻ_(ă)_/ÂŻ
The IO-API serves as a new way for the browser to detect when DOM elements are currently within the viewport and even to a certain threshold/percentage it is in. Itâs pretty nifty using the IO-API. And itâs being used online for a variety of things, namely lazy-loading assets when theyâre actually needed plus scroll-library interactions. Itâs not perfect, not great for all use cases, and at the moment requires a polyfill, but it fulfills a performance & simplicity need of viewport detection that wasnât as natively* there before.
Here’s a small presentation that I gave on the IO-API for some of the Front-End Developers at Viget.
I used the IO-API in this project to add highlight classes on the landing page’s nav items as one of the corresponding sections appeared on the screen.

I also used a smoothscroll polyfill to get smooth scrolls when clicking on one of those nav items. Here’s a link to the implementation that I used: SmoothScroll.
Small Reflection
I noticed a few things doing this particular project. Most notably was the ease of Craft. Craft gives you the ability to write things from an approachable Twig focus. So you don’t need to know much, if any, PHP. Because of this, Craft is more approachable to front-end developers that might be scared about messing with WordPress. Other than a few Google queries whenever issues come up (as they do on any new project), building a site with Craft is easier than ever, and holds true with the latest Craft 3 release.
One thing that can become an issue to using Craft is licensing. Unlike WordPress, Craft requires you purchase a Client or Pro license for $199 or $299 respectively. Unless you’re a developer and coding a site for someone other than yourself, there’s no way around this. This might make it difficult for small time clients to justify paying for and actually leads into another issue: justifying to your client why Craft is a better option than WordPress for a CMS. But I rather not reinvent the wheel and things that have already been said. If you’re interested in learning about some differences and reasons to check out Craft, check out this article from Viget.
All in all, this project was fun and tricky to build as there were a TON of background images and different problems to solve with Craft. Hopefully, the future of CMS development looks more like Craft and with new and upcoming things like WordPress Gutenberg, it might.