Admin panel and Grav viability for content focused project

Archive
1

Hi all. I’m looking at Grav as a viable option for a small business project. initial plan was a static site generator but client worked previosly with Wordpress and wants fuller admin control. I’ve worked with the big 3 CMS systems and interested now in less bloated options for small projects (also looked at Processwire). I am adament not to just opt for WP as I do not believe it is right for this type of project long-term (and looking for solution as model for similar site development).

Grav’s flat-file approach looks great but my main worry is that the Admin side seems to be an afterthought. It’s not core, not wysiwyg, and on a free / paid model (which can mean free gets less attention and important features end up in paid version). Not saying the devs shouldn’t make money, I just come from the full-on CMS world with admin included, so it’s not been a cost consideration before (and I only get small business projects, my preference, by not charging a lot).

So t o those who’ve taken a similar journey, is Grav viable for an admin based CMS for non data heavy, content focused site, where the user is familiar with WP and keen on admin access and control?

2

TrilbyMedia, who consists of the core team, does do paid development for Grav. As I see it, Admin is anything but an afterthought. It integrates heavily into every aspect of Grav and manages absolutely every aspect of content, settings, themes, and plugins without being a burden. It is a great feature, however, that the Admin-interface can entirely be decoupled from the rest of the Grav-environment.

The issue of a true WYSIWYG-editor has been discussed many times, the hindrance is that no such editor is available as a stable, well-maintained layer that can be integrated to replace the current hybrid, WYSIWYM-editor. More solutions are popping up, like integration with StackEdit and other editors, but there are preciously few true WYSIWYG-editors for Markdown available (Typora is an example, but not open source) - and interpreting messy HTML misses the whole point of Markdown.

For a small site, where the owner will manage virtually everything himself, the Grav Admin-plugin will suffice. A few improvements in the ACL and user-scope might be desired, or just the instructi on “don’t fiddle with the settings unknowingly”, but it allows very easy and intuitive management of content. Getting used to editing Markdown in the hybrid-mode is not much of a bother for end-users, if anything it makes formatting more explicit and assuring than pure WYSIWYG-editors.

3

What a thoughtful and comprehensive reply. Thank you.

The difficultly I see with non-WYSIWYG is the WP influence. I face a constant battle with small business clients to give what I believe is the best option for them (which most of the time is not Drupal, Joomla or Wordpress due to infrequent contents updates and need to focus on their business rather than having too much control (temptation), complicated administration and constant eye on updates and security. In my opinion, better they pay maintenance to improve and market the site rather than keep it updated).

I guess I am asking for too much for free. My concern is how development will be split with the Admin panel (which would always be a necessity for me), and whether I should consider Grav a commercial package (Grav + Paid Admin).

Still you’ve given me something to explore with StackEdit. I hadn’t thought of that. I might see if a combination of Admin panel and some service like that can fill a gap

4

Currently, Admin Pro (paid version of Admin with some more advanced features) does not exist yet, and it’s still in development. We are not keeping important features away from “regular” Admin because of that. Pro will be more focused towards site builders that want to “hand off” a site to a less tecnical end user, with white label, full interface customization and branding. It’s surely not mandatory, and you can integrate your own features on top of Admin, already, by building plugins that provide additional panels.

WYSIWYG - the main problem, which is not resolved anywhere as far as we know, is integrating the Markdown-powered pages with a WYSIWYG editor that defaults to use HTML, as there do not exist yet a reliable WYSIWYG that saves to markdown.
You’d end up with some Frankenstein-style pages, or even worse sacrifice the use of markdown and all our powerful actions and plugins that are based on it. It’s not that we are keeping WYSIWYG for Pro, but that currently there is no solution for this problem except writing the editor ourselves, which is not a quick task, but maybe it will be what we need to do.

StackEdit is not solving any problem, really, as it’s exactly like the Grav editor, only with the preview in the right column.

5

@flaviocopes I follow the development of the Admin Pro plugin for a long time. Actually, I don’t understand the problem or don’t know the use case @rhukster is dreaming of. For a simple conversion HTML <-> Markdown there already exists a lot of ready-made PHP packages. Even if one decides to write one own, it is not that difficult. The direction Markdown -> HTML is already there and for the opposite direction one just have to write a plug-able parser. I already did that once.

But as I said, I don’t know the use case. Maybe you can elaborate on that @flaviocopes or @rhukster (may be better in a separate Thread?).

Kind regards,
Sommerregen

6

Of course Markdown -> HTML is what every markdown library does, including parsedown which we use in Grav. This is not the issue. The problem is that there is no good WYSIWYG editors in markdown that reliably save as markdown.

HTML -> Markdown however, is very hard to do properly, and no editor or library is doing it ‘safely’…

Pretty much every WYSIWYG that gets mentioned is simply an HTML editor, the ‘raw’ format is HTML, that is what gets saved. For Grav this is less than ideal, because we feel markdown is a better format for writing content. WYSIWYG Editors that purport to support markdown run through a very simplistic parser where if something has a direct match to markdown (eg link, strong, italic, headers, etc), that gets converted to markdown, and everything else is thrown away.

With the code-style editor we have now in Grav admin, you can put markdown, twig, shortcodes, and even mix that with HTML where you need it. Anything that was not pure markdown (common mark usually), is lost, as in gone forever! This is a dangerous scenario for any Grav users that has a site they are happy with, installs WYSIWYG editor, saves, and now has a bunch of content just missing, or the page is left broken simply because the editor didn’t know how to parse something to markdown.

Even the cutting edge WYWIWM editors (notice the trailing M) like ProseMirror don’t solve this problem. So there is really no way to keep the power we have already when you implement a WYSIWYG editor that saves as markdown.

The only alternative we have at this point is to simply store the content as HTML after you use an editor of this type. That way extra HTML is usually not visualized, but it’s not lost either. Of course this means that your Markdown content is then left as HTML, and you pretty much have to use the WYSIWYG editor from this point on or you will be left editing ugly HTML.

The other downside of this was the loss of important core Grav functionality like the media manipulation, link translation etc. We have moved these out of the Parsedown extension we had originally, so we have opened up the possibility to enable these in a sufficiently extensible WYSIWG editor via an Ajax call. But other plugins that provide markdown extensions are simply going to be unusable.

If anyone has a better idea or can prototype a decent solution, i’m all ears! :slight_smile:

7

@rhukster I think it is better to chat with you :slight_smile:

8

Chats are great but if we want to discuss this subject, which is quite fundamental and (thus) keeps popping up every once in a while, this forum is still the best we have and the best place to do so. Or is it better to to so in an issue on GitHub?