Blog

You change a headline, click Update, refresh the live page, and the old headline is still there. Or the text changes and the spacing collapses on mobile. Or the edit link opens a purple screen that says Edit with Elementor and none of the tutorial steps match what you see.

Finding a page and typing in it is the easy part. The part that costs an afternoon is working out which layer of the site owns the thing you want to change. A page has content, but it also sits inside a template, which belongs to the theme, and editing a WordPress theme safely is a different job with different risks. Get the layer right and most edits take two minutes.

Open the right page before you change anything

Log in at yourdomain.com/wp-admin, open Pages, then All Pages. Hover the title of the page you want and click Edit. Make the change, click Update. That is the whole flow, and on a simple page it works exactly as it reads.

Two shortcuts save time on busy sites:

• Quick Edit. Hover the title in the Pages list and click Quick Edit to change the title, the slug, the status or the parent without loading the editor. Click Update in the same row.
• The admin bar. While logged in, open the page on the front end and click Edit Page in the black bar at the top. This is the reliable way to be certain you are editing the page a visitor is looking at, not a similarly named copy.

That copy problem is common enough to check for. Sites accumulate duplicates: /about/ and /about-2/, a seasonal landing page cloned three times, a translated version that looks identical in the list. Before editing, confirm the slug in the row matches the URL you visited. You need the Administrator or Editor role to edit published pages; Contributors can write but not publish.

The editor that opens tells you where the content lives

WordPress.org’s documentation calls the default editor the block editor, the WordPress editor or the Gutenberg editor, all the same thing. It builds a page out of blocks: paragraph, heading, image, buttons, columns, group. What you type there is saved into the page’s content, so it is the layer you can reach and change with no help.

Three other things can open instead, and each one means something:

• One large text area with a formatting toolbar. That is the classic editor, usually because the Classic Editor plugin is active or the page holds a Classic block. Content still saves into the page. Layout control is minimal.
• A button that says Edit with Elementor, Edit with Divi or Beaver Builder. The builder stores the layout in its own data, not in the page content. Elementor’s listing in the WordPress.org plugin directory describes it as a drag and drop website builder, and the practical consequence is that the page’s design belongs to it. Edit that page in the block editor and you either change text nobody sees or you wreck the layout. Stay in the builder, or rebuild the page deliberately. Our explainer on what a landing page builder really does covers that tradeoff.
• The Site Editor, reached through Appearance then Editor. WordPress.org’s documentation says the Site Editor is only available when a block theme is installed and activated. If Appearance shows an Editor item, part of what you see on your pages is a template, and headers and footers are template parts rather than page content.

The same distinction explains locked blocks. If you select a section and the layout controls are missing, you are usually inside a pattern, which opens in content-only editing, or inside a template part being edited from a template. Text is editable, structure is not. Edit the pattern at its source, or open the template part directly, which is the same path as editing the footer in WordPress.

Change the block, not the container

Most “I broke the design” damage is a container that moved. A paragraph sits inside a Group, which sits inside a Column, which carries the padding. Drag the paragraph and the spacing goes with it.

1. Open List View (the icon at the top left of the editor). It shows the real nesting. Select the block you mean to edit there, not on the canvas.
2. Use the sidebar, not just the toolbar. Dimensions, spacing, colour and typography live in the block settings panel on the right. If one call to action has custom padding and the next inherits theme defaults, they will look aligned in the editor and uneven on the live page.
3. Duplicate a section that already works rather than rebuilding one. Right-click the block in List View, choose Duplicate, then change the text. Inherited settings come with it.
4. Save a draft first on anything structural. Revisions are good for text and weak for layout, especially with synced patterns involved.
5. Preview in a new tab, and check it logged out. An incognito window shows what a visitor gets, without your admin styles or your cache.

For small markup fixes, the three-dot menu at the top right switches to the Code editor, and a Custom HTML block holds raw markup inside a page. Structural changes belong in a child theme, not in the page.

You clicked Update and the live page looks the same

The edit almost always saved. Something else is deciding what visitors see. Work down this list in order, because the cheap causes are also the common ones.

