primocms / builder Goto Github PK

I'm coming from primocms/primo#284 in look for the resizing bug.
I think it has something to do with HSplitPane.svelte as is bases on Readiz/svelte-split-pane and they've talked about this issue Readiz/svelte-split-pane#4

The thing is, there are 4 instances of HsplitPane, whit little to no changes so I'll keep looking. Maybe I'll try to reunify them and check the behaviour.

The SitePages Component allow creation of multiples pages with the same route
It might be needed to use validation during creation to avoid this behaviour,
https://github.com/primocms/builder/blob/main/src/lib/views/modal/SitePages/PageList/PageList.svelte

I'm sure anyone who spents a couple hours in primo server's source code can figure it out, but why not have a guide about it?

I was doing some dependency upgrades and stomped on svelte-undo:
The thing is, svelte-undo requires svelte ^3 as peer dependency so when upgrading to svelte 4 it throws me a warning, but then I went looking where this library was used and found that in fact it uses a physical copy of that enhanced with lodash.
I think that dependency is an orphan. I'll check later if is still needed in the current version, I have to many upgrades installed and I don't want to mislead the results.

I've been dying to add features to Primo like:

• more field types
• seo functionality
• ai integration (OpenAI API)
• font manager (with API support for Google/Adobe/My Fonts)
• file manager

But that's just my ideas and would probably bloat the project. Plugins is the way to go. There are some things we need to decide before moving forward:

Plugin Installation

It's pretty much standard that whoever uses Primo forks it first, that doesn't apply to the builder though. So the easy option to have each user add his plugin packages in his Primo fork means that whoever wants to use just the builder won't be able to use plugins. Forking both the builder and the server is pretty inconvenient IMHO.

My best idea is to standarise the naming of the plugins (e.g. primo-plugin-*) and have a prepare script that installs them via environment variables during deployment. OFC the plugins need to be published in npm.

Plugin Integration

Vite should handle importing the plugins at build time, I see no reason for using dynamic imports in the app code.

Integration Points

Register functions (or hooks if you're familiar with Wordpress) must be added throughout the codebase wherever we want that functionality extended. This WILL require some refactoring.

Plugin Structure & Documentation

It is very important to have clear guidelines on how a plugin should be written, what it can and cannot do. A skeleton plugin is a nice starting point for most people. Perhaps have different structure per plugin type, e.g.:

• Field Type
• Component
• Deployment target
• etc

Tests and error handling

People will write trash plugins, use same export names, or simply Primo updates might break them. We should force basic tests and give proper error descriptions. If we were to load the plugins dynamically during runtime we could also skip loading erroneous plugins, but I'm more of a fan of build time.

Hello, maybe this is an issue with the rollup browser or something with my configuration.
I downloaded and published primo to caprover with docker image. Any idea what this might be appreciated.

Cannot import "@iconify/svelte/dist/Icon.svelte": no matched export path was found in "pkg_name/package.json"