Quicktags are useful when a website editor needs to insert the same HTML without hunting through menus or remembering code. If you want to enable Quicktags in block editor screens, start with one practical fact: Gutenberg does not include the old Quicktags toolbar as a native block-editor feature. There is no hidden toggle that restores it everywhere.
That does not mean you need to give up on quick HTML controls. It means you need to choose the right approach for the work your team actually does. For most service websites, the best answer is either to use the Classic Editor where legacy markup matters, or replace repeated HTML with reusable blocks and block patterns. Both options keep editing manageable for non-technical administrators.
What Quicktags do in WordPress
Quicktags are the small HTML buttons traditionally shown above the Text editor in Classic WordPress. They can insert tags such as bold text, links, lists, headings and custom snippets. A site developer can also register extra Quicktags for commonly used content.
They were built for the old editor workflow: type directly into an HTML field, place the cursor, then select a button to insert markup. The block editor works differently. Content is stored as individual blocks, and WordPress expects editors to use each block’s settings, toolbar and controls instead of editing one long HTML document.
That difference matters. Trying to force a Classic Editor toolbar into every Gutenberg block can create confusing editing screens, invalid markup, and content that is harder for the next staff member to maintain. A lightweight solution is better than a clever workaround that breaks after the next WordPress update.
Can you enable Quicktags in block editor natively?
No. WordPress does not provide a standard setting to enable the traditional Quicktags bar across the block editor. The Quicktags JavaScript API and the `quicktags_settings` filter are intended for classic editor fields created through the older WordPress editor system.
You may see a Quicktags-related option in a plugin, a custom theme, or an old tutorial. Check what it applies to before switching it on. In many cases it will affect only Classic Editor screens, comment forms, custom metaboxes, or editor fields created with `wp_editor()`.
This is not a fault in your WordPress installation. It is a compatibility boundary between two different editing experiences.
Use the Classic Editor when exact legacy HTML is required
If your existing pages depend on shortcode buttons, custom HTML snippets, or staff workflows built around the Text tab, Classic Editor is the cleanest option. Install and activate a reputable Classic Editor solution, then open its settings in the WordPress administration area.
Choose whether Classic Editor is the default editor for all users or whether users can switch between Classic Editor and the block editor. For a small team, allowing a choice is often sensible. A person updating a simple service page can use blocks, while the person maintaining technical templates can work in the familiar Text editor with Quicktags available.
Just activate, configure the default, and test one draft page before changing an important live page. Do not assume all users need the same editor. Choice is useful, but only when people know which option to choose.
Be aware of the trade-off: Classic Editor restores the older workflow, but it does not provide the layout controls, pattern library and structured content tools that make Gutenberg valuable. It is best for legacy content or HTML-heavy administration, not necessarily every new page.
Use a Classic block for limited legacy content
A Classic block can be a practical middle ground when a single section of a Gutenberg page needs an older editing experience. Add the Classic block, paste or type the legacy content, and keep the rest of the page in standard blocks.
Compatibility here depends on your theme and plugins. Some Quicktags extensions recognise the Classic block; others only load on a full Classic Editor screen. Test it on a staging site or draft first. If the Quicktags buttons do not appear, that plugin is not designed to support the Classic block, and forcing it with extra code is rarely worth the maintenance cost.
For a short HTML fragment, the Custom HTML block may be more reliable. It gives a clear, contained place to edit markup and makes it obvious that the content is technical. Use it carefully: malformed HTML can affect how a page displays, especially on mobile.
A better Gutenberg replacement for repeated Quicktags
Many Quicktags exist because teams repeatedly add the same thing: a callout, a phone prompt, a service area note, a heading style, or a short disclaimer. In Gutenberg, a block pattern is usually the stronger long-term solution.
Create the content once using normal blocks. Set the spacing, heading level, colours and buttons according to your website style. Then save it as a synced pattern if changes should update everywhere, or an unsynced pattern if staff should be able to adjust each copy independently.
For example, rather than asking an administrator to insert HTML for a contact prompt, create a pattern containing a heading, paragraph and button. It is visible in the editor, easier to review, and less likely to introduce inaccessible code. This is particularly helpful for disability support sites, where clear headings, descriptive link text and predictable page structure make information easier to use.
Reusable blocks also reduce the risk of an editor pasting old code that includes obsolete styling or an incorrect phone number. The person updating the page can focus on the message, not tags.
Add custom Quicktags only for classic editing areas
If you maintain a custom plugin or child theme and still use Classic Editor, custom Quicktags can be registered with a small script. Keep this code in a purpose-built plugin rather than placing it directly in a theme. A plugin remains active if the theme changes.
A basic example might look like this:
“`php add_action( ‘admin_print_footer_scripts’, function () { if ( ! wp_script_is( ‘quicktags’ ) ) { return; } ?> QTags.addButton( ‘service_note’, ‘Service note’, ‘
‘, ‘
‘ ); <?php } ); “`
This adds a button to supported Quicktags fields. It does not turn the Gutenberg interface into Classic Editor. That distinction is essential when testing.
Keep custom buttons narrow in purpose. A button that adds one approved note style is easy to support. Ten buttons that output complicated nested HTML become a second content system hidden inside WordPress. Document what each button produces and check it after WordPress, theme or plugin updates.
Configuration checks before you change editors
Before enabling a Classic Editor option site-wide, check whether another plugin is already controlling the editor. Page builders, custom post types and membership or form plugins can each load their own editing interface. Two plugins trying to select the default editor can lead to inconsistent screens.
Also check user roles. An administrator may see a plugin setting or a code editor that an editor-level user cannot access. That can be intentional security protection. Give staff only the permissions they need, particularly on a site that handles contact forms or client-related information.
Finally, test the full publishing path. Create a draft, view it on a mobile, edit it again, then preview it in the current theme. Confirm that headings remain in order, buttons work, and any custom HTML has not created unexpected spacing. Fast editing is useful only if the published page stays clear and dependable.
When not to use Quicktags
Do not use Quicktags simply because they feel familiar. If staff are adding content such as service descriptions, support information, FAQs or announcements, standard blocks are generally easier to train, review and maintain.
Avoid custom HTML for visual effects that can be achieved with built-in block controls. Native blocks respond better to theme changes and are more likely to stay accessible. Use Quicktags where precise legacy markup genuinely saves time, not as a replacement for a modern editing workflow.
The practical choice is straightforward: retain Quicktags for the classic areas that need them, and build repeatable Gutenberg content as patterns for everything else. Your administrators get a clearer editor, your developer gets less brittle code, and future page updates stay within reach.
