WordPress Site Editor missing: find the correct tool under Appearance

Check which editor you actually need

You are following a tutorial requiring Appearance → Editor, but this entry is missing from your WordPress administration. Before installing another tool, identify what you want to change: a page’s text, shared site structure, a theme setting, or a code file. These tasks use different screens.

The post or page editor handles its content. The Site Editor lets you work on templates, styles, and shared parts, particularly with a block theme. The Theme File Editor displays code and replaces neither visual tool. Its absence does not automatically explain a missing Site Editor.

The goal is to find the tool your installation can use, then understand any restriction. You do not need to change the public theme to establish this initial diagnosis. Also remember that menus may vary by account, theme, version, and platform.

1. Write down the element to change: paragraph, header, menu, colors, or template.
2. Note the entries actually visible under Appearance.
3. Confirm the site address and logged-in account.
4. Record the active theme before following a procedure intended for another theme.
5. Do not open the file editor in an attempt to obtain a visual screen.

Choose the approach according to theme and access

If your theme is classic, begin with the first approach. Absence of the full Site Editor may be normal; customization then uses the features actually supported by that theme. Using blocks in posts does not turn a theme into a block theme.

If a block theme is already active but the expected entry is missing, move to permissions and context checks. An author publishing posts does not automatically have permission to change templates for the whole site. The displayed role must be compared with actual permissions, especially on a site with customized administration.

The third approach is appropriate if you actually want full site editing. It involves trying a compatible theme on a copy after backup. This does not turn the test into an immediate public change: existing menus, headers, and settings require checking.

1. First identify the active theme and how it works.
2. For a classic theme, find the native tool or the one intended by its author.
3. For a block theme, compare the menu with an authorized administrator’s menu.
4. For a deliberate migration, prepare a copy and rollback.
5. Keep the three questions separate: compatibility, permission, and design choice.

Record the active theme without changing anything

This check is for an administrator with Appearance → Themes access. The theme marked active is the one that matters. A compatible theme merely installed in the library does not activate the full editor. If a child theme is active, also record its parent: a theme family’s marketing name is insufficient to identify the files actually used.

Tools → Site Health → Info also provides an active-theme section and version when your account can view it. Keep only details useful for diagnosis without sharing every technical site detail. Compare them with official documentation for that theme version.

The expected result is reliable identification of the theme, version, and site examined. This inspection changes no page and requires no rollback. If both Themes and Site Health are inaccessible, an administrator can supply this information from their own account.

1. Open Appearance → Themes.
2. Find the card marked Active and open its details.
3. Note the name, version, and any parent.
4. In Tools → Site Health → Info, compare the active-theme section.
5. Check the theme’s documentation to see whether it provides full site editing or only block features.

Approach 1: use a classic theme’s customization

With a classic theme, Customize is often the correct starting point. Open Appearance → Customize if this entry exists. Available panels depend on the theme: site identity, colors, menus, or other settings. A particular panel missing does not mean you must directly edit files.

This approach suits an authorized administrator wanting a theme-supported change, such as its logo. Record the current value, first make the change in preview, and check several pages before publishing the setting. For inspection only, exit without clicking Publish.

The expected result is either a setting meeting your need or confirmation that the theme does not provide that change in the Customizer. To undo a published change, restore the recorded value; do not erase all theme options. A complete header redesign may require a different approach from changing a logo.

1. Open Appearance → Customize.
2. Find the panel matching your need in this theme.
3. Record the initial setting, then change a single element in preview.
4. Check its display on desktop and phone.
5. Publish only the agreed change, or exit preview without applying it.
6. If no suitable setting exists, consult the theme documentation before searching for another tool.

Do not confuse Design, Patterns, and the full editor

In WordPress 7.1.4, core provides different labels depending on the theme. A block theme receives the Editor entry. For a classic theme, the menu may offer Design or Patterns depending on available features; Patterns is generally translated as Compositions in French. These labels do not guarantee that every theme template can be edited visually.

It is therefore possible to find a patterns or styles screen without all the capabilities shown in a tutorial about a block theme. A theme using editor styles or a modern configuration file is not automatically a full block theme.

This step is inspection. The expected result is recognition of the features actually present. Do not artificially rename a menu or add a theme file to force its classification.

