CMS Naming conflicts

[jimafisk]

While building out a few sites and testing the CMS on different Plenti themes I've noticed a couple of common naming conflicts with existing libraries and tools. I'm torn about this because Plenti is aimed at a simplified solution for folks who like to build things from scratch with less overhead so using the most logical names for things makes sense. On the other hand, avoiding the collisions might make things more simple for folks overall who are inevitably going to run into these conflicts.

Proposal 1: Rename magic prop user => editor The user variable is not surprisingly used in most example code for backend solutions. The Plenti CMS is not really set up to be a full database backend, it's aimed to be a content editing interface. Folks who want roles/permissions for access control will most likely turn to one of the popular backends (Supabase, NHost, StaticBackend, Userbase, PocketBase). You can rename destructured variables, for example user "member" instead of "user":

({ user: member, session, error } = await _supabase.auth.signUp({
  email: email,
  password: password,
}));

However, it may relieve some friction if we simply rename our magic prop from user to editor. This might even better describe the specific intention of the git-backed CMS workflow and signal that it's not meant for more robust user management. Would love to hear other folks thoughts on this.

Proposal 1: Rename class modal => plenti-modal Popular CSS frameworks like Bootstrap attach styles to common names for things, like modal for popup windows. We're trying to make our styles with as low specificity as possible (still have improvements to make there) so people could reskin the admin interface if they'd like, but that means our default styles often get overridden by heavy-handed frameworks. For example the Bigspring and Roxo themes suffered the same Bootstrap overrides for modal:

See media gallery screenshot


See creating content screenshot


The _reboot.scss file in bootstrap also does wonky things with fieldset elements and other aspects of the editing interface:

See fieldset screenshot


I'm not a huge fan of including libraries like Bootstrap, Zurb, or other frontend frameworks in general because IMO it's easier to write something specific from scratch than to add a huge codebase and painstaking peel back all the layers that aren't needed (usually by adding more specific overrides). So I could be convinced that we shouldn't work around other frameworks like this, but it might be easier for folks who inevitably use them. Thoughts?

[jamestagal]

Hi @jimafisk I think editor would work here because it does seems to describe the intentions of the git-backed CMS better i.e. having an editor role as opposed to user. And hyphenating both as in editing-user seems overkill. And I don't think other common role options would work like admin or creator because they don't align with the intention. But in the case of plenti-modal l like it! :) It nicely differentiates it from just modal as a plenti specific term.

Great work Jim.