Category: WordPress

  • Gutenberg blocks your editors will actually use

    The blocks that survive contact with a real editorial team are the ones that remove a decision, not the ones that add options. A hero block with twelve toggle switches gets used once and then copy-pasted forever; a hero block with three required fields and sane defaults gets used every day.

    We design block libraries backwards from the content model, not the design file: what does an editor actually need to say, and what is the smallest set of fields that lets them say it correctly every time.

  • Migrating 62 WordPress installs without losing rankings

    Every legacy URL gets mapped before a single line of new code ships. Not after — before. The redirect map is reviewed by whoever owns search performance, tested against real crawl data, and signed off before launch is even scheduled.

    Done that way, organic traffic dips for days, not months, and usually recovers within two weeks.

  • When a WordPress rescue is cheaper than a rebuild

    A rebuild is the right call when the content model is wrong. It is the wrong call when the content model is fine and the problem is fifteen abandoned plugins and no one who understands the theme.

    We run a fixed-price audit before quoting either option, specifically so the answer is not just “whichever pays us more”.

  • The plugin audit we run before quoting any rescue

    Active plugin count, last-updated dates, direct database writes, anything hooking into wp_loaded before the query is even resolved, and anything storing serialised data in an autoloaded option. Fifteen minutes with Query Monitor tells us more than an hour of the client describing symptoms.

  • Custom post types vs. a page builder: a cost argument

    A page builder lets a client “just add a section” without touching a developer. It also means every page is a one-off, nothing is consistent, and a design change means editing forty pages by hand.

    A custom post type with well-designed fields costs more up front and less for the rest of the site’s life.

  • Staging, deploys and rollbacks for WordPress teams

    Editors publish content. Developers push code. The two should never collide, and the way you guarantee that is a database that syncs one direction and a codebase that deploys the other, with a rollback that takes under a minute.

  • Object cache without breaking the editor experience

    Object caching is the highest-leverage change on most WordPress sites, but it is also the one most likely to make an editor’s draft preview show stale content if the cache is not invalidated on save. Test the editor workflow, not just the homepage, before you call it done.