1. Your browser. Hard refresh with Ctrl+Shift+R, or Cmd+Shift+R on a Mac, then load the URL in a private window.
2. Site and CDN cache. Purge the caching plugin, then the host’s cache, then Cloudflare or whatever sits in front. Two cache layers with no exclusion for the admin will also break the editor itself, not only the front end.
3. The wrong page. Compare the slug you edited against the URL in the address bar. Duplicates and translated copies look identical in the Pages list.
4. A template is printing the homepage. Check Settings, then Reading, which is where WordPress decides whether the front page shows your latest posts or a static page. Even when that setting is right, the theme handbook’s front page hierarchy checks front-page.php before the page you selected, so a theme file can output a layout that owes nothing to the page editor. Change it in the template, in a child theme so an update does not wipe the work.
5. The content is builder data. Open the page and look for an Edit with Elementor or Edit with Divi link. If it is there, that is where the visible text lives.
6. You are looking at the wrong environment. Staging edits stay on staging until someone pushes them.

The WooCommerce Shop page deserves its own line, because it is the single most reported version of this. WooCommerce’s own documentation lists Shop, Cart, Checkout and My Account as pages created automatically during setup, and notes that Shop requires no content. WooCommerce builds the product listing on the fly. Editing that page does nothing. Change the Product Archive template in the Site Editor, use your theme’s catalog options under Appearance then Customize if it has them, or build a normal page with a shortcode such as [products columns="3" orderby="date"] and assign it as the shop page in WooCommerce settings.

If tracking down which layer owns a change is not how you want to spend the afternoon, SiteSelf handles WordPress page edits through chat: you say what to change, the agent finds the page, makes the change, fetches the result and reports what it changed and what it checked, and pages owned by Elementor, Divi or Beaver Builder are refused at the moment of work, with the reason.

When the editor will not load at all

A blank editor canvas, a critical error on the edit screen, or a 404 on the edit link is a different problem from an edit that does not appear. WordPress.org support replies and builder documentation converge on the same sequence. Follow it in order; the early steps are reversible and the last one is where people lock themselves out.

1. Browser and cache. Different browser, private window, cache cleared. Five minutes, and it settles a surprising share of cases.
2. All plugins off. Not two suspects, all of them. If editing works, reactivate one at a time until it breaks. The last one you switched on is the culprit. One WordPress.org thread titled “Cannot edit page until I disable BOGO” is a clean example of the pattern: the reporter first blamed the theme and the host, saw “You attempted to edit an item that doesn’t exist. Perhaps it was deleted?”, and found the answer in the plugin they had installed most recently. Our guide to fixing WordPress plugins that are not working walks the isolation process in detail.
3. Default theme. Switch to a recent bundled theme such as Twenty Twenty-Five and retest. Theme and core updates that land out of step are a repeatable trigger: a theme stylesheet loaded into the editor can render your content white on white.
4. Check /wp-json/. Load yourdomain.com/wp-json/ in a browser. You want JSON. A 403, a 404, an HTML page or a PHP warning printed above the JSON gives you the classic blank block editor. Resave Settings, then Permalinks, with no changes to reset routing, then look at security plugins and host firewall rules that filter that path.
5. PHP memory and logs. A white screen with nothing in the browser console usually means a PHP fatal error. Add define('WP_MEMORY_LIMIT', '512M'); to wp-config.php, and raise the server’s own memory_limit too, since WordPress cannot exceed it. Then read the PHP error log, or ask the host for it, because more memory hides a fatal error rather than fixing it. The white screen troubleshooting guide goes through the log reading.
6. Roles and capabilities, last. “Sorry, you are not allowed to edit this item” on an account that shows as Administrator usually means capabilities in wp_usermeta are wrong, or a membership or role manager plugin is overriding them, or you are an admin on a different site in a multisite network.

When to stop and get help

Stop at the database. Editing user capabilities by hand in phpMyAdmin is how people lose access to their own site, and it is the step to hand to a developer along with the error log. Stop too when the cause is a plugin’s code rather than its settings: a plugin that opens output buffering without closing it, or ships files with whitespace after ?>, corrupts the JSON the editor depends on, and only the plugin author or a developer can fix that. And back up before any of this, on a staging copy where you have one. Running a full plugin deactivation test on a live store during business hours is its own outage.

Frequently asked questions

The Services item in your header will not open on a phone. Or a quote form keeps arriving with an empty “Choose a service” value. Or the size picker on a product page renders, but there is nothing inside it. All three get searched as the same thing: a WordPress drop down list.

They are not the same thing. WordPress has no single dropdown feature. The phrase covers at least five surfaces, each owned by a different system, each with its own cause when it stops working. Picking the wrong one and fixing that instead is the expensive mistake here.

