Form Function IO

Category: 4 CMSs

4 CMSs: WordPress’ Patterns made Blocks Useful (and Unmatched)

It was a rough start…

When WordPress launched the Gutenberg blocks plugin the bugs were plentiful and features minimal. The long running WYSIWYG editor, while stable and consistent, offered very little in the way of layout and dozens of 3rd party layout editors sprang up to bring more visual layout to WordPress’ otherwise powerful administration. Now, 5 years later, being able to bundle paragraphs, headers, images, and many more blocks into reusable patterns and templates is better than any of the other CMSs we work with (and better than the 3rd party WordPress alternatives.) Patterns, made from blocks, are powerful for not only for developers, allowing easier site building, but also for clients, allowing better working layouts that are flexible and reusable.

Choosing Premade Patterns

Patterns a series of premade block arrangements that bundle both design and functionality. This reusability is a awesome for developers, who are often tasked with recreating previously developed functionality, and designers, who are desperate to maintain layout and branding integrity.

Building a Block Pattern Right in the Editor

Being able to build a comprehensive and transportable layout in WordPress is one of the best and most unique features of Blocks. (The editor isn’t often referred to as Gutenberg outside the plugin.) With the other CMSs we are testing there doesn’t seem to be an easy way to build, copy then paste, and save as either code or “setting” the same way as WordPress can.

Options in Craft CMS, Ghost, and Decap CMS

SquareSpace put the most pressure on WordPress to change their editing but there are many more CMSs (thankfully) and many more self-hosted options. So far, we haven’t seen quite the level of ease of editing, ease of repeatability, and design “friendliness” as close to the WordPress’ block editor. There are block possibilities, such as the Matrix block in Craft CMS, but they aren’t quite as easy to create and do require some level of coding to implement.

Now invaluable for quick comprehensive editing.

WordPress Blocks are, fortunately, an example of a rough initial launch being smoothed out with continual steady progress. Blocks aren’t perfect, far from it, but compared to standard WYSIWYG editing, they are an enormous step forward.

June 13, 2023
Conforming Images: WordPress Aspect Ratio

Adding images to posts can easily throw off grids of logos, lists of posts, and other series where images should all be the same size. Ideally, there will be an option when adding an image that aligns the image for that space. When setting up a theme, image sizes should be set up for the various areas but it does need to either be coded or configured with a plugin. These settings need some finesse as well. While a large enough image will always enable the options needed, if cropping is not enabled, the image will still throw off the layout. Also, if an image is too small (or just right which is tricky,) the right options won’t show at all. Let’s look at how this should work.

Selecting an Image for a Space

We have a 3 column grid with a default image filling out each of the spaces. When uploading a new image, we see that this new image isn’t following the aspect ratio that is set up. For the technically minded, the original images are 600 by 900 pixels or 2:3 and the new image is 750 by 1000 pixels or 3:4. WordPress can work with an odd shaped images but sometimes there are compromises.

Custom Image Sizes

There are default image sizes, small at 150 by 150 pixels, medium 300 by 300 pixels, and large 1024 by 1024 pixels that can work in body text areas but design elements will likely need specific sizes noted by a designer. With our 3 column design, we have custom image tall size that is 600 by 900 to make the design.

Custom images needed for a design like this should be added to the theme settings to get the right effect. When uploading a large image, we should see an option to scale the image down. Here we have cropped and uncropped options that show how images are conformed if an uploaded image is larger than a needed space.

Cropping After Uploading

Uploading images larger than a needed space (using our 600 by 900 grid example) is common but there are 2 ways WordPress conforms images either cropped or uncropped. If a size is set to cropped then WordPress will trim the largest dimension down to fit the image to the aspect ratio.

Our too large image, 750 by 1000, becomes 667 by 1000 to fit the 2:3 aspect ratio needed. The uncropped image stays the odd ratio of 3:4 and even enlarging the image doesn’t work since the extra width spills over the space. If an image, like the 04 example, is too large, but the same aspect ratio, it fits in the space regardless of what size is chosen. Choosing the right size will optimize the loading of the page instead of loading a high resolution image.

June 6, 2023
4 CMSs: Comparing Craft CMS, Ghost, Netlify CMS, and WordPress

This project is testing a variety of Content Management Systems built on active sites with genuine, timely, content. In this way, we are testing each CMS in real world use, more extensively than would happen with just demo or “filler” content. Beginning with version WordPress 2.3, nearly 10 years ago, we started building by building WordPress sites using custom themes. Many of these information WordPress sites continue to be used today with minimal theme changes.

