Corporate Website: centrum-csr.com

#centrum-csr.com, your centre of knowledge on corporate social responsibility

centrum-csr.com is an online platform about corporate social responsibility and sustainable development, built for companies, non-governmental organisations and anyone working on responsible business practice inside their own organisation. It went live in 2012 on WordPress, with Redis for object caching, a REST API layer feeding parts of the interface, a front end in HTML5, CSS3 and SASS, and a CDN in front of the media files. Delivery took around six weeks. The client supplied the layout and element placement; my part was turning that into a content model, templates and integrations.

#Who the site was built for

The audience was never the general public. It was business owners, HR and marketing staff, sustainability specialists and consultants, people who arrive with a specific question and limited patience: what does a given standard require, how is an initiative usually reported, what have comparable organisations actually done.

That profile shapes the whole build. Readers come from a search result or a link in a newsletter, land deep inside the site rather than on the home page, and either find what they need in the first screen or leave. Every decision below follows from that: deep pages have to stand on their own, the navigation has to work from the middle of the site outwards, and the publication date has to be visible because in this field a document without a date is a document nobody can rely on.

#Site functionalities

The knowledge base carries the articles and guides, organised with categories such as ecology and business ethics plus tags for cross-cutting themes. This part uses WordPress native structures deliberately, because a content model built out of native pieces survives a decade of updates far better than a bespoke one, and the editors already know how it behaves.

The news section runs as a separate stream for short, current items, optimised for frequent posting rather than for depth. Keeping it apart from the knowledge base is the single most useful editorial decision in a site like this. Both look like text with a title and a date, but they age at completely different speeds: an item is worth a week, a guide is worth as much as its accuracy two years later. Mixed into one archive, the durable material is buried under the perishable, and nobody can tell which is which.

The project gallery presents examples of CSR implementations, managed through the NextGEN Gallery plugin. Its purpose is reference rather than decoration: the case examples are linked from the substantive articles, which is why each of them needs its own fields rather than being another paragraph with an image pasted in.

The contact form runs on Contact Form 7 and delivers enquiries to the administrator’s mailbox. Responsiveness came from a theme built on Bootstrap 3, the standard approach for a 2012 build, and search visibility work used All in One SEO Pack together with an XML sitemap, aimed at the phrases the audience actually types, such as corporate social responsibility and CSR in Poland.

Naming those plugin choices matters more than it looks. They were the pragmatic options available at the time, they are all still identifiable, and a reader can tell exactly how much of this site is custom work and how much is standard WordPress assembly. That honesty is worth more in a portfolio entry than a vague claim about bespoke architecture.

#Forms are where a knowledge site meets people

A contact form on a topical site does a different job from one on a shop. It does not take orders; it takes requests for consultation, requests for materials and messages from organisations that want their own practice featured. Messages are long and the sender wants an answer, not a receipt.

Three things matter technically. Deliverability first: mail sent by the site’s own server with the visitor’s address in the From field lands in spam far more often than anyone expects, so the sending address has to belong to the site’s domain and the visitor’s address belongs in the reply-to field. Spam second: any publicly reachable form is found by automated traffic within weeks of launch, so filtering and rate limiting are a condition of the mailbox staying readable rather than a refinement. Field length third: truncating the message body at a character limit is the kind of defect that only surfaces when somebody has described their situation in three paragraphs and two of them arrived.

#Challenges and implemented programming solutions

Asynchronous loading was introduced so that lists and sections could pull in further items without reloading the page. With a large base of articles and reports this is a real convenience: a reader browses a list, narrows it, and does not pay the full cost of rendering a page each time.

There is exactly one boundary worth knowing before the build rather than after. Content that exists only after a script has run does not exist for part of the audience: for a crawler in the mild case, for a screen reader in the serious one. So every article and every report has its own address and its full text in an ordinary HTML document, and the asynchronous layer only accelerates navigation through lists.

The REST API does the same job here as a well designed endpoint does anywhere: it returns exactly the data needed to draw one part of the interface. If the article list requested full posts, every load of further items would drag the entire body text across just to display a title, a category and two lines of summary. A smaller response is not only faster; it also caches better, because that resource changes far less often than the article text does.

Redis handles object caching. A WordPress page is assembled from many small reads: options, metadata, taxonomy relationships. On a list view with categories, tags and summaries, the number of those reads grows faster than the number of visible elements suggests. The interesting question is who the cache actually helps. Full page caching serves the anonymous reader and, from their side, settles the matter. It does nothing for a logged in editor, for parameterised views, or for API responses, which is precisely where the publishing team spends its day. A site that is fast for readers and slow in the admin discourages publishing, and that costs more than a few hundred milliseconds on the home page.

Media files, the photographs, infographics and video illustrating initiatives, are delivered through a CDN. The reason is mundane: they are the largest files on the site, and serving them from the application server consumes capacity better left to generating pages.

Performance work was measured against a copy of production rather than a clean install. An empty WordPress answers quickly no matter how the queries are written, because there is nothing to search. Only a database holding the full set of articles, reports, category relationships and comment history shows which query scans half a table.

#The front end is where the debt accumulates

The interface layer was written in HTML5, CSS3 and SASS. SASS was a maintenance decision rather than an aesthetic one: it keeps colours, spacing and breakpoints in one place instead of scattering them across stylesheets, which on a site extended over years is the difference between a fifteen minute change and an afternoon reading CSS.

It is worth saying plainly that this layer ages faster than anything else in the project. The responsive conventions of 2012 and the grid frameworks people built on then are, today, the part a serious rebuild replaces wholesale. The content model and the way data is delivered through the API have held up considerably better. That observation transfers to every new project: money spent on data structure keeps working for longer than money spent on presentation.

#Support and maintenance of the site

Ongoing care covers core, theme and plugin updates, log review, backups and small functional or visual changes. Updates are tested on a copy, because a site with custom templates, an API integration and public forms has several places where a plugin change alters behaviour without raising an error: a filter one view relied on disappears, a query is assembled differently, form delivery quietly stops.

A backup is a restore procedure, not a file on a disk. The one nobody has restored from is a statement of intent. The one worth having is the one that has already been used to stand up a working copy of the site, with a note of how long it took.

#Summary

centrum-csr.com is a site where the editorial material is the product and the technology exists to keep it readable for years. What decided its shape is invisible from the outside: the knowledge base kept separate from the news stream, asynchronous loading treated as an accelerator rather than the only route to the text, object caching tuned for the people who publish, and data structure kept apart from a presentation layer that was always going to age first.

What carries over to the next build is the technical layer and the method: WordPress, Redis, REST API, CDN, and testing against a copy of production. What does not carry over is this site’s content model or its integrations, written for one body of material and one editorial routine. A new project starts with a scope review, and the quote follows it.