Introduction
WordPress development has changed significantly over the past few years. The introduction of Gutenberg brought a block-based approach, allowing editors to build pages visually and apply consistent styles more easily. With Full Site Editing (FSE), we gained the ability to create reusable templates, manage global styles, and implement advanced layouts directly in the editor. By combining theme.json, block patterns, and custom plugins, our team built a flexible system that empowers editors while keeping code clean and maintainable.
In this blog, we share our journey to modern, scalable WordPress workflows — showing how we streamlined styling, templates, navigation, sliders, and custom blocks to improve both efficiency and design consistency.
Table of Contents:
Global Styling
In our earlier days working with the Classic Editor, one of the most difficult challenges we faced was managing global styling. There was no central place to control design choices, so every time we needed a consistent style — whether it was colors, typography, or spacing — we had to manually write custom CSS and apply it block by block, section by section. This often led to repetitive code, bloated stylesheets, and wasted hours ensuring that every page looked consistent. Even something simple, like updating a brand color or adjusting heading sizes, meant digging through multiple files and updating dozens of rules.
When we transitioned into Gutenberg, things began to improve. At first, we still relied on child themes and custom SCSS to manage styles, but then we discovered the power of the theme.json configuration. This was a turning point for us. Instead of scattering styles everywhere, we could now centralize them in one file and apply them globally across the site.
With theme.json, we were able to streamline our work by defining:
- Global colors – set once and reused across headings, paragraphs, buttons, and backgrounds.
- Typography rules – consistent font families, sizes, and line heights across the site.
- Heading and paragraph styles – no need to manually add classes for every block.
- Theme variations – such as light and dark modes, easily switchable and scalable.
This shift not only saved us significant development time but also reduced maintenance effort. Instead of hunting down inconsistent styles, we could trust that global rules would handle them for us.
And today, with the introduction of Full Site Editing (FSE), the process has become even more seamless. Now, we can create and manage global styles directly inside the WordPress editor itself, applying them across headers, footers, and templates. What once took hours of manual coding in the Classic Editor can now be achieved in minutes with a few JSON rules or editor settings — making our workflow faster, cleaner, and more future-ready.
{
"version": 2,
"styles": {
"color": {
"text": "#333333",
"background": "#f9f9f9"
},
"elements": {
"button": {
"color": {
"text": "#ffffff",
"background": "#6c5ce7"
}
}
},
"blocks": {
"core/code": {
"color": {
"text": "#d63031",
"background": "#ffeaa7"
}
}
}
}
}Heading Styling:
Initially, Gutenberg only provided the basic H1–H6 heading levels, which made it challenging to maintain consistent visual hierarchy and styling across the site. Editors had to manually apply custom classes, which was prone to errors and inconsistencies. To overcome this, we developed a custom heading panel in Gutenberg that works alongside the standard heading selector. This panel allows editors to choose both the semantic level and a predefined style, including advanced variations such as display headings, eyebrow headings, and banner headings with extra spacing. As a result, headings became more consistent across all pages, editors could work faster, and there was no need for them to handle CSS directly. This solution improved both workflow efficiency and the overall design consistency of the site.
Image Styling :
By default, Gutenberg only provides two image styles: Default and Rounded, which was too limited for our design needs. We required more variations, including semi-circle images, styled edges, fully rounded images, box-shadow effects, and gradient overlays. To make these styles easily available to editors, we registered some of the image styles via JSON, allowing them to be applied directly within the Gutenberg editor. In addition to JSON-registered styles, we also extended them using JavaScript, which gave us even more flexibility to introduce experimental effects. Beyond these, we incorporated advanced styling such as clip-path shapes and dot-cone patterns, giving editors even more creative freedom. This approach ensured that all images maintained visual consistency, while providing an efficient way for editors to apply sophisticated styles without manually writing CSS.
Button Styling :
Gutenberg’s default buttons were limited to just two styles, which was insufficient for the requirements of many projects. To address this, we developed multiple button variations that editors could apply directly within Gutenberg. These buttons included different visual styles and interactive features, such as triggering pop-ups or video modals. Instead of relying on JSON, we implemented these functionalities using JavaScript, allowing buttons to perform advanced interactions without requiring editors to write any code. This combination of flexible styling and interactivity ensured that buttons remained consistent, reusable, and easy to manage, while giving editors the tools they needed to create engaging and functional user interfaces.
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"slug": "fill-with-white",
"title": "Fill with White",
"blockTypes": [
"core/button"
],
"styles": {
"typography": {}
}
}
Navigation Styling :
In our WordPress journey, one of the most challenging areas we faced was building the header section. At first, we used a custom Walker_Nav_Menu to create our header with sub-menus. While this approach worked, it was time-consuming and difficult to manage. Later, we discovered the built-in menu options in the Appearance section, which made creating and managing menus much easier. All we had to do was design the styles, and the process became far more efficient. However, one limitation remained—there was no straightforward way to build a mega menu.
After some time, we found a solution for this as well. We extended the menu options by adding mega-menu support and integrated it into our block patterns. This allowed us to simply drag and drop the mega menu layout and make it easily editable for content editors, while maintaining consistent styling across the site.
The footer presented similar difficulties in the beginning. To address this, we created a backend editor option called “Other Content”, which allowed us to set predefined patterns for areas like the footer, blog archive banners, and other repeated sections. This approach made managing footer layouts just as smooth as working with headers.
Another challenge we faced was with anchor navigation. In some pages, apart from the common site header, we also needed page-specific anchor menus that linked to different sections of the same page. Initially, building and styling these anchor menus directly inside the editor was both difficult and time-consuming. After struggling with this multiple times, we finally built a custom navigation plugin. Once activated, this plugin allowed us to easily create anchor navigations for any page with minimal effort, saving both development and editing time.
Now, with the introduction of Full Site Editing (FSE), the entire process has become even more streamlined. We can create reusable header and footer templates directly within the editor and apply them across all pages. Combined with our solutions for mega menus and anchor navigation, this evolution has saved us a significant amount of time, simplified our workflows, and given editors much more flexibility in managing layouts without needing developer intervention.
Swiper Styling :
In the early days of our WordPress projects, one of the toughest challenges we faced was creating sliders. Gutenberg didn’t provide any native slider or carousel options, which meant that if we wanted to build one, we had to do everything manually. This involved writing the entire swiper functionality using JavaScript and handling the styles with SCSS. While it gave us complete control, it was extremely time-consuming, repetitive, and not very editor-friendly. Each time a new slider was needed, we had to write code from scratch, which slowed down development and added unnecessary complexity to projects.
To make the process easier, we moved to Slick.js, a popular slider library at that time. Slick helped us reduce development time because it came with built-in functionality like autoplay, navigation, and responsive support. Instead of coding every little feature ourselves, we could rely on Slick to handle the basics. This was a huge step forward and saved us a lot of effort. However, it still had its limitations—it wasn’t deeply integrated with Gutenberg, and editors couldn’t easily customize sliders without developer help. Most of the styling and setup still lived in code.
As our projects grew in complexity, we realized that what we needed wasn’t just a slider library, but a solution that integrated smoothly with Gutenberg. That’s when we decided to build our own custom swiper plugin. This plugin brought together both functionality and styling, but more importantly, it allowed editors to create and manage sliders directly from the block editor with a drag-and-drop interface. No more digging into code—sliders could now be added, customized, and styled visually.
The plugin came with multiple prebuilt layouts like card sliders, testimonial carousels, and portfolio showcases, making it versatile enough for a wide range of use cases. On top of that, we introduced an entire panel of customization options:
- Choose how many slides appear per view.
- Apply different animation styles.
- Customize navigation buttons and pagination dots.
- Control slide timing and transition speeds.
- Enable equal-height slides for cleaner layouts.
- Turn on autoplay, looping, and other advanced behaviors.
Templates
Before the release of Full Site Editing (FSE) in WordPress 6.7, creating templates was a much more complicated process. At that time, templates could not be built directly inside the Gutenberg editor. Instead, our team had to create each template manually through code, writing both the structure and the styling in PHP and CSS.This approach worked, but it came with a major drawback: any time a template needed to be updated — whether it was a small design change or a layout adjustment — we had to go back into the code, rework the styles, and redeploy. This was especially challenging for archive pages, single blog posts, and other dynamic layouts, where even small edits consumed a lot of development time.
When Full Site Editing arrived, this entire process changed for the better. Now, we can build and manage templates directly inside the editor without touching a single line of PHP or CSS. Whether it’s a blog archive, a single post layout, or a custom page template, we can create and edit everything visually.
The real advantage comes in future maintenance: instead of going back into the code, we can simply adjust templates or styling directly in the WordPress editor. This not only saves us hours of development time but also gives content editors more flexibility, since they can manage layouts without relying on a developer.
Plugin Development
In our team’s development journey, we often faced challenges when working with themes and third-party plugins. Many times, client requirements didn’t align with what was available by default, and relying too heavily on existing tools made customization difficult. This pushed us to start building our own custom plugins tailored to specific project needs.
Over time, we built many more plugins to cover different needs, such as:
- Anchor navigation – allowing editors to add smooth scroll anchor menus within pages.
- Tabbed sections – reusable tabbed layouts directly in the block editor.
- Swiper/slider plugins – with customizable styles, navigation, and animation options.
- List table plugin – to manage structured data with sorting, filtering, and bulk actions.
- Custom post types – like testimonials, careers, or portfolios, with their own styling.
- Team card blocks – prebuilt designs for team member showcases.
- Review and testimonial blocks – styled layouts for user feedback.
- Fully integrated Gutenberg styling – ensuring consistency across all custom blocks.
- And many more… such as gallery enhancements, dynamic content blocks, form integrations, and other project-specific plugins, etc.
The biggest advantage of this approach is flexibility and reusability. Once a plugin is created, it can be installed, activated, and immediately used in the editor. If new fields, styles, or variations are required, we simply extend the classes and adjust them — without breaking the existing workflow.
By moving toward custom plugins, our team not only solved specific client requirements but also built a library of tools that now accelerate our development process, reduce dependencies, and give editors powerful features directly inside WordPress.
Frequently Asked Questions About Modern WordPress Development
1. What is Gutenberg in WordPress, and how is it different from the Classic Editor?
Gutenberg is WordPress’s block-based editor that allows users to build pages visually. Unlike the Classic Editor, which relies on a single content area and manual HTML/CSS, Gutenberg provides blocks for text, images, buttons, and more, making design consistent and easier to manage.
2. What is Full Site Editing (FSE) in WordPress, and why is it important?
Full Site Editing (FSE) lets you create and manage templates, headers, footers, and global styles directly in the editor. It reduces dependency on custom code and gives editors more control, improving workflow efficiency and scalability.
3. How does theme.json improve global styling in WordPress?
theme.json centralizes global styles such as colors, typography, and block-specific settings. This ensures consistent design across the site and saves time by eliminating repetitive CSS edits.
4. How does FSE make WordPress workflows faster and more scalable?
FSE allows editors to manage templates, global styles, headers, and footers directly in the editor. This reduces developer dependency, speeds up updates, and ensures design consistency across the site.
Final Thoughts :
Looking back, every stage of our journey taught us something new — and looking forward, we see even more possibilities. WordPress is moving toward a future where no-code and low-code solutions blend seamlessly with custom development. With Gutenberg and FSE, we’re ready to continue building faster, smarter, and more creative solutions for the projects ahead.
Take your WordPress site to the next level with FSE — book a consultation today!
