From @padraicbc

A lot of files are getting rebuilt each time outside of the one actually saved/changed so it may be worth looking at incremental changes based on actual files with new content. That will reduce build times in production especially with large sites.

https://github.com/zeit/pkg

Should:

• [x] Not require devs to have nodejs installed on their computer
• [x] Not require internet access to start new project (currently runs npm install)
• [ ] Still be extensible via NPM
• [x] Still allow custom Gopack package to create web_modules for ESM

I'm putting this issue here as a placeholder for when someone inevitable hits it. In release v0.2.39 we modified the svelte node_module in order to work with plenti's new hydration setup. You need that modified version in order to have things work properly.

What you may experience: On the initial page load, when plenti tries to hydrate the static HTML, some of the content will be removed. Then if you try to navigate to other pages, the navbar will remain but all the content will be gone.

What is causing this: This is happening because we're trying to hydrate the document which isn't currently supported by Svelte. You're likely using the standard version of Svelte because you ran an npm update or something similar. If you're using the modified node_modules/svelte/internal/index.mjs that ships with Plenti, you should not experience this issue.

Long-term fix: You will continue to hit this if you try to update Svelte to a newer version using NPM because the standard lib does not have the fix. We have an open issue to discuss this with the maintainers, so hopefully future versions will accommodate this: https://github.com/sveltejs/svelte/issues/5547. If the proposal is rejected I will have to create a custom injection (likely in cmd/gopack.go or cmd/npm_defaults.go) to add this, but it's not ideal given changing versions of svelte.

Here are the console errors you will see:

• Firefox: DOMException: Node.insertBefore: Cannot have more than one Element child of a Document
• Chrome: DOMException: Failed to execute 'insertBefore' on 'Node': Only one element on document allowed.

Loading a site results in a flash of content and thereby a bad cumulative layout shift. I suspect the hydration to be responsible for that.

Edit: See the second screenshot in Lighthouse where the content is gone

Picking up the discussion on themes started here: https://github.com/plentico/plenti/issues/19

It would be nice to have a command for adding themes, for example: plenti new theme [email protected]:jimafisk/my-theme.git. This should download the git repo into a themes/ folder and could even make an entry in plenti.json in order to keep track of what theme is currently being used + could allow checking for updates on the remote repo.

Maybe also add a flag to the new site command, e.g. plenti new site MY_SITE --theme=REPO.git. This should run the --bare flag in the background.

When I run plenti new site my-site [email protected]:plenti-themes/bigspring it throws:

022/03/18 17:20:07 errs.go:57: Can't clone theme repository: unable to find any valid known_hosts file, set SSH_KNOWN_HOSTS env variable
unable to find any valid known_hosts file, set SSH_KNOWN_HOSTS env variable (File: /home/runner/work/plenti/plenti/cmd/theme_add.go, Line: 75)
2022/03/18 17:20:07 errs.go:57: Can't get HEAD: reference not found
reference not found (File: /home/runner/work/plenti/plenti/cmd/theme_add.go, Line: 84)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x985965]

goroutine 1 [running]:
github.com/go-git/go-git/v5/plumbing.(*Reference).Hash(...)
	/home/runner/go/pkg/mod/github.com/go-git/go-git/[email protected]/plumbing/reference.go:183
github.com/plentico/plenti/cmd.getCommitHash(0xc0001a9c80, 0x18, 0x7fff9711615f)
	/home/runner/work/plenti/plenti/cmd/theme_add.go:87 +0x125
github.com/plentico/plenti/cmd.glob..func6(0x2404c00, 0xc00007d6c0, 0x1, 0x2)
	/home/runner/work/plenti/plenti/cmd/site.go:103 +0x4b8
github.com/spf13/cobra.(*Command).execute(0x2404c00, 0xc00007d6a0, 0x2, 0x2, 0x2404c00, 0xc00007d6a0)
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:856 +0x2c2
github.com/spf13/cobra.(*Command).ExecuteC(0x2404700, 0xc000000180, 0x200000003, 0xc000000180)
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:960 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:897
github.com/plentico/plenti/cmd.Execute()
	/home/runner/work/plenti/plenti/cmd/root.go:58 +0x31
main.main()
	/home/runner/work/plenti/plenti/main.go:7 +0x25

I thought it might be because I didn't have an SSH key uploaded to GitHub, but the problem still persists even after adding it.

Possibly related to https://github.com/src-d/go-git/issues/454

@brikou's first impression of lack of hot reloading:

I've updated foo/layout/content/index.svelte to see a change... but I miss hot reload. Let's hit F5. Ok it is updated :). Maybe I can use snowpack to act as a proxy to enable hot reload

I expect others feel the same way. It might be difficult with Plenti's custom architecture to rig this up yourself with snowpack, but if anyone knows how to do it, I'd love to hear about it. This is something I'd like to see in the project eventually, but it's low on my priority list at the moment.