1. Compare your menu entries with the WordPress version used.
2. Open Design or Patterns if available to your account.
3. Look at the sections actually offered without saving changes.
4. Compare them with the desired function, such as template editing.
5. If only a partial tool exists, return to theme choice instead of treating its interface as a full editor.

Approach 2: compare permissions on the same site

Editing theme options and templates requires permissions different from writing a post. In core, the corresponding access relies in particular on the edit_theme_options capability. An author or content editor does not necessarily have it. On a customized installation, the role name does not establish all its capabilities.

Ask an authorized administrator to open the same site with their own account. They should check the menu and active theme without sharing their password. The expected result is a reproducible difference: the tool appears for them but not you, or is missing for both.

If you actually need access, the owner chooses an arrangement appropriate to your task. Role changes take place in Users → All Users → Edit user when the administrator has that permission. Do not routinely promote an author to administrator for a one-off intervention; the owner can perform the change themselves.

1. Compare both accounts’ menus at the same site address.
2. Have the administrator record your role under Users.
3. Confirm whether your task includes shared theme settings.
4. Have only a justified permissions correction applied, or assign the work to the authorized account.
5. Log the affected account in again and verify access; keep the previous state to undo a temporary role change.

Check multisite or WordPress.com context

On multisite, make sure you are in the affected site’s dashboard, not only network administration. Themes available to that site depend on network permissions. Making a theme available does not automatically activate it; the site’s active theme still needs separate checking.

To allow a limited test, the super administrator can open My Sites → Network Admin → Sites, choose Edit beneath the affected site, then the Themes tab. There they make the selected theme available for that site when it is not already network-available. Activation then takes place from the relevant test site. Do not broaden availability to the whole network for a single diagnosis.

On WordPress.com, the expected access remains Appearance → Editor for a compatible theme. First check the selected site, your role, and its theme. A missing menu alone does not justify changing plans; do not confuse this diagnosis with a particular paid feature.

1. In multisite, open the exact site’s dashboard from My Sites.
2. Have the super administrator confirm theme availability if a test is planned.
3. On WordPress.com, select the intended site, then examine Appearance and the active theme.
4. Repeat the comparison with an authorized account in that same context.
5. Record the result without changing plans or activating a theme on the public site.

Technically confirm the theme type if necessary

This optional check is for a technician who already has WP-CLI and authorized access to the copy. It helps when a child, hybrid, or custom theme makes documentation ambiguous. Run the commands from the correct installation directory. Replace the example address with the test site’s address; in multisite, this choice is particularly important.

The first command records the active theme without requesting a new update check, thanks to --skip-update-check. The second asks core whether the active theme is recognized as a block theme. It displays block or non-block. It does not check your browser account’s permissions or guarantee that the interface will load correctly.

These expressions contain no option update or activation. WordPress and its components are nevertheless loaded; use the copy intended for diagnosis. Do not add code to theme files or skip theme loading to artificially obtain another response. If an error occurs, keep the message instead of inferring a type.

1. Confirm the copy’s directory, site, and address.
2. Run the active-theme list.
3. Run the classification expression and record its result.
4. Compare it with the menu and theme-card information.
5. There is no setting to undo for these two inspection expressions.

wp --url="https://copie.exemple.fr" theme list --status=active --skip-update-check --fields=name,status,version --format=table
wp --url="https://copie.exemple.fr" eval "echo wp_is_block_theme() ? 'block' : 'non-block';"

Approach 3: try a block theme on a copy

Choose this approach if you want full site editing and the current theme does not provide it. It requires a backed-up copy, an account authorized to activate themes, and a block theme compatible with the copy’s WordPress and PHP versions. Its official listing must confirm requirements; do not choose solely from a screenshot.

Open Appearance → Themes on the copy. If a compatible block theme is already installed, examine its details. Otherwise, use Add New Theme and check its listing before installation. The official directory has a block-theme selection for identifying candidates. Preview helps prepare the test, but activation on the copy allows the actual menu to be checked.

The expected result is Appearance → Editor appearing with the block theme active and an authorized account. This confirms an operating prerequisite; it does not demonstrate migration of your old design.

