Why You Can’t Edit Your Own WordPress Site and Who Decided That for You

Wordpress
Author George MantyPosted on Categories CMS, Digital Marketing, Web Development, Wordpress

We regularly hear from business owners who need help with their WordPress sites.

They often don’t understand why they can’t make basic changes themselves. Their sites weren’t built using WordPress’s normal editing tools, so they may be unable to change an image, update a navigation menu or edit part of a page without calling the original developer.

They shouldn’t have to understand the technology behind the site just to make ordinary updates.

Sometimes the problem is obvious. The header and footer simply aren’t editable anywhere in WordPress. Other times, the site looks editable until you try to change something the original developer didn’t plan for. You can update the words in a section, for example, but you can’t add a new section, move anything around or change how the page works.

In other cases, the site depends on a page builder, custom development framework or completely separate front-end application. The business owner may not even know any of that is there until the original developer is gone and somebody new has to work on the site.

That’s usually when the real cost of those decisions becomes clear.

WordPress itself can be extremely editable. Whether your particular WordPress site is editable, though, depends heavily on the decisions made by the people who built it.

And a lot of business owners don’t discover those decisions until years later, when they need to make what sounds like a simple change and find out that their WordPress site doesn’t work the way they thought WordPress worked.

What Should You Normally Be Able to Edit in WordPress?

Modern WordPress gives website owners a lot of control without requiring them to touch code.

With a WordPress block theme, the built-in Site Editor can be used to edit the header, footer, navigation, templates, page layouts, colors, typography and other parts of a website. WordPress specifically describes block themes as themes that use blocks for all parts of the site, including navigation, headers, content and footers.

That doesn’t mean every business owner needs the ability to redesign every pixel of the site.

There are perfectly good reasons to put some guardrails around a website. You probably don’t want someone accidentally deleting the company navigation while trying to change a phone number five minutes before leaving for lunch.

But there’s a big difference between protecting a site’s design and creating a site that only its original developer understands.

You should have reasonable control over the things your business changes regularly.

And another experienced WordPress developer should be able to take over the site without first having to learn an entirely different development system.

That’s where things sometimes go sideways.

Here are six common ways WordPress sites become harder to edit, maintain or hand off.

1. There’s Another Templating System Sitting on Top of WordPress

Some developers use additional templating systems to build WordPress themes.

Two examples are Timber with Twig and Roots Sage with Blade.

Timber lets developers create WordPress templates using the Twig templating language instead of putting all of the template logic directly into traditional PHP theme files. Timber’s own documentation shows WordPress page templates being rendered through separate .twig files.

Sage takes a different approach but adds its own development stack. Sage uses Laravel’s Blade templating engine, and its current development process includes Composer and Vite for building theme assets.

There are good reasons developers like these systems. They can make development cleaner and give developers tools they prefer working with.

The tradeoff is that you’ve added another layer between WordPress and what visitors see.

That’s fine if the people maintaining the website know that layer.

It becomes a problem when a business owner calls another WordPress company three years later and asks them to change something in the header.

Before anyone changes the header, they may first need to figure out how the previous developer built and deployed the theme.

The giveaway: You can edit the words inside your pages, but parts of the site such as the header, footer or page structure seem to be missing from the WordPress editor. When you ask how they’re built, you start hearing words like Twig, Blade, Composer, Vite or build process.

2. Your WordPress Installation Isn’t Laid Out Like a Typical WordPress Installation

Bedrock is another example.

Bedrock is a WordPress development framework from Roots that changes the normal WordPress file structure and configuration process.

It manages WordPress and plugins through Composer, stores configuration in environment variables and moves WordPress into a different directory structure. What would normally be wp-content, for example, becomes web/app, while WordPress core lives under web/wp.

Again, there’s nothing inherently wrong with that.

Roots created Bedrock this way intentionally, and for a development team that knows the system, it can provide a cleaner development and deployment workflow.

But the next company working on your website now needs to understand Bedrock too.

Bedrock is also often paired with Sage. In that situation, someone taking over the website may encounter a different WordPress file structure, Composer-managed dependencies, environment configuration, Blade templates and a Vite asset-building process.

That’s quite a stack just to get to WordPress.

The important question isn’t whether Bedrock or Sage is good or bad.

It’s whether your project needed that extra complexity, whether you knew it was being added, and whether anyone thought about how the website would be handed off later.