Which of the five dropdowns are you looking at

Before any of that, answer one question: is the site on a classic theme or a block theme. Classic themes store navigation in the Menus screen. Block themes store it in a template, edited through the Site Editor. If you are unsure which you have, open the Appearance menu and look at what is in it, the same test used for editing a WordPress theme safely: a Customize item points to classic, an Editor item points to block. WordPress.org’s documentation notes that 5.9 was the last version to include the Appearance Menus screen for all sites by default, and that block themes in 6.0 and later manage navigation through the Navigation block.

Editing the wrong screen for your theme type is the top reason people say “I saved it and nothing changed”.

Build a submenu on a classic theme

Go to Appearance then Menus. You need an editor or administrator account; no file access is involved.

1. Create a menu, or select the existing one from the dropdown at the top.
2. Add the parent item first, for example the Services page.
3. Add the child items below it.
4. Drag each child slightly to the right, under the parent. The item label changes to “sub item”. That indentation is the dropdown.
5. In Menu Settings, tick a display location such as Primary Menu. A menu with no location ticked renders nowhere.
6. Save Menu, then load the front end in a logged-out window and check desktop and mobile.

A correct result looks like this: hovering or tapping the parent reveals the children, and the parent still links to its own page if it has one. If the admin screen shows your items but the front end shows nothing, go back to step 5 first. Missing location assignment is the single most frequent cause, and it takes a minute to rule out.

Build a submenu on a block theme

Open Appearance then Editor, then Patterns or Templates, and open the template part that holds your header. Select the Navigation block inside it. The block’s documentation on WordPress.org covers creating a menu, selecting an existing one, and adding submenu items.

1. Select the link you want as the parent.
2. Use the block toolbar option to add a submenu, then type or search for the child pages.
3. In the Navigation block’s settings, check whether submenus open on hover or on click. Click is the safer default, because touch devices cannot hover.
4. Save, and confirm the change on the live header rather than in the editor preview.

The block-theme version of “nothing happened” is usually one of two things: the header template part contains no Navigation block at all, or the block points at a different menu than the one you edited. Both are visible in the Site Editor in about thirty seconds. The same template-part logic applies lower down the page, which is why editing the WordPress footer follows the same route.

Resist the urge to create a second menu when the first one will not appear. Duplicate menus are how a site ends up with different navigation on different templates.

Add a select field to a form without losing the answer

Form dropdowns come from the form plugin, not from WordPress. In a builder like WPForms or Forminator you drag in a Select field, type the options, and set required or multi-select in the field settings. Contact Form 7 does the same job with a form-tag; its documentation covers drop-down menus alongside checkboxes and radio buttons, and the starred version of a tag makes the field required:

[select* service "Web design" "SEO" "Maintenance"]

Four decisions matter more than the markup:

• Who maintains the list. If office staff need to rename an option next quarter, keep it in the plugin’s interface. Hard-coded options save nothing if every edit becomes a developer task.
• How long the list is. A fifty-item select is a scrolling problem. Split it into two dependent selects (category, then subcategory), or use radio buttons when there are five or fewer choices.
• What the empty state submits. A first option reading “Select…” must not be an acceptable value. Mark the field required so it cannot be submitted blank, otherwise that placeholder becomes a row in your reporting.
• Where the value lands. Send a test entry and check the notification email and the saved entry. A dropdown that works on screen and maps to the wrong field downstream still costs you the lead.

Dynamic options, pulled from products, posts or taxonomy terms, are possible but not from core alone. Custom fields with a select, a form plugin’s dynamic choices feature, or a small function that turns terms into options all work. The tradeoff is worth naming: business logic built around a niche plugin is hard to move if that plugin stops being maintained.

Fix a WooCommerce dropdown that is empty or missing

Variation pickers and the shop’s sort box fail for different reasons.

An empty variation dropdown. WooCommerce’s documentation describes variable products as a product type offering a set of variations with their own price, stock and image. The chain has to be complete: set the product type to Variable product, add the attribute with its values, tick Used for variations on that attribute, save, then generate the variations and give each one a price. A select can render and still be empty when the attribute exists but was never marked for variations, or when variations were never created.

A missing “Sort by” box. That control comes from the theme calling WooCommerce’s catalog ordering hook, woocommerce_catalog_orderby. Themes that build their own shop templates sometimes remove it. Restoring it is a template change, which means a child theme and file access, not a settings toggle. Check the theme’s own options first; some expose sorting as a checkbox.

