The SiteMods process begins with the website's purpose and follows a deliberate path into platform, architecture, functionality, presentation, and long-term ownership.
1. Understand the Website
The work begins with people and outcomes: who uses the site, what they need to understand or accomplish, what content and workflows must be managed, which integrations matter, and who will maintain the result.
Operational Questions
Roles, permissions, editorial work, forms, data, integrations, account or commerce needs, reporting, support, and recurring administration.
Experience Questions
Audience priorities, information architecture, navigation, accessibility, devices, visual identity, media, and the path each visitor should follow.
2. Choose the Architecture and Platform
The platform follows the requirements. When WordPress is the appropriate foundation, responsibilities are mapped between the reusable SiteMods frameworks, selected extensions, and the project-specific plugin and child theme.
Shared WordPress Foundation
├── Plugin Framework
├── Theme Framework
└── Selected Extensions
Site-Specific Layer
├── Project Plugin
└── Project Child Theme3. Develop the Functionality
The project plugin owns behavior unique to the website: content structures, fields, permissions, administration tools, account flows, integrations, imports, or other defined workflows. Shared loading, lifecycle, settings, and extension services remain in Plugin Framework.
4. Shape the Experience
The child theme establishes the project's visual identity and presentation on top of Theme Framework. Content hierarchy, navigation, typography, responsive layouts, editor presentation, media treatment, and focused template decisions are developed around the actual website.
5. Integrate, Test, and Refine
Functionality, content, and presentation are reviewed together using representative data and roles. The work includes accessibility, responsive behavior, permissions, error handling, security boundaries, administrative usability, performance, dependencies, and recovery from failures.
6. Prepare for Use and Maintenance
Before launch or handoff, shared and site-specific packages receive a production review. Deployment assets, documentation, versions, backups, and recovery expectations are verified so framework improvements and project changes can be managed at the correct layer.
Does every project begin with the frameworks?
No. Every project begins with its requirements. The SiteMods frameworks become relevant when WordPress is selected and their shared structure fits the work.
Does every WordPress project use every extension?
No. Extensions group optional capabilities so unrelated behavior can remain disabled. Project-specific requirements can also be implemented directly in the site plugin when they are not broadly reusable.