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 popular content management platform. It worked well enough at first, but as the site grew, several patterns became clear:

  • Routine updates carried the risk of breaking unrelated parts of the site
  • Small editorial changes required technical intervention
  • Long-form writing, images, and references were difficult to manage cleanly
  • The site was increasingly shaped by the platform's assumptions rather than our own needs

Most importantly, the site was drifting toward a model where speed and automation mattered more than clarity, accuracy, and care.

That wasn't what we needed.

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:

  1. Editorial independence
    Editors should be able to see their work exactly as it will appear, without publishing it publicly by default.
  2. Structural clarity
    The site should reflect how our work is actually organized — not how a platform expects content to behave.
  3. 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
  • take time 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.

This means:

  • there is no live database on the public site
  • there are no background scripts running
  • there is 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 forever after.

It avoids:

  • maintenance contracts
  • forced upgrades
  • plugin conflicts
  • security patches for systems that don't need to exist publicly

It also aligns with how we actually work:

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, not inferred
    •  
  • Templates needed to be written at the code level, not assembled from blocks
    •  
  • The system needed to remain usable without plugins
    •  
  • 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, images — has:

     
  • its own template
    •  
  • its own set of fields
    •  
  • 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
    •  
  • 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
    •  
  • 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
    •  
  • the need for ongoing platform updates
    •  
  • dependencies on third-party services
    •  
  • performance variability

Once exported, the site is simply 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.