From the docs

We also use a simple JSON data source instead of markdown, because we don't intend for you to edit content directly through files.

Does that mean there will not be one?

Error messages could be substantially improved.

Generally, there is reference to where the error occurred - ie which component

In addition, sometimes errors are reported and they are not valid. For example: Can't render htmlComponent: ReferenceError: layout_components_Led_svelteMatrix is not defined Can't render htmlComponent: ReferenceError: layout_components_Led_svelteMatrix is not defined Total build took 475.769705ms

I have a LedMatrix.svelte file in my project (why is it reference in the error) and I can make changes to that file, it compiles fine and is used with the changes reflected in the browser

I included all the components in the components folder. (it is not pretty yet... just working on functionality)

components.zip

We're still relying on a quick fix during the SSR'ing of cmd/build/client.go to change variables into a component signature that can be reliably referenced by other components: https://github.com/plentico/plenti/blob/6312546fc31615396dcd51fab6acaec2e3b47230/cmd/build/client.go#L152

The problem is, we're assuming that everything with the original variable name and space on either side of it is a reference to that original variable. However, there could simply be other strings with the same text that shouldn't be replaced. A good example came to light when looking into stores. The variable name in the example is count but the title where it's displayed also contains the text "count." When the page hydrates, the client display looks fine:

...but if JS is disabled (or still loading) it's not:

We should use regex to make this replacement more precise and avoid these accidental string changes.

While working on adding the git-cms, I noticed that named imports don't always work. For example, the following breaks the build:

import { requestAuthCode, requestAccessToken, requestRefreshToken } from './cms/auth.svelte';

Error message: javascript stack trace: SyntaxError: Cannot use import statement outside a module

But if you reorganize it differently, it works fine:

import { requestAuthCode, requestAccessToken } from './cms/auth.svelte';
import { requestRefreshToken } from './cms/auth.svelte';

The problem appears to be that during the build if this gets too long it gets converted to a multiline import:

This seems to be happening somewhere around: https://github.com/plentico/plenti/blob/0a14d97a01182f9a3f5948a872e58196c7cb862c/cmd/build/compile.go#L173

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:

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

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?

Currently in the CMS we apply a simple rich text editing experience if the JSON value of a content source appears to be:

• A simple string (as opposed to a date or asset)
• Is over a certain length to distinguish from a plain text value, which is often used for titles (current threshold is 50 characters)

This has two fundamental problems:

1. If you delete enough text from a WYSIWYG field it will convert to plain text and if you add too many characters to a plain text field it will convert to a WYSIWYG field. This experience is jarring and happens often.
2. Since we're only considering the content source, and not how that content source is being rendered, we sometimes add a WYSIWYG editor to fields that are displayed only as plain text and vice versa. We should only apply WYSIWYG features when the field is being rendered with @html in a svelte template.

We probably should standardize these fields as well so they both use the same contenteditable element and somehow pull the info about how it's being rendered from the svelte template.

The discoverable CMS looks at the content source to provide a reasonable editing experience for users out-of-the-box without doing any special setup. However, there are going to be scenarios when a developer may want to override those defaults to provide a specific editing experience. They may also want to provide additional features that are difficult to discover from simple JSON:

• required fields
• select lists, multiselect lists, radio buttons, checkboxes
• autocomplete / entity reference
• text, number, boolean, date
• WYSIWYG (configurable options?)
• assets (image, doc)
• defined components (that aren't part of default content)

We should add an optional _schema.json file that lives inside Type folders (e.g. content/pages) that allows devs to do these overrides. This will require defining a specific API that must be followed. We could look to https://json-schema.org/ for inspiration.

Currently we have a workflow in the CMS where if you try to add a file with the same filename that already exists, instead of creating a new file it simply opens the editor on the existing file: https://youtu.be/57xwWZXMjvk?t=454

It's great that we're checking filenames before trying to create a duplicate, but it's so seamless that it might be confusing to folks who aren't aware that they're editing an existing file vs creating a new file.

When trying to save the filename, we could create a warning the says Content with this filename already exists (edit file) similar to what we discuss here: https://youtu.be/57xwWZXMjvk?t=503. That way the user has better awareness of what is happening and retains control over how to proceed (they might simply want to try a different filename).

mediaList should probably be changed to something like commitList since this object is not only used for managing assets like png and jpg, but also used for creating and editing page content (in JSON format).

The cms/publish.js file should probably become cms/gitlab_commit.js since it's specific to GitLab's commit API and can be used for creating, updating, and deleting. This will be different for other backends (like GitHub, Bitbucket, Gogs/Gitea and even the local workflow), so we need to think through reusing as many common features as possible and compartmentalizing the API differences.