The giveaway: Your hosting company or a new developer goes looking for the usual WordPress file structure and quickly realizes your installation works differently.

3. WordPress Is Only Half of Your Website

Then there’s headless WordPress.

On a traditional WordPress site, WordPress manages your content and generates the website visitors see.

On a headless WordPress site, those jobs are separated.

WordPress becomes the content-management system in the background, while a separate application creates the actual website. That front end might be built with Next.js, React or another JavaScript framework.

There are projects where this makes a lot of sense. A large publisher might need to send the same content to a website, app and other systems. A complex web application may also benefit from separating the front end from WordPress.

But a typical small-business website may not need a second software application just to display its About page.

Separating the two also means some familiar WordPress behavior has to be recreated.

WP Engine, which offers a platform specifically for headless WordPress, describes its Faust.js toolkit as a way to bring WordPress features such as previews and page template hierarchy into headless projects. That tells you something important: those features aren’t automatically connected to the separate front end the way they are on a traditional WordPress site.

You may now have two codebases, two sets of dependencies and a separate deployment process to maintain.

The giveaway: You make a change in WordPress but Preview doesn’t show the website correctly, or design changes require a developer to change and deploy a separate application.

4. Your Page Builder Became Part of Your Content

Page builders made WordPress much easier for a lot of people to edit, but they can also create another kind of dependency.

The details matter because different builders work differently.

WPBakery, for example, has long been closely tied to WordPress shortcodes. Its own documentation includes tools specifically for turning shortcodes into WPBakery content elements.

That’s why anyone who has inherited an older WPBakery site has probably seen pages containing things like:

[vc_row]

[vc_column]

and a whole lot more stuff inside brackets.

Older versions of Divi used a similar shortcode-based system.

Elegant Themes has been very open about this. When developing Divi 5, the company completely replaced that architecture and specifically cited the problem of Divi shortcodes remaining in page content after someone moved away from Divi. Divi 5 now uses a different storage system rather than the old shortcode framework.

Elementor works differently, so it isn’t accurate to say every page builder creates the same problem.

But the larger concern still applies.

When most of your site’s layout depends on a proprietary builder’s widgets, templates and settings, changing builders later may mean rebuilding substantial parts of the website.

A page builder can make a site incredibly easy to edit while you’re using it.

The dependency becomes obvious when you want to leave it.

The giveaway: Nearly every important page requires a specific builder, and nobody can clearly explain what happens to those pages if you stop using it.

5. The Builder Replaced the WordPress Theme System

Some tools go further than building pages.

Oxygen is one of the clearest examples.

Oxygen’s own documentation says that activating it completely disables the default WordPress theme system. Your normal WordPress theme’s layout and styles are no longer being used.

That’s not an accidental side effect. It’s part of how Oxygen works.

It gives the builder control over the entire site, including headers, footers, templates and layouts.

But it also changes assumptions that other WordPress tools may make about the site.

Oxygen’s documentation even notes that PHP code placed in a theme’s functions.php won’t work normally because the theme system has been disabled. It recommends putting that code in a plugin or another code-management system instead.

Oxygen has tools and integrations designed to work around these differences, and an experienced Oxygen developer may be perfectly comfortable maintaining a site this way.

The issue comes later.

If you decide you no longer want to use Oxygen, switching to a standard WordPress theme isn’t simply a matter of clicking Activate and cleaning up the colors. Oxygen may have been responsible for the site’s entire design and template system.

The giveaway: Traditional WordPress themes don’t seem to have anything to do with how your site looks, and the site has to be maintained through its own separate site-building system.

6. The Custom Theme Only Lets You Edit What the Developer Expected You to Edit

This one doesn’t have a product name.

And I’ve seen it a lot.

A developer creates a custom WordPress theme and gives the client a collection of custom fields for managing the page.

Headline goes here.

Photo goes here.

Button text goes here.

Maybe there are fields for three feature boxes.

It works beautifully.

Until the business needs a fourth box.

There isn’t one.

Or they want to move a section higher on the page.

They can’t.

Or they want to add a new type of content that wasn’t imagined when the site was built.

Now they need a developer.

Advanced Custom Fields, usually called ACF, is commonly used to build sites this way. But ACF itself isn’t the problem.

In fact, ACF’s Flexible Content feature specifically allows developers to create reusable layouts that editors can add and arrange.

The problem is how the website was designed.

