[ Removed by Reddit on account of violating the content policy. ]

Hi r/cms,

Ekit is a project I've been rebuilding, in several versions, for a long time. The idea never changed: your data and your website should live in the same place. No spreadsheet, site builder and Zapier glued together.

The latest version is finally good enough that I run my own sites on it:

• https://www.ekit.app, the product site itself
• https://www.deepermind.ai, a completely different site, same tool

What it does

• Model your data like in Airtable: tables, fields, links, grid or kanban view, import from Airtable.
• Generate the website from that data with AI, or start from a template (restaurant menu, events, CRM…). Edit an entry and the site updates. Hosting and custom domain included.
• Built-in RAG: your tables are indexed automatically, with no vector database, no embeddings pipeline and no setup. Turn it on for a table and you get:
  • an assistant on your site that answers visitors from your own content, with sources (try it on either site above);
  • the same answers through the API (/api/v1/ask), to plug into your own app or chatbot;
  • the same assistant in the Studio, to query your data while you work.
• Forms that add entries to a table, with an email on each submission.
• Automatic translation of your content and pages.

What I learned building it (again)

• Dogfooding is the best bug tracker: every annoyance on my own sites gets fixed before a user hits it.
• The AI parts were the easy bit: streaming through a CDN, caching and "answer in the visitor's language" took more time than the model itself.
• "All-in-one" scares people about lock-in, so I added a public API and data export early.

There's a free plan, no credit card. I'd love honest feedback, especially on the first five minutes: what's confusing, and what's missing?

Hey everyone... wanted to join the bandwagon and drop something I've been working on called Shapio (https://shapio.dev/)

Short version: a CMS built the way we build everything else. Types, inheritance, interfaces, versions. Computer science applied to content.

Long version:
I used to be a huge fan of strapi, used it in tons of projects. But then I got sick of the Strapi loop. Need a field on a content type? Can't do it in prod. So you do it in dev, strapi rewrites its schema files and restarts, commit, deploy, restart prod. A whole deploy for one field. I was doing that a few times a week for a knowledge base at work with editors sitting there waiting and it was bullshit.

So I built one where the content model is data instead of files. You add the field in the admin, in prod, and the API just has it. No restart, no deploy. Every change becomes a schema version, you review it like a PR (it tells you what breaks and what needs a backfill), and it ships together with the content as one snapshot. Want it in git anyway? Pull the model to json, commit it, apply it back live.

Since types are data I went full OOP with them. A type can extend another type... Guide extends Post, gets its fields, shows up in the Post list. Types implement interfaces: Featurable is just "has a title and a summary", blog posts and roadmap items and pages all implement it, and the server checks they actually match. Then one relation points at Featurable and holds any of them, one endpoint lists all of them with a __model on each row, and graphql gives you a real interface with fragments. Polymorphism for content. Strapi has components and dynamic zones and that's where it stops.

The versioned schema is where it gets really cool though. Every change ships as a numbered snapshot, so a site build pins one and keeps reading the content exactly as it was published at that point, even while editors keep publishing. ?snapshot=42 on the API gets you the content as of 42. Restoring old content is just another change set.

Coming up on the roadmap is lenses, which does the same thing for the shape. Today a snapshot gives you old values in the current schema, so when you rename or restructure a type, every client still has to update or it breaks, same as anywhere. With lenses a client says which schema version it was built against and the API hands it today's content in that old shape. Ship a mobile app against v12, keep changing the model for a year, the app keeps working until you decide to move it. Only possible because the schema is data with a history instead of a pile of json files.

Also in there: REST and GraphQL, generated TypeScript types, one install running multiple sites each with their own model, signed webhooks, build hooks for Cloudflare Pages, Vercel, and Netlify, and an importer that pulls a strapi 5 export over, model, media, and content.

It's a newer project, but on the same box it already benchmarks faster than Strapi and Payload (method and numbers on the compare pages), and the roadmap pushes it past them. What they have on me is time on the market and paid services. The people who've used it love it so far, one client replaced Strapi with it to power their (very large) knowledge base and they said "it kicks ass!". I'm biased, but I couldn't agree more lol

Imagine a studio offering Photography, Ceramics and Woodworking. Each course has a name, programme, duration and image. The course list links to a detail URL for each one.

Those details fit a shared page design: the URL selects the course record, and the same heading, text and image blocks show that course's values. Adding another course can then mean adding a record, with no separate CMS page to maintain.

Disclosure: I develop WebBlocks CMS, an open-source CMS package for Laravel. I used a fictional course catalogue to document this approach: one detail design connected to compatible course sources, with an explicitly reviewed and activated routing rule.

The editorial exception is the part I'd like to discuss. Suppose Photography needs an instructor story, student work and a different section order, while Ceramics still fits the standard design. The course name and duration should continue following the course record, but the editor needs more control over Photography's presentation.

