E-commerce Development: mavicon.pl

#mavicon.pl, a modern website showcasing innovative solutions

A company that sells technical solutions has the opposite problem to a shop. A shop shows a product and a price, and the visitor knows within seconds whether it is for them. A technical services provider sells something that cannot be photographed, to a buyer who usually cannot yet name their own problem. They arrive with a symptom, not with an order.

Everything about the mavicon.pl content model follows from that. The offer has to be readable from the symptom side, not only under the name of the service, because someone whose warehouse system has become unusably slow does not search for the technology that needs replacing. Case studies do more work than service descriptions, because they let a reader recognise their own situation in somebody else’s. And the site has to survive being read by a technical person checking whether the supplier knows what they are talking about, which is a test that generalities fail immediately and permanently.

The site was built to position the company as an expert, present its case studies, and attract clients interested in advanced IT and digital marketing work. The layout and element placement came from the client, so the work on our side went into the content model, the templates, and what happens to the site after launch. The implementation took around six weeks.

#key functionalities and technologies used

The content model separates three things that a typical corporate site keeps together: the service description, the proof in the form of a delivered project, and the explanatory material about the underlying topic. Each has a different reader, a different update cycle and a different position in the path to an enquiry. Keeping them in one content type saves a week during the build and costs for years afterwards, because any change to one of them then forces caution about the other two.

WordPress with custom post types carries that separation. This is a decision that only pays back after about two years. In month one it looks like needless complexity, because categories can do the same job. After two hundred entries the difference is that changing the case study template does not touch the blog, and an editor adding a service sees a form with the fields a service actually has, rather than a universal body field with the instructions written in a comment.

The presentation modules load content asynchronously without a full page reload. The trade-off there is rarely stated, so it is worth stating: content fetched after the fact is content a search engine may never see, and on a page whose only job is to generate enquiries from search, that is a commercial decision rather than a technical one. The resolution was that navigation, filtering and further listing pages load asynchronously, while the body of a service page never does. The first screen is complete in the document source.

Search optimisation covers structured data, meta tags and readable URLs. Structured data was worth considerably less in 2012 than it is now, because search engines were only beginning to use it. The return arrived later, and it arrived only where the markup described a real entity, the company and its services, rather than where it had been sprinkled across every subpage.

The contact form validates on both the client and the server and routes enquiries to the right department. The duplication is not redundancy. Browser-side validation exists so that a visitor does not wait for a server round trip to learn about a typo. Server-side validation exists because the first one can be bypassed, and a contact form without it is simply an open door for bots.

#what the technology list does not say

The list of tools further down describes the site as it stands after years of maintenance, not the stack it launched on, and that distinction matters enough to be made explicitly rather than left for a reader to work out.

The project went live in 2012. That was WordPress without a REST API in core, without a block editor, with custom post types two years old and with responsive layout only just past the stage of being a novelty. React was not released publicly until 2013. The REST API reached WordPress core in version 4.7 at the end of 2016. Tailwind CSS did not exist until 2017, and PHP 7 arrived in 2015, so moving the environment off the 5.x branch was a separate maintenance task years after launch rather than a decision taken at build time.

Case study write-ups routinely present today’s technical layer as the original one, and the result is that nobody can tell a design decision apart from a later substitution forced by the passage of time. On a project that has been maintained for over a decade, the second kind outnumbers the first.

#challenges and programming solutions

Serving dynamic content needed custom endpoints. With no REST API in WordPress core, that meant writing an input layer by hand, with its own capability checks and its own response format. That work aged faster than anything else in the project, and that is the interesting part: code written because the platform lacked something is the first candidate for deletion on the day the platform gains it. The alternative, keeping a private implementation alongside core, charges rent at every subsequent update.

Performance work leaned on layered caching with Redis and Memcached, asset compression and CDN delivery. Two caches in one deployment sound like excess until you notice they handle different things, one holding an object cache for database queries and the other sessions and view fragments. The gain from an object cache on a marketing site is smaller than generally assumed, though, because most traffic is anonymous visitors moving across a dozen pages, and those can be served more cheaply by returning the whole page from cache and never descending into PHP at all.

Integration with external systems covered two-way exchange with a CRM and analytics platforms. The decisive question was failure behaviour. Most plugins default to showing an error or an empty section, which on a sales page looks like the whole site is down. Here every connection has a fallback: the last known response, and where even that is missing, a static variant of the section. The visitor then sees a page with one module absent rather than an error message.

