No, your post is not a discussion, example after few words : " Existing modules will continue to work" Who decided that ? This décision would be an huge impact on the new structure of the Core. Kevin wrote: “One of the main problems today is that the XOOPS core hasn't kept up with the times.” It may therefore be better to rebuild a new core without the constraint of module compatibility, in order to achieve a high-performance kernel. I’m not saying that “modules won’t work in the new core”; I’m asking if it’s better to start from a new core. What is the impact of maintaining compatibility in the core if we want to achieve a high-performance core?
You have good ideas, but this lobbying with videos isn’t a discussion.
And I repeat: “Once the direction has been defined by the committee, we will look for solutions—in that order. ” Vision, direction… Choices, approved by the committee. Then the technical solution.
Before discussing new features, it is important to remember that the first step is to clarify the project governance. We believe a clear framework is necessary so that all future decisions are coordinated and consistent.
Following several recent issues regarding governance and coordination, we have initiated this discussion to clarify and improve how the project is managed.
The main points proposed are: - Establishment of a strategic committee to define and approve the overall XOOPS roadmap. - The committee will work collegially and appoint an operational project lead responsible for implementing decisions in the development branches. - Operational teams can work autonomously on features and PRs, while respecting the strategy defined by the committee.
For technical reasons, we have launched a vote by email among active project members to determine if they agree with the creation of this committee.
We have set a one-week deadline to gather opinions and avoid delaying the project.
We hope this discussion will be open and constructive:
Members can give their opinion on governance by a committee. Users and contributors can share their ideas and suggestions on XOOPS governance directly in this post.
Here we can discuss the future of XOOPS. In this thread, no lobbying, no endless videos, just a place for discussion where we talk about directions, strategies, and visions—and above all, not about solutions that have already been proposed, as is the case in another very recent thread. Discussion, direction, and above all, not SOLUTIONS!
Once the direction has been defined by the committee, we will look for solutions—in that order.
XOOPS 4.0 – Vision, Direction, and Roadmap (Discussion)
Over the past months, a significant amount of work has been done to move XOOPS forward in a practical and future-proof way. I’d like to consolidate that into a clear starting point for discussion, feedback, and alignment.
Core Principle: Evolution, not Revolution
XOOPS 4.0 is designed with one key goal:
Do not break existing modules and themes — extend them.
• Existing modules will continue to work • Developers can adopt new architecture incrementally • No forced rewrites or disruptive migrations
This follows XOOPS’ long-standing philosophy: stability + gradual evolution
2) XOOPS Business Objects (XBO) • Structured domain layer for module development • Encourages better separation of concerns • Works alongside XMF 2.0
3) XTF – XOOPS Theme Framework • Unified framework for frontend and admin UI • Eliminates duplication between themes • Built on modern standards (Bootstrap-based)
4) New Admin Theme (Modernized UI) • Built on XTF • Extends the “Modern” admin concept • Cleaner, consistent, and responsive UI
5) XMF Widgets System • Reusable UI components • Simplifies module and theme development • Foundation for more dynamic layouts
6) PageBuilder • Visual page composition • Flexible content layout system • Built on top of widgets and modern UI
8) Impact on Modules • Existing modules continue to work • New architecture available progressively • Developers can migrate at their own pace
Proposed Roadmap (for discussion)
2.7.x (LTS) • Stability and bug fixes only • Long-term support baseline
2.8.x (Optional Bridge) • Limited, well-scoped improvements • Preparation layer for future changes • No large architectural shifts
4.0 (Next Generation XOOPS)
Focus areas:
1. Modern architecture (XMF 2.0 + XBO) 2. Unified UI framework (XTF) 3. Improved developer experience 4. Backward compatibility with gradual migration path 5. New capabilities (Widgets, PageBuilder, etc.)
Vision overview:
Priorities (what makes the most sense next)
To keep things practical and aligned, here’s a suggested priority order:
1. Stabilize 2.7x as LTS 2. Define minimal scope for 2.7.1+ (if needed) 3. Release XOOPS 4.0 as pre-alpha for feedback 4. Document migration paths for modules/themes 5. Iterate based on real usage and community input
Discussion
To keep things transparent and accessible, let’s use this thread to discuss:
1. Introduction: The Death of the "Drafting" Phase
For years, web design has been haunted by a persistent shadow: the "gap." It is that frustrating space between a visionary design mockup and the technical reality of a live web page. Historically, moving from concept to a functional layout required a tedious cycle of drafting, coding, and debugging. Creative intent was often diluted by technical constraints, and the final product rarely felt as polished as the original vision because developers were forced to work with "placeholder" boxes rather than the final, realistic content.
The coming soon XOOPS 4.0 PageBuilder arrives as the definitive bridge across this gap. By shifting the focus from manual coding to visual assembly, it allows creators to manifest their ideas in real-time. It transforms the web development process from a static drafting phase into a dynamic, living environment where the final product is shaped as quickly as you can imagine it. You are no longer looking at abstractions; you are building the actual site from minute one. The philosophy behind this tool is simple yet transformative: Build beautiful pages with XTF themes and XMF widgets — no coding required. By combining pre-styled themes with a robust catalog of XMF widgets—including immersive heroes, feature grids, and complex pricing tables—the XTF Page Builder democratizes high-end web design, allowing strategists to focus on the story rather than the syntax.
Introduction: The "Invisible" Problem of Modern Theming
In modern CMS development, the browser’s "Inspect Element" tool is our first line of defense, but it’s often blind to the architectural intent of the page. As XOOPS themes have evolved into complex, structured systems involving the upcoming XOOPS Theme Framework (XTF) and XMF widgets, the boundary between a "theme shell," a layout "slot," and a "widget" has become invisible to standard tools. You see a sea of nested div tags, but you can’t easily tell which logic layer rendered them.
cssHolmes 3.0 is the purpose-built diagnostic workbench for XOOPS (v2.5.12+) that bridges this gap. It doesn't just look at the DOM; it analyzes the underlying XTF logic to provide true "X-ray vision." For a Senior Architect, this tool represents a shift from guessing at styles to auditing a structured system.