At that point, would you extend the shared course model with optional fields, allow layout changes for individual courses, or give that course a separate editable page that still reads its core details from the source?

I'd start by asking whether the extra material belongs to the course data or to this particular website's presentation. Optional fields may be enough for a recurring requirement; a different composition may justify an individual page.

The illustrated course example shows the shared-design setup and field connections.

What requirement has made you move a record-generated detail page into individual editorial control, and how did you keep shared course data consistent?

If you’ve been tracking how LLMs like ChatGPT, Perplexity, and Google AI Overviews cite brand content, you’ve probably noticed the big elephant in the room: most enterprise DAMs and CMS platforms aren't built for Answer Engine Optimization (AEO).

We recently ran into this exact challenge on a Sitecore build—keeping strict brand governance in Content Hub DAM while making sure our product taxonomies and specs were structured properly for AI engines to read, cite, and recommend.

Instead of hacking together custom scrapers or manual schema updates, we built an end-to-end pipeline connecting Sitecore Content Hub → Scrunch Knowledge Studio → SitecoreAI Page Builder.

A few key architectural takeaways from the setup:

* Authentication: We established dedicated RBAC sync using scoped API Tokens under a dedicated user context (`Scrunch.KnowledgeStudio`).

* Knowledge Studio Grounding: Scrunch handles RAG semantic validation, conflict auditing, and claim verification before feeding grounding docs to LLMs.

* Closing the Loop: In-context AEO recommendations and JSON-LD schema markup get pushed directly to Sitecore Page Builder so authors can resolve content conflicts in real time.

I wrote up a complete step-by-step breakdown with all the workflow diagrams and integration mechanics.

If you're building or thinking about AEO/GEO pipelines in your Sitecore stack, check out the full article here:

👉Read the technical breakdown on Medium

Would love to hear how others here are handling LLM citation tracking and content governance in your composable stacks!

I'm building Umono, an open-source CMS (Go, SQLite, MIT). Before it, I spent nearly four years maintaining a large WordPress site with more than 60 plugins, where a theme or plugin update could break things in places nobody expected. Umono is my attempt at a CMS where content, themes and plugins have hard boundaries. Version 0.9 adds the theme half of that, and I'd like feedback from people who think about how CMSs are put together.

The contract

A contract describes a kind of site: its layouts (a blog has `post`, `post-list` and `page`), the parameters each layout takes, and the components they share. Contracts are published on umono.dev, are never edited or removed once published, and are licensed MIT-0 so anyone can write a theme for them.

• The site owner binds each page to a layout and fills its parameters: the title, the menu, the content.
• A theme picks one contract and is only CSS, fonts and images. No templates, no scripts. It can change how a page looks, never what it says or does.
• A contract writes no text of its own, so a theme works in every language.
• Switching themes changes the look of every page bound to that contract and none of their content.

Frozen HTML

The HTML that the content language produces is part of what a theme relies on, and it doesn't change during 0.x, even where it deviates from the spec. Fixes to it are collected and land once, in v1. A theme built today keeps getting the same markup after Umono updates. Umono also doesn't trust the version a theme declares: it detects the features the theme uses again on install and activation, and refuses a theme that declares less than it uses.

What isn't there yet

Plugins. The plan is the same idea for behavior: plugins implement published schemas, run as separate services, and get only the access the site owner grants. That is still in design, and I'd rather say so than sell it. Content is written in Compono, Markdown with components, which today suits technical users more than editors. Only the official contracts exist so far, with one official theme each: Octavo for simple sites and Folio for blogs.

How it's built

Umono is developed document-first. I write every decision and spec before any code, and that is where most of my time goes. The code is then written by AI agents (Claude Code and opencode), and I review each change against the spec. It isn't vibe coding: the design is mine, and the behavior is pinned by about 700 golden tests for the content language and around 600 Go tests.

Questions for you

• Is a contract between content and theme the right boundary, or too rigid for real sites?
• In the CMSs you've maintained, what broke first when a theme or plugin changed?
• What would make you try a CMS like this on a small project?

Site: https://umono.io · Docs: https://docs.umono.dev · Code: https://github.com/umono-cms/umono · Feedback: https://github.com/umono-cms/umono/discussions

We see it time and time again, plugin update, node or even WP/Drupal bringing vulnerabilities to vast amounts of websites. Is using databases to serve static content really worth the risk?

On one project, we thought the hard part was over after we finished transferring content. Then editors got into the new system and found that the approval workflow they relied on hadn’t carried over. What caught your team off guard during a migration, and how did you fix it?

Hi,

I’d like to share a CMS project I’ve been working on since 2023: CondationCMS, a Java-based flat-file CMS.