A picker nobody uses. On mobile, a variation dropdown below the Add to cart button gets missed, and you hear about it as “the item is out of stock”. Put selectors above the button, label them explicitly (“Select size”), and show a clear message when nothing is chosen.

The dropdown exists but nobody can see it

Work down this order. It is the sequence that resolves these fastest, because each step is cheaper than the one after it.

1. Assignment. Classic: is a display location ticked. Block: does the header template actually contain a Navigation block, pointing at the right menu.
2. CSS. Right-click the parent item and inspect. If the submenu is in the page source but not on screen, it is a style problem, not a broken feature. The usual four: z-index too low so the submenu sits behind a sticky header, slider or the admin bar; overflow: hidden or a fixed height on a parent container clipping it; a visibility: hidden or display: none rule that never gets reversed; a gap between the parent and the submenu so the dropdown closes as the pointer travels toward it.
3. JavaScript. Open the browser console on the front end. Uncaught TypeError or ReferenceError: $ is not defined means the script that opens the menu died. WordPress loads jQuery in no-conflict mode, so custom scripts need wrapping:

   jQuery(document).ready(function($) {
     // menu code
   });

4. Conflicts. Deactivate plugins, reproduce, re-enable one at a time, then switch to a default theme such as Twenty Twenty-Five to isolate theme scripts. Do it on staging, or in a troubleshooting mode that only affects your own session, so visitors do not watch you work. The same method covers most cases where WordPress plugins are not working.
5. Caching. Purge every layer you have: the caching plugin, the host’s server cache, the CDN. Then turn off JS and CSS minification and combination, or exclude the menu’s scripts from them. Stale assets make correct fixes look like they did nothing.
6. Rebuild. After a migration or a repeated menu import, items can exist in the admin and never render. Delete that menu, rebuild it by hand, reassign the location.

One rule runs through all six: change one thing at a time. Disable five plugins at once and the symptom goes away without telling you what caused it.

If you would rather hand the diagnosis over, SiteSelf takes a report like “the Services submenu does not open on mobile” through chat, does the work on the live site, and reports what it changed and what it checked, which is the kind of request covered by WordPress bug fixes through chat.

When to stop and get help

Stop before you edit header.php or a wp_nav_menu() call in a parent theme, because the next theme update overwrites it. Stop if the site runs a theme header, a page builder header and a mega menu plugin at once; that is three systems competing for the same navigation, and the fix is choosing one and removing the others, which is a project rather than a tweak. Stop if a copied CSS or JS snippet changes behaviour you do not understand.

Make the dropdown work without a mouse

A dropdown that only opens on hover is finished for mouse users and broken for everyone else. Keyboard users cannot hover. Touch users cannot either.

For forms, the rule is short: every select gets a visible label associated with it through for and id, with unique IDs on the page. W3C’s WAI tutorial on labeling controls covers that association. Placeholder text inside the select is not a label, no matter how well it reads.

For navigation, W3C’s WAI tutorial on fly-out menus covers making submenus that open on hover also work from the keyboard. Test it yourself in two minutes: put the mouse aside, press Tab through the header, confirm every top-level item shows a visible focus outline, confirm Enter or Space opens the submenu, and confirm focus never vanishes behind a sticky header or an off-canvas panel.

Where you have a choice, use the native <select>. It is announced correctly by screen readers, it behaves the way each phone expects, and it survives plugin updates that break custom widgets. A custom dropdown with search, swatches or grouped options has to earn its place by adding something the native element cannot do, and then it owes you keyboard operation, focus management and correct roles and states.

Frequently asked questions

Enabling Multisite is one line in wp-config.php, one form in Tools, and two blocks of generated code. Most people get through it in ten minutes. Then the second subsite returns a 404, the admin loops back to the login screen, and the same ten-minute job turns into a day.

That gap is the whole subject. Multisite spans four layers that have to agree with each other: DNS, web server configuration, WordPress constants, and plugin behaviour. Nearly every reported failure is a disagreement between two of them, not a bug in WordPress.

It multiplies ordinary problems, too. One network-activated plugin that was never written for a network takes every subsite down at once, so the routine for a plugin that is not working applies across the whole install rather than one site. That is worth knowing before you enable anything.

Decide whether you need a network before you edit a file

