Livecode Content Management System

[Alex Tweedly]

So many interesting, thoughtful and thought-provoking responses - I am 
overwhelmed. Thank you.

I can't reply to each of them - flooding the list with 24 responses 
would be somewhat anti-social :-), so I'll arbitrarily pick the most 
recent (as I type) and respond to it, with responses to various points.

A number of people have made perfectly sensible suggestions, musings or 
"project proposals"  that would constitute useful "CMS's to play to LC's 
strengths, and avoid simply re-inventing existing wheels which already 
in another language. I would love to do (or contribute to) many of those 
- but I know I don't have the time or immediate need for them. So (for 
me, for now) that rules out David's static-site generator scheme, 
Andre's PWA and even much of Andre's Desktop with API.

I will definitely take David's advice ("be opinionated " :-), and I will 
be mindful of the fact that 3 of the people whose opinions I most 
respect (Ralf, Andre and Richard) all said something along the lines of 
"stop - it's a huge task - make sure you know what you're getting into 
.." :-)

So here's my current take (sorry for the very long email)

"CMS" is a broadly defined beast and it's important to fovus on what you 
want it to mean.

To Ralf's point about the need for large amounts of "front-end" effort, 
in-line editing, and "lots of Javascript" - that's true, for a certain 
kind of CMS you would indeed need that - and I wouldn't even consider 
building such a thing. The websites I have done to date (and am about to 
update and build some more of) have people (not very tech-savvy) whom I 
would call "content editors" adding / maintaining the *content* using 
simple web forms (no JS, just plain-old html "Web 1.5" forms) and 
Markdown-lite. I am happy for them to continue that, they had no 
difficulty understanding a simplified version of markdown - I mostly 
want to make it easier for myself (and other "site-creators") to enable 
this, i.e. provide simple, easy, built-in access to forms and 
"db"-update mechanisms without extra work for each new site.

Again - this should be *content* management only - whether the site 
itself uses Bootstrap, or JQuery, or *any* other technology is entirely 
up to the site creator, and the 'CMS' should allow that.

(Note - when investigating Wordpress, I really liked Visual Composer for 
in-line editing and page layout - until I discovered that it was 
incompatible with Pods Custom Post Type extension for anything beyond a 
simple list - without significant PHP coding). So the page content 
definition (described below) is simple - should cover 95% of all actual 
pages :-)

And, finally for my "intro" - my preference has always been to put this 
on top of revIgniter - and the responses have confirmed that no-one 
would regard that as a disadvantage or problem - so I feel comfortable 
with my original preference. Also, I have realized that my concerns 
about the "rigLoadView" mechanism are misplaced - it's not "a problem 
that they don't fit well with themes", in fact, it's a "solution that a 
folder full of 'views' *is* one good way to define a theme".

On 04/12/2017 18:12, Richard Gaskin via use-livecode wrote:
> We have many options available, and many different needs.  Whatever 
> Alex finds as the best fit for the specific CMS he's aiming to build 
> will hopefully reflect less any fashion or trends or technologies 
> among the nearly infinite range at his disposal as it will reflect an 
> understanding of what constitutes an excellent UX for visitors of the 
> sorts of sites he's looking to build.
Here's what I am aiming at:

Summary: based on top of revIgniter, this will provide a controller 
script to display any and all pages, with simple, easy-to-understand and 
easy-to-use mechanisms to allow multiple people with varying skill-sets 
to create, build, maintain a web site of simple to moderate complexity.


The long version :

revIgniter will be the base technology.

LCMS (or whatever more descriptive name I can think of) will provide a 
primary controller script which will display pages as required, as well 
as a set of web pages for updating the site content.

A "site creator" will create (and maintain) the site - providing the 
(core) set of pages, the menus setup, choosing (or creating/extending) a 
theme and setting up the initial admin interface; a fairly tech-savvy 
person, most likely a LC scripter though I would hope that the majority 
of straightforward sites such as I usually help people with will be 
doable without any new coding).

A "site maintainer" will extend / update / modify the site content - the 
info in the pages, uploading images or other media assets, etc. (Not 
necessarily tech-savvy - but with some clue - able to edit markdown text 
for simple content, and perhaps to copy/update simple command sets).

[Some page changes might be more structural and need the "site creator", 
depending on the tech comfort level of the sit maintainer.]

An RDBMS (e.g. MySQL) will be used (as in the revIgniter default), 
providing user management, etc., but (to allow the possibility of 
Git-based roll-back, etc.) a number of features will be flat-file based.

So the things needed in a site are:

