Build great WordPress websites with Flynt, the component based starter theme for developers

After working with WordPress since my teenage years and trying all sorts of ways of building websites with it I came across the Flynt WordPress starter theme about two years ago. It allowed me to build a lot of websites since then. I’ve come to love it’s component based approach so much that I’ve decided that more people know about this great tool. So I decided to make a “Getting started with Flynt” video about it:

Flynt – A Component Based WordPress Starter Theme for Developers To Create Tailored Websites 🚀

It’s actually the first screencast video that I’ve recorded in English – which turned out harder than I thought 😅 I would really like to receive feedback by you (I mean you!) in the comments of this post or on YouTube, whether it’s related to Flynt or also the video itself.


Full transcript of the video

Intro

Hey everyone!

In this videos I want to talk to you about a fantastic way to build WordPress websites. It begins with a starter theme I’ve discovered about two years ago, called Flynt.

Flynt is not your average theme or site builder: it’s a starter theme for developers that want to efficiently build custom sites. So, if you are looking for a path to get better at developing with WordPress, want to write maintainable code and provide a good flexible admin experience for your editors – THIS IS THE WAY!

In the next few minutes I will tell you about

  • what makes Flynt great
  • then show you how your content editors workflow is going to look like
  • and last but not least show you insights into how the theme’s code looks in practice.

Let’s get started!

About Flynt

The main paradigm when building with Flynt is breaking down your site into smaller parts – the “components”. So if you’re looking at your site try to identify the components that make it up – for example here on the Flynt website:

  • The Logo
  • The main Navigation
  • and a content section containing an Image besides a text

Treating all these elements as their own little things breaks down your code for logic, styling and interactivity into small packages that can be quickly understood and reused – on one site or also easily copied to the next site you’re building.

Flynt is a starter theme, and a theme for developers – what does that mean? It’s a starting point for a practical best-practices theme setup and tooling to make your life easier.

Opposite to some well known end-user themes like Divi or Avada or Enfold that focus on letting you to build your site without coding it doesn’t provide a ton of ready-to-use elements but instead only a good basic set of components that you may fully customise, remove if you don’t need them, and for sure add new one’s yourself. So the idea is to ship something tailored to your needs instead of unused bloat.

And one of the best things? It doesn’t invent a lot of new things but rather combines some very well known, widely used developer tools for WordPress in a hassle-free way.

So, the main ingredients of Flynt are:

And by the way: Flynt was built by Bleech, an agency from Berlin, Germany that needed an efficient solution to create great WordPress websites and shared it with the world. Thanks a thousand times guys!

Admin / Content editing experience

Let’s quickly look into WP Admin in order to then better understand how the concept of components works.

When I am editing a page with Flynt you’ll see that the native WordPress editor / Gutenberg is removed and replaced by a component based editor. This editor is actually nothing else but ACF’s Flexible Content Field. It allows me to quickly add new components, move their order with drag & drop and of course – editing the content of my pages and posts. As you can see the actual fields and interface that is displayed for each component has been custom tailored for what it needs and nothing more.

This is a big plus of the concept in my experience with content editors: the interface may not be too fancy, but it can quickly be understood and used by clients without a steep learning curve.

Overview of the theme & components

Now enough of the theoretical talk: let’s dive into code.

I’ve opened up the Flynt theme directory in my VS Code. You’ll find the familiar WordPress theme core ingredients: we have index.php, page.php, style.css – I assume you’ve already met them elsewhere. Let’s not yet get into much more detail about the theme in general, but focus on one interesting directory: “Components”.

When developing your site, you’ll probably be spending most of the time working on components. So let’s now see how these are built. Let’s look at the Image Slider Component, that we’ve just used, as an example.

The typical files a component can have in the Flynt starter theme.