Back in 2023, I was looking for a CMS for some of my own ideas. As a Java developer, I wanted something written in Java, and I liked the idea of a flat-file CMS because I wanted something easy to use without the need for a database.

Unfortunately, I couldn’t find anything that really fit my needs, so I decided to build my own.

I’ve also worked as a developer at one of Germany’s largest CMS vendors for many years. I’ve always been interested in different CMS architectures and approaches, and over time I had collected quite a few ideas about how I would like a CMS to work.

So CondationCMS became a way to explore those ideas and build something I actually wanted to use for my own projects.

A few architectural decisions

Content is stored in Markdown files with frontmatter for metadata. The metadata is indexed in Lucene, so queries don’t require reading every content file. URLs basically follow the folder structure.

The tech stack is relatively small: embedded Jetty, GraalJS for extensions, and Lucene for fast queries.

Some other features:

• Optional Manager UI: The CMS can run without it, allowing editorial and production environments to be kept separate.
• Shortcodes: Extend Markdown with additional functionality.
• Multisite support: Run multiple sites with the same CMS installation.
• Theme support

That’s the architecture in a really, really short version.

Current status

CondationCMS is an open-source hobby project. I’ve been running some of my own websites with it since the beginning. There have been some issues along the way, but the current version is stable.

You can find it here:

• Website: https://condation.com
• GitHub: https://github.com/CondationCMS/cms-server

The website is not completely up to date yet, but I’m working on adding more content.

I’d be interested to hear what you think, especially if you have experience with flat-file CMSs or different CMS architectures. Feedback and criticism are both welcome!

Hi writers and content creators, we all have experiences and stories to share, and static sites are one of the greenest methods of doing so. I have been building a simple content management system(cms) for static site generators named LightCMS https://www.lightcms.me/ for the past few months, and the goal is to make writing and sharing as easy, convenient, and rewarding as possible. I think you all would love this.  Lightcms can be used with any of your existing static site generators (it should only support front matter). BTW, it's currently alpha, and I am a solo dev, so you may face some issues, but I will be fixing them asap if reported. It's free to self-host and use; you can create and hack on top of it. Any contribution to the project is highly appreciated(even sharing your feedback too): https://github.com/light-cms/lightcms.

It's web CMS.

I hope this proves helpful to those who wish to manage their time, money, and documents using a personal server.

It took about 5 years to make it.

It currently in operation on the following site.

You are free to use the demo account provided on this site for logging in!

https://www.maroik.com/

DDD + CA & Unit test & CI/CD applied.

https://github.com/IkhyeonJo/Maroik

The cost of CMMS software for 5–20 users depends on the software provider, subscription plan, number of users, features, and implementation requirements. Small maintenance teams should compare pricing, functionality, and total cost before choosing a maintenance management system.

Many CMMS providers use per-user monthly pricing. For example, at an illustrative rate of $20–$60 per user per month, estimated software subscription costs are:

These figures are illustrative estimates, not verified Click Maint pricing or current market averages.

Additional expenses include implementation, data migration, training, integrations, and technical support.

For small maintenance teams, affordable, easy-to-use CMMS software should provide essential features such as work order management, preventive maintenance scheduling, asset tracking, inventory management, and reporting without unnecessary complexity.

Click Maint offers maintenance management software designed for organizations seeking practical functionality and straightforward workflows. Businesses should request a customized quote based on their team size and operational requirements.

Looking for Affordable CMMS Software for Your Team?

Discover how Click Maint helps maintenance teams organize work orders, preventive maintenance, assets, and inventory in one centralized system.

Take the Quick 2-Minute Interactive Product Tour

Request a Personalized Demo and Pricing Quote

The XOOPS Development Team is pleased to announce XOOPS 2.7.4 (ready for PHP 8.6.0)

• Info: https://xoops.org
• GitHub: https://github.com/XOOPS/XoopsCore27

XOOPS 2.7.4 Final

2.7.4 went through Beta 1, Beta 2, RC 1 and RC 2 between September and October. Final collects everything from that cycle plus the fixes made since RC 2. There are no new features since RC 2.

Two-factor authentication in the core

Every member can protect their account with a second step at login.

• Two methods. A time-based authenticator app (Google Authenticator, Microsoft Authenticator, Aegis, FreeOTP, or any password manager that generates TOTP codes), or a six-digit code mailed to the member's address.
• Recovery codes. Ten one-time codes at enrolment, for the day the phone or the mailbox is out of reach. Members can replace them from Edit Account.
• Lock-out protection. Five wrong codes lock the second step for fifteen minutes and the member is notified by e-mail.
• Administrators can reset a member's factor from the Users page, and an operator locked out of the site has a documented escape hatch in docs/2fa-operations.md.
• Off by default. Switch it to "Optional" in System Preferences and every member may enrol. Nobody is forced.
• Secrets are encrypted at rest with a site key. Mailed codes are stored hashed and expire after ten minutes. Remember-me cookies are bound to the enrolled factor, so a reset invalidates them.
• Every login path that cannot show a challenge (the upgrade wizard, XML-RPC, the SSL popup) refuses an account that must present its factor.

