The safe way to customise a WordPress theme depends on who maintains it. Avoid direct edits to a third-party parent theme that updates will replace. Use the Site Editor, a child theme or your own version-controlled theme as appropriate; put independent functionality in a plugin and test the change before release.
The short answer
- Changes made directly to a theme’s files are wiped out the next time the theme updates.
- Block themes are customised in the Site Editor, and the changes can be saved back into theme.json and template files.
- Classic themes are customised safely through a child theme, which inherits the parent and survives its updates.
- Elementor suits teams who want to design pages visually. ACF suits structured, repeatable content that must stay consistent.
- Back up, use staging, and keep customisations in version control. That is what “without breaking it” means in practice.
What is the safest way to customise a WordPress theme?
The safest way to customise a WordPress theme is to use the lightest tool that does the job: built-in styles and settings first, then block-level or additional CSS, then a child theme or theme.json, and only then custom code. Each step up adds power and adds something you must maintain through every future update.
| What you want to change | Block theme | Classic theme |
|---|---|---|
| Colours, fonts, spacing | Global Styles in the Site Editor | Customizer or theme options |
| One block or section | Block settings, or block-level custom CSS | Block settings, or Additional CSS |
| Header, footer, templates | Site Editor templates and template parts | Child theme template files |
| Theme-wide defaults and presets | theme.json (in a child theme or your own theme) | Child theme style.css and functions.php |
| New functionality | A plugin, not the theme | A plugin, not the theme |
| A distinct brand and content model | A custom theme | A custom theme |
Before any change, take a full WordPress backup and make the change on staging. WordPress 7.0 added custom CSS at the block level, which is handy for one-off fixes. It is also an easy way to scatter styles across hundreds of posts, so use it sparingly.
How do you customise a block theme with the Site Editor and theme.json?
A block theme is customised visually in the Site Editor, where Global Styles controls colours, typography and spacing, and templates control every page layout. Behind the scenes, theme.json defines the defaults and presets. Changes you make in the Site Editor are stored in the database until you save them into the theme’s files.
- Start in Global Styles. Try the theme’s style variations before changing anything by hand.
- Edit templates, not individual pages. Change the single post or page template once and every page using it follows.
- Use responsive controls. WordPress 7.1 brought responsive styling into Global Styles and block settings, and lets block themes define their own mobile and tablet breakpoints in theme.json, along with hover and focus states.
- Save changes into code. The Create Block Theme plugin, maintained by WordPress.org, can save your Site Editor changes to the theme, create a child theme, or export a new theme. Then commit the files to Git.
The last step is the one most people skip. Customisations that live only in the database are hard to review, hard to move between staging and live, and easy to overwrite. The theme.json documentation explains how presets and settings fit together. If you are new to the editor, start with my block editor tutorial.
Before release, compare what is stored in theme files with database overrides and the rendered result. A template edited in the Site Editor can override its file, so changing Git alone may not change the page. Record which layer owns the setting and verify it after deployment.
When do you need a WordPress child theme?
You need a WordPress child theme when you want to change a classic theme’s templates, add PHP functions, or write substantial CSS while still receiving the parent theme’s updates. A child theme inherits everything from its parent and overrides only what you change. Block themes need one less often, because theme.json and the Site Editor cover most styling.
The Theme Handbook puts the reason plainly: functions added to a parent theme’s functions.php disappear the next time that theme updates. In a child theme they stay. A minimal child theme is a folder with a style.css file whose header names the parent in a Template: line, plus a functions.php file if you need one. Copy a template file into the child theme with the same name and the child’s version wins.
Keep child themes thin. If your child theme is rewriting most of the parent’s templates, you are building a custom theme with extra dependencies, and it is time to make that call deliberately.
What CSS mistakes break WordPress themes?
The CSS mistakes that break WordPress themes are editing the parent theme’s stylesheet, repeating the same rules in many places, overriding styles instead of structuring them, ignoring typography basics such as heading spacing and blockquotes, and letting content stretch too wide on large screens. Most come from adding CSS reactively, one fix at a time, with no plan.
- Editing the parent theme. The next update erases your work. Use a child theme, theme.json or Additional CSS.
- Redundant rules. The same declarations copied across selectors bloat the stylesheet. Group shared styles, use CSS custom properties, and in block themes use the presets theme.json generates.
- Undoing styles instead of designing them. Adding a border to every H2 and then writing a class to remove it is backwards. Put optional styling on a class you add, not on the base element.
- Weak typography. Headings need clearly different sizes and more space above than below. Quotes and lists need deliberate styles, because editors will use them.
- No maximum width. Long lines are hard to read on wide screens. Set a content width, which block themes do through the layout settings in theme.json.
What theme development choices cause problems later?
The theme development choices that cause problems later are unlimited design options, especially free-choice colour pickers, heavy options panels that generate inline CSS, features that belong in plugins, and customisations stored only in the database. Each feels flexible on day one and turns into inconsistency, slow pages or accessibility failures within a year.
A controlled palette can reduce accidental contrast failures, but the combinations still need testing. WCAG 2.2 generally requires 4.5:1 for normal text. Check hover, focus, selected states and text over images too; testing each colour alone does not establish that every pairing is accessible.
Build tools still have a place when they make the team’s release process clearer. I build and test agents and workflows every day, with a project structure, review and recovery controls. For a client theme, the useful question is whether another developer and the editing team can maintain the design safely.
Elementor or ACF: which should you use?
Elementor is the better choice when marketers need to design and change page layouts visually without a developer. ACF, short for Advanced Custom Fields, is the better choice when content is structured and repeated, such as products, people, locations or specifications, and must look consistent everywhere. Many professional builds use both, each for what it does best.
| Factor | Elementor | ACF |
|---|---|---|
| What it is | Visual drag-and-drop page builder | Custom fields for structured content, with templates built by a developer |
| Who builds layouts | Marketers and designers | Developers |
| Who edits content | Anyone trained on the builder | Editors fill in fields, so the design stays locked |
| Consistency across pages | Depends on discipline and templates | Built in, because every entry uses the same template |
| Performance | Heavier by default, needs tuning | Lean, depends on the theme’s code |
| Lock-in | High: layouts live in the builder’s own data | Lower: data lives in standard WordPress fields |
| Block editor | Replaces the editor on builder pages | Works with it, including custom ACF Blocks in the Pro version |
| Active installs | 10,000,000+ | 2,000,000+ |
| Best for | Landing pages and campaign pages | Directories, catalogues, specs and flexible page sections |
Both have paid tiers. Elementor Pro adds theme building and more widgets. ACF Pro adds the Repeater and Flexible Content fields, options pages and ACF Blocks. There is also Secure Custom Fields, a fork that WordPress.org created in October 2024 and still maintains.
At WP Creative my team builds with Gutenberg, ACF and Elementor, and the results depend more on discipline than on the tool. The villain is usually sprawl: years of widgets, add-ons and one-off layouts piled on top of each other until nobody dares touch the theme. Bidfood, a national food distributor, runs a heavy Elementor build. My team converted old sections to Elementor containers, trimmed the plugin stack and tuned caching and images. In August 2026 its field data showed all three Core Web Vitals passing on mobile and desktop, the result of the whole maintenance programme rather than any single change.
Two smaller examples point the same way. A professional services firm needed to update its content without calling a developer, so my team rebuilt it on ACF with custom post types; on the staging build, its lab speed scores climbed from middling to the high 80s on mobile and above 90 on desktop. And for one B2B client we kept their existing page builder, because switching would have meant retraining the team for little functional gain. (Details of these two changed to keep the clients private.)
For frequent landing pages, compare the editor’s actual tasks and guardrails. For structured content, compare the field model, templates and export path. Elementor, ACF and core blocks can each fit; no choice guarantees speed or consistency for years without maintenance.
What to do next
- Check whether your theme is a block theme or a classic theme, because that decides your tools.
- Take a backup and set up a staging copy before you change anything.
- Move any edits made directly to theme files into a child theme or theme.json.
- Put your theme customisations into Git. My list of WordPress developer tools covers the rest of a safe setup.
- Decide Elementor, ACF or both based on who edits the site each week.
- If you are weighing a page builder against a custom build, book a free call with me and my team.
Frequently asked questions
Will customising my theme stop it from updating?
Customising a theme through the Site Editor, the Customizer, Additional CSS or a child theme does not stop updates. Editing the theme’s own files does not stop updates either, but the next update overwrites those edits. That is why changes belong in a child theme, in theme.json within your own theme, or in a plugin.
Can I customise a WordPress theme without coding?
Yes. With a block theme, the Site Editor lets you change colours, fonts, spacing, headers, footers and templates without code. Classic themes offer the Customizer and theme options. Code becomes necessary when you need new functionality, custom templates beyond what the editor offers, or a design system that must stay consistent across many editors.
Do block themes need a child theme?
Often not. Block themes keep styling in theme.json, and Site Editor changes are stored separately from the theme files, so updates do not erase them. A child theme still helps when you want your customisations saved as files in version control. The Create Block Theme plugin can generate one for you.
Is Elementor bad for performance?
Elementor adds more code than a lean theme, so it needs care, but it is not automatically slow. Using its newer container layout, limiting add-on plugins, and tuning caching and images can get an Elementor site passing Core Web Vitals. Problems usually come from piling up widgets, add-ons and old layouts rather than from Elementor itself.
Should I pick a new theme or customise my current one?
Customise your current theme if it is maintained, fast and close to what you need. Pick a new one if it has not been updated for a year, fails accessibility or speed checks, or you are fighting it on every change. If you are choosing, start with a shortlist of well-maintained WordPress themes and test on staging.