It shows the core files that a component can have:

  • a functions.php file that contains the definition of the ACF fields that are shown in the admin area. It’s also the place where you can fetch and modify your data before it gets passed on to the next step:
  • in index.twig – you are going to write the HTML that is later rendered when your component is shown to the visitor of your site. It’s written in HTML, flavoured with the Twig templating language which makes juggling with data quite easy.
  • Further we have a _style.scss file – This is where all the CSS styling of this individual component is defined. It’s written in Sass, which is just CSS with a few additional tricks like nesting to make it’s development more joyful. It will later be compiled into standard CSS.
  • And last but not least: script.js – in here we can let our component do things interactively, for example letting our bunch of images turn into a slider. Each component that contains Javascript is turned into a standard web component and provides a familiar way to work with.

So let’s again go through these files and see what they contain in more detail:

  • functions.php: this file first defines a custom PHP Namespace for each component, in order to prevent conflicts with equally named functions. Next to it we see the getACFLayout() function where all of our data fields are defined that will show up on the content editor’s screen. Let’s quickly open up WP-admin side by side and have a look at a few fields:
    • Title (wysiwyg)
    • Images
    • …and more
      These definitions are standard ACF field definitions as they can also be created through ACF’s WP-Admin page. Thankfully we don’t have to remember all of these by heart but can use Flynt’s VS Code Snippets Plugin to insert example definitions.
  • Let’s go into the next file index.twig. In here we prepare our HTML. All of our data fields that are defined in functions.php getACFLayout() function are automatically available here. Remember how we defined the “images” field that holds our slider images? We’ll that’s what is accessed here on line 11. We’re using the “loop” function of Twig to loop over all the images in that field. Technically the images field returns an array, so we’re looping over all array items. We then output an image tag for each of our images. Further below we’re adding some next & previous buttons to control our slider.
  • Of course so far our slider component wouldn’t really do anything but output a list of images, since we didn’t add any Javascript or CSS. Let’s quickly look at a important detail here in our twig template. If we look closely we can see that our outermost div contains an is="flynt-slider-images" attribute. This is used inside script.js to define a standard web component. What that means is that we have now created a new and reusable block on our website. Once that component is loaded on a page the constructor() is called which initialises our javascript slider. I will not go into much more detail here since this is custom for every component, but to give you a quick overview is that for this example we are loading the swiper slider, find some DOM elements and initialise the swiper-slider is on them.
  • So far so good: we’ve added some fields to add data, output that data to HTML with a little help of Twig and then turned that into a neat image slider. Now let’s make it pretty ✨ When we look at the _style.scss file we see that the CSS-selector is targeting the same ‘is=”flynt-slider-images”‘ element. All of our styling is then typically written inside it, which means it’s scoped by that component and will not accidentally style any other parts of your site. Since we’re writing all custom code this also generally means that you can write really low-specificity CSS which makes your life – again – less painful and a lot more joyful.

That’s about it for a basic component. There can also be components that are only used in your layout, not in WP admin such as your Navigation or Footer. And of course there’s lot a other things to be said and seen, but I’ll finish here for the moment.

Further resources

If this has made you curious, then let me share three helpful links for finding out more about Flynt:

  1. the Flynt website has some good introductions about it’s core concepts and setup, you should definitely read these to get started easier.
  2. The Flynt Github repo Readme also explains some ideas more practically and of course let’s you download the theme ;-)
  3. If you’re stuck with a problem or have some ideas then please share them in Flynt’s discussion board on Github.

Outro

Please let me know in the comments if you found this video interesting or helpful. And oh: hit the Thumbs Up button if you liked it 🙌🏻

Bye Bye!

Automatic Text Excerpt / Truncated Texts with Twig

Today I had to create a grid of cards for a search page. To ensure a consistent layout I wanted the excerpt texts to be cut off, if necessary, at certain length.

This can be done easily when using the truncate filter in the Twig template engine for PHP:

toLongText|truncate(14)

The number 14 stands for the number of words after which the text will be cut off and an ellipsis is added.

Goodbye OnePlus 5T – Hello Google Pixel 6A

Today marks the end of a small digital era for me – I am saying goodbye to my beloved OnePlus 5T. It’s the best smartphone that I’ve ever owned and served me very well for close to five years.