1. Record the initial theme, any parent, and important settings.
2. Back up the copy’s database and files before activation. Check that its emails, payments, tasks, and integrations cannot affect production services.
3. In Appearance → Themes, choose the verified compatible candidate.
4. Activate it only on this copy.
5. Reload administration and open Appearance → Editor.
6. Examine template access without saving any public change.

Assess the theme change before retaining it

Once the editor is visible on the copy, check the rest of the site. The new theme may present content differently and not reproduce the previous theme’s settings identically. A menu appearing is not enough to validate migration. Examine the homepage, a post, an internal page, menus, and shared areas before deciding.

Keep theme activation separate from changes saved in the editor. If you experiment with a style or template, note what changed. The copy’s backup remains the complete rollback for the test; reactivating the initial theme restores its behavior without guaranteeing reversal of every write performed by components.

The expected result is a documented decision: retain the current tool, prepare a migration, or reject the candidate. Do not automatically transfer the test database’s contents to the public site to gain the new menu.

1. Compare reference pages and navigation on the copy.
2. Check header, footer, forms, and mobile display.
3. Note elements needing reconstruction before a possible migration.
4. To finish simple diagnosis, open Appearance → Themes and reactivate the initial theme.
5. Check that its menus and rendering return.
6. If the test changed more settings, restore this copy’s backup after verifying its destination.

If a compatible theme and authorized account are not enough

If the theme is recognized as a block theme and the administrator still cannot see the expected menu, look for administration customization. A plugin or site-specific code may remove an entry. Hiding a menu and removing permission are different mechanisms; visual absence alone does not prove that the tool no longer exists.

This diagnosis requires a copy and an identified suspect component, such as a recent admin-menu change. Do not perform general deactivation on the public site. In Plugins → Installed Plugins, deactivate only that component on the copy, then compare the same account and theme.

The expected result is a reproducible link between the component and missing menu. Must-use or network-activated plugins may require separate intervention; not all can be deactivated on this screen. Keep their names and context for the person responsible for that configuration.

1. Record changes close to when the menu disappeared.
2. On the copy, deactivate only the administration plugin identified as suspect.
3. Reload the dashboard and examine Appearance with the same account.
4. Reactivate the component and check whether the absence returns.
5. Then correct its documented setting or targeted code; restore the initial state if the test explains nothing.

Confirm useful access and avoid false fixes

The correct result is not necessarily the word Editor appearing. With a deliberately retained classic theme, finding the correct setting in Customize may meet your need. With a block theme, the expected result is authorized access to the editor and actually supported functions. With an account restriction, the solution may be intervention by the owner without a role change.

Do not install a block plugin merely to make the full editor appear for a classic theme. A builder may provide its own editor with different logic; that is not an automatic repair of the native menu. Likewise, re-enabling PHP file editing does not meet this visual need and would introduce another type of intervention.

Keep a note of the theme, account, screen used, and conclusion. It will make future tutorials easier to follow: you will know whether they match your environment before looking for a nonexistent menu.

1. Repeat the workflow from the exact site’s dashboard.
2. Open the chosen tool with the intended account.
3. Check that the desired function is available without saving an unnecessary change.
4. Restore permissions or components temporarily changed during diagnosis.
5. Keep the migration decision separate from a simple access test.
6. If the screen opens but stays blank, handle that new symptom through its own diagnosis.

Match the need to the screen actually useful

To choose quickly, start from the intended change instead of the word Editor.

A free block plugin may enrich page content, but does not automatically turn a classic theme into a block theme. If the actual goal is a new header structure, first compare the existing theme’s function with a compatible theme on a copy. This decision is separate from assigning permissions: an administrator does not create a function the theme lacks. Preserve the initial theme and settings before any migration.

1. Change text on one page: Pages, then Edit the page. The theme may be classic or block-based.
2. Change a logo or color supported by a classic theme: Appearance, Customize, or the theme’s documented panel. Use preview and exit without publishing during diagnosis.
3. Change a shared structure with a block theme: Appearance, Editor, then the relevant template or template part. Check pages inheriting that structure before saving.
4. Modify PHP: this is not the visual-editor workflow. Assign the change to child-theme or plugin maintenance, with its copy and deployment.