Hello everyone,
I’d like to introduce a project I’ve been working on over the past few months and have also been using in various ways for some time now. It’s called “NUR CMS”—“NUR” simply means “only.”
Since there are already quite a few Rust-based CMSs out there, you’ll have to decide for yourselves whether this one is really worthwhile; I can’t say at this point which one is objectively the best.
I’ve tried to make the project as modular as possible, which means that NUR CMS can also be integrated as a library and has its own “migration table name.” I’d like to take this opportunity to thank the SQLX developers who made this possible in version 0.9.
I see three possible scenarios for NUR CMS:
Use it as-is, with the admin panel and various API endpoints.
Use it in your Rust headless project, create your own migrations, and extend the admin area as you see fit.
Use the admin area for content management and render the HTML directly in the backend using Handlebars or something similar.
The API itself has three different output modes: it can output content as Markdown, as HTML, and as AST (JSON).
In addition, you can specify in the settings what resolutions uploaded images should have. These images are then created accordingly and also saved as AVIF and WebP files.
Content is edited in the admin panel using Markdown; on desktops, there’s also a preview feature.
The current drawbacks are:
The documentation is currently very poor.
Although the project is open source, due to my negative experiences with open-source projects in recent years, there is currently no support via issues or discussion forums.
I added some new features. The most important ones are:
The admin frontend can now be customized more. This means that inputs and other fields can be hidden, data templates can have type support, and a title and logo can be set.
Public routes are now cached with Moka. The lifetime is configurable; however, when the content changes, the cache will be invalidated.
It is now possible to use WASM plugins. Plugins can have routes if configured root routes are allowed. Plugins can also have their own database migrations. If a plugin needs its own tables, they are created in their own schema. You can also extend the admin frontend with menu items and views. Frontend extensions are based on web components.
since you don't allow questions via GitHub, i'll ask a couple of ones here and you can tell me if you prefer a more appropriate channel.
first of all, congratulations on implementing Plugins via WASM WASI P2! i'm in the process of putting the final touches w/ something much more modest for my server. wish i knew about your project much earlier. your PluginManager is a little beauty!
i couldn't find any crates on crates.io for your server or plugins. only full fledged distro packages; e.g. RPMs, etc... can you confirm you're not publishing your crates to crates.io? if yes, any particular reason you'd like to share?
the http server seems to be axum, i use another framework. while every framework has its own "ways" of doing things especially for wiring middleware, do you have a document/note that details the "requirements" for other than axum http server Rust framework to adopt/implement your concepts + ideas?
Hello @rsn, I'm glad you like the project! Maybe I'll address the issues at a later time.
As for your questions:
I don't have experience publishing on crates.io; that's the only reason I haven't done it yet. However, my research indicates that the project is not ready for that yet.
The core is also deeply intertwined with Axum. The plugin crate is almost agnostic. I could see making the core and plugin system web framework agnostic, with only the app building with Axum. However, that will take some time.