WordPress’s own Advanced Administration Handbook opens its multisite preparation page with the question “Do you really need a network?” before it gets to any requirements. That order is deliberate.

Multisite fits sites that belong to the same organisation and share a stack: franchise locations, university departments, regional or language variants of one brand, an internal publishing group, a set of microsites built from the same base theme. One codebase, one update cycle, one hosting bill, shared users where you want them shared.

It fits badly when the sites are unrelated. The most common regret in practitioner threads is an agency that put a portfolio of unconnected client sites into one network for the convenience of a single dashboard. Shared convenience is shared fate: one compromise, one bad update, one runaway cron job, and everything is affected. Per-site experimentation gets awkward, and offboarding a client means extracting a subsite from the network, which is possible but not quick.

Two alternatives come up repeatedly and both are reasonable. Separate installs with a management tool across them gives you most of the single-dashboard benefit without coupling anything at the database level. Multi-tenant setups, where one codebase serves isolated sites without WordPress’s network tables, are a different answer to the same cost problem. Neither is Multisite, and neither carries its lock-in.

A short filter: if the sites will share users, themes and governance for years, Multisite earns its place. If any one site must be able to fail, move host or leave on its own, use separate installs.

What your host has to support before you touch wp-config.php

Most failed installs are host capability problems that surface halfway through. Check these first, because finding out afterwards means unwinding a half-configured network.

• Pretty permalinks already work on the single site. If they do not work now, they will not work network-wide.
• Rewrite support. On Apache, mod_rewrite has to be enabled or the .htaccess rules are ignored silently. On nginx there is no .htaccess at all and the rules belong in the server block, which means you need either server access or a host that applies them for you.
• Writable wp-config.php and .htaccess. If the files cannot be saved, the network looks installed and keeps behaving like a single site.
• Writable uploads tree. Each subsite gets its own directory under wp-content/uploads/sites/. Wrong ownership produces “Could not create directory” on the first media upload.
• Wildcard DNS, if you are going with subdomains, plus a virtual host or app mapping that accepts wildcard hostnames. Add the record and let it propagate before onboarding sites, or you will misdiagnose intermittent resolution as a WordPress bug.
• Headroom. A currently supported PHP version, a supported MySQL or MariaDB release, and enough memory and process allowance that network-wide operations do not fail at random.
• A full backup of files and database, taken and verified before you start.

Budget shared hosting is where this list gets expensive. Some plans do not expose wildcard subdomains, some do not let you touch rewrite configuration, and a few managed hosts either do not support Multisite or support it with limits on domain mapping. If your host treats server rewrites or wildcard DNS as a special case, that is the answer about whether Multisite is a first-class workload there.

Subdomains or subdirectories, decided once

Network Setup asks you to choose, and the choice is not cosmetic. It determines routing, cookie handling, certificate coverage and how domain mapping will work later. You cannot flip it afterwards with a config edit: changing structure after launch breaks URLs and internal links, and the honest path is a controlled migration.

Subdirectories (example.com/paris/) are the lower-friction option. No wildcard DNS, cookies are simpler to reason about, and your existing certificate covers everything. They suit sites that are genuinely one brand: regional sections, departments, campaign hubs.

Subdomains (paris.example.com) suit sites that need visible separation or will eventually run on their own domains. They need a *.example.com record pointing at the server, a web server configured to answer wildcard hostnames, and a wildcard certificate, which usually means DNS-based validation rather than the click-through flow you used on the single site. Trying to fake subdomain routing with rewrite tricks instead of fixing DNS is a reliable way to lose a day.

One thing that surprises people testing locally: if the site runs on localhost, on an IP address, or on a URL that already contains a path, Network Setup only offers subdirectories.

Running the installation

The handbook’s Create A Network article walks the same sequence every host guide repeats, from Step 0 “Before You Begin” through Step 6 “Administration”. Here it is with the parts that actually bite.

1. Back up files and database, and keep a copy of wp-config.php and .htaccess outside the site.
2. Deactivate plugins. All of them, on an existing site. Security plugins, redirect managers and cache layers interfere with Network Setup often enough that you end up debugging the wrong thing. Reactivate one at a time afterwards.
3. Add the constant to wp-config.php, above the /* That's all, stop editing! Happy publishing. */ line and not inside any if block or function:

   define( 'WP_ALLOW_MULTISITE', true );

   If that comment does not exist in your file, put it above the first require or include. Placed below it, or inside a conditional, Tools > Network Setup never appears.
