Ask the Bartender: Frustrations and Finding the Right WordPress Block Plugins

Hello. I always supported the idea of a WordPress block editor as a whole, but lately, I’m a bit frustrated in that there are some blocks I need with urgency to work on a (non-visitor editable) wiki-like site (mostly a Tabs block, a Countdown block, an Accordion/Toggle block, a Table of contents block and a Footnotes block) and have not had luck finding appropriate plugins. I can name a long list of the specific problems I have with the ones available right now…

Andrés

Andrés’ question spanned another 400 words or so. The following summarizes the problems he has run into:

  • Block collection plugins cover some but not all use cases.
  • Seemingly suitable blocks have too few or too many options.
  • Few blocks can be converted to other block types.
  • Many block plugins have not been updated in a while, causing fear of abandonment.
  • No way to batch convert blocks if a better plugin is found.
  • Need a footnotes block.

I do not necessarily see most of these as block-related problems. It can be tough to find that sweet spot, fine-tuning your WordPress site with just the right tools.

When I first began using WordPress in 2005, I hit these same sorts of problems. And they were problems throughout my career as a developer. I would find a plugin that would do almost what I wanted. I would find another that would add way too many unnecessary features. Often, nothing seemed to exist that was perfect for my needs. This was the sole reason I jumped into development — if you want something done right, do it yourself. I wanted my WordPress site to work according to my own strict specifications. No one else would do it for me, and I was a starving college student who could not afford to hire a developer. It left me little choice other than putting in the time and effort to make it happen.

While I am not suggesting that you must go down the path that I once did, it is always an option worth exploring. Many great developers began with this same type of frustration. They had a problem and needed a fix for it.

Open-source is about giving and taking. When you cannot pay it forward in terms of code, feedback is always welcome. That is one reason I like to highlight these questions. Even when I do not have the answer, maybe someone else will. Perhaps your requests will spark an idea for one of the many developers who read WP Tavern.

I definitely do not have all the answers to this laundry-list of questions. It is a broad subject that will take a community to solve.

Many of your issues might be handled by nothing more than having a conversation with the developers behind the block collection plugins you are using. Step one is to start a dialogue with them. I bet most are willing to listen to your ideas on how they can improve their products as long as you address them constructively.

Try One-Off Block plugins

Searching for and installing a single-use block directly from the WordPress editor.
Installing a single-use block from the editor.

The future of using blocks is going to be far more about finding and installing individual blocks rather than collections. WordPress has done its users a disservice by not actively promoting these one-off block plugins. We are over two years into the block editor and still do not have a block directory and management screen built directly into the software. Sure, users can search via the block inserter directly from the editor, but it does not replace a full management experience.

This missing feature has helped spur massive library plugins, which have become the de facto method that most users find new blocks. Far too many plugin developers are following the Jetpack model of packaging them all together. Without full block management baked into core, this trend will only continue. At this point, it may be hard to break from the mold.

However, you can still find a listing of available single-use blocks from the block directory on WordPress.org, at least the ones that plugin authors have appropriately tagged.

Screenshot of the WordPress.org block directory.
WordPress block directory.

I recommend testing these blocks before diving into a library-type plugin. There is always the risk of developer abandonment — there is nothing you can really do about that when it comes to any type of plugin other than supporting the authors.

The block directory’s problem is that it has only a little over 120 blocks — like I said, WordPress has not done enough to promote it. This means there is not enough competition to drive innovation and bring clear winners to the forefront. Some of the blocks are hit-or-miss projects. I know this does not breed confidence, but I can say from experience that I always loved user feedback as a developer. It is the lifeblood of any project. Give the plugins a test. Even if you do not like or use them, send your feedback over to the developers.

The following is a short, not comprehensive, list of some single-use blocks that may be appropriate for you:

Footnotes Block Plugin

Decorative image of a page in a dictionary, highlighting the "footnote" definition.

I feel your frustration about footnotes. WordPress lacks this feature that any decent desktop-level writing software has. From past experience earning my B.A. in English, footnotes were a core part of the experience. It baffles me that the most-used CMS in the world has yet to add even a basic version of footnotes to its toolset.

Fortunately, other like-minded people want to see footnotes in WordPress. Ella van Durpe has a draft of a footnotes feature on the Gutenberg repository. This is an ongoing, three-year discussion. There is no reason to believe it will be baked into core soon, but it is reason enough to be hopeful.

The Academic Blogger’s Toolkit plugin supports footnotes. It has not been updated in a year and could be overkill for what you need. However, it would not hurt to give it a test run.

Several footnote plugins in the directory should work fine with the block editor. The standard method employed by many of them uses a ((double-parentheses)) to add footnotes from within the editor. Those notes are then parsed before being displayed on the front end.

That is not my style. I prefer the visual separation of the references and the footnotes in both the editor and the front end. The great thing about the block editor is that you can manually build footnotes without a plugin. Or, at least you can create almost-footnotes.

