A clear structure. Room for your ideas.
Python and Django at the foundation. Content, templates and purpose-built modules working together as one website.
Look inside Wulver ↓The visible result rests on invisible decisions.
A visitor sees a page. Behind it are decisions about where content lives, how a URL finds that content, which template presents it and what information surrounds it. A thoughtful architecture makes those decisions understandable, so the next change has a clear place to begin.
Wulver is organized as a Django project with specialized applications. Pages, publications, themes, accounts and supporting services have their own areas of responsibility. They share the project configuration and work together through models, views, services and templates.
This gives the developer a practical balance: ready tools for common website tasks and direct access to the code that implements them. The architecture is a working foundation for further decisions, with the project requirements guiding each extension.
Freedom to create starts with knowing where every part belongs.
One product. Distinct responsibilities.
The application names describe the system’s main responsibilities. This map groups them by purpose; it is a conceptual overview of the codebase, not a network of independently deployed services.
core_managerThe site core
Pages, site settings, SEO, sitemap and redirects.
blog_managerThe publishing layer
Articles, categories, tags and content selections.
theme_managerThe presentation layer
Themes, template editing, components and versions.
userprofile + comments_managerThe interaction layer
Accounts, profiles and comment workflows.
ai_assistantThe assistant layer
An application for the integrated AI assistant.
analytics_manager + backup_managerOperational tools
Analytics and backup management.
Follow a request. See the system work.
A public page is the result of a sequence. The router identifies the view, the view retrieves the relevant content, the context brings the data together and the template renders the response. Wulver’s page views make this connection explicit by linking a page to its selected theme template.
- 01
URL
The address selects a route and language context.
- 02
View + data
The view retrieves the page and its template relationship.
- 03
Context
Page data and SEO values are prepared for rendering.
- 04
Template → HTML
The selected theme template produces the response.
The route for an article has its own content needs, while search builds a different context again. The shared framework keeps the request-response pattern familiar; each view supplies the details that its page requires. This is a useful boundary when extending behavior or tracing a problem.
Content has a structure. Design has a language.
Wulver stores content and theme metadata in models, while its theme workflow works with Django template files. A theme groups templates; template types distinguish the base layout, includes, pages, categories, articles and system screens. This makes the presentation layer a part of the system that can be worked on deliberately.
A base template carries the common frame. Child templates fill the relevant areas. Includes and reusable components give recurring elements a place of their own. Changing a design still requires adapting its templates to the expected data, and the template builder supplies tools for that work.
Explore the template builder →Extend with a purpose. Preserve the connections.
A clear structure helps answer the next practical question: where should a new capability live? A content feature starts with its data. A visual change starts with the theme. A new interaction needs a route and behavior. Keeping those responsibilities visible makes changes easier to reason about.
Model the meaning
Define the entities, fields and relationships that the feature needs. Keep the data meaningful beyond a single layout, so different templates can use the same content.
Connect the behavior
Add the view or service that prepares and processes the data. Decide which context the template receives and which conditions the feature must handle.
Verify the whole path
Review the rendered page, content states and related routes. A local change can affect shared pieces, so validation should follow the connections it touches.
Architecture continues after the first launch.
The source tree also contains the tools that support a running website: analytics, backups, environment checks and template history. Configuration, uploaded media and static resources each have their own role. These operational details belong to the life of the project just as much as its public pages.
A development environment and a production deployment need different settings and infrastructure. Wulver provides a starting point and configuration visibility; hosting, resource delivery and restoration checks still need to be prepared for the actual project. A maintainable system makes these responsibilities visible.
Build the next idea on something you understand.
Wulver brings a working set of website capabilities into a structure a Django developer can explore and extend. Its value is in the connections: between data and design, between publishing and operations, between a first release and the changes that follow. The foundation is here. The direction is yours.