Since then though, our WordPress focus has shifted to more extensive WooCommerce installs, custom API construction and connection, and fully custom plugins. We continue to build some simple informational sites but the development landscape has drastically changed since WordPress’ early years. WordPress started as one of the only stable, actively updated content management systems. Now there many mature options including; Ghost a publication focused system, Netlify a platform for static sites that also includes a simple CMS, or Craft CMS which can work with widely flexible content.

Starting Point

To explore all these new options, we’ve setup 3 example sites based on a variety of current topics, Automation, the Green New Deal, and the Shapes and Screens of modern computing; these topics will provide endless angles from which to create media and content. We then started building a universal theme to use across each of the the CMSs, the theme isn’t pretty yet but sets a level starting place.

Are these CMS fair to compare to each other?

These CMSs are not directly comparable. For one, WordPress is often bundled right on many hosting platforms. Positioned as a “default” option, WordPress has near endless application. Each of these site managers is more difficult to set up and get going. However, even if they aren’t directly comparable, we are starting each with a simple publishing base. Each site should be able to have a customizable homepage, leading to list of posts, and individual posts should have layout options for images and other media. Ideally, getting started building these on an Nginx platform shouldn’t be difficult. (Also each site has to work locally, more on that later.)

Craft CMS

Craft’s feature types are key the flexible content management of the system.

Craft CMS is often compared to WordPress as both are run on PHP. Our setup on localhost was downloaded from the community version. At the moment, Craft needs the database information entered in code, not a browser, but overall installation was straightforward. From there, setting up the sections and entries to make the blog took some work wasn’t difficult. Our main critique is that there should be placeholder content and set up that helps users get started with a blog or simple information site. Craft CMS has been more difficult to update though, we are seeing a PHP issue that isn’t obvious to resolve. We’ll definitely have a follow post on updates for each CMS.

Ghost

Ghost has total focus on publishing.

From install to content creation, Ghost has an elegant interface and keeps clutter to an absolute minimum. Ghost has a paid option but installing the standalone system can be done from the command line and is built in the speedy, straightforward Node.js. With no database to setup, Ghost is self-contained and setup was a breeze on the local and remote servers. The complexity with Ghost came in editing the template, which needs a restart to show the edits. Overall though, Ghost startup and early management is the easiest.

Netlify with the Hugo Starter

Ghost has total focus on publishing.

Netlify CMS is the outlier in the group. Not only does Netlify CMS run as a static HTML site, the others are complied when a user visits or “time-of-flight,” but also Netlify is known more for it’s CDN infrastructure than for it’s CMS. Hosting the static site on a shared server removes the advantages of using the whole CDN but we’ll explore hosting options in the future. While many CMSs can output somewhat “static,” Netlify is purpose built and leans on Git versioning for content. This developer focus is appreciated, but is unlikely to be used by an “average” site creator.

Right now all the sites are set up and we are actively publishing content for each. First, we’ll dig into how post writing and publishing works. Stay tuned!

(Originally published in October 2020. Modified and republished February 2021.)

April 1, 2021
NGinx Locations for Multiple Dynamic Sites
Skip to the Important Code

Nginx is not only a fast server for single production sites but also a robust development server, with the right settings. With a default Nginx install, the /etc/nginx/sites-available/default serves overall index files for folders but doesn’t resolve queries to dynamic files. To fix this, create locations for each dynamic site.

The default Nginx file linked here with all the important pieces, port declaration, root, index files, and locations. Locations are where Nginx resolves browse requests for files in the targeted folder (in this case the root /). The examples on the Nginx page, don’t offer too much context about how various methods can work.

Locations standard code
```
	location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		try_files $uri $uri/ =404;
	}
```
With just the try_files $uri, the server only resolves to files directly in the browser URL and that’s it, limiting most modern CMSs. These location sections function similar to Apache’s .htaccess files so we need a directive that properly targets WordPress’ startup index.php for queries. (Here, all the directives are in one place though.)

Often when serving multiple CMSs on Nginx multiple config files will be added to sites-available (and linked in sites-enabled) but in this case we aren’t really making multiple sites so much as enabling the same CMS in multiple directories. When testing, the easiest method was to add one location section for each WordPress install using the syntax below.

Locations for Dynamic Sites (without needing multiple server blocks)
```
	location /wordpresssites/siteone.com {
		# First attempt to serve request as file or
		# serve from the WordPress startup file, then
		# as directory, then fall back to displaying a 404.
		try_files $uri $uri/ /wordpresssites/siteone.com/index.php?q=$uri$args;
	}
```
In this way, when navigating to http://localhost/wordpresssites/siteone.com the server resolves requests to the index.php as expected. Want to setup multiple WordPress sites? Or another PHP CMS? Just copy the section and rename as needed. Make sure to restart Nginx!
```
sudo service nginx restart
```
or
```
sudo systemctl status nginx
```
Have another way of approaching these directives? Comment below!
March 1, 2021