Building websites with Magento and Bolt CMS
What I've learned building shops and sites on Magento and Bolt, and why APIs and custom modules are my favourite part.
A lot of my web work has been on two platforms: Magento (both 1 and 2) for e-commerce, and Bolt CMS for sites that are more about content than checkout. Sites like Buzz Catering Supplies and EntirePro are the kind of thing I build.
The part I enjoy most isn’t the theme. It’s the plumbing: connecting a site to other systems through APIs and writing custom modules so the platform does exactly what the business needs.
Magento 1
Magento 1 was where a lot of serious PHP e-commerce started. It’s built on Zend Framework 1, configured through a lot of XML, and stores products with the EAV model, so attributes are flexible but queries get heavy.
What it taught me:
- Rewrites are a blunt tool. Overriding a core class works until two modules try to rewrite the same one. Observers on events are kinder to everything else.
- Keep the core clean. Anything in
app/code/coregets lost on the next upgrade. Local and community modules are the place for changes. - Caching and indexing matter. A slow Magento 1 store is usually missing a cache or fighting its indexers.
Official support ended in 2020, but plenty of stores still run on it, and the community-maintained OpenMage fork keeps it patched.
Magento 2
Magento 2 is a different beast, and much nicer to extend:
- Dependency injection instead of hard-coded class names, configured in
di.xml. - Plugins (interceptors) let you run code before, after or around a public method, without replacing the whole class.
- Service contracts give modules a stable PHP interface to build on.
- REST and GraphQL APIs come built in, so the same contracts are available to other systems.
- Composer handles modules and updates like any modern PHP project.
The trade-off is weight. It needs a properly tuned server, and a build step (compiling DI, deploying static content) before changes go live.
Bolt CMS
Not every site needs a shopping cart. For content-led sites I like Bolt CMS: it’s PHP and Symfony underneath, with Twig templates and content types defined in YAML. You describe the shape of your content in config, and Bolt gives editors a clean admin to fill it in.
It’s lightweight, quick to theme, and much easier for clients to live with than a full e-commerce platform when all they need is pages, news and forms.
Why I love APIs and custom modules
Off-the-shelf extensions get you most of the way, but the interesting work is in the last bit:
- Integrations. Pulling stock and prices from another system, pushing orders into a back office, syncing customers. Done well, the shop stops being an island.
- Custom modules. When a business works a particular way, a small focused module that does exactly that beats bending a generic extension.
- Clean boundaries. Using the platform’s own extension points (observers, plugins, service contracts) keeps upgrades possible.
What I’ve learned
- Extend, don’t edit. Never change core files. Use the platform’s hooks so the next upgrade isn’t a rewrite.
- Small modules beat big ones. One module per job is easier to test, debug and remove.
- Treat every integration as unreliable. Other systems go down and APIs change, so log everything, retry sensibly and fail gracefully.
- Pick the platform for the job. Magento for serious e-commerce, something lighter like Bolt when it’s mostly content.
Further reading
- Adobe Commerce developer docs: the official Magento 2 guides, including plugins, dependency injection and the web APIs.
- OpenMage: the community fork that keeps Magento 1 alive and patched.
- Bolt CMS documentation: content types, Twig templates and extensions.