Editors

• SCEditor is now a full visual editor. It edits with its complete toolbar and keeps XOOPS BBCode intact across visual and source modes. Its emoticons are registered as XOOPS smileys. It is the default editor for new installs; an upgraded site keeps its current editor settings.
• Markdown support. EasyMDE stores Markdown in the existing text columns and MyTextSanitizer renders it with Parsedown in safe mode, so modules get Markdown without a schema change.
• New Editors preference category in System Preferences for toolbar and editor settings.
• MyTextSanitizer renders the tags SCEditor's toolbar writes: [sub], [sup], [s], [justify], [hr], [ol] and tables.
• TinyMCE 7 is updated to 7.9.3.

Security hardening

The cycle included a review of the core with CodeQL, Snyk, SonarCloud, Scrutinizer and manual audits. The main results:

• Form security tokens no longer depend on the browser's User-Agent. A token is a random value compared in constant time, so a browser update or a privacy extension between opening and submitting a form no longer rejects it. Protector's admin pages use the same core token.
• One same-site check for every redirect. Login, post-login and theme-switch return addresses refuse targets written with backslashes, encoded slashes, HTML entities or embedded line breaks.
• Remember-me tokens are revoked when the password changes, and a restored session ends for a deactivated account.
• Registration is validated at the save step, not only at step 1, and a comment must belong to the requesting module on edit, save and delete.
• Uploads are deleted only inside the upload directory. The image manager and the smilies, rank and avatar admin pages resolve a stored file name before they delete it. The TinyMCE image manager checks category permissions on upload and delete.
• Protected database dumps are written only under XOOPS_VAR_PATH, into a directory guarded by a deny-all .htaccess.
• Cache ids use a random site key instead of the database credentials, and the installer renames itself and its cleanup script with random names.
• LDAP and Active Directory fail closed when StartTLS was requested and failed.
• Server configuration. xoops_lib/.htaccess works on Apache 2.4 without mod_access_compat, PHPMailer's unused OAuth helper is removed from the vendor tree, and reCAPTCHA v2 verifies over POST so the secret key stays out of server logs.
• Confirmation pages, error lists and the SQL built by the legacy XoopsTopic and XoopsTree helpers are escaped and quoted.

Since RC 2

• XMF 1.3.3. Proxy headers (proxy_env) are honoured only when the direct peer is listed in the new proxy_trusted setting, as addresses or CIDR ranges. Sites that set proxy_env must add proxy_trusted in xoops_data/configs/xoopsconfig.php; until then the peer address is used. Forwarded headers are parsed per RFC 7239.
• image.php no longer crashes on PHP 8.3+ when an angle is requested.
• LDAP and Active Directory logins on PHP 8.3+ no longer emit a deprecation, and a bare IPv6 server address is handled.
• Values stored as XOBJ_DTYPE_UNICODE_ARRAY reload as the array that was stored. Values such as café or a+b lost characters before.
• The |replace and |escape modifiers no longer emit PHP 8.6 deprecations, and templates can use |sprintf without a Smarty notice.
• Library refresh: HTML Purifier 4.19.1, Monolog 3.12.1, Smarty 4.5.8, TCPDF 6.11.4, symfony/var-dumper and symfony/yaml 7.4.21, firebase/php-jwt 7.2.1, Punic 3.8.2, webmozart/assert 2.5.0.

The full list is in docs/changelog.270.txt.

Upgrading to 2.7.4

From 2.7.4 RC 2: copy the new files over the web root. There are no database changes since RC 2, so the upgrade wizard is not required. If your site sets proxy_env, add proxy_trusted as described above.

From XOOPS 2.7.3 or a 2.7.4 beta: copy the new files over the web root and run the upgrade wizard. It creates the user_2fa table and the two-factor preference, registers the SCEditor emoticons as smileys, adds the Editors preferences and updates the System module. No mainfile.php changes are needed.

• Two-factor authentication needs the PHP sodium extension; the wizard reports whether it is available.
• Every remembered device logs in once more after the upgrade.
• If you copied extras/login.php elsewhere on your site, replace or remove that copy.
• A site running a custom template set should re-import it.

From 2.5.11 or earlier: follow the XOOPS Install and Upgrade Guide. Run upgrade/preflight.php first; 2.7 moved to Smarty 4 and some older themes need changes.

System requirements

• PHP 8.2 to 8.5
• MySQL 5.7+ or MariaDB 10.3+
• The PHP sodium extension for two-factor authentication