4. Reload the admin and open Tools > Network Setup. Choose the structure you already decided on, check the network title and admin email, and submit.
5. Paste the two generated blocks exactly as shown, into wp-config.php and .htaccess. Do not tidy them, do not adapt a version from a tutorial, and do not merge the .htaccess block with your old rules.
6. Log out and log back in. Network Admin appears under My Sites only after a fresh login. “The install finished but there is no Network Admin” is almost always this.

On a subdirectory network the generated constants look like this, with your own domain in place:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

A subdomain network gets the same constants with SUBDOMAIN_INSTALL set to true. DOMAIN_CURRENT_SITE has to match the primary site URL exactly, with no trailing slash and with www. present or absent exactly as the site runs. If you see COOKIE_DOMAIN suggested in a tutorial, leave it out unless you have a tested reason; copied cookie settings cause a lot of avoidable login trouble.

The Apache block for a subdirectory network replaces the entire existing WordPress section of .htaccess:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

What a correct result looks like

Before you create real sites, confirm all of this:

• Network Admin is reachable from My Sites in the admin bar.
• Settings > Permalinks saves without error on the main site.
• A throwaway test subsite loads its own front page, not the main site’s, and its admin does not loop at login.
• A media upload on that test subsite succeeds and lands in wp-content/uploads/sites/2/.
• Reactivated plugins still behave on both the main site and the test subsite.

If something looks off, do not re-run Network Setup repeatedly hoping for a different outcome. By then WordPress has written constants and database records; re-running on top of a partly configured install adds duplicates to untangle.

If it did not work, check the layers in order

The single most useful habit here is changing one layer at a time, from the outside in. Practitioners converge on the same order, for the same reason: each step’s result is then readable.

1. DNS and host routing. Wildcard record present and propagated, server configured to answer wildcard hosts, mapped domains pointing at the right place.
2. Server modules and permissions. mod_rewrite or the nginx equivalent, writable config files, PHP version and memory.
3. The constants from Network Setup, SUBDOMAIN_INSTALL in particular.
4. Rewrite rules, then Settings > Permalinks > Save Changes on each affected subsite to flush them.
5. Plugins, deactivated network-wide and re-enabled one by one.
6. The database, last.

Two symptoms tell you which layer you are in without any guessing. If a broken subsite shows your host’s branded 404 page, the request never reached WordPress, so the problem is DNS or server routing. If it shows your theme’s 404 page, WordPress answered and the problem is rewrite rules or constants.

The failures that account for most of it

Every subsite 404s, the main site is fine. Rewrite rules. Usually someone merged the new network block into the old single-site rules instead of replacing the WordPress section outright. Re-copy the block from Tools > Network Setup, replace the whole section, flush permalinks.

Subsites load the main site’s content, or core assets 404 with a subdirectory in the path like /site1/wp-includes/js/jquery.js. Constants. Check DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE against the real primary URL, confirm SUBDOMAIN_INSTALL matches the structure the rewrite rules describe, delete any duplicate definitions, then flush permalinks.

White screen or a 500 straight after saving wp-config.php. PHP syntax, almost always: a missing semicolon or smart quotes from a copy and paste. Nothing renders and the error is in the log, not on screen.

Network Setup never appeared. The constant is below the stop-editing comment, inside a conditional, or the file never saved because the host would not write it.

Subdomains do not resolve at all. Missing wildcard DNS, a server that is not configured for wildcard hosts, or a certificate that covers the apex domain and nothing else.

Network problems are unusually good at pointing at the wrong cause, and the fix often sits in files you reach over SSH rather than in the dashboard. If you would rather hand that over, SiteSelf fixes WordPress errors on request: you describe the symptom in chat, the agent works on the live site, and it reports what it changed and what it checked.

Plugins, themes and code in a network

In Multisite, only the Network Administrator installs plugins and themes. A beginner on r/WordPress who selected Multisite during setup by mistake reported the giveaway clearly: there was no Add Plugin button on the site they were working in. They removed the network and reinstalled.

Installation and activation are separate. A plugin is installed once at network level, then either network-activated across every site or made available for per-site activation. Those are different states, and several plugins built for networks, including WP Multi Network by John James Jacoby, which turns one Multisite installation into several networks, only work correctly when they are network-activated. Activating them per site produces partial behaviour that is hard to read.

