search

glennfeys / CMSingle

Open source flatfile CMS with no database, that is using only a single file and is extremely easy to integrate in any html flatfile project.
MIT License
5 stars 1 forks source link

Proposal: how content editing could work #13

Open nielsdos opened 5 years ago

nielsdos commented 5 years ago

What are important factors to take into account for editing and WYSIWYG?

The whole point of CMSingle is not to develop whole new websites, rather easily change existing websites. Since our core audience aren't web developers, it should be easy enough to change webpages without breaking the template. Minor changes to the template should be allowed though, for example: adding/changing columns in a column layout on a page. Another point is that some sections of a page stay the same throughout different pages of the same website (header, footer is a classic example).

Idea

Therefore, I believe we shouldn't just put an editor on the whole <body> of the page. Making <p>, <a>, ... editable is not the best option either, because you'll want to group related content and make the group editable instead for flexibility reasons (e.g. column layout, articles, ...). Ideally, we'd have a system that can detect editable sections on its own, and detect common components on different pages. Since auto detecting is probably error prone and not perfect, I suggest the following solution that consists of two modes: "informed" and "uninformed" editing.

"Informed" editing

The templates and pages contain a data attribute on tags that contain editable content. For example:

<div class="card" data-cmsingle-content>...</div>

or, if you want to group multiple cards (which would allow cloning and removing single cards => the flexibility I talked about earlier)

<div class="card-deck" data-cmsingle-content>
<div class="card">...</div>
... (etc)
<div class="card">...</div>
</div>

Data attributes can be safely included in the page source, it's hidden for the user anyway. It'll also be very unlikely that javascript on the page that use data attributes will be an issue, since we prefix the data attribute.

Okay, so now we handled content, what about the templating we talked about earlier? We can use data attributes again. Suppose we have a common footer:

<footer data-cmsingle-component="id of footer">...</footer>

How would this work? For example: you open the homepage, you can still edit the footer. When you save, it scans for files with the same data-cmsingle-component id (in this case: "id of footer") and replaces the inner html code. It's intuitive for the user: they can change any part of the page, if it's common, all pages that share the same common part will change as well, if it's uncommon, only this page will be affected.

Alternatively, we could also let data-cmsingle-component work with files instead of ids.

<footer data-cmsingle-component="some_component_folder/footer.html">...</footer>

In that case, we save the footer to some_component_folder/footer.html, scan the files for the same data-cmsingle-component="some_component_folder/footer.html" part, and replace that.

"Uninformed" editing

What if you don't have a template with CMSingle data attributes, and still want to use CMSingle? The CMS doesn't have information about templating now, however we can do an attempt at figuring out what editable content is.

Usually, editable content is wrapped together in some sort of container element, such as a <div>. Related content is usually also next to each other. So an idea is to:

  1. Find all <p>, <a>, <h1>, ...
  2. Get their parent element
  3. If their parents are neighbors, they're likely to be related content, so they should be grouped for flexibility as discussed earlier. Then a data-cmsingle-content is added (virtually) and we can proceed like earlier.

PHP

This is also related to #2. The main reason we'd like php editing capabilities is because it allows templating. Editing php files is very fragile as we discussed before. I'd rather not allow editing php files. With the proposed system in place, editing php isn't needed.

Implementation

PHP provides the DOMDocument and related classes which makes finding and changing data attributes and their content easy.

Questions

I'm not sure how we would go about minor differences in common components (e.g. navbar). An option is to create some sort of magic keywords, but I'm not 100% sure about this.

glennfeys commented 5 years ago

Vague, but exciting

I really like the idea of making things like the header and footer more generic, so we can easily change them on different pages. But I don't really get the way you want to do this without use of php. Do you want to scan all webpages for a component when it changes ? Also a big part for me about the whole cmsingle editting expirience, was the ability to easily plug it in and do everything. So with the added tags that part of the philosophy is partially broken. personally I would think it would be nice if we could keep the php and try to maybe support some sort of php and then document what is supported. overall I would just say we are able to edit html within php files but still if people want to include a header they can just go to the header.php/header.html file and edit it.

nielsdos commented 5 years ago

Do you want to scan all webpages for a component when it changes ?

Yes. Find the matching components names/ids.

Also a big part for me about the whole cmsingle editting expirience, was the ability to easily plug it in and do everything. So with the added tags that part of the philosophy is partially broken.

I agree on this matter. This is the reason I proposed two modes: informed & uninformed. To unlock full power, people would use the informed mode. Useful in the case there are templates which are specific to CMSingle. In case of putting CMSingle on an existing project, uninformed can be used.

Personally I would think it would be nice if we could keep the php and try to maybe support some sort of php and then document what is supported. overall I would just say we are able to edit html within php files but still if people want to include a header they can just go to the header.php/header.html file and edit it.

Tbh, I'm not a huge fan of editing PHP because it can break things easily and is very error prone. The whole reason we wanted to edit PHP is because of templating, which could be fixed with the informed mode.