Give your WordPress site its first task.
Connect the site you already have, add your agent to Slack or Telegram, and tell it what you need.
Connect your siteStart with 500 free credits. No credit card needed.
On this page
Key takeaways
- The command is wp plugin list, not wp list plugin. WP-CLI’s docs describe it as showing the plugins installed on the site with activation status and whether an update is available.
- Most wp plugin list failures are environmental: you are in the wrong directory or passing the wrong –path, WP-CLI cannot reach the database, or the shell user cannot read wp-content/plugins.
- Front-end list plugins usually fail for configuration reasons, not bugs: wrong folder, not activated, a parameter that does not match a real slug or ID, nothing to list, or a cached page.
- Core handles more list jobs than people expect. The Query Loop block displays posts by specified parameters, and wp_list_categories() outputs a category list without a plugin.
- If the Plugins screen fatals right after a core update, one known cause is an invalid recently_activated row in wp_options. Delete the row rather than editing it, and check your real table prefix first.
“wp list plugin” is not the name of a plugin. It is what people type when they want one of four different things, and those four have almost nothing to do with each other.
- An inventory of the plugins installed on a site, usually from the command line.
- A list of content on the front end: posts in a category, a team page built from users, a table of contents from headings.
- A table of structured data that is maintained by hand, like a price list or a spec sheet.
- The WordPress admin Plugins screen, specifically when it stops opening after an update.
Search results mix all four, which is why the first search rarely helps. The fix is to name the object you are listing and who reads the list. A heading list for readers, a post query for a resources page, and a CSV of active plugins for your own records need three different tools. This article separates them, gives the command or the setting for each, and covers the failure modes that follow. If the reason you are looking is that something already broke, start with the guide to plugins that are not working and come back here for the inventory part.
Listing the plugins you have: wp plugin list
WP-CLI puts the noun before the verb, so the real command is wp plugin list. There is no wp list plugin alias. WordPress’s developer documentation describes the command as displaying the plugins installed on the site with activation status and whether an update is available.
wp plugin list
wp plugin list --status=active
wp plugin list --update=available
wp plugin list --fields=name,version,update
wp plugin list --format=csv > plugins-inventory.csvThose last two are the ones that earn their keep. --update=available answers “what needs updating right now” in one line, across one site or fifty. The CSV export answers “what was active before I started touching things”, which is the record you want when a conflict hunt goes sideways and you need to put the site back the way it was.
No shell access? The same inventory is on the admin Plugins screen at wp-admin/plugins.php, filtered by Active, Inactive and Update Available. It is slower to read and harder to keep a copy of, but it is the same data. Must-use plugins are the exception: they live in wp-content/mu-plugins, load unconditionally, and cannot be deactivated from that screen, so an audit that ignores them is incomplete.
Why wp plugin list fails or shows the wrong plugins
Ranked by how often it actually happens:
- Wrong working directory or wrong
--path. WP-CLI needs to run inside the WordPress install or be told where it is:cd /var/www/mysite, orwp plugin list --path=/var/www/html/wordpress. Pointing--pathat the document root when WordPress lives in a subdirectory meanswp-config.phpis never found. The worse version of this mistake is pointing it at a staging install: you get a clean, plausible list that describes the wrong site. - WordPress or the database cannot be loaded. WP-CLI reads the same
wp-config.phpthe site does, so bad credentials or a down database server break every command that boots WordPress. Repair the credentials rather than experimenting in that file: a stray character inwp-config.phptakes the site down along with the CLI. - Filesystem permissions. The shell user needs read access to
wp-content/plugins. Wrong ownership produces read errors or a short list. Fix the ownership. Do notchmod 777the plugin directories to make the error go away, because that trades a listing problem for a security problem and many hosts will flag it.
Listing content on the front end: match the tool to the object
This is the job most people mean when they want a plugin. The selection error that costs the most time is choosing by layout (“I want cards”) instead of by object (“I am listing posts from one category”). Plugins are not interchangeable across object types.
| What you are listing | Start with |
|---|---|
| Posts, pages or a custom post type, on a block theme | The core Query Loop block, which WordPress’s documentation describes as displaying posts based on specified parameters |
| Categories or terms as a simple index | Core’s wp_list_categories(), which displays or returns the HTML list of categories |
| Posts from one or more categories, inside classic content | List Category Posts, which lists posts by category using the [catlist] shortcode |
| Hand-maintained tabular data such as a price list or spec sheet | TablePress, which creates and manages data tables without writing code |
| A clickable list of the headings inside one article | Easy Table of Contents, which inserts a table of contents generated from the page content into posts, pages and custom post types |
Try core before you install anything. A Query Loop block and a category list cover a surprising share of “I need a list plugin” requests, and they carry no update burden of their own. Reach for a plugin when the list needs something core does not do: grouping posts under year or author headings, a searchable catalog table, filtering by custom fields.
Check the plugin page before you install, not after. WordPress.org shows a compatibility warning on plugins that have not been tested with the latest three major releases, and the Display Posts plugin page carried that warning when we checked it in September 2023. That notice is not a verdict, but on a plugin whose whole purpose is rendering a list on a public page, it is a reason to look at the support forum before committing a client site to it.
Why the shortcode outputs nothing
Almost every “this plugin is broken” report for a list plugin turns out to be one of five configuration problems. Work down the list before you open a support ticket or swap plugins.
- Wrong directory. The plugin folder belongs in
wp-content/plugins/<slug>/. Uploads that land inmu-pluginsor one level too high look installed and behave like nothing. - Uploaded but never activated. A shortcode for an inactive plugin prints as plain text or prints nothing at all.
- Parameter mismatch. The three classics: using a category label where the slug is required, pasting the documentation’s example ID instead of your own list ID, and using a plugin’s display name where its WordPress.org slug is wanted, such as “Akismet Anti-Spam” instead of
akismet. - Nothing to list. An empty taxonomy, no items created yet, or users hidden by a visibility setting in their profile. The plugin is working; the query is empty.
- Stale cache. A page cached before activation keeps serving the old HTML. Purge the page cache and any CDN cache before concluding anything.
When the Plugins screen itself will not open
You need the Plugins screen precisely when you are doing updates, and that is when it tends to break. The symptom is “There has been a critical error on this website” on wp-admin/plugins.php only, often immediately after a core update.
Triage before you touch the database. Write down the exact error text, the screen it appears on, and the last change made. Then read wp-content/debug.log or the host error log and look at the file path in the fatal: a path under wp-content/plugins/ makes a plugin the first suspect, a path under wp-content/themes/ points at the theme or child theme, and “Allowed memory size” is a resource limit rather than a broken screen. If wp-admin is unreachable entirely, renaming a plugin folder over SFTP forces that plugin to deactivate, and renaming the active theme folder forces a fallback to a default theme.
One cause is specific to this screen and worth knowing. WordPress keeps a recently_activated row in wp_options, and if that value ends up as something other than a valid array, rendering the Plugins list throws a fatal error. The fix is to open the database in phpMyAdmin or Adminer, find the recently_activated row in the options table, and delete it. WordPress recreates it and the screen loads again.
Three ways people make this worse. They delete the wrong row, and removing active_plugins deactivates every plugin on the site. They search wp_options on a site with a custom prefix such as wp123_options, find nothing, and conclude the diagnosis was wrong. Or they try to repair the serialized value by hand and leave it malformed in a new way. Delete the row, do not edit it.
If wp-admin is completely inaccessible, the same normalization can be done from a must-use plugin at wp-content/mu-plugins/fix-recent.php that filters option_recently_activated and returns an empty array when the stored value is not an array. Files in mu-plugins load early and unconditionally, which is the point. Get the <?php tag and the braces right, because a syntax error there fires before your filter can help. A PHP version downgrade in the hosting panel sometimes restores access, but treat it as a way to buy an hour, not a fix: the bad data is still there, and other plugins may not run on the older version. If none of that is a comfortable afternoon, this is the point to have the error diagnosed for you rather than experimenting on a live site.
What changes when an agent does the listing work
The listing question is small. The process around it usually is not: someone decides what the list should show, someone else knows which plugin the site already has, and the change waits for whoever has database or SFTP access. That is the part worth removing.
Example request: “Our /resources page should list every post in the Guides category, newest first, with excerpts and a thumbnail. Use core blocks if the theme supports it. Only add a plugin if there is no other way, and tell me which one and why.”
SiteSelf reads the theme and the page first, builds the list with a Query Loop block where the theme is a block theme, and falls back to a shortcode from a plugin the site already runs before proposing a new one. Before making the change it says what is about to change and whether it can be undone. Afterwards it fetches the page and reports in plain language what it sees: how many posts rendered, whether the excerpts are there, whether the query returned nothing. Content and settings work needs the SiteSelf Connector plugin from the WordPress.org directory; editing a template file or functions.php needs hosting access over SSH.
The limits are worth stating plainly. If /resources is owned by Elementor, Divi or Beaver Builder, the agent refuses at the moment of work and tells you why. Verification is a fetch of the changed page and a report, not a screenshot and not a device test, so a list that renders correctly can still need your eyes on a phone. Work happens on request, so nothing is being watched between requests. The same request shape covers the inventory side of this topic, which is where plugin maintenance handled in chat fits: ask what is installed, what is inactive, what has an update waiting, and what can be removed.