Oerlinghausen Marketing

Taking over an existing website is a different job from building a new one. On a new build every decision is known, because you made it. A takeover starts with an inventory instead: which extensions are in use, which of them are still maintained, which adjustments were made directly in the system, and how they depend on one another.

On a WordPress installation that has grown over years, this is rarely trivial. Features were added at different points in time, often by different people, and the reasoning behind a particular solution is no longer written down anywhere. Clean up too quickly here and you remove something that is needed elsewhere.

Then there is the question of whether a rebuild makes sense at all. For a city marketing site that brings together events, a shop and a newsletter, the value sits less in the surface than in the content and the routines attached to it. A relaunch interrupts those routines without automatically answering the actual requirements any better.

The decision in this project is therefore to keep the existing WordPress site running and extend it deliberately. A module for a photo contest with uploads and online voting was newly built. Alongside that came adjustments to the WooCommerce shop, the event calendar and the newsletter integration.

A photo contest is more demanding than it looks from outside. An upload accepts files of unknown size and unknown format and has to process them without slowing the site down. A vote has to settle who may vote and how often, otherwise the winner is not the best picture but the most persistent repetition. And because submitted images become publicly visible, there has to be a review before publication and a clear position on the rights to the entries.

For a module like this to sit well in a grown installation, it is better built as a self-contained extension than written into existing files. Anything that stands on its own can be updated, switched off and replaced later without touching the rest of the site. That counts double for a feature that is only needed during a certain period.

On a site under continuous care, the emphasis moves from building to operating. Updates for the system and its extensions arrive constantly. Ignoring them is not an option, and applying them untested is not either, once a shop and custom-built features are involved. That calls for a fixed routine with a backup, a check and a way back.

The second point is the editorial side. An event calendar depends on dates being entered promptly, a shop on articles being kept current. Both only happen when entering them needs no manual. Extensions should therefore not merely behave correctly, they should also be operated the same way as the rest of the system.

Finally, city marketing runs on an annual rhythm. Campaigns, contests and events have fixed points at which they have to be in place. Support that carries that rhythm plans extensions around the calendar they belong to, not around when they happen to be technically ready. Starting to build two weeks before a campaign means the decision has already been made for you.