About Our Website
This website did not begin as a redesign.It began as a practical problem: how to publish clear, accurate, durable information about habitat, plants, and birds without being dependent on systems that constantly demand attention, upgrades, subscriptions, or rebuilds. Over time, that problem became architectural.
Where We Started
Saving Birds Thru Habitat inherited an earlier website built on a proprietary content management platform. It worked well enough at first, but as the site grew, several patterns became clear.
What We Decided to Change
Rather than moving to another hosted or template-driven platform, we chose to rebuild the site with three goals in mind:
- Editorial independence
Editors should be able to see their work exactly as it will appear, without publishing it publicly by default. - Structural clarity
The site should reflect how our work is actually organized — not how a platform expects content to behave. - Long-term stability
The site should be able to exist for years with minimal maintenance, without tracking users or relying on third-party services.
This led us to separate working from publishing.
How the Site Works Now
The site is developed and edited in a private staging environment. Editors can write and revise content, adjust layout, captions, and structure, review changes in context, and take the time needed without pressure. Nothing edited in staging is automatically public. When a set of changes is complete, the site is exported to a static version — a snapshot of the site at that moment — and that static version is what visitors see. There is no live database on the public site, no background scripts running, and nothing to “update” in the usual sense. The public site is fast, simple, and stable because it is not performing work — it is displaying the results of work already done.
Why We Chose This Approach
This approach costs more time upfront and less time thereafter. It avoids maintenance contracts, forced upgrades, plugin conflicts, and the need to secure systems that do not need to be publicly exposed. It also aligns philosophically with how we actually work.
In a traditional content management system, databases, administrative systems, and plugins are all exposed on the public site. As a result, they must be secured, patched, and maintained on an ongoing basis. In this approach, those systems still exist, but only in a private staging environment and not on the public site. The public site therefore has nothing to secure in that sense.
How This Site Was Built
This website was rebuilt rather than redesigned. The goal was not to change how the site looked, but to change how it behaved: how content is created, stored, reviewed, and published over time.
Choosing the Content Management System
We chose ProcessWire as the site’s content management system after evaluating several common alternatives. The decision was based on a few practical requirements. Content structure needed to be defined explicitly rather than inferred, templates needed to be written at the code level rather than assembled from blocks, the system needed to remain usable without plugins, and editors needed a clear separation between content and presentation. ProcessWire provides a minimal core and allows the site’s structure to be defined directly in templates and fields using standard PHP and HTML. This made it possible to build exactly what was needed, and nothing more.
Defining the Site Structure
Rather than using a single generic content type, the site is composed of many specific page types. Each major kind of content — essays, resources, news items, plant information, and images — has its own template and its own rules for layout and navigation. This avoids the need for conditional logic inside content and keeps each section of the site legible to editors and maintainers. Navigation, sidebars, and relationships between pages are handled explicitly rather than inferred automatically.
Writing Custom Templates
All front-end output is generated by custom-written templates. These templates control exactly how content is rendered, separate main content from sidebars and supporting material, avoid shortcodes, page builders, or visual editors, and rely on standard, readable markup. This makes the site predictable. A given type of content always behaves the same way, and changes to layout are made in one place rather than across multiple pages.
CSS and Presentation
The site’s presentation is handled with a single, cohesive CSS system rather than page-specific styling. The emphasis is on consistent typography, predictable spacing, limited use of decorative elements, and a clear hierarchy between primary content and supporting material. Images, captions, pull quotes, and block quotes are handled with defined patterns rather than ad hoc styling. This allows long-form writing and photography to coexist without visual conflict. The goal is not novelty, but legibility.
Separating Editing from Publishing
One of the most significant architectural decisions was separating the editing environment from the public site. All editing and development happens in a staging version of the site. Editors can see their work exactly as it will appear, but changes are not automatically public. When a set of changes is ready, the site is exported to a static version. That exported version is what visitors see.
This means:
- no live database on the public site
- no server-side processing for visitors
- no background services running publicly
The public site is static by design.
Why Static Export Matters
Static export simplifies the site in ways that are difficult to achieve otherwise. It removes security concerns associated with live CMS installations, eliminates the need for ongoing platform updates, reduces dependencies on third-party services, and avoids performance variability. Once exported, the site is simply a collection of files served by a web server. It can be cached easily, archived, mirrored, or restored without specialized tools.
Ongoing Development
The site is not finished, but its foundations are stable.
Future work consists of:
- writing new content
- refining existing templates where needed
- expanding structured resources
- adjusting layout details based on use
Because the core structure is explicit and code-based, these changes can happen incrementally without forcing redesigns or migrations.