Ramblings on code, Sitecore and stuff
One of the reasons I chose to use Bash to orchestrate the build process for my minimal static site generator was due to it's ubiquity. Bash has been around for a long time and it's present on the build platforms I most frequently use, not to mention on my dev machines. So to wrap up this series, I wanted to have the build process run not only on Github, but also Bitbucket.
I added multiple page types back in Part 6: Multiple Page Types of this series. But with multiple different pages I'm using multiple different HTML templates, duplicating quite a bit of HTML between them. I want to make sure I keep all that HTML boilerplate consistent, which I'll do with "layouts". I also want to create some "components" which can be used on any page to display specific content across many pages. I'll explore these concepts in this post.
In the last post of this series I duplicated a lot of code in the script file. To keep the script clean as I extend it further (and add more page types) I need to spend some time refactoring to improve the structure of the script. I can also apply the DRY principal (Don't Repeat Yourself) by extracting duplicated logic to separate functions.
So far in this series I've only been processing a single kind of content item and that's blog posts. But sites rarely have a single content page type. It's time to add an additional page type and generate the static files for this new page type.
In previous posts of this series I showed how to generate pages for each blog post I had in Content Hub ONE. Now the pages are generated I need some way to navigate and display the list of blog posts to users. I need to generate a list page (index page) that shows all the blog posts and provides links to them.
In the previous posts in this series I've been processing multiple pages by using the allBlogPost query field which returns a list of blog post content items. But at some point I'm going to hit the page size limit and a single query won't do. I need to rework my querying to be able to page over all the results in Experience Edge.
So far in this series I've only used 2 types of fields: Short text and Rich text. But the blog post content type in my Content Hub ONE tenant has some additional field types which I want to use: Date and time and Select. In this post I'll extend the blog post output to make use of these additional fields.
In the previous post, I showed the minimum required to generate a single page, consuming content which I manage in Content Hub ONE and which is delivered via Experience Edge. Now I want to build on that exercise and generate many pages.
In this multi-part series, I'm going to explore how far I can progress, building a static site generator (SSG) for a headless CMS using a restrained toolset and minimal dependencies.
Eleventy (the cool static site generator) has a great feature called Pagination which allows you to iterate over a list of things in chunks and produce multiple output files. As I was migrating this very site over to Eleventy, I found I needed to perform a double pagination. This is when, during paginating over a list of blog post years, I found I wanted to also paginate again over the posts in those years, so I could have at most 20 posts on a single list page.
Update 10th August 2024 In June of 2024, MailChannels announced it would no longer be offering free access to Cloudflare Workers customers; https://support.mailchannels.com/hc/en-us/articles/26814255454093-End-of-Life-Notice-Cloudflare-Workers. The links in this article which link to Cloudflare documentation all appear to redirect to documentation which covers using Resend to send email from...
Back in 2018 I migrated my blog from WordPress to Hexo. Hexo is a static site generator running on Node.js. At the time I chose Hexo because it allowed me complete control over the structure of the resulting website, plus I could override and tweak the markup of the resulting pages. Hexo is a fairly fully-featured static site generator. It has a lot of functionality built into it to cover a lot of...
The GraphQL schema used by Content Hub ONE is the same as that used by Content Hub. But there are a few differences between the two systems and the resultant GraphQL schema used by the Experience Edge tenants for these systems. In this post I'm going to explore the key differences you'll find when working with an Experience Edge tenant for each of these systems.
Experience Edge hosts tenants for a number of different Sitecore systems including XM, XM Cloud, Content Hub and Content Hub ONE. However, the data models of the Content Hub based systems is different to that of the XM based systems, so each requires a different GraphQL schema to access the content which has been published to Experience Edge. In this post I'm going to explore the GraphQL schema which is generated for a Content Hub tenant.
Sitecore Experience Edge is a multi-tenant system hosting tenants for a number of different Sitecore source systems. The data models of each source system are quite different which requires a different schema in the GraphQL API for each kind of source system. In this post I'll be exploring the GraphQL schema used for XM tenants on Experience Edge. This schema is used by XM, XM cloud and managed cloud XM instances.
Experience Edge is a SaaS offering from Sitecore which allows users to publish content and retrieve it via a globally available GraphQL API. The service takes on the burden of scalability so you don't have to. It provides a buffer between your content delivery applications (statically generated sites (SSG), server side rendered sites (SSR), kiosk applications, mobile applications, etc) and your headless CMS (Content Hub or Sitecore XM/XP) which allows the CMS to go offline for upgrades or maintenance without losing the ability to serve dynamic content.
Kafka is a great piece of technology for integrating disparate applications in a decoupled manner. It does however have some nuances which are important to understand. I've been tripped up a few times while doing local development, so I thought I'd write it all down in the hope of saving someone else some frustration.
WeBlog 4.2 has been released. You'll find the Sitecore packages for various Sitecore versions on the release page at https://github.com/WeTeam/WeBlog/releases/tag/release%2F4.2.
This is the final post in my "Unit Testing Sitecore Components" series. In this series I've taken a seemingly simplistic Sitecore component and refactored it by applying several principals to make the code more reusable and testable. In this final post of the series I'll recap the principals and provide a few resources to help explain them further.
In the previous posts of this series, I've refactored an existing Sitecore component to make it's logic more reusable and prepare the component and the logic it includes for unit testing. In this post I'll be writing the unit tests for the refactored EntryTaxonomy class, showing how to mock items and field values.