Tag: MOFU

WordPress plays audio with no plugin at all. The Audio block embeds a music file, a podcast episode or any other sound file directly in a post or page, with the browser’s own controls. The Playlist block goes further: WordPress’s documentation describes it as a collection of audio tracks played in a single player, where visitors browse the track list, play in order or on shuffle, and follow the current track in an interactive waveform visualization.

So the question is not “which music player WordPress plugin is best”. It is narrower: what does a plugin add that core does not, and what does it cost you three months later. The cost is usually one of four things going wrong, and those four are the same for every plugin in the category. If yours has already stopped working, the general method in our guide to WordPress plugins that are not working applies here too.

What core already covers, and where it stops

The Audio block handles one file per block. Its toolbar includes a Replace control, which matters more than it sounds: the URL of the file you chose is written into the post content, so swapping the MP3 in the Media Library does nothing to blocks you already published. You change the block, not the library.

The Playlist block is the bigger change to the calculation. Multi-track playback with a waveform was the main reason to install a plugin for years. Its documentation opens with a requirements section, so check it against the WordPress version you actually run before you plan around it. Sites on older releases will not have the block, and a page built on a newer staging install will not render it when you copy it down.

If you need one track in a post, or an album on a release page, you may already be finished. Everything past that point is what the plugin market exists for.

What a plugin adds that core does not

Six things, and most sites need one or two of them:

• Page-builder placement. Music Player for Elementor ships a dedicated Elementor widget, so the player is a layout component rather than a shortcode dropped in a text box.
• Product previews. Music Player for WooCommerce puts a player on products and supports OGA, MP3, WAV and WMA files plus M3U and M3U8 playlists, with Dokan, WCFM Marketplace and MultivendorX support for marketplace setups.
• Podcast and radio sources. AudioIgniter’s listing covers building playlists from standard WordPress media uploads and streaming a radio show. MP3 Audio Player by Sonaar is written for music, beat makers and podcasters, with players on posts, WooCommerce products or custom post types.
• Format breadth. HTML5 Audio Player by bPlugins lists .mp3, .wav, .ogg and more.
• Sticky and floating players that stay visible while the visitor scrolls.
• Skins and branding, where the player is part of the page design rather than a grey bar.

If your list of needs is empty, do not install anything. A player is JavaScript, and JavaScript on a WordPress site has a maintenance cost that a block does not.

How to read a plugin listing before you install it

Install counts in this category are small. The leaders sit around 10,000 to 20,000 active installs, not the hundreds of thousands you see in forms or SEO. That means abandonment risk is real in the long tail, and it also means a high install count is not proof of much on its own.

Four signals are worth more than the feature list:

• Tested up to. A plugin lagging a full WordPress release behind its peers is a mild staleness signal, not a disqualification. Two releases behind, with no update in a year, is a different conversation.
• Does it ship a block or a widget, or only a shortcode? Shortcodes are where the support tickets come from, because attribute names get typed by hand.
• Builder lock-in. An Elementor-only player means the audio implementation gets rebuilt if the site ever leaves Elementor. Prefer something with a block and a shortcode as an escape route.
• The description itself. Compact WP Audio Player’s listing still describes the plugin as an HTML5 and Flash hybrid supporting .mp3 and .ogg files. Flash has been dead since 2020. Copy that old tells you how much attention the listing gets.

The signal almost nobody checks is the vulnerability record, and in this category it is the one that matters most.

Why audio players need update discipline more than most plugins

Patchstack’s entry for MP3 Audio Player by Sonaar, the most installed plugin in the category at 20,000 installations, lists 16 patched vulnerabilities and none currently present, against a latest version of 5.14.2. The recent run reads: cross site scripting up to 5.13.1, broken access control up to 5.12, an unauthenticated insecure direct object reference exposing sensitive information in versions 4.0 to 5.10, a server side request forgery up to 5.11, and an author-level server side request forgery in 5.3 to 5.10.

It is not only that plugin. Patchstack lists two patched issues for Music Player for WooCommerce, including cross site scripting up to 1.8.9, and one for AudioIgniter, an unauthenticated insecure direct object reference on the audioigniter_playlist_id parameter up to 2.0.2.