Cathy Meder-Dempsey, a genealogist and blogger for Opening Doors in Brick Walls, has an exhaustive tutorial on manually adding references and a footnotes section with the block editor. It is not a perfect solution and works best when you have only a few footnotes. This is because the reference links jump to the overall footnotes section rather than the individual notes. It is a quick solution in a pinch.

This post is a part of the Ask the Bartender series. If you have a question about WordPress, feel free to shoot it over. Your question could be featured next.

12

12 responses to “Ask the Bartender: Frustrations and Finding the Right WordPress Block Plugins”

  1. Similar to this, when using the Elementor page builder I was overwhelmed by the sheer volume of addons (widgets and extensions) there were out there – it took me hours to find the right ones for my projects.

    My only option was to build my own directory where I could quickly search, compare, and find what I was looking for, which you can see here:

    https://wpwhichplugin.com

    This is updated weekly and is available to anyone that might find it helpful. I’ve been thinking of doing something similar for Gutenberg blocks.

  2. Useful list Justin, thanks (I’m still using WP-Footnotes, which is no longer supported but still works).

    I share Andrés’s frustration, and regularly download block libraries to a test site and try them out on a page to compare and contrast with other libraries. I still feel that block libraries should be more like block frameworks, where you download the ones you want and ignore the rest (as opposed to downloading them all and then having to turn off the ones you don’t want on a settings page).

    One problem with the one-shot blocks is that they sometimes disappear (which isn’t sorta brilliant). With plugins, if I’ve downloaded them I can still use them if they work (and even fix them when they don’t – I use a wiki-style links plugin written for php4, now updated) and sometimes I throw the routines from these small plugins into one larger file to keep things simple. Could I build a block library of my own using the one-shot blocks, I wonder…?

  3. I just experienced this same frustration yesterday. Usually, I build custom themes with custom blocks, and remove any blocks not needed/supported by the theme. However, I’m supporting a client with a purchased theme who is adding additional languages to the site. They have an accordion plugin that uses shortcodes, which a pain to manage because you have multiple places to enter/change content instead of having everything in the page. I figured switching to an accordion block would be beneficial before translating the site into 6 different languages. However, the only well supported (backed by WordPress focused companies) accordion blocks I could find are bundled with other blocks. The problems with bundling blocks are: I don’t have budget/time to make sure all the other blocks look nice or work well in this purchased theme, the extra blocks create confusion for site editors and don’t follow the premise of “decisions, not options”, and there isn’t a way to easily disable blocks for every user, and never allow the bundled blocks plugins to add more blocks to the site in the future. I wish bundled blocks plugins had separate settings to exclude/include blocks (instead of the user’s page preferences) where you can check which of the bundled blocks you want to enable for the theme. More like Jetpack’s options instead of per user options.

    And before anyone points out the allowed_block_types filter – yes that is great if you built the site and have controlled what is added to pages from the start. But, I don’t know what blocks have been used throughout the site and what the site editors are used to – and the names of blocks change, gosh darn it: see core/button[s] and core-embed/[service] . I could build a custom block, but it isn’t in the budget.

    And sure, you shouldn’t look a gift horse in the mouth, but I can’t be the only one who has these frustrations with bundled block plugins.

    • There is the plugin Disable Gutenberg Blocks – Block Manager https://wordpress.org/plugins/disable-gutenberg-blocks/ that I use on sites to disable blocks that won’t be used or to disable blocks that offer the same features of other blocks. Even though it hasn’t been updated in a while, it still works and the functionality is simple enough that it should not need to have regular updates to keep working.

      You can then use the plugin Find My Blocks https://wordpress.org/plugins/find-my-blocks/ to find used blocks and compare that to the list of blocks that you want to disable.

      Not a perfect solution but will greatly reduce the number of blocks that you have to worry about.

    • So, you can disable blocks without concern for breaking the site where they may be used, the only catch is that they will end up showing a warning in the editor and ask a user to convert it to HTML. However, I will also say that trying to find the actual names of the individual blocks in a block library plugin, to allow only the ones I want, can be a real pain.

      Also, recently Core broken the filtering of embed blocks because they decided to convert them all to block variations of the generic core/embed block. 🤦🏻‍♂️ I opened up an issue on this to point out that they broken documented existing functionality. They didn’t bother to note this in their release notes, or apparently even realize they were breaking their own functionality.

      Sometimes it appears that Gutenberg has gotten too big and no one actually understands they impacts to other areas when they make changes. They obviously don’t have enough automated tests to flag these broken regressions.

  4. I’ve got a PR to add a Table of Contents block into core. It automatically creates links to headings with ids/anchors (but doesn’t create the anchors itself… that’s something that should be handled by a change to the Heading block), it supports multi-page posts (including a toggle to only show headings from the page that the block appears on), and can be quickly converted into a static List block for further customization.

    All it needs is some feedback on the naming (e.g. “Table of Contents” versus “Document Outline”), some code reviews to ensure the technical implementation is sound, and a fix for a block-selection bug that currently exists but is unrelated to the PR itself.

    https://github.com/WordPress/gutenberg/pull/21234

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.