a theme: themes should be *site-independent* - i.e. usable with no 
change (or an inheritance-based extension mechanism) on many sites. 
These define whether (and more importantly) how (i.e. the html code 
snippets as well as JS and CSS assets) to implement high-level 
constructs (page headers for different page types, snippets for common 
features such a banners, galleries, carousels, responsive grids of 
images / mini-pages, etc.   Themes will be implemented as a set of view 
files in a View folder. As such, they are pretty "techy" and will be 
defined by a "site creator" or perhaps a them creator for general use.  
(NB first release won't include the inheritance/extension mechanism; 
hey, I'll be licky if there are two themes defined in it  :-)

menu and controller definition : the 'controller' definiton might well 
be standard (i.e. only using the built-in features), or might need to be 
extended for a site that needed custom coding. The menu definition 
simply determines what pages are shown in the menu.

pages: the (initial) set of pages to be available on the site; note this 
includes those directly available from the menu as well as possibly 
others. These are flat-files (so suitable for Git-control). Each one has 
a (optional set of intro definitions) and a simple text description of 
the content. See below for definition of content.

A simple "media uploader / manager". This will be needed for images, 
audio clips, etc. It will be *simple*, i.e.  upload a file or a few 
files at a time, no fancy JS drag / drop / select, fill in category / 
tag / etc. form entries., etc.  (Can probably also be used to upload 
other things (e.g. markdown text files) for anyone who wants to do it 
that way.)  This currently will automatically build specific sized 
versions of the images on upload (i.e. it won't automatically resize on 
each access - that requires too much smarts on caching that I don't have 
:-); these can be referred to as "thumb", "small", "medium" and "large" 
- while the actual definition of those sizes can be set by the site creator.

Custom DB types: the site creator can determine custom DB Objects to be 
used on the site. (Versions >1 might allow these to be DB or flat-file 
??)  These define the fields, field types, etc. in the DB, and 
automatically generate a simple (dumb, ugly) form page to edit them.


Now we are ready for "Page Content"

Each page is described by a simple text file (flat file, in 
/user/pages"). There will be some meta data (cf Grav CMS) optionally  at 
the head of the file, but the main file will consist of a series of 
'directives':
     "set",
     "Banner",
     "Carousel",
     "mdl",
     "html",
     "image"
(more to come ...)

Any text outside these directive blocks will be simply output as is; 
probably shouldn't be any of this.

A directive begins with  a line enclosed in "[" and "]" with only 
whitespace outside the brakcets, and has a directive name and possibly 
argument, followed by "," and a number of 'details' each separated by 
comma. In general, the theme will need to define one or more snippets 
related to each of these directives. So it is assumed that the theme 
will have an entry for 'banner', etc.

The current set of directives is :

"banner"
[banner, where Category=banner, orderby id=random]
Produces a full width banner image. The 'where' and 'orderby' clauses 
are basically passed to the DB selection (of media asset type 'image')); 
in my case, all images with category 'banner' are panoramas and I want 
any random one of them.

"carousel"
[carousel, where category=hotel, name mycarousel]
Produces an image carousel (named so we can have more than one on a page).

"image"
[image size reference alternative text to show]
"size" is one of thumb, small, medium, large
reference is either a number (th eID) or the shortname of an image
alternative text to show is the 'alt text'
(Note - this should match the custom addition to Markdown - see below)


"html"
[html <type>]
The following lines (up to one saying   [html end] are html text and 
should be passed through unchanged. <type> is not yet really defined, 
but will expect to  match something in the theme.

"mdl"
[mdl <type>]
The following lines up "mdl end" are Markdown-Lite text. <type> is not 
yet fully defined, but will expect to  match something in the them - 
currently only using "text-section" to include the header/footer for a 
simple text section. 'mdl' stands for Markdown-lite - only handles basic 
forms of Markdown (tbd elsewhere), but does also include some special 
forms for LCMS
    - !![text](image)    - refers to an image from the media library, by 
either id or shortname
       NB the "text" part is image size reference alt text - to match a 
"image" directive), while the part in                     parens is ignored
    - ![text](image)      - standard Markdown
    -  ...[visible](url)    - standard markdown, except that if 'url' 
ends with "*" or "_NEW_TAB, then it will             open in a new tab, 
and if [visible] == [fb] then it will generate a Facebook link.
    (other social media to come in later versions)

and (keeping the best for last :-)
"set"
[set businesses, where Category=hotel, title Hotels, count=3, template 
businesses_grid]
Produces the output for a set of objects; the object type (e.g. 
'business') determines the DB table, while the 'where' and 'orderby' 
clauses would filter and sort those objects, and a template can be 
defined to specify how they should be displayed, the title is a 
mini-header before the display, and the 'count' determines how many 
should be shown per row.

This is, obviously, the most complex and powerful of the directives; 
note that it expects (requires) that the theme will specify both header 
and footer snippets for each of "section", "row" and "item", while the 
format of the entry for the actual object is specified in the "Content" 
field of the "template" specified.

It is perhaps worth pointing out here that the html snippets 
*surrounding* each object are part of theme (i.e. they define how to put 
something *into* a "n"-grid, while the content template cannot be part 
of the theme, because it will be dependent on the values to be displayed 
- i.e. it's site-specific.


I hope to have this cleared-up in my mind, and an initial prototype done 
for Christmas (which should allow an initial upload to Github by New 
Years's).

Later,
Alex.
P.S. a page similar to 
https://www.kilmelford.com/igniter.lc/basic/Businesses would therefore 
be created by the page definition:

[mdl text_section]
<article>
## Business Directory
If you run a business in this area and would like to be included,
please use our Contact Info. If your business is already included,
and any of the contact etc. data has changed, please give your
input via the contact page.

The day/time/place information for visiting services (mobile library,
bank) can be found on the [Services Page](services) .
</article>
[mdl end]

[set businesses, where Category=hotel, title Hotels, template 
businesses_grid]

[set businesses, where category=B_and_b, title Bed & Breakfasts, 
template businesses_grid]

[set businesses, where Category=eating, title Places to eat, template 
businesses_grid]

[set businesses, where Category=activity, title Activities, template 
businesses_grid]

[set businesses, where Category=interest, title Places of interest, 
template businesses_grid]

[set businesses, where Category=business, title Businesses, template 
businesses_grid]

[set businesses, where Category=government, title Government, template 
businesses_grid]