Migrating content from archived versions of the site used import and export tooling together with the Web Archive. Pulling content out of an archive has a trap that only becomes visible after publication. The archive preserves text, but it does not preserve the addresses that text was indexed under, nor images that used to load from external domains. Without recreating the old addresses as redirects, the migration looks successful and simultaneously deletes the site’s entire ranking history.

#where the time actually goes on a marketing site

Performance discussions about a corporate site tend to settle on minification and image compression, the dozen or so percent that a measuring tool will show. The real cost sits elsewhere and is nearly identical across WordPress builds of this class.

The first cost is the number of database queries per request. A theme that builds the menu, the project list and the related services section with separate queries inside loops issues dozens where three would do. On a clean install this is invisible, because every table holds a handful of rows. After two years of publishing the difference is obvious and shows up as general slowness with no single identifiable cause, which is the worst kind of performance problem to inherit.

The second cost is assets loaded globally. A contact form plugin adds its stylesheet and script to every subpage by default, including the ones with no form on them. So does the gallery plugin, and the slider plugin. Together they come to a few hundred kilobytes that nobody will ever use, and none of them looks guilty on its own.

The third is the least obvious and concerns third-party scripts. Analytics, chat widgets and advertising pixels enter through code pasted into the header and immediately fall outside any kind of version control. An outage at the provider of such a script can block rendering of a page that is otherwise entirely healthy, and the investigation starts with your own code, because nobody remembers a line pasted in a year earlier.

The order of performance work follows directly from those three: full-page caching for anonymous traffic first, query discipline for the views that cannot be cached second, asset compression last. Reversing that order produces a pleasant synthetic score and changes nothing that a visitor can feel.

#tools and technologies

WordPress remains the base because it lets the client edit content without a developer, which on a marketing site is the criterion that outranks the rest. PHP and MySQL carry the server layer. HTML5, CSS3, SASS and JavaScript make up the presentation layer, and SASS earns its place not by shortening the syntax but by giving the brand colour one home instead of forty. Bootstrap and Tailwind CSS speed up building a consistent layout, with the caveat above about when each of them entered the project.

Redis and Memcached hold the caches, and Git holds the code. Version control on a project this size is sometimes treated as a formality, and the truth is the reverse: it is the only mechanism that lets a fix made in a hurry be reversed without guessing what exactly was changed.

#support and maintenance of the WordPress site

Ongoing care covers responding to technical problems and fixing breakage after updates, regular core, theme and plugin updates, log monitoring, scheduled backups, and small functional and visual changes as the business needs them.

One item on that list deserves expansion, because it is the source of most incidents on sites of this profile. A plugin update rarely breaks a site by itself. It breaks the site when the theme was overriding that plugin’s behaviour by leaning on an implementation detail its author never promised to keep. That is why updates go first to a staging environment that is a copy of production rather than a clean install. On an empty install with a default theme everything works, and the test says nothing about what will happen in production.

Backups only acquire value once somebody has actually restored from them at least once. A backup that has never been restored is a statement of intent rather than a safeguard, and the difference between the two is always discovered at the worst possible moment.

#summary and preliminary client requirements analysis

The initial analysis settled several points that became the foundation of the project. The goal was to build the company’s standing as a supplier of advanced solutions and to attract clients interested in that kind of work. The requirements covered dynamic presentation of the offer, integration with external systems and a flexible content management system. The scope covered modernising the site architecture, implementing responsive views and adding presentation modules. The project was split into stages so that features could ship incrementally. The client named reference sites with clear offer presentation, and that shaped the final result.

That last point is the most interesting in hindsight. Reference sites supplied by a client are usually treated as material for a moodboard. In practice they carry information about something quite different from aesthetics: they say what order the client considers natural for reading an offer, where they expect to find a price, and where they expect to find contact details. Those are content model decisions rather than visual ones, and they transfer to later projects far better than any layout does.

The site was built as a marketing instrument with a clear offer structure, room for case studies and the groundwork for continued content updates. What carries forward from this build is the method: content model before template, tests against a copy of production, and a firm line between what belongs in the document source and what may arrive later. The stack itself does not carry forward, because half of a 2012 stack is different today, and that is the ordinary course of things rather than a defect in the project.