Which (if any) CMS?

1

I have been looking at CMS over the last several weeks, and it seems they fall into Git-based and API-based categories.
From there, they split into SAAS versus self-hosted.

My impression of most Git-focused and Jekyll-friendly CMS’s are that they are more focused on Markdown / text / blogging / Informational type of functionality.

For now, that isn’t our problem area. Where our bottle neck is, is setting up and maintaining our eStore, which is over 200 products and growing. To date, I have maintained this from a spreadsheet feeding into CSV, and then using Jekyll to iterate the products within each category. For various reasons, this means a template page for each category.
For now, the individual item pages are created through a Python program, and then Jekyll kicks in.

Very obviously the spreadsheet has issues: invalid characters in the text-content-fields can break the load, and handling images for 200 products (typing in the URI to the CSV and uploading the images to the target directories) is obviously a real PITA.
Plus it forces over-simplification on how we need to manage the store.
For example, a simple data structure would be site, site-category, category, product-category, product, brand, product-brand, product-images, customer-type, customerType-category (for discounts) as a start.

I have tried a few of the open-source API-focused CMS packages, such as Strapi and Directus. There are also commercial and hosted solutions, but we don’t want to commit the money there until we know how the site is going to work

Very concerning is that some of the open source packages don’t seem to have a lot of traction, or have an incompatible technology stack (we don’t use PHP and MySQL), or are very buggy…

One of them I have started a test project some 5 times, and each time I get to an issue that means restarting. Not wanting to do that if I have 200 products loaded and we are transacting…

Anyone have a suggestion?

2

Just to carry on with the topic.
Looking at the various API CMS packages, they typically have an app for content input (often built with React or Vue), a data / data type / content / content type manager, a database for storage, with images in the file system. Then there is an API to pull data out, usually REST with GraphQL support being developed.
They also have an access / security capability to control both app and API.

But, given the sheer amount of work to get this going, I could just as easily simplify it a lot.
We use Postgresql as our DBMS standard.

I can (and have) generated a very robust data model using my standard modelling tool, which is much faster and more comprehensive in usage than any of the CMS content type managers I have seen.

PostGraphile will plug directly into the schema
Given this, Post Graphile provides high-performance GraphQL serving capability, and can automatically generate most of the schema from the database.
It also handles most of the API access and security.

That leaves content input and maintenance: for now, I have spend a day spinning up a LibreOffice Base application which can input all of the above data, with drag and drop image storage directly into the database.
For structured content, I can input data much faster than through most of the content editors I have seen… A lot of the data is entered as you would in table / spreadsheet format.
I can share this via Git with fellow workers for now, and as my Vue skills improve, can generate a Vue app to do the same.

As for maintaining page text, I can do that by spinning up a data structure that looks like
_site // navigate to site, site template directory, site static/public directory (we have multiple sites)
__pages // navigate to template page, static/public page output
___tags: tagname + text +text-type // the tag-name to search for and string / markdown to replace it and the format of the text (string, markdown…)

For posts or informational pages, we can just use Git and a suitable Markdown editor.
I already have a python program that reads through some pages and replaces tags with data, then outputs the page, where Jekyll / Liquid can’t without a plug-in.

What am I missing? (Apart from a bunch of extraneous software layers to handle multiple types of (SQL and NoSQL) databases, several types of APIS, frameworks, access modules to cater to organisations of any size and type and so on…)

3

Answering my own question here.
I went ahead and did my own quick fix on this.
All of it looks pretty stable and proof for long term use, apart from the front-end content input.

Now I have a working GraphQL / RDBMS based CMS solution feeding into Jekyll. The last part, reading from the GraphQL API into Jekyll should work for any GraphQL-based CMS system or data source.

Front end: I rolled my own using Libreoffice Base. I taught myself the tool and iterated the design over a weekend: now I can input site, catalog, brand, products and their relationships, including photos directly to a Postgres DB
Notes: While this is a longer term throwaway, the input screens are far more user friendly with image pickers, multiple master / child / many-to-many relationships implemented as scrollable datagrids. I can see and maintain all brands and catalogs and scroll through all images for a particular product on 1 screen, for example.
Next up is to convert this to a Vue.js solution.

Content store: Using Postgres, I designed the product catalog and implemented over the course of a weekend. Storing all data related to an eStore in the database.
Way easier and faster to design and generate the database even using the very basic pgAdmin4 tool than for example, Strapi’s Content Type Management plugin.
Plus I have full control of the database, for things like indexing, uniqueness factors, relationship definition and so on, where some of the CMS packages generated rather flawed data structures.
Plus the database is the source of origin for everything including images.

API: Using Postgraphile here, which seems to be a very fast and fairly complete Graphql schema / API generator, reading the database schema directly and exposing and implementing things like relationships, datatypes, uniqueness, IDs, access control and so on.
Looks like it could be a long term tool, as I can hide Postgres behind a firewall / router, and to the consumer of the API it will look like any other GraphQL end point.
Took me a few days to learn GraphQL and so on , but it’s up and running (fast).
Takeaway: Design specific schema for GraphQL, and then link other schemas as necessary in Postgres. Also, use the right GraphQL explorer / tool, that exposes the schema documentation, structure and also does code completion for template queries.

Jekyll: GraphQL outputs a formed JSON resultset. I used a python program Irequests and JSON modules) to output this JSON to the data directory as a file,
At the same time create and resize each product image to primary, thumbnail and shopping cart versions using the Python Pillow module to resize and insert the photos on the fly. Also python output individual template pages for each product including front matter.
Then configured a page template using Jekyll / Liquid to read the JSON and create the catalogs and generate to the site.
Over time: Configure GraphQL and the python extract / build tool for subscriptions so that I can automatically regen the website once the changes are committed to the database.
Maybe also look at converting the Python modules to node.js to reduce the technology footprint.
And automate page creation / generation even further for the catalogs.

Futures

  • Replace Base front end with Vue / Nuxt or Quasar

  • GraphQL subscriptions for automatic site regeneration (Jekyll -> Github -> Netlify)

  • Add in CMS for page elements: should be as simple as a Site / Page / Element structure in the DB, with options on the front end for plain text / Markdown / HTML element content support.

Probably took me less time to build my own solution than to implement one of the CMS solutions I looked at.

1 Like
4

I agree

It looks you’re looking for more and more functionality. Have you considered Django plus Wagtail. Everything you could need, but of course knowledge of Python is a prerequisite . But that shouldn’t be a problem, the future is Python isn’t it?