The OnePlus 5T smartphone laying on a table
Farewell to the best smartphone I’ve ever owned: OnePlus 5T

Why I Iove the OnePlus 5T

OnePlus is not a very well known brand here in Switzerland. But they managed to catch my attention back in 2018 by creating inexpensive smartphones that delivered rather strong performance. And for me, with the 5T they’ve ticked all the main boxes that a great phone should tick:

  • A good camera
  • Decent battery life and a very quick charger
  • Great software: near stock Android with no unnecessary modifications
  • Solid performance

These are also the main drivers that made me keep it for the longest time that I’ve ever had a phone. And it’s only now that it started to have lags in performance and limited charging capabilities that left me want to let it go.

I think it’s great and important that the smartphone industry has matured as much so a device doesn’t need to thrown away after two or three years.

Google Pixel 6A laying on a piece of wood. The Google logo is shown on screen.
Hello Google Phone

Switching to the Google Pixel 6A

I was thinking quite a bit about switching to an iPhone and possibly specifically the iPhone mini. Since I haven’t owned an iOS device for quite a while I’ve lost touch with the platform a bit. I couldn’t really tell however, if I would have enjoyed the trip back or not: I generally don’t really like their physical phone designs (although the mini form factor is fantastic) and rather dislike their general photo processing.

So long story short: I’ve seen the Pixel 6A in a shop today for 399 Swiss Francs (about 400 dollars) and took it. While it’s not a flagship I’ve checked it out previously and it seems like reasonable middle ground – probably more than enough smartphone for me. And I also imagined it would be a an interesting look into the Pixel series.

What I like about it:

  • It runs Android in it’s latest version and as Google imagines it. So far that is the best version of the OS that I’ve seen. I really enjoy using Android and also the latest Material You overhaul.
  • It’s not too large. It’s actually physically a bit smaller than the 5T although the display size is a bit larger.
  • It’s not fancy but yet seems to do the main things right and to check all the needed boxes.

I hope it will make a fine daily driver for the next years to come – wish me luck! 😉

How to disable the “Synchronise repeater and flexible sub-fields positions in post translations” WPML ACF option

The Problem

If you use WordPress and have WPML with their Advanced Custom Fields Multilingual (ACFML) plugin installed you may have already spotted the following option below repeater fields:

Option to synchronise repeater and flexible sub-fields positions in post translations
(record drag-and-drop moves and do the same moves in other translations).

While this may seem like a nice option it’s turned on by default and not great for websites that use a repeater as the main content field and have pages with varying content for different languages. I often use the Flynt theme for developing custom-made WordPress sites, which uses the given setup.

The solution: disable the “Synchronise translations” option by default

Sadly I haven’t found a documented way to disable the option. While looking through the ACFML plugin however I’ve found the following solution in two easy steps:

1. Add the following lines to your wp-config.php file:

/* Disable ACFML's sync of repeater field positions across languages by default */
define( 'ACFML_REPEATER_SYNC_DEFAULT', false );

2. Most likely: update setting of existing posts

In your database select the “wp_options” table and look for a record with “option_name” = acfml_synchronise_repeater_fields. This record seems to contain the post IDs of existing posts with their corresponding boolean setting.

Rename the acfml_synchronise_repeater_fields column to something like acfml_synchronise_repeater_fields_backup in order to disable/unset the value for all existing posts. As soon as you set the setting for a post again this record will be recreated.

Feedback appreciated

If this solution helped solve the same problem for you it would be great if you could let me know that in the comments below.

HTML5 Video Autoplay in Mobile Safari

For autoplay to work on Mobile Safari with a native HTML video element you need to also set the “playsinline” attribute. Otherwise the video wouldn’t start to play automatically:

<video muted loop autoplay playsinline preload="auto">
    <source src="video.mp4" type="video/mp4">
    Your browser does not support playing this video.
</video>

The playsinline attribute is actually a standard HTML attribute, I learned today. I did not encounter any problems with autoplay in other browsers besides within Mobile Safari though.