Keep network activation for things every site genuinely needs. Themes work the same way: Network Admin decides what is available, each subsite picks from that list, and the shared stack is the point. Note that the Theme File Editor is restricted in a network by default, which changes how you edit theme files safely.

If you write custom code for the network, two habits save later pain. Guard multisite-only calls such as switch_to_blog() with is_multisite() so the code does not fatal if it ever runs on a single site. And use home_url() or site_url() in templates rather than hard-coded domains, so mapped domains and per-site URLs resolve correctly.

Three things people expect to be built in and are not: cross-subsite user access (adding a user to the network does not give them access to every site), search across all sites in the network, and pulling one subsite out into its own install. All three need plugins or custom work.

Moving a network later

A Multisite moves as one piece. Site-by-site migration is where these projects die, because shared user tables, per-site media directories, network-level plugins and domain values stored in both the database and the config files all have to land together. When you fix URLs after a move, WP-CLI’s wp search-replace searches through all rows in a selection of tables and replaces the first string with the second. Run it with the network flag so it covers every subsite, and skip the guid column, because rewriting GUIDs causes more trouble than it solves. If tables come out corrupted, wp db repair first, restore from backup if errors persist, and check wp_blogs and wp_site for duplicate entries.

Frequently asked questions

WP-CLI names the object first and the action second. The command is wp plugin list. Type wp list plugin into a terminal and you get a usage error, not a list, and that single transposition explains a good share of the searches for the phrase.

The other group of people typing it want something else entirely: a list of posts, categories, headings or products rendered on a page. That is a front-end job with its own set of tools, covered in what a wp list plugin is and how to pick one. This page is about the terminal command and the inventory it produces.

What wp plugin list prints, and what it needs to run

WP-CLI’s reference page for wp plugin list says it displays the plugins installed on the site along with activation status and whether an update is available. In practice that is four columns: name (the plugin folder slug, not the pretty title), status, update, and version.

Two things have to be true before it works. WP-CLI has to be installed on the server, and you need SSH access with a shell user that can read wp-content/plugins. Shared hosting without SSH rules this out; skip to the admin-screen method further down.

cd /var/www/example.com/htdocs
wp plugin list

Output looks like this:

+--------------------+----------+-----------+---------+
| name               | status   | update    | version |
+--------------------+----------+-----------+---------+
| akismet            | active   | none      | 5.3.3   |
| classic-editor     | inactive | none      | 1.6.5   |
| contact-form-7     | active   | available | 5.9.8   |
+--------------------+----------+-----------+---------+

The status column is the one people misread. inactive means installed but switched off, and an inactive plugin still has its PHP files sitting on disk where a known vulnerability can be reached in some configurations. Inactive is not removed.

The flags that turn output into an audit

The bare command is a glance. The flags are what make it useful on a Monday morning when someone asks which of forty sites is running the plugin that just got a CVE.

• --status=active or --status=inactive narrows the list to one state.
• --update=available shows only plugins with a pending update.
• --field=name returns a single column, one value per line, ready to pipe.
• --fields=name,version,status picks the columns you want, in order.
• --format=csv or --format=json changes the output shape for spreadsheets and scripts.
• --path=/var/www/example.com/htdocs tells WP-CLI where WordPress lives if you cannot change directory first.
• --url=example.com targets one site in a multisite network.

The combination worth memorising is the CSV export:

wp plugin list --field=name --format=csv > plugins.csv
wp plugin list --fields=name,version,status --format=csv > inventory.csv

That is the whole answer to “how do I get a spreadsheet of every plugin on this site”. You do not need to install a plugin to list your plugins. Adding a single-purpose utility to export something the command line already prints adds code, an update obligation and one more thing that can go unmaintained.

For a network, loop the sites and tag each row with its URL so the rows stay distinguishable after you merge them:

for site in $(wp site list --field=url); do
  echo "$site"
  wp plugin list --url="$site" --fields=name,status,version --format=csv
done

What each error message actually means

“Error: This does not seem to be a WordPress installation”

You are not in the WordPress root. Either cd into the directory that holds wp-config.php and wp-content, or pass --path.

The version of this that bites hardest is pasting the example path from a tutorial. --path=/var/www/html/wordpress exists on a lot of demo servers and almost no real ones. If it happens to match a stale copy or a staging clone, the command runs, prints a clean list, and you walk away from a security audit with a false all-clear. Confirm the path with pwd or your host’s document root setting before you trust the output.