If every page consists of a rigid template with a fixed collection of fields, you haven’t really been given a page editor.

You’ve been given a form for filling in somebody else’s page.

That can be perfectly appropriate for certain projects. If a company needs 5,000 product pages to follow exactly the same structure, strict fields can be a feature.

It becomes frustrating when that same approach is applied to pages the business reasonably expects to change.

The giveaway: You can change the words and images on a page, but you can’t add, remove, move or substantially change its sections.

Why Do Developers Build Sites This Way?

Usually there isn’t some evil developer sitting in a dark room plotting to make sure you need them forever.

Developers choose tools because those tools solve problems.

Twig or Blade can make templates easier for a development team to manage.

Composer can make software dependencies more predictable.

Custom fields can stop editors from accidentally destroying carefully designed layouts.

A page builder can make development dramatically faster.

Headless WordPress can solve real technical problems for the right organization.

Oxygen gives a designer far more control over the site than a traditional theme.

These are real benefits.

The problem comes when the developer’s experience building the website becomes more important than the client’s experience owning it.

The development team may spend three or six months building your website.

You could spend the next two to eight years owning it.

That’s a very different timeline.

We’ve taken over WordPress sites built in just about every way imaginable. One of the biggest hidden costs of an unusual setup is simply figuring out what the previous developer did before we can safely change it.

The more specialized the stack is, the smaller the pool of people who can easily work on it.

That doesn’t automatically make the technology wrong.

But it should be part of the decision before the site gets built.

How Can You Tell What Kind of WordPress Site You Have?

You can learn quite a bit about your site without becoming a developer.

Start in the WordPress dashboard.

Go to Appearance and see what theme is active.

If you’re using a modern block theme, you should normally see Appearance → Editor. WordPress’s Site Editor is designed to let you work with things such as templates, headers, footers, styles and navigation.

Next, open a few important pages.

Can you edit them directly in WordPress?

Do they have a button that says something like “Edit with WPBakery,” “Edit with Elementor,” “Use Divi Builder” or another builder name?

Now try to find your header and footer.

Can you edit them?

Create a draft page and try Preview.

Does it show you an accurate preview of the website?

If you have a staging copy of the site, a developer can also safely investigate what depends on the theme or page builder without risking the live website.

Don’t start randomly disabling plugins on your production site just to see what happens. That’s a good way to turn a five-minute investigation into a much more interesting afternoon.

You don’t need to understand every piece of technology involved.

You mainly want to know how dependent the site is on any one developer, theme, builder or development system.

Three Questions to Ask Before Your Next WordPress Site Is Built

If you’re hiring someone to build a WordPress website, ask these three questions before development begins.

1. If your company disappeared tomorrow, could another experienced WordPress company take over this site?

A developer may use custom technology and still have a perfectly good answer.

What matters is whether there is a reasonable handoff path.

2. Can I change my own header, footer, navigation and normal page content without calling you?

You don’t necessarily need access to every technical setting on the site.

But ordinary business changes shouldn’t require a developer every time.

3. What happens if we eventually stop using this theme, page builder or development system?

This may be the most important question.

Ask what happens to your content.

Ask what needs to be rebuilt.

Ask whether another developer needs special tools or knowledge to maintain the site.

Ask it before you spend the money.

A complicated answer isn’t automatically a bad answer.

But you deserve to know what you’re buying.

Your Website Should Still Be Yours After the Developer Leaves

Websites change.

Employees change.

Agencies change.

Technology changes.

A WordPress site shouldn’t depend forever on the exact developer who happened to build version one.

Sometimes a complicated development setup is absolutely justified.

Most of the time, though, we prefer the simplest system that does the job well.

At MantyWeb, we’ve been working with WordPress for more than 20 years. We’ve inherited custom themes, abandoned builders, strange hosting setups, mystery shortcodes and plenty of websites where changing one sentence somehow turned into a development project.

That experience has changed how we build sites ourselves.

We want our developers to be able to work efficiently.

But we also want our clients to be able to edit the things they should reasonably be able to edit.

And if somebody else has to take over one of our sites someday, they shouldn’t need an archaeological expedition to figure out how it works.

If you own a WordPress site that you can’t seem to edit, or you’ve been told that a seemingly simple change requires a surprisingly large development project, feel free to contact us.

We can take a look at how the site was built, explain what you’re dealing with in plain English, and help you figure out the most practical way forward.

Sources & Further Reading

Back to Blog