Read that the right way. A plugin with 16 patched issues and zero present is a plugin whose maintainer is fixing things. The danger is the site sitting on 5.9, sounding perfect, with private post content readable by anyone who knows the AJAX endpoint. None of this is visible from the front end. There is no broken layout, no error message, no dead play button. The only remedy on offer for each of these entries is the same: be on a version past the affected range.

The awkward part is that media plugins are also the ones most likely to break on update, because updates change the markup and the enqueued scripts. So the answer is not automatic updates applied blind, and it is not leaving the plugin alone. It is updating on purpose and then loading a page with a player on it and pressing play.

Example request

“Our audio player plugin is three versions behind. Read the changelog, update it, and check the players on the releases pages still render.”

SiteSelf reads the changelog and the plugin’s current version, tells you what is about to change and whether it can be undone, applies the update, then fetches the pages you named and reports what it found. Plugin and settings work runs through the SiteSelf Connector plugin from the WordPress.org directory; if the fix turns into a template or theme-file change, it needs hosting access over SSH. Handing routine plugin updates to your agent is most useful in exactly this category, where the version number is the whole security story.

The limits are worth stating plainly. Verification today is a fetch of the changed page and a plain-language report in chat, so it can confirm the player markup and the script are on the page. It cannot listen to the audio, and it is not a device test. If the release page is owned by Elementor, Divi or Beaver Builder, that page is refused at the moment of work, with the reason. Nothing runs unattended; the work happens when you ask, and what was done is recorded.

The four things that break, in the order they happen

The file URL. Most “audio is broken” tickets are a 404. Open the audio file’s URL directly in a browser tab. If it does not load there, no plugin setting will help. This is also what a domain change or an HTTP to HTTPS migration does: the URL is stored in the post content, changing the Site URL setting does not rewrite it, and mixed-content rules then block the old asset silently. Migrate with a proper search and replace across post content, not just the setting. Format matters too: a 24-bit WAV will not play in Firefox, and a server configured to send audio as text/plain or with forced download headers breaks in-browser playback whatever the plugin does.

The player renders but play does nothing. Open DevTools and look for Uncaught TypeError. This is almost always JavaScript aggregation, deferral or minification in a caching plugin. Turn JS and HTML minification off, clear every cache layer, retest. If playback returns, add targeted exclusions for the player’s script and for the core media scripts wp-mediaelement.min.js and mediaelement-migrate.min.js rather than leaving optimisation off site-wide. Keep that exclusion list with the rest of your WordPress speed work, so the next performance pass does not undo it.

No player at all. Check in this order: is the track published rather than draft or private, is the plugin activated and not merely uploaded, does the page source show the shortcode rendered or printed as literal text, and are the attribute names exactly as documented. Copy shortcodes from the plugin’s own management screen instead of typing IDs by hand, or use its block or widget and remove the opportunity for the mistake.

The waveform is blank but the plain player works. Waveform players fetch the audio file over XHR to draw the waveform, which a plain <audio> element never does. A CDN that blocks XHR or omits an Access-Control-Allow-Origin header breaks one and not the other. Fix the CDN headers, serve that file from the main server, or fall back to the plugin’s simple player for that instance. This is the one case where offloading media to a CDN, normally good practice, is the cause.

Stop and get help when the console is clean, the file loads directly, minification is off and the player still does nothing. At that point you are looking at a theme or plugin conflict, and the isolation work is worth doing in staging rather than live.

The one thing no plugin solves properly

People want music to keep playing while visitors browse. A normal WordPress page load replaces the document, which stops playback. Every workaround trades one problem for another: frames keep the audio alive and break mobile rendering, AJAX page loaders keep the audio alive and interfere with other scripts on the site, a single-page or headless front end solves it and is a rebuild, and a pop-out player window solves it at the cost of an extra window most visitors will close.

Sticky and floating players are not the same thing. They keep controls visible while the visitor scrolls one page. They still stop at the next page load, and a vendor describing the feature as continuous playback is usually describing that.

Frequently asked questions

Do I need a plugin at all?