“wp: command not found”

WP-CLI is not installed, or the wp Phar is not in your $PATH. Managed hosts usually document their own install path or alias; some require you to call a versioned binary such as wp-cli or a PHP-specific wrapper. Check the host’s SSH documentation before installing your own copy into a home directory.

Permission errors, and the root habit that causes them later

The shell user needs read access to wp-content/plugins. Run as the user that owns the WordPress files:

sudo -u www-data wp plugin list

wp plugin list is read-only, so root does no damage here. The problem is the muscle memory. The same session usually continues into wp plugin update, which writes files as whoever ran it, and now PHP-FPM owns nothing and updates from the dashboard start failing with permission errors nobody connects to last week’s terminal session.

Plugins that look missing on multisite

Network-activated plugins and per-site-activated plugins are different states. Run the command against one site with --url=example.com and you see that site’s picture, which is not the network’s picture. Administrators regularly conclude a plugin has vanished when they are simply asking the wrong context. Decide which scope you want before you read the list, and label the export accordingly.

An update list that is short but wrong

This is the failure worth being paranoid about. --update=available depends on WordPress being able to reach the WordPress.org update API. If a host firewall, a security plugin or an outbound proxy blocks that request, the command returns a short list of updates and everything else looks current. Nothing errors. The site reads as patched.

Cross-check when the result looks suspiciously clean: open Dashboard then Updates in wp-admin, or compare against the version numbers on the plugins’ own WordPress.org pages. A network of sites that all report zero pending updates on the same day is a connectivity story, not a maintenance achievement.

A list is not an audit until you act on it

Producing the inventory is step one. The failure that managed hosts keep writing about is owners who run the list, see an unpatched or closed plugin, and leave it active. The sequence that finishes the job:

1. wp plugin list --update=available to see what has a fix waiting.
2. Update what is patched. wp plugin update --all for bulk, on staging first if the site earns money.
3. Check anything with no update against its WordPress.org page. A plugin whose listing has been closed will not get a patch.
4. Deactivate and then delete what cannot be fixed. wp plugin deactivate slug followed by wp plugin delete slug removes the files rather than parking them.
5. Re-run the list and keep the CSV. That file is your evidence of what the site looked like on that date.

Step four is where people stall, because deleting a plugin means replacing whatever it did. Budget for that rather than postponing it, and if a broken plugin is the reason you are running the audit in the first place, work through fixing WordPress plugins that are not working before you start deleting things.

If the running and the reading and the replacing is the part that never gets scheduled, SiteSelf handles WordPress plugin updates and removals through chat: you describe the audit you want, the agent does the work on the site with the access you have given it, and reports what changed and what it checked.

Listing your plugins without SSH

The Plugins screen in wp-admin carries the same information with a worse export story. The filter links above the table split the list into All, Active, Inactive, Update available and, when relevant, Recently Active and Drop-in. Set the screen to show all plugins per page from Screen Options, then copy the table into a spreadsheet by hand.

FTP or the host’s file manager is the last resort. Browsing wp-content/plugins shows you folder names and nothing else: no versions, no activation status, no update state. It answers “what is installed” and none of the questions that matter for security.

If you wanted a list on the page, not in the terminal

Half the traffic to this phrase wants output a visitor can see. The command has nothing to do with that. Name the list type first, because it decides the tool:

• Headings in a long article. A table of contents plugin builds the list from the content. Easy Table of Contents, in the WordPress.org directory, generates one automatically from the headings in posts, pages and custom post types.
• Posts from a category. List Category Posts lists posts by category in a post or page using the [catlist] shortcode, with options such as [catlist name="news"].
• A queried list inside a block theme. Try the core Query Loop block before installing anything. It covers most recent-posts and category-feed layouts.
• Tabular data you maintain by hand. A table plugin, not a post-query plugin. Asking a query tool to behave like a spreadsheet ends badly.
• Your installed plugins shown publicly. Possible with a shortcode plugin, and rarely a good idea. A published list of your plugins and versions is a map for anyone scanning for known vulnerabilities.

When one of these goes wrong, the cause is almost always setup rather than code. A shortcode rendering as literal [catlist] text on the page means the plugin is not activated, the shortcode has a typo, or it sits in a context that does not run shortcodes. A blank list usually means the plugin has nothing to list yet because its items or categories were never created.

Frequently asked questions