Form Function IO

Category: The Ongoing

Collected here are ideas, trends, analytics, quirks, any part of web design and development that has a reasonable baseline, clear variables to track, and can report regular results for.

  • 4 CMSs: Comparing Craft CMS, Ghost, Netlify CMS, and WordPress

    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.)

  • NGinx Locations for Multiple Dynamic Sites

    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!

  • Upgrading to React 2 is easier than shoehorning ES6 fixes into React 1

    Title is pretty self explanatory.

    After a long battle, many many yarns later, it turned out that trying to get CK Editor to work in an older version of React Scripts, as an example, was far too much work. What’s more, there aren’t too many barriers in moving from React Scripts 1 to version 2. Some of the Routing syntax has changed but overall a build using forms, axios, mammoth, and a few other common repos, switched with minimal effort and no feature loss (or replacement.)

    This came about when trying to build an older repo with the newest CK Editor, 5. The error shown right away is:

    Failed to minify the code from this file:                                              [31/75]         <project_root>/node_modules/@ckeditor/ckeditor5-build-classic/build/ckeditor.js:5:2077

    The directions provided by CKEditor are to eject the app, which is lasting and a huge pain, so instead React App Rewired looked like an option. After more than a few attempts, including duplicating and ejecting a backup repo, no amount of config overriding looked to get the editor to build in React Scripts v1.

    This took, admittedly, hours to try and hack around only to hit more JS that refused to compile.

    Updating the dependencies to React 2.1.8 and, after a couple more yarn updates, the build went right through. Done. No hacks, no weird shoehorning of ES5 into a largely ES6 build.

    Ejecting should be a very last ditch effort for trying to get any repo that may not support the latest scripts version and while overrides are absolutely helpful in tweaking settings, they can’t redirect a whole build. Also, don’t eject React (this has been well covered.)

  • Running a Heroku based Website

    Heroku is a platform that enables developers to “build, run, and operate applications.” The way Heroku hosting is managed is both more complex yet with fewer standard features than more consumer focused cPanels, control panels, commonly found for shared website hosting. The platform has a modular setup allowing for plug in of databases, caching, load balancers, and more. Also, adding additional apps, different instances of the site, and arranging them in a pipeline is as easy as adding additional domains in cPanels. Last, open ended environmental variables are available to edit where other website managers would only show settings for simple packaged features such as site databases (maybe even calling them the more technical MySQL databases.)

    All of this said, there’s nothing concrete stopping the hosting of a website on Heroku’s platform, even if it is a bit tricky.

    Though most of the sites we have are on standard cPanels, we do have a few sites hosted on Heroku. Some of the sites are on Node.js based Content Management Systems, some on Ruby based CMSs. Some of the features are very welcome such as the pipeline configuration, which allows for a seamless development arrangement that is harder to make on a standard shared host. Since Heroku is targeted towards developers, it’s welcome to see these features well thought though.

    Most of the pitfalls with the hosting so far are fairly straightforward; don’t have too many virtual instances using the same database, caching needs a careful eye since clients may connect to different instances, and there is a plugin or module for nearly everything but they need some wrangling.

    As we build on the sites, it’s a good to compare against the other sites we host, and see how viable sites of different sizes are on Heroku.