WonderCMS community

TinyCoding wrote: Thu Aug 15, 2024 8:16 pm Well, MD (markdown) writing takes some getting used to, and it requires a parser which converts the MD into HTML using PHP.

I recognise that MD requires a parser and that complicates things and enlarges the package, which goes against the "keep it small" philosophy of Wcms. Perhaps I was not thinking straight. As I said at the beginning it depends who you see the intended audience is. Perhaps, if a good WYSIWYG editor is not available, then it is better to encourage users to learn a little bit if HTML rather than a more general purpose language. I confess that my very few experiments with it have been limited to playing with the service at: https://dillinger.io/ and that begins to make me wonder why one would want to add it to the Wcms package, Just use that to generate the HTML for you and paste it into the default editor.

That said, the main problem with wCMS from my perspective is the fact that it uses one file for serving everything instead of separate files (database.js) which a JSON file.
Either way, a flat-file system requires PHP memory (open, read, close) and opening the same file each time no matter what the query is, might not be the best option.

I'm not technically competent to assess that issue. Bear in mind Wcms is not intended for large sites, just a those with one to a few pages. I don't think any of the Wcms team's themes even include code to cope with sub-pages appearing on the menu and you'll notice how the main site uses within page buttons extensively not not second or third tier menu options.

I have almost finished my walk through of the core, and from what I've found so far, I might just fork it and remake it.

There's one or two places on the forum where you'll find Robert encourages people to fork Wcms.

True, the PHP parser is one option for MD > HTML. Another is markedJS which is smaller (25kb). I'm not sayig that MD is the right way forward, or even the right way as an plugin option. But from a "keeping it small" perspective, the core devs do kind of trick us since the admin part loads a lot of external scripts and files - which in reality means; it's not really so small.

All that being said, other areas need focus for wCMS to be more user friendly. Something I hope the core devs will, at some point, focus on. Menu being one of those things.

Edit: yes, I might fork it and remake the editor, menu, and some other things while also removing the need for external libraries.

To address a few of the topics from TinyCoding, as some of the points are interesting.

> But from a "keeping it small" perspective, the core devs do kind of trick us since the admin part loads a lot of external scripts and files - which in reality means; it's not really so small.

It's not meant to be a trick, as we explicitly state them in the readme (https://github.com/WonderCMS/wondercms? ... ies-used-3).

The un-minified files can be found here: https://github.com/WonderCMS/wondercms-cdn-files
The admin css file takes care of the modal styling, and the admin js takes care of the editing.

The main purpose of these files was:
- loading from CDN's
- to always enable us to update them within the index.php file
- always push only updates to the index.php file, everything else being supported by users (themes/pluugins).

The third library is for the default (HTML editor), which gives the user the ability to use tabs, like in a regular text editor.

I am really personally all for forking, creating PR's and generally improving the web. On this note, one of the most notable forks is called BoidCMS: https://github.com/BoidCMS/BoidCMS

I hope it's clear what we're trying to do - it's not for us personally maintain a million themes/plugins (those should be mainly coming from awesome devs). In an ideal world, users would be opening PR's for those and we would be happily accepting them after reviews. Any PR's for generally improving the WonderCMS core are welcome as well.

Regarding Summernote being the only included editor, it's the only one that was contributed by the community. If any new editor was suggested and coded, we would happily include it as well. We used to have an markdown editor, however it no longer works.

On the topic of a larger database.js and it slowing down the site, we extensively tested it with huge databases and it worked pretty fine. I couldn't find a hiccup on it personally.

Having WonderCMS load pages separately instead of from one database.js file -> this was how the first versions of WonderCMS initially worked. After feedback and iterations, we found that a single file worked best. This could be modified with a fork, but it would take some medium lifting.