Our blog

Page 1 of 2

  • Our plugins are Craft CMS 4 ready

    Prateek Rungta

    We make no secret of our love for Craft CMS here at Miranj. While we rarely prize a tool or tech over the problem it helps us solve, we greatly value the efficiency of a good tool, and Craft CMS continues to shine on that front. One such aspect is the ease with which one can tap into and extend the core functionality of the CMS. There’s a thriving community of plugins that enhance, boost, and add to the already elaborate set of core features offered by Craft. While we depend on a fair few of them for most of our projects, we have also released some plugins of our own:

    And as of this week, all five of our plugins have been updated to work with the latest release of Craft 4. Some of these plugins (Router, Obfuscator and Cryptographer) date back all the way to 2015 and Craft 2, and we are glad to continue supporting them and making them available for the community to use on their projects as well.

  • Critical CSS for CMS-based, Server-rendered Websites

    Prateek Rungta
    CSS loading and Critical CSS
    Location & Date

    Our sites have undeniably grown in complexity over the years. Each year we send more data, show bigger images and process lots more JavaScript per page than the year before, growing steadily for at least the last decade and outpacing the gains we’re making in computing and network capacity. The bloating of the web hasn’t gone unnoticed though — sites take their own sweet time to load, eat through data allowances, drain out the battery and bring the computer down to a crawl. Thankfully, the web community realises and acknowledges the problem. Performance is no longer an afterthought. Yet it is no easy band-aid either. Performance is impacted by a multitude of factors, so achieving success in this domain requires a multitude of solutions.

    The folks at Hasgeek recently put together an event focused on Critical CSS (under the JSFoo(!) banner) and we got on stage to share how we approach and implement this technique on sites we build at Miranj.

    Critical CSS for CMS-based, Server-rendered Websites on Vimeo.

    We look at an end-to-end solution that we have evolved and battle tested over the years. Starting with a primer on Critical CSS and its place in the larger performance pie, I go over a 4‑part strategy to introduce Critical CSS generation and delivery to a CMS-based website. We look at some performance metrics impacted by Critical CSS, cover identifying target templates and page selection, leveraging the Critical library to extract critical CSS, automating the extraction process using Gulp, reducing response size for repeat visitors, and getting this entire system to work with the caching layer(s) that you may already be using.

  • Fortifying Craft CMS for High Traffic

    Prateek Rungta
    Dot All 2019
    Location & Date
    ·Montréal, Canada

    In the vast, multi-layered subject area of web performance, server response time is an important metric. From a CMS standpoint however, it is one of the most significant. Best practise recommends a 200ms or lower time-to-first-byte (TTFB). That is the time in which a CMS has to figure out what to do with the request, parse templates, query the database, render the HTML, capture it all and send it back as the response.

    Craft CMS — our preferred CMS for content-heavy websites here at Miranj — is quite fast out of the box, but as our pages and content models grow in complexity so does the server response time. Add traffic to that mix and it can quickly lead to poor TTFBs and slow overall experience.

    In this talk we go through a multi-tiered caching strategy using Craft and Nginx that enables a single VPS to consistently deliver sub-200ms response times, even while handling loads of 10 to 100 concurrent requests per second. It covers our learnings from optimising a low-powered server to handle millions of visitors each month on the Guiding Tech website project. We achieve this by caching the website at two places — at the web server level using Nginx’s FastCGI micro-caching, and at the CMS level using flag-based template caches in Craft CMS. We also factor in real-world edge cases such as bypassing the cache, delivering variations to different visitors, etc, that are necessary to account for in a robust, production-ready system.

    Fortifying Craft for High Traffic with Prateek Rungta from Craft CMS on Vimeo.

    We also put out a sample Nginx config for the micro-caching strategy discussed in the slides.

    This talk was prepared for and delivered at Dot All 2019 in Montréal, Canada. This was my first time speaking at a conference outside India, but any nervousness I carried on stage was quickly dispelled by the warm engagement and wonderful conversations with the Craft community.

    Prateek speaking at Dot All 2019 Souvik and Prateek share a laugh with Ben Parizek of Barrel Strength Design

    Photographs courtesy Pixel & Tonic

    I’m extremely grateful to the folks at Pixel & Tonic for extending me an opportunity to present to an international audience, and for placing their trust in us a second time after Souvik’s talk the previous year at Dot All 2018, Berlin.

    I email hidden; JavaScript is required about your mileage from adopting any of the caching strategies mentioned in the talk, or any alternate approaches you have implemented to optimise Craft CMS for heavy loads and high traffic.

  • We are a Craft Partner

    Souvik Das Gupta

    Back around 2013 with every passing project, we were trying to push ourselves to break down websites into small, atomic information pieces, almost in the object-oriented way. The more we pushed ourselves the more we got disappointed by the website tools (and paradigms) that surrounded us. On the one hand, we felt constrained by WordPress’ pervasive Pages and Posts paradigm. It was (and still remains) so ubiquitous that everyone seems comfortable in imagining websites as a collection of hierarchical pages and an accompanying blog. On the other hand, some tools (like Jekyll) supported atomic content pieces by combining data formats like YAML and Markdown, but fell short in extending a reasonable authoring experience. We had reached a point of dreaming up our own custom CMS architecture but stopped short of implementing it since that would be a significant deviation from our core work i.e. designing and developing content-driven websites.

    An year later, while working on the Quicksand website, we were desperately looking for a reliable Content Management System (CMS) that could complement our approach while delivering a good authoring experience. That’s when we stumbled upon Craft — an un-opinionated, content-first CMS. It touted several good features but there were a few noteworthy ones which caught our immediate attention:

    Flexible Content Modelling

    This one hit the nail right on the head. Craft allowed us to deconstruct content into small pieces and build websites bottom-up. We even learned that our object-oriented approach was called Content Modelling. It freed us from existing content paradigms and allowed us to architect the website content uniquely as per project needs.

    Relational Fields

    Every independent piece of content modelled inside Craft can link to any piece of content across the website. Relationships are extremely powerful because not only do they help create cross-references and allow people to navigate to related information, but they greatly cut down redundant data capture. Shared pieces of information can now be independently created once and simply linked/​reused in several related places.

    Matrix Field

    This was around the time when design systems were maturing and the Matrix field complemented a modular component-based page design. It enabled the creation of re-usable blocks/​patterns which could be included multiple times on a page. Further, the blocks could be moved up or down to re-order content within a page.

    Live Preview

    It’s very reassuring to be able to review how the content will show up on the website before it’s published. And it’s even more powerful if you can see a live preview as-you-type. That’s exactly what Craft shipped and it reminded us of the experimental interfaces demonstrated by Bret Victor in his talk Inventing on Principle.

    Clean Separation of Concerns in Code

    Developers crave to focus on one thing at a time – data, business logic or templating. An architecture that cleanly separates these three layers makes the code more resilient, error-free and secure. Not to mention it’s also far more enjoyable to work with.


    The Craft team has never beaten around the bush about their security measures. They’d been following all the good practices in the book, published zero-day fixes and diligently updated vulnerability databases. We were re-assured that Craft’s security was taken very seriously by its makers.

    One-Time License and Developer Support

    Craft was not a free CMS (unlike many popular alternatives) but their pricing was very compelling — reasonable for the value it delivered, affordable for a small business and importantly a one-time fee for perpetual use. We saw this as good thing because it assured us that the product had a sound business model and that they’d likely be around for a long time to come. Also, who doesn’t like developer support from the makers of the product.

    Zero-byte (empty) output for fresh CMS installation

    If this one sounds trivial, trust us, it’s a profound change. When a CMS does not impose a starter theme but instead comes with zero front-end code, it puts the control right back in the hands of the designer and the developer. The CMS landscape had many firmly established players (WordPress, Drupal and the likes) but Craft was a breath of fresh air in this regard.

    Not only did Craft check most of our requirements but it also raised our curiosity and excitement. However, like with any new software, we approached our first few Craft projects with extreme caution. It took us about a year to grow confident in Craft’s versatility, and then we were hooked! Quicksand was our first Craft project and it continues to be running stably today.

    Fast forward to late 2018. The Craft team rolled out the Craft Partner Network to bring together agencies from around the globe with proven expertise in Craft. With over 4 years of Craft CMS experience (at that time), our team satisfied the review criteria and we became an official Craft CMS Partner — the first agency from India, and among the earliest set of members from the Asia Pacific region.

    Miranj is a Craft Partner

    Over the years Craft has enabled Miranj to take on several information-dense projects with formidable IA challenges. Craft’s feature set has been steadily expanding and today we’re using it to power some fairly complex use-cases. We leveraged its multi-lingual and multi-site capabilities in MIIT and Forech. In fact, in the latter project we hooked up Google Translate to pull in automated translations for French, German and Spanish (thanks to Craft’s extensible architecture). Our client IndiaBioscience is making great use of the multi-user capability with user groups and fine-grained permissions system to collectively manage their large website. We used Craft’s powerful Twig templates to enable Guiding Tech to syndicate content with external services. Craft also has a growing Plugin Store where one can find many useful extensions for the CMS, including a few that we‘ve built and published. And perhaps the most important of all (and dare I say — our favourite feature of Craft CMS) is the thriving community that is growing steadily in India and around the world. The close-knit community is connected over Discord, Stack Exchange, an annual conference (Dot All) and the Craft Partner Network.

    With over six years of Craft experience, we are proud to be at the forefront of its adoption in India and the neighbouring geographies. During this journey we’ve participated in every Dot All Conference and have been invited to present our techniques at the 2018 and 2019 editions. Needless to say, Craft CMS has been a great ally in facilitating our purpose and we couldn’t be happier with our decision to adopt this technology.

    If you’d like to learn more about Craft CMS and how it compares with some of the other CMSes out there, join me on June 6th (Saturday) at Content Web — a series of online discussions on content publishing, web design, web development and the business around it.

  • Modular Architecture for Building Content Websites

    Souvik Das Gupta
    Dot All 2018
    Location & Date
    ·Berlin, Germany

    Back in 2014 we were looking for a Content Management System (CMS) that could fit our concept of a website constructed from a collection of atomic pieces of content. Our search led us to Craft CMS – it was still a fairly new CMS back then but it looked promising. We initially adopted Craft for a project where the website was moved from WordPress. In the next project the move was from Drupal. Both implementations were a learning experience but the outcomes reinforced that we made a good choice. The latter has now grown to be our largest Craft implementation.

    Craft CMS makes no assumption about the content. It frees our thinking from the shackles of the WordPress content model (Posts and Pages) while at the same time does not weigh us down under Drupal-like technical baggage. Being able to model content from scratch (almost treating the content model as data) and not being held back by any starter theme helps unlock creative freedom. As a result, we can hand-craft a website’s information architecture, user interface and user experience without the CMS acting a hurdle (or barrier).

    Our relationship with Craft strengthened over time and 3 years since our discovery, in 2017, I found myself attending two conferences in the US: Peers (Craft CMS was a sponsor) and Dot All – the first official Craft CMS conference. Little did I know that the very next year I’d be taking the stage at the Craft CMS conference.

    Any system that offers high flexibility, in turn, demands a disciplined approach – and that applies to Craft as well. With each passing project executed in Craft, we inched towards a disciplined approach for content modelling and developed a modular templating architecture that can be used in a large number of use cases, especially sites that contain a lot of information. I presented this architecture at Dot All 2018, in Berlin.

    The talk walks through how our imagination of a website has evolved over the years and goes on to outline our current approach and utilises these fundamental principles—

    • modelling content and giving them a structure (objects)
    • separating content (objects) from presentation (views)
    • defining presentations (views) based on a clear purpose
    • ensuring presentations (views) are evolvable in order to serve a different (or greater) purpose

    I further go on to explain the implementation that uses a Routers-Views-Components-Layouts paradigm. It’s amazing how we’ve been able to simplify large and complex websites using this approach – making our work more flexible, scalable and maintainable.

    Here’s a video of the full talk —

    Architecting a Content Website with Souvik Das Gupta from Craft CMS on Vimeo.

    It’s always great to meet the Pixel and Tonic team, and the Craft CMS community who we mostly know through Slack Discord. I got great feedback on the talk, and based on Andrews recommendation went on to convert Craft’s Happy Lager demo site into our templating approach. It’s called Happier Lager and should be a good resource to observe the contrast.

    Photographs courtesy Dot All.

    It was my first time in Berlin (and Germany) and after the conference, I took some time out to visit a few other cities, which included Munich and the popular Oktoberfest 🍺.

    If you use Craft and have any feedback or questions, email hidden; JavaScript is required. I’d also be keen to hear from you if you’re tackling similar challenges and the techniques you’ve adopted.

  • Page Loading Performance Strategies

    Prateek Rungta
    ReactFoo Delhi
    Location & Date
    ·New Delhi, India

    Performance on the web isn’t a simple switch that can be flipped on, but a vast, multi-layered subject. Page loading speed is one of the layers that has received a fair bit of attention recently thanks to tools like PageSpeed Insights and WebPageTest. While these profilers serve as great checklists to measure our sites against, their recommendations can often be difficult to incorporate or grasp fully.

    In this talk, presented originally at the Delhi 2018 edition of ReactFoo, I examine and demystify modern front-end page loading best practises. For each performance strategy, we break down the why and how. We go through the principles on which these loading strategies are based, and look at ways to implement the strategies with real-life examples.

    The ideas and experiences presented in this talk are based on my experience building and maintaining CMS-based websites for clients both large and small. However, these learnings and performance gains should be applicable to all websites, independent of the technology stack.

  • Vanity URLs in Craft CMS

    Prateek Rungta

    One of our recent projects, built on Craft CMS, required support for top-level user profile URLs like twitter.com/miranj and instagram.com/_basestation (also commonly known as vanity URLs). While Craft offers a fair amount of flexibility for routing requests, implementing vanity URLs wasn’t particularly straightforward. This post is a run-through of how we worked our way around it.

    To begin with, the routing precedence in Craft is as follows:

    1. All URIs beginning with the resourceTrigger config setting are treated as a Resource request
    2. All URIs beginning with the actionTrigger config setting (or POST parameter) are treated as an Action request
    3. Any direct URI matches with Entry or Category (or any other Element) object URIs are treated as an Entry/​Category/​Element request, wherein the corresponding Entry template is loaded with a pre-populated entry object.
    4. The first successful URI match against user declared regular expressions. Craft calls these dynamic routes, and the routes can be declared either via the Control Panel or in craft/config/routes.php.
    5. All URIs that match a file in the template folder(s) when interpreted as a template path.

    Given this precedence, the ideal scenario for supporting a user profile page for each User object was to assign our desired URI to the User object. The routing would’ve automatically been handled at the third level (as an Entry/​Category/​Element request). However, the URI field appears to be unsupported for User objects and we couldn’t figured out a way to change or override that behaviour.

    We were left then with the fourth level (dynamic routes). So we added a rule to match all top-level URIs and direct those requests to the user profile template page.

    '<username:{slug}>' => [ 'template' => 'user/_profile' ],

    Since this pattern is quite liberal and will match all top level URIs, we placed this as the last rule in our config/routes.php file. The templates/user/_profile.twig template looked something like this:

    With these two components in place, we started seeing the desired results. Requesting any valid user profile page like /batman loaded the templates/user/_profile.twig template for Bruce Wayne. So far, so good.

    The problem we ran into here was that we had broken template path based routes (level 5) for top level URIs. For instance:

    • The templates/about/index.twig template should’ve been reachable via /about
    • The templates/contact.twig template should’ve been accessible via /contact

    However both those URI requests resulted in a 404 response due to line number 6 of templates/user/_profile.twig. (Provided there were no users with about or contact as their username. (Always a good idea to maintain a username blacklist when dealing with vanity URLs.)) Now one option was to simply declare dynamic routes for 'about' => [ 'template' => 'about/index' ] and 'contact' => [ 'template' => 'contact' ] and place them before the user profile routing rule. This would’ve worked if we had only a handful of templates with top-level URIs, but it would not have scaled very well for a large number of template path routes.

    So how did we get around this? By altering the logic to look for a template path match before looking for a username match. We introduced an intermediate template file templates/_vanity_router.twig to achieve this.

    And we modified the dynamic route to hand off control to the intermediate template file:

    Template paths now take higher precedence than vanity URLs, and that is exactly the behaviour we were going for.

    Hope you find this useful for adding vanity URLs to your Craft project. If you’ve taken a different approach or have any feedback on this approach, we’d love to know.

    All code samples in this article have been updated for Craft 3 as of March 2019. Craft 2 versions can still be found on GitHub.