dhershman1 / silicate-cms

Headless CMS that should be locally hosted per project, built using Nuxt

Silicate Headless CMS

A simple locally hosted headless CMS. I planned to use this for myself on any future projects that required something like this, however the license is MIT and the plan it to keep it that way, so as it comes along feel free to use it for yourself!

Support

Browser	Support
Firefox	52+
Chrome	57+
Safari	10.1+
Edge	16+
Opera	44+
Internet Explorer	Not Supported

How To

Currently the project is not being hosted (We're still in heavy development) with the lack of more legit functionality.

However if you'd like to preview some of the UI pieces and give some feedback here's how you can locally run the CMS:

• clone this repo
• cd into the repo directory
• Run npm i
• Run npm run dev
• Go to localhost:3000

There are no current permission or authentication blockers so whatever UI currently exists is accessible!

Features (Current and Planned)

• Complete Accessibility following WCAG Standards
• Handles all levels of content: Text, Images, Files, Themes, etc...
• Easy to use REST API to retrieve data objects for your content
• Generate and serve Static HTML files (No sending html over the wire)
• Authentication system baked right in
• Internal permissions system baked right in
• User management for the CMS itself
• Plug and play

Philosophy

The goal for Silicate is not to re invent the wheel so to speak, but to build upon and improve where it can to become a useful and easy to learn tool in your web development world.

Making client work easy to serve up so your clients can still edit their site when you're done, without needing to be on something like WordPress.

Granted, there are plenty of headless CMS tools to give you this advantage as well! However with Silicate ease of use, better A to B connecting, and following strict rules and standards might help to put it ahead. As well as expanding upon and improving implemented ideas of course!

Technology

Built on Nuxt. Hand crafted styles, and taking advantage of the CSS Grid system

silicate-cms's Issues

Add Ability to use Date Driven Content

It might be a slick idea to allow the user to create content that will automatically expire after a certain date.

This of course will require some validation on our end to make sure the content is callable or not.

This also raises the question, do we delete content that "expires", or do we just leave it in an expired state?

This feature would add functionality giving the user some automated tools to take advantage of.

Login Page

The basic login and authentication page most likely acting as the home page.

• Create basic layout and page design
• Add ability to login
• Add block so you cant go back to the login page when already logged in
• Add stricter validation

Waiting for Nuxt 2.0

Nuxt 2 is apparently around the corner. Which is sort of why updates to the CMS have been rather slow.

Once 2.0 releases we can hit the ground rolling!

Bucket Search, Filtering, & Sorting Capability

With issue #12 being a thing, I want to take it a step further and add the ability to search, filter, and sort content buckets.

This will make it easier to find particular ones you want to change.

Sort should be able to work like so:

• By Date Created
• By Date Ending
• By Title
• By Type (We will need to form a makeshift hierarchy for this sort possibly)

You can filter by:

• Type
• Edited by (?)
  (?) = If this feature is added in issue #12 then it can be a thing

Searching should work for pretty much any key piece

• Title

• Type

• Edited By (?)
  (?) = If this feature is added in issue #12 then it can be a thing

• Added Search Functionality

• Added Filter Functionality

• Added Sort Functionality

• Tweak and improve sort functionality

Possible Preview Functionality

A preview feature would be a pretty helpful addition, perhaps to preview stuff like images?

Switch Bucket Display

Scrap the idea of displaying buckets in a 3 column list of cards.

Instead I think a table would be much more handy and easier to us.

The following info should be listed per row:

• Title
• Type (Text, Image, File, etc)
• Last Edited (?)
• Edited By (?)
• Edit Button

(?) = Possible features to be added/used

Clicking the Edit button will take you to a separate page to modify the content bucket.

Build Pages

We obviously will need to have the pages for the application

• Login Page
• Dashboard Page
• Users Page
• Analytics Page (?)

(?) = Maybe add in at some point

Plug in Materialize

Let's go with the materialize framework to give a nice look and feel to the application.

Do we want to bring it in via CDN or locally?

• Add Materialize framework

Plug in Database

Let's add in a DB to get storage rolling, let's choose between Rethinkdb or couchbasedb they're similar to an extent, but which one will fit our needs better?

Some of the current options are:

• RethinkDB
• CouchbaseDB
• Postgres
• SQLlite

Handle Authentication

We will need to be able to handle login authentication obviously for access to the CMS UI

• Build authentication middleware
• Plug into Vue Router to make sure authentication exists for access
• Handle a users table
• Make sure the DB is keeping track of users correctly

Dashboard Page

Creating the dashboard page which is the primary location for maintaining and adding new content that can be requested by the other server.

• Create basic page layout
• Ability to create/add new content buckets
• Ability to edit existing buckets
• Ability to delete existing buckets
• Handles basic text content
• Can handle storing a theme and serving a css file (?)
• Handles image files to be uploaded
• Handles other file types (like a pdf perhaps) to be uploaded

(?) = it may be more of a store theme values and the CSS is built by the actual app making the request instead.

Create User Page

Adding a create user page so that owners could easily create specific users with certain permissions to access pieces of the app.

• Create User Page
• Ability to create new users
• Ability to edit current users
• Ability to remove users

Too Much Microing?

I feel like maybe we are breaking the flow down into to much of a micro level.

page -> section -> content bucket might be too much.

Instead why not do page -> content bucket and let the requester dictate where it goes on the page instead of worrying about a section category?

This would work for Text, image, and file content types (possibly theme types too). As for serving up static HTML pages that itself would be a different situation that might fall under a different way of being handled.

• Remove the middleman section from the flow, it's not needed

Accessibility

Keeping in mind that we want to build from the ground up while keeping accessibility as a priority.

So far:

• h1 heading for login page
• Adding a landmark role tag to the main div
• Trying to keep color contrast for inputs
• Add lang attribute to html tag
• Fiddle with login button perhaps for more contrast fixes

Create Endpoints

Create the API endpoints so which ever app can communicate with the server this is hosted on.

Do note: I want this to be hosted per project using it, not a global CMS handling all projects but locally.

More to come

Local Routes

• Ability to save changes
• Ability to find and show current content

API Routes

• Fetch desired content
• Fetch the correct CSS specific to generated themes

Rethink Dashboard UI

Currently the UI contains ALL of the questions in choosing a bucket, as well as has pages in a tab layout. This could get really ugly if a user has a lot of tabs.

Suggestion 1: Convert the tabs layout for pages simply into a dropdown

Suggestion 2: A Progressive UI, so the user selects a page it will navigate to the next "page", the user will select a section. Then it navigates to the final page which has the table of content buckets to choose from.

Each question would still be a dropdown (besides the content buckets those would remain as a table) we could implement a stepper component at the top during this process. As well as the appropriate back buttons if needed.

Understanding Dashboard page Flow

The overall flow of the dashboard page can be pretty tricky to remember without a visual aid.

It's not too complex overall, but the flow is nice to have a visual of, I created a lucid chart to sort of give that visual: (May change in the near future as development continues)

https://www.lucidchart.com/invitations/accept/c4fb69b6-56e5-4dea-aebf-c755696ab503

May want to take into consideration whether or not we want to have sections able to be applied across multiple pages. Say for instance, a header section that is simply a logo and brand name, having to create it for every single page might be annoying?

Make "bucket-table" more generic

The component bucket-table was originally built to house the table for content buckets, but I am using similar table structures in other location.

I think it'd be a good move to make this a bit more Generic allowing the component to be reused in other locations.

Some steps to take to achieve this:

• Generic Table Headers
• Generic row/cell handling
• Generic styles
• Generic/Dynamic Sorting, filtering, or searching
• Ability to turn off Sorting, filtering, or searching

Permissions System

Create a broken down permissions system

• Manager: Is only permission that allows you to add/remove admins
• Admin: Can do pretty much anything
• Edit: Can edit existing text/theme content
• Create: Can create new text/theme content
• Upload: Can upload files like images or pdfs
• Delete: Can delete any content bucket

Notes:

• Thinking that only an Admin is allowed to create, edit, or remove a user from the system
• There should be only 1 Manager level account

Login Functionality

The core of the main page is going to be the login functionality so we can let users keep track of what is going on, while also allowing them to make changes to their app this is connected to.

• Add login route
• Add login form page
• Build login post route
• Add authentication to pages
• Add authentication middle ware to nuxt