If you want one track in a post, no. If you want an album with a track list, shuffle and a waveform, check whether your WordPress version has the Playlist block first. Install a plugin when you need a page-builder widget, product previews, podcast feed ingestion, radio streams, custom skins or analytics.

Why did my audio stop working after I moved to HTTPS?

The full file URL is stored in the post content, and changing the Site URL setting does not rewrite it. The old http:// URL stays in every embed, and the browser blocks it as mixed content on an https:// page. Run a search and replace across post content, or re-select each file in the block.

I replaced the MP3 in the Media Library and the old one still plays. Why?

Same cause. The block holds a URL, not a live link to the library item. Edit the block and use Replace in the block toolbar, or upload the new file over the old one at the same path.

Why won’t autoplay work?

Browser policy, not WordPress. Modern browsers block autoplay of audio with sound until the visitor interacts with the page. Give people a visible play control rather than relying on the HTML5 autoplay attribute, and expect custom JavaScript that forces playback to be blocked and to log console errors.

Can I stop people downloading my MP3s?

Not completely. Anyone who can hear the file can capture it. You can reduce casual downloading with players that hide the direct file path and serve short-lived URLs, by gating tracks behind a membership or LMS plugin, and by serving previews rather than masters. Treat it as deterrence, not protection.

Does an audio player slow the site down?

It depends on whether the plugin enqueues its scripts everywhere or only on pages that contain a player. Check the page source of a page with no audio on it. If the player’s CSS and JS load there, that is the cost you are paying site-wide, and it is worth raising with the plugin’s support before you build around it.

“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.csv

Those 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:

1. 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, or wp plugin list --path=/var/www/html/wordpress. Pointing --path at the document root when WordPress lives in a subdirectory means wp-config.php is 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.
2. WordPress or the database cannot be loaded. WP-CLI reads the same wp-config.php the 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 in wp-config.php takes the site down along with the CLI.
3. 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 not chmod 777 the 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.

1. Wrong directory. The plugin folder belongs in wp-content/plugins/<slug>/. Uploads that land in mu-plugins or one level too high look installed and behave like nothing.
2. Uploaded but never activated. A shortcode for an inactive plugin prints as plain text or prints nothing at all.
3. 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.
4. 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.
5. 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.

Frequently asked questions

Is there a WordPress plugin actually called “WP List Plugin”?

No plugin by that exact name shows up in the WordPress.org directory as a widely used tool. The closest literal matches are unrelated: “WP-list” is a marketplace cross-listing connector for eBay, and the rest of the results are plugins with “list” in the name that do very different jobs. Most people searching the phrase want the wp plugin list command or a content list on a page.

How do I export a list of all my plugins to a spreadsheet?

Run wp plugin list --format=csv > plugins-inventory.csv from the WordPress install directory. Add --fields=name,version,update to narrow the columns, or --field=name for names only. Always export CSV rather than parsing the default table output, which is formatted for reading and not for scripts.

Why does wp post list not show my pages?

WP-CLI’s documentation for wp post list notes that it shows only the ‘post’ post type by default. Pass --post_type=page for pages, or your own post type slug for a custom post type. Add --post_status=draft or --post_status=trash when the posts you expect are not published.

Do I need a plugin just to list categories?

Not if you are comfortable with a small amount of PHP. wp_list_categories() is core, it displays or returns the HTML list of categories, and its hide_empty argument drops categories with no posts. Wrapping it in a shortcode registered in your child theme’s functions.php means editors can place it without touching templates. A mistake in that file breaks the theme, so make the edit over SFTP where you can undo it, or use a plugin instead.

Will a list plugin survive the next WordPress core update?

Check the “Tested up to” value on the plugin’s directory page before a major core upgrade, and give extra attention to any plugin that adds custom columns, bulk actions or filters to admin list screens, because those hook into core internals that change more often than the public APIs. Test on staging first. Removing plugins you no longer use is the cheapest way to shrink the surface that can break.

What should I record before I start deactivating plugins?

The list of what was active, saved somewhere outside the site: wp plugin list --status=active --format=csv, or a screenshot of the Plugins screen filtered to Active. Conflict hunting means deactivating everything and reactivating one at a time, and without that record you will not know which plugins were meant to be off.