{"id":349756,"date":"2026-08-18T20:06:45","date_gmt":"2026-08-18T20:06:45","guid":{"rendered":"https:\/\/de.wordpress.org\/plugins\/emn-faq-accordion-block\/"},"modified":"2026-08-18T20:11:41","modified_gmt":"2026-08-18T20:11:41","slug":"emn-faq-accordion-block","status":"publish","type":"plugin","link":"https:\/\/wordpress.org\/plugins\/emn-faq-accordion-block\/","author":8234884,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"4.4.4","stable_tag":"4.4.4","tested":"7.0.4","requires":"6.0","requires_php":"7.4","requires_plugins":null,"header_name":"EMN FAQ & Accordion Block","header_author":"Engelhardt Medien","header_description":"Gutenberg Block f\u00fcr FAQ (mit Schema.org JSON-LD) und Accordion \u2013 umschaltbar pro Block-Instanz.","assets_banners_color":"d4dded","last_updated":"2026-08-18 20:11:41","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/engelhardt-medien.de\/leistungen\/webdesign\/wordpress\/wordpress-accordion-faq-plugin\/","header_author_uri":"https:\/\/engelhardt-medien.de","rating":0,"author_block_rating":0,"active_installs":0,"downloads":37,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"4.4.4":{"tag":"4.4.4","author":"beatcore","date":"2026-08-18 20:11:41"}},"upgrade_notice":[],"ratings":[],"assets_icons":{"icon.svg":{"filename":"icon.svg","revision":3653467,"resolution":false,"location":"assets","locale":false}},"assets_banners":{"banner-772x250.jpg":{"filename":"banner-772x250.jpg","revision":3653467,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":{"custom\/accordion":{"name":"custom\/accordion","title":"FAQ \/ Accordion"},"custom\/accordion-item":{"name":"custom\/accordion-item","title":"Accordion Item"}},"tagged_versions":["4.4.4"],"block_files":[],"assets_screenshots":{"screenshot-1.jpg":{"filename":"screenshot-1.jpg","revision":3653467,"resolution":"1","location":"assets","locale":"","width":588,"height":313},"screenshot-2.jpg":{"filename":"screenshot-2.jpg","revision":3653467,"resolution":"2","location":"assets","locale":"","width":588,"height":313}},"screenshots":{"1":"The FAQ\/Accordion block in the editor.","2":"The custom styled plugin in Accordion mode in the frontend.","3":"The standard styled plugin in FAQ mode in the frontend."}},"plugin_section":[],"plugin_tags":[1741,1220,1643,148076,1117],"plugin_category":[43,55],"plugin_contributors":[276361],"plugin_business_model":[],"class_list":["post-349756","plugin","type-plugin","status-publish","hentry","plugin_tags-accordion","plugin_tags-block","plugin_tags-faq","plugin_tags-gutenberg","plugin_tags-schema","plugin_category-customization","plugin_category-seo-and-marketing","plugin_contributors-beatcore","plugin_committers-beatcore"],"banners":{"banner":"https:\/\/ps.w.org\/emn-faq-accordion-block\/assets\/banner-772x250.jpg?rev=3653467","banner_2x":false,"banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":"https:\/\/ps.w.org\/emn-faq-accordion-block\/assets\/icon.svg?rev=3653467","icon":"https:\/\/ps.w.org\/emn-faq-accordion-block\/assets\/icon.svg?rev=3653467","icon_2x":false,"generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/emn-faq-accordion-block\/assets\/screenshot-1.jpg?rev=3653467","caption":"The FAQ\/Accordion block in the editor."},{"src":"https:\/\/ps.w.org\/emn-faq-accordion-block\/assets\/screenshot-2.jpg?rev=3653467","caption":"The custom styled plugin in Accordion mode in the frontend."}],"raw_content":"<!--section=description-->\n<p>Developed by <a href=\"https:\/\/engelhardt-medien.de\/\">Engelhardt Medien<\/a>, a digital webdesign and graphics agency based in Nuremberg, Germany.<\/p>\n\n<p><strong>Why this plugin?<\/strong><\/p>\n\n<ul>\n<li>Schema.org <code>FAQPage<\/code> JSON-LD is generated automatically and tied directly to the block's mode \u2014 no separate schema plugin needed. This structured markup helps AI systems and assistants (ChatGPT, Perplexity, Gemini, and others) understand and surface your content, and gives search engines clean, standards-based context about your page \u2014 increasingly important as more traffic is driven by AI-powered search and answers. (Note: Google discontinued its visual FAQ rich-result snippet in Google Search in May 2026; the underlying structured data is still valid, standard, and used elsewhere, e.g. by AI assistants.)<\/li>\n<li>FAQ and Accordion mode are switchable independently per block instance.<\/li>\n<li>Fast and lightweight \u2014 no external libraries, and assets only load on pages that actually contain the block.<\/li>\n<li>Fully accessible, matching WCAG 2.1 Level AA for this interaction pattern \u2014 particularly relevant for websites operating in the European Union, where the European Accessibility Act has required many businesses to meet digital accessibility standards since June 2025.<\/li>\n<li>WPML-compatible; translation-ready with translations delivered via translate.wordpress.org.<\/li>\n<li>Works with your active theme's own color palette and gradient presets.<\/li>\n<li>Freely customizable \u2014 every visual aspect can be adjusted in the block editor sidebar, without touching any code.<\/li>\n<\/ul>\n\n<p>EMN FAQ &amp; Accordion Block adds a native Gutenberg block for building expandable question\/answer sections. It works in two modes, switchable per block instance (Accordion mode is the default for new blocks):<\/p>\n\n<ul>\n<li><strong>Accordion mode<\/strong> (default) \u2013 the same expandable UI without structured data, for general-purpose content (services, features, steps, etc.).<\/li>\n<li><strong>FAQ mode<\/strong> \u2013 automatically outputs valid Schema.org <code>FAQPage<\/code> JSON-LD structured data alongside the visible content. This structured data helps AI systems and assistants (such as ChatGPT, Perplexity, and Gemini) understand and surface your content when answering questions related to it, and provides search engines with clean, standards-based context about the page (note: Google discontinued the visual FAQ rich-result snippet in Google Search in May 2026).<\/li>\n<\/ul>\n\n<p>By default, opening one item automatically closes any other open item in the same block \u2014 this can be turned off per block (under the \"Type\" panel) to allow multiple items to stay open at once. The first item can also be set to already be expanded when the page loads, again on a per-block basis (also in the \"Type\" panel).<\/p>\n\n<p><strong>Design controls<\/strong><\/p>\n\n<p>Every visual aspect can be adjusted directly in the block editor sidebar, without touching any code:<\/p>\n\n<ul>\n<li>Solid color or two-stop gradient backgrounds for both the question and the answer, including separate hover colors\/gradients.<\/li>\n<li>Border color, hover border color, border width, and border radius.<\/li>\n<li>Independent top\/right\/bottom\/left padding for both the question and the answer, and independent top\/right\/bottom\/left icon padding \u2014 using WordPress's own native \"Dimensions\" spacing control (including your theme's own spacing presets, if defined), with the same unit choices as WordPress itself (px, %, em, rem, vw, vh).<\/li>\n<li>One shared border color and width for all four sides. Border radius can be set per corner (using WordPress's own native corner-radius control) or all at once.<\/li>\n<li>All of the above native WordPress controls automatically and invisibly fall back to this plugin's own equivalent, simpler control if a given native component isn't available on a specific WordPress version.<\/li>\n<li>Padding and border settings each have a compact \"\u22ee\" reset-to-default menu.<\/li>\n<li>Normal\/hover color pairs (question background, question text, icon color, icon background) are grouped into a compact two-way switch instead of being listed one below the other.<\/li>\n<li>Choice of icon: <strong>plus\/minus<\/strong>, <strong>chevron<\/strong>, or <strong>arrow<\/strong> \u2014 freely selectable per block (the chevron and arrow rotate when an item is opened; the plus turns into a minus).<\/li>\n<li>Icon color, icon background color (with separate hover colors), icon size, icon background radius, icon padding, and the spacing between the icon and the question text.<\/li>\n<li>Icon position: left (default) or right of the question text.<\/li>\n<li>Choice of HTML element for the question (div, p, or h2\u2013h6), so it can match your document heading structure \u2014 with an optional custom font size override, set independently for desktop, tablet, and mobile (any breakpoint left empty automatically falls back to the next larger breakpoint, and ultimately to your theme's own default size for that element).<\/li>\n<li>Any color or gradient field can also use your active theme's own color palette (e.g. Astra, or any theme that registers <code>editor-color-palette<\/code> \/ <code>editor-gradient-presets<\/code>), exactly like core WordPress blocks.<\/li>\n<li>The answer area accepts any block available in your WordPress installation \u2014 not just text: paragraphs, lists, images, headings, quotes, tables, galleries, columns, buttons, embeds, and any block added by other plugins\/addons.<\/li>\n<\/ul>\n\n<p><strong>Lightweight &amp; fast<\/strong><\/p>\n\n<p>Built with no external libraries or frameworks: a small, dependency-free editor script and a compact vanilla-JS frontend script. Nothing is loaded on pages that don't contain the block, and all output is plain HTML\/CSS \u2014 no heavy runtime, no bloat, and virtually no impact on page load time. All CSS and JavaScript ships pre-minified and is served minified by default, keeping the amount of data sent to visitors as small as possible (the original, readable source files are also included for transparency and are used automatically instead when <code>SCRIPT_DEBUG<\/code> is enabled).<\/p>\n\n<p>Images, iframes (e.g. video embeds), and self-hosted videos placed inside a collapsed answer are automatically served with native lazy-loading attributes (<code>loading=\"lazy\"<\/code> \/ <code>preload=\"none\"<\/code>) as a reliable fallback, on top of WordPress core's own automatic lazy-loading \u2014 so media inside FAQ\/accordion items that aren't visible on load don't block the page. Existing <code>loading<\/code>\/<code>decoding<\/code>\/<code>preload<\/code> attributes (yours or another plugin's) are always left untouched. Media inside an item that is set to be open by default is deliberately excluded, so it loads immediately like any other above-the-fold content.<\/p>\n\n<p><strong>Accessibility<\/strong><\/p>\n\n<p>The expand\/collapse interaction is built to be fully keyboard-operable and screen-reader-friendly, in line with WCAG 2.1 Level AA for this type of disclosure widget:<\/p>\n\n<ul>\n<li>Each question is reachable via Tab and operable with Enter or Space, in addition to mouse\/touch.<\/li>\n<li>Correct ARIA semantics are used throughout: <code>role=\"button\"<\/code> and <code>aria-expanded<\/code> on the question, <code>aria-controls<\/code> linking it to its answer, and <code>role=\"region\"<\/code> with <code>aria-hidden<\/code> and <code>aria-labelledby<\/code> (pointing back to its own question) on the answer \u2014 all written directly into the server-rendered HTML, not added as an afterthought by JavaScript.<\/li>\n<li>Decorative icons (plus\/minus, chevron, arrow) are hidden from assistive technology via <code>aria-hidden<\/code>, since the open\/closed state is already announced through <code>aria-expanded<\/code>.<\/li>\n<li>A visible focus indicator is shown for keyboard users.<\/li>\n<li>If an item is set to be open by default, it is rendered already expanded (correct <code>aria-expanded<\/code>\/<code>aria-hidden<\/code> state and focusable content) directly in the initial HTML \u2014 no reliance on JavaScript running first.<\/li>\n<\/ul>\n\n<p>No plugin can honestly certify a page as \"100% accessible\" on its own, since real-world accessibility also depends on the content and colors you choose. What this plugin guarantees on its own is the interaction pattern itself: correct roles\/states, full keyboard operability, a visible focus indicator, and screen-reader-friendly markup, matching WCAG 2.1 Level AA for this type of disclosure widget. Final color contrast (text against background, icon against its background) depends on the colors you choose in the block settings \u2014 pick sufficiently contrasting colors (a ratio of at least 4.5:1 for normal text) to keep the result compliant with WCAG AA.<\/p>\n\n<p><strong>Security<\/strong><\/p>\n\n<p>All styling attributes are re-validated and rebuilt on the server on every page load \u2014 via strict allow-lists for colors, gradients, numeric ranges, and HTML tags \u2014 regardless of what is stored in the post content. This prevents malicious or malformed attribute values from ever reaching the page's HTML or CSS.<\/p>\n\n<p><strong>Multilingual<\/strong><\/p>\n\n<ul>\n<li>The plugin's source strings are in German; fully translation-ready, with translations delivered automatically per-locale via translate.wordpress.org once contributed there \u2014 no bundled <code>.po<\/code>\/<code>.mo<\/code> files, in line with how WordPress.org-hosted plugins handle translations.<\/li>\n<li>Includes a <code>wpml-config.xml<\/code> for WPML compatibility, so only the question text itself is offered for translation \u2014 all styling attributes are copied as-is across languages.<\/li>\n<\/ul>\n\n<!--section=installation-->\n<ol>\n<li>Upload the <code>emn-faq-accordion-block<\/code> folder to the <code>\/wp-content\/plugins\/<\/code> directory, or install the plugin directly through the \"Plugins \u2192 Add New\" screen in WordPress.<\/li>\n<li>Activate the plugin through the \"Plugins\" screen in WordPress.<\/li>\n<li>Edit any post or page, add the \"FAQ \/ Accordion\" block, choose FAQ or Accordion mode, and add one or more accordion items underneath it.<\/li>\n<li>Adjust colors, icon, spacing, and other options in the block settings sidebar on the right.<\/li>\n<\/ol>\n\n<h4>Updating from the old plugin<\/h4>\n\n<p>If you previously used the earlier \"Custom FAQ Block\" plugin, note that this is a separate plugin (different folder\/slug), so installing and activating this one does <strong>not<\/strong> automatically deactivate the old one \u2014 both would otherwise run side by side. Please deactivate (and, once you've confirmed everything looks right, delete) the old \"Custom FAQ Block\" plugin after activating this one; having both active at the same time can cause each plugin's own frontend script to load together, which stops the accordions from expanding. This plugin will show a notice in the WordPress admin for as long as it detects the old plugin is still active. Content you already published continues to display correctly either way.<\/p>\n\n<!--section=faq-->\n<dl>\n<dt id=\"does%20this%20plugin%20add%20any%20faq%20schema%20markup%20automatically%3F\"><h3>Does this plugin add any FAQ schema markup automatically?<\/h3><\/dt>\n<dd><p>Yes, but only when a block is set to \"FAQ\" mode. In that mode, the plugin outputs a Schema.org <code>FAQPage<\/code> JSON-LD block based on the actual questions and answers in that block. Blocks set to \"Accordion\" mode do not output this schema.<\/p><\/dd>\n<dt id=\"will%20my%20existing%20accordions%20break%20if%20i%20update%20the%20plugin%3F\"><h3>Will my existing accordions break if I update the plugin?<\/h3><\/dt>\n<dd><p>No. Every markup shape produced by earlier versions of this plugin is explicitly supported through WordPress's block deprecation system, and legacy attributes (such as the old single \"padding\" value) are automatically mapped to their modern equivalents at render time.<\/p><\/dd>\n<dt id=\"can%20i%20use%20my%20theme%27s%20own%20color%20palette%20in%20the%20color%20pickers%3F\"><h3>Can I use my theme's own color palette in the color pickers?<\/h3><\/dt>\n<dd><p>Yes. If your active theme registers a color palette and\/or gradient presets (via <code>add_theme_support( 'editor-color-palette' )<\/code> \/ <code>add_theme_support( 'editor-gradient-presets' )<\/code>), those colors and gradients are automatically offered in every color\/gradient field of this block, in addition to a fully custom color\/gradient picker.<\/p><\/dd>\n<dt id=\"is%20this%20plugin%20compatible%20with%20wpml%3F\"><h3>Is this plugin compatible with WPML?<\/h3><\/dt>\n<dd><p>Yes, a <code>wpml-config.xml<\/code> is included that marks the question text as translatable while keeping all styling attributes identical across every language.<\/p><\/dd>\n<dt id=\"which%20blocks%20can%20i%20use%20inside%20the%20answer%3F\"><h3>Which blocks can I use inside the answer?<\/h3><\/dt>\n<dd><p>Any block registered in your WordPress installation. There is no restriction to a fixed list \u2014 this includes every core block (paragraph, list, image, heading, quote, table, gallery, columns, buttons, embeds, and more) as well as blocks added by other plugins or page-builder addons.<\/p><\/dd>\n<dt id=\"can%20multiple%20items%20be%20open%20at%20the%20same%20time%3F\"><h3>Can multiple items be open at the same time?<\/h3><\/dt>\n<dd><p>By default, no \u2014 opening an item automatically closes any other open item in the same block. This can be turned off per block via the \"Automatically close other items\" toggle in the Type panel, allowing several items to stay open simultaneously.<\/p><\/dd>\n<dt id=\"can%20the%20first%20item%20be%20open%20by%20default%20when%20the%20page%20loads%3F\"><h3>Can the first item be open by default when the page loads?<\/h3><\/dt>\n<dd><p>Yes, via the \"First item open on load\" toggle in the Type panel (right above \"Automatically close other items\"), on a per-block basis. It's off by default, so existing content keeps its previous, fully collapsed starting state after updating.<\/p><\/dd>\n<dt id=\"is%20this%20plugin%20accessible%3F\"><h3>Is this plugin accessible?<\/h3><\/dt>\n<dd><p>Yes. Every question is keyboard-operable (Tab, Enter, Space) and carries the correct ARIA roles and states (<code>role=\"button\"<\/code>, <code>aria-expanded<\/code>, <code>aria-controls<\/code>, <code>role=\"region\"<\/code>, <code>aria-hidden<\/code>, <code>aria-labelledby<\/code>) rendered directly into the HTML, matching WCAG 2.1 Level AA for this interaction pattern. Decorative icons are hidden from screen readers. Since colors are fully customizable, make sure the text\/background\/icon colors you choose provide sufficient contrast (at least 4.5:1 for normal text) to stay compliant. As with any plugin, \"accessible\" ultimately also depends on the content you put inside it (meaningful link text, alt text on images, a sensible heading structure) \u2014 this plugin covers the interaction pattern itself, not the content you add.<\/p><\/dd>\n<dt id=\"are%20images%20and%20videos%20inside%20the%20answers%20lazy-loaded%3F\"><h3>Are images and videos inside the answers lazy-loaded?<\/h3><\/dt>\n<dd><p>Yes. WordPress core already adds native lazy-loading to images and iframes automatically on most pages (since WordPress 5.5\/5.7). This plugin adds its own fallback on top of that \u2014 applied directly when the block is rendered, so it also works in contexts where WordPress's own content filter doesn't run (e.g. block-theme template parts, widgets, or page builders that render the block directly). Any <code>loading<\/code>, <code>decoding<\/code>, or <code>preload<\/code> attribute you or another plugin already set is never overwritten, and media inside an item that's set to be open by default is left to load immediately, exactly like other above-the-fold content.<\/p><\/dd>\n<dt id=\"does%20the%20block%20check%20my%20faq%20content%20for%20common%20mistakes%3F\"><h3>Does the block check my FAQ content for common mistakes?<\/h3><\/dt>\n<dd><p>Yes. Whenever a block is set to \"FAQ\" mode, a \"FAQ-Pr\u00fcfung\" (\"FAQ check\") panel appears in the sidebar and flags, purely as an editorial aid: questions without text, questions without an answer, duplicate\/very similar questions, an accordion\/FAQ block nested inside an answer (not supported in the FAQ schema), and unusually short answers (under 40 characters \u2014 our own practical guideline, not an official Google requirement). This check is informational only and never blocks saving or publishing.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>4.4.4<\/h4>\n\n<ul>\n<li>Fixed a gap still appearing between the question and its answer in the editor preview when the question's HTML element was set to a heading (h2\u2013h6), even after the 4.4.1 fix for this: that fix's margin reset for the new heading wrapper didn't carry <code>!important<\/code>, so it could still lose to WordPress core's or the active theme's own editor-only heading styles depending on load order\/specificity \u2014 the same class of conflict this plugin's question-text color\/font-size rule already had to work around the same way (see the comment above that rule). \"div\" and \"p\" were never affected.<\/li>\n<\/ul>\n\n<h4>4.4.3<\/h4>\n\n<ul>\n<li>Fixed WPML not translating the question text at all (confirmed by a user report, on a site with no Custom XML Configuration override and 4.4.2 already installed): <code>.accordion-question-text<\/code> is changed back from <code>&lt;span&gt;<\/code> to <code>&lt;div&gt;<\/code> \u2014 the tag it had before 4.4, and the one WPML's xpath-based translation for this field was already confirmed to work correctly with. Switching to <code>&lt;span&gt;<\/code> in 4.4 (for slightly cleaner, fully HTML5-valid markup when combined with the new native <code>&lt;button&gt;<\/code>, see 4.4's changelog entry) turned out to break this in practice: even after correcting <code>wpml-config.xml<\/code>'s xpath in 4.4.2 to match either tag, translations still weren't written back. Rather than keep guessing at WPML's exact xpath-matching behavior, this reverts to the exact, previously-proven-working <code>&lt;div&gt;<\/code> shape. <code>wpml-config.xml<\/code> additionally now matches <code>&lt;div&gt;<\/code> and <code>&lt;span&gt;<\/code> explicitly (so content saved during the brief 4.4\u20134.4.2 window, if any, still translates). If you added or edited questions while running 4.4, 4.4.1, or 4.4.2, please check their translations after updating to this version \u2014 for already-existing translations, WPML may need the original question re-saved (even a trivial edit) before it re-picks-up the new content shape.<\/li>\n<\/ul>\n\n<h4>4.4.2<\/h4>\n\n<ul>\n<li><strong>Security fix (stored XSS):<\/strong> the editor-only \"FAQ check\" panel's internal helper for measuring question\/answer text length parsed HTML via <code>innerHTML<\/code> on a detached (not inserted into the page) element. Browsers still fetch resources referenced in HTML assigned this way (e.g. <code>&lt;img src&gt;<\/code>), which can trigger inline event-handler attributes such as <code>onerror<\/code> even though the element is never visibly attached to the page \u2014 verified directly in a real browser. Since this ran automatically on already-stored question\/answer content every time a FAQ block was opened in the editor, malicious markup saved by any account with the <code>unfiltered_html<\/code> capability (Administrators always; Editors too, by WordPress's own default on single-site installs) could execute in the browser session of whoever next opened that post \u2014 including a higher-privileged user. Replaced with <code>DOMParser<\/code>, which parses into an inert, non-active document that never fetches resources or fires event handlers (also verified directly). This only ever affected the block editor (wp-admin); the public frontend was not affected, since this helper's output is never used there.<\/li>\n<li>Fixed WPML translations of the question text no longer reaching newly-saved accordion items after updating to 4.4: <code>wpml-config.xml<\/code>'s <code>&lt;xpath&gt;<\/code> still looked specifically for a <code>&lt;div class=\"accordion-question-text\"&gt;<\/code>, but 4.4 changed this element to a <code>&lt;span&gt;<\/code> for newly saved content (see the 4.4 entry below). The xpath now matches the class on any element, so it keeps working for both the pre-4.4 <code>&lt;div&gt;<\/code> shape and the current <code>&lt;span&gt;<\/code> shape. If you're on WPML and have added or edited FAQ\/accordion questions since updating to 4.4, please re-check their translations after updating to this version.<\/li>\n<\/ul>\n\n<h4>4.4.1<\/h4>\n\n<ul>\n<li>Fixed a gap appearing between accordion items in the editor preview whenever the question's HTML element (Type panel) was set to a heading (h2\u2013h6): the new heading wrapper introduced in 4.4 didn't yet have its browser-default margin reset in the editor stylesheet (the frontend stylesheet already had this reset). \"div\" (the default) was never affected.<\/li>\n<li>Fixed the question button showing a visible rounded corner where it meets the answer below it, and generally not respecting a \"Border radius\" of 0: some browsers apply their own default border-radius to native <code>&lt;button&gt;<\/code> elements (introduced in 4.4) independently of this block's own border-radius setting. The button itself now always has <code>border-radius: 0<\/code> \u2014 only the outer item container (<code>.accordion-item<\/code>, via its own <code>overflow: hidden<\/code>) provides the rounded-corner look at the true outer edges, exactly as before 4.4.<\/li>\n<li>Fixed a longstanding bug (present since the Normal\/Hover tab UI was introduced, unrelated to the 4.4 changes above): switching between \"Normal\" and \"Hover\" for any color field that offers a \"Color\"\/\"Gradient\" choice (question background, answer background) could keep the same \"Color\" or \"Gradient\" sub-selection for both instead of remembering each one independently, because both shared the same underlying editor component instance. Each is now correctly kept independent.<\/li>\n<\/ul>\n\n<h4>4.4<\/h4>\n\n<ul>\n<li>Accessibility improvement: <code>.accordion-question<\/code> (the clickable question header) is now saved as a native <code>&lt;button type=\"button\"&gt;<\/code> instead of a <code>&lt;div role=\"button\"&gt;<\/code>, and <code>.accordion-question-text<\/code> as a <code>&lt;span&gt;<\/code> instead of a <code>&lt;div&gt;<\/code>. This makes the markup fully valid HTML5 when the question is set to a heading (h2\u2013h6) \u2014 a heading element only permits phrasing content, and a <code>&lt;div&gt;<\/code> inside it (as used through 4.3) is not valid, while a <code>&lt;button&gt;<\/code>\/<code>&lt;span&gt;<\/code> are. Keyboard activation (Enter and Space), focus handling, and the correct implicit button role now also come directly from the browser instead of relying entirely on JavaScript. Existing content keeps working exactly as before without any changes needed or re-saving required \u2014 the previous <code>&lt;div&gt;<\/code>-based shape is preserved through WordPress's block deprecation system, so already-published questions keep validating against their actually-stored markup and keep rendering identically. Only newly saved\/edited blocks pick up the native <code>&lt;button&gt;<\/code>\/<code>&lt;span&gt;<\/code> markup going forward.<\/li>\n<li>This release ships without a pre-minified <code>block.js<\/code> (<code>block.min.js<\/code>) \u2014 see the code comment above <code>emn_faq_accordion_asset_file()<\/code> for why. The plugin automatically falls back to the full, readable <code>block.js<\/code> in that case (this only affects the block editor's JS payload size in wp-admin; there is no effect on frontend page weight or load time, since the editor script is never loaded on the public site). A future release will restore the minified file once it's rebuilt through the normal build process.<\/li>\n<\/ul>\n\n<h4>4.3<\/h4>\n\n<ul>\n<li>Accessibility fix: when the question's HTML element is set to a heading (h2\u2013h6), that heading now correctly wraps the entire clickable question button, instead of sitting inside it. Previously (up to 4.2), the heading ended up nested inside the <code>role=\"button\"<\/code> element \u2014 the reverse of the W3C WAI-ARIA Accordion Pattern, which places the heading as the outer wrapper around the button. In practice this meant screen-reader users navigating by heading shortcuts couldn't jump directly to a question. No visual change on the frontend (a CSS reset keeps the new wrapper element invisible in the layout), and blocks left on \"div\" (the default \u2014 unchanged unless you explicitly picked a heading level) or \"p\" are entirely unaffected. Nothing about the saved block content changes; this is applied purely at render time, so existing content needs no re-saving.<\/li>\n<\/ul>\n\n<h4>4.2<\/h4>\n\n<ul>\n<li>Fixed WPML translations of the question text never reaching the frontend, even though the translation could be entered correctly in WPML's own editor. The bundled <code>wpml-config.xml<\/code> used an element WPML doesn't actually recognize for this field; it's now declared using WPML's real mechanism for content that lives directly in the block's saved HTML (an <code>&lt;xpath&gt;<\/code> rule) instead. Translations entered before this update may need to be re-saved once in WPML's translation editor to take effect, since the previous configuration never wrote them into the actual post content in the first place.<\/li>\n<\/ul>\n\n<h4>4.1<\/h4>\n\n<ul>\n<li>Fixed the plus\/minus icon staying on \"+\" when expanding an item in the block editor's own preview, instead of switching to \"\u2212\" like it correctly already did on the live frontend \u2014 the editor preview now mirrors the open\/closed state the same way the frontend script does.<\/li>\n<\/ul>\n\n<h4>4.0<\/h4>\n\n<p>Summary of everything that changed since the 3.0 rebuild (see individual 3.x entries below for full detail on each point). Nothing in this release changes stored data or requires any action \u2014 every existing block keeps rendering and behaving exactly as before.<\/p>\n\n<ul>\n<li><strong>Design &amp; editor controls:<\/strong> the sidebar now consistently uses WordPress's own native controls where available (spacing\/dimensions control with theme presets, per-corner border radius, unit-aware fields for px\/%\/em\/rem\/vw\/vh), each with an automatic, invisible fallback to this plugin's own simpler control if a native component isn't available on a given WordPress version. Repeated, similar settings (color pairs, single pixel values, two-way choices) were unified to consistently reuse the same handful of controls instead of each field being styled differently. Every resettable field now has a compact \"\u22ee\" reset-to-default menu, correctly aligned and positioned to match WordPress's own panel design.<\/li>\n<li><strong>New features:<\/strong> gradient backgrounds, per-side padding for question\/answer\/icon, per-corner border radius, choice of icon (plus\/minus, chevron, arrow) with full styling control, icon position (left\/right), choice of HTML tag for the question with responsive font-size overrides, \"first item open on load,\" \"automatically close other items,\" theme color-palette\/gradient integration, and an in-editor \"FAQ check\" panel that flags common content mistakes.<\/li>\n<li><strong>Accessibility:<\/strong> full keyboard operability and correct ARIA roles\/states written directly into the server-rendered HTML, matching WCAG 2.1 Level AA for this interaction pattern; native lazy-loading fallback for media inside collapsed answers.<\/li>\n<li><strong>Security &amp; WordPress.org compliance:<\/strong> all styling attributes are re-validated server-side on every page load through strict allow-lists (colors, gradients, numeric ranges, HTML tags); removed deprecated PHP functions and bundled translation files in favor of translate.wordpress.org, in line with WordPress.org hosting requirements; JSON-LD output is built via <code>wp_json_encode()<\/code>, never string-concatenated.<\/li>\n<li><strong>Backward compatibility:<\/strong> every markup\/attribute shape from earlier versions \u2014 including content from before this plugin stored its display mode as an attribute at all \u2014 is explicitly handled through WordPress's block deprecation system and defensive server-side fallbacks, so existing content keeps rendering and behaving identically after updating.<\/li>\n<li><strong>Build process:<\/strong> fixed a release-process bug where the pre-minified CSS\/JS files shipped to production could get out of sync with source changes across several point releases, silently shipping outdated styling\/behavior to non-debug WordPress installs; the build now verifies minified output is rebuilt from current source before every release.<\/li>\n<\/ul>\n\n<h4>3.11<\/h4>\n\n<ul>\n<li>Fixed the \"\u22ee\" reset menu floating one row above the field it belongs to on fields whose label is shown by the control itself instead of by the outer wrapper (border width, icon background radius, and the two newly added ones below) \u2014 it's now overlaid on the same visual row as that label instead of getting its own (empty) row above it.<\/li>\n<li>Added individual \"\u22ee\" reset points for icon size and icon-to-text spacing, matching the other sliders in the panel.<\/li>\n<li>Removed the \"\u22ee\" reset menu from the border color field \u2014 the color picker already has its own built-in \"Clear\" action per swatch, so the extra reset was redundant.<\/li>\n<\/ul>\n\n<h4>3.10<\/h4>\n\n<ul>\n<li>Fixed the actual cause of the \"\u22ee\" reset menu not aligning to the right in the editor sidebar: the plugin ships a pre-minified CSS file for production use, and that minified file had gotten out of sync with several rounds of source CSS changes, so none of the previous alignment fixes were actually being loaded in a normal (non-debug) WordPress install. The minified editor and frontend stylesheets are now rebuilt from the current source so the fix actually ships.<\/li>\n<\/ul>\n\n<h4>3.9<\/h4>\n\n<ul>\n<li>Fixed the \"\u22ee\" reset menu still not aligning to the far right on some panels \u2014 it's now wrapped in its own dedicated element so its position no longer depends on internals of the underlying WordPress component.<\/li>\n<li>Removed the \"Edges\" panel's own now-redundant \"Randfarbe und -st\u00e4rke\" section title \u2014 the border-width slider and the border-color Normal\/Hover switch already show their own descriptive label, so the extra title was pure duplication. Each now has its own separate \"\u22ee\" reset menu instead of one shared one.<\/li>\n<li>Reordered the Icon panel: icon position now comes right after icon type, before icon size (previously: type, size, position).<\/li>\n<li>Fixed the icon's own background radius field, which had a bug causing it to not reliably work \u2014 replaced with the same plain slider used by \"Border width\" and \"Spacing between items\", instead of the more complex (and, as it turned out, unreliable) unit-aware slider introduced in 3.7.<\/li>\n<li>Renamed the padding\/spacing section title from \"Ma\u00df\" back to \"Ma\u00dfe\" (matching WordPress' own exact wording) across all three padding panels (question, answer, icon).<\/li>\n<\/ul>\n\n<h4>3.8<\/h4>\n\n<ul>\n<li>Unified the sidebar's visual language so similar settings consistently look and behave the same way, instead of each one being its own slightly different \"construction site\":\n\n<ul>\n<li>Fixed the question's \"Background\" field showing its own label (\"Background\") a second time directly below the already-visible Normal\/Hover switch.<\/li>\n<li>The border panel no longer uses a separate native border-width\/color control; border width is now the same plain slider used for \"Spacing between items\", and border color (normal\/hover) uses the same Normal\/Hover switch already used for the question's background and text colors.<\/li>\n<li>Icon size and the icon-to-text spacing are now the same plain slider (with an editable number field built in) used for \"Spacing between items\", instead of a plain number field.<\/li>\n<li>Icon position (left\/right) is now the same two-button switch used for Normal\/Hover, instead of a dropdown.<\/li>\n<\/ul><\/li>\n<li>As a general rule going forward: fields that represent the same kind of choice (a single pixel value, a normal\/hover pair, a two-way choice) now consistently reuse the same control across the whole sidebar.<\/li>\n<\/ul>\n\n<h4>3.7<\/h4>\n\n<ul>\n<li>Simplified the border\/edges panel back to a single width and color for all four sides (no more link\/unlink toggle for individual sides), per feedback that a single shared value is what's actually needed here \u2014 this also removes the small set of \"per-side\" attributes added in 3.6, since they're no longer used by the UI.<\/li>\n<li>Fixed several sidebar panels (Question\/Answer\/Icon padding, Border, Corner radius) showing the same label twice, once as this plugin's own section title and once as WordPress' native control's own built-in caption (e.g. \"Innenabstand\" appearing twice). The plugin's own section titles are now distinct from the native control's own caption, matching WordPress' own two-row panel header pattern (overall title on top, the specific control's own label directly below it).<\/li>\n<li>Fixed the \"\u22ee\" reset menu not aligning to the right edge of its row on some panels (stuck to the left, right next to the label) \u2014 it's now reliably pushed to the far right regardless of other layout on the page.<\/li>\n<li>The icon's own background radius field now accepts the same units as WordPress itself (px, %, em, rem, vw, vh) alongside its slider, and has the same \"\u22ee\" reset menu as the other fields in this panel.<\/li>\n<\/ul>\n\n<h4>3.6<\/h4>\n\n<ul>\n<li>Fixed a bug where choosing a theme spacing preset (\"Use size preset\") for padding showed no visible effect in the editor preview (looked like zero padding), even though the frontend rendered correctly. The editor preview now converts the preset token to the same CSS variable WordPress' own global styles use, matching the frontend behavior.<\/li>\n<li>Reworked the border (\"Edges\") panel's linked\/split sides control: a previous implementation based on WordPress's native multi-side border component (<code>BorderBoxControl<\/code>) had a recurring bug where entering different values per side (top\/right\/bottom\/left individually) silently had no effect on either the editor or the frontend. This has been replaced with a self-built, fully-controlled link\/unlink toggle backed by four independent instances of the same single-border control already used for the \"all sides linked\" case (proven reliable in earlier testing) \u2014 this class of bug can no longer occur, since there's no dependency on the native component's internal multi-side reconciliation anymore.<\/li>\n<li>Native controls (padding, border radius) now show their own built-in label\/caption row (matching WordPress's own two-row panel header layout: an overall title with the \"\u22ee\" menu on the first row, the specific control's own label on the second), instead of a hidden\/generic label.<\/li>\n<li>The \"\u22ee\" reset menu now uses a smaller, vertically-oriented three-dot icon matching WordPress's own panel header icon, instead of a larger horizontal one, and got a bit more breathing room from the control below it.<\/li>\n<li>The icon's own background radius field is now a slider (matching the rest of this panel's fields), instead of a plain number field.<\/li>\n<\/ul>\n\n<h4>3.5<\/h4>\n\n<ul>\n<li>Matched the \"Dimensions\" and \"Border\" sidebar panels even more closely to WordPress's own native panels for core blocks (e.g. the Heading block), based on a direct comparison against WordPress's actual rendered markup:\n\n<ul>\n<li>Padding now uses WordPress's own native <code>SpacingSizesControl<\/code>, including its \"Use size preset\" toggle tied to your theme's own spacing scale (if defined in theme.json) \u2014 exactly like core blocks. A previous, more conservative implementation deliberately avoided this control after an early version had a bug converting preset values; the underlying preset-token format is now recognized and handled correctly server-side.<\/li>\n<li>The border control now uses WordPress's own native <code>BorderBoxControl<\/code>, including the \"linked\/split sides\" toggle, so each side of the border can genuinely have its own width and color, exactly like core blocks. A 3.2 release had a bug where switching to \"split sides\" and setting different values per side silently kept only one side's value; that data flow has been rewritten and verified directly against Gutenberg's own source code this time. Existing single-color\/width borders are completely unaffected.<\/li>\n<li>Added a genuine corner-by-corner border radius control (WordPress's own native <code>BorderRadiusControl<\/code>, top-left\/top-right\/bottom-left\/bottom-right individually, with a link\/unlink toggle), replacing the single all-corners radius field. Existing values are unaffected (used as the shared starting value for all four corners).<\/li>\n<li>All of the above keep the previous safe fallback approach: if a given native component isn't available on a specific WordPress version, or fails to render for any reason, this plugin's own previously-existing simpler control is used instead automatically, with no visible error.<\/li>\n<\/ul><\/li>\n<li>Removed the \"Outer spacing\" option added in 3.2\/3.3 entirely, per feedback that it kept misbehaving. \"Spacing between items\" (the gap between individual FAQ\/accordion entries) is unaffected and unchanged.<\/li>\n<li>Addressed WordPress.org plugin review feedback: removed the deprecated <code>libxml_disable_entity_loader()<\/code> call (the <code>LIBXML_NONET<\/code> flag already used elsewhere provides the relevant protection, and PHP 8.0+ disables external entity loading unconditionally regardless); removed the bundled <code>.po<\/code>\/<code>.mo<\/code>\/<code>.json<\/code> translation files (translations are now delivered exclusively through translate.wordpress.org, the standard mechanism for WordPress.org-hosted plugins); removed the <code>Contributors<\/code> field from this readme.<\/li>\n<\/ul>\n\n<h4>3.4<\/h4>\n\n<ul>\n<li>Removed the \"Outer spacing\" option added in 3.2\/3.3 entirely, per feedback that it kept misbehaving. \"Spacing between items\" (the gap between individual FAQ\/accordion entries) is unaffected and unchanged.<\/li>\n<li>Padding (question, answer, icon) and the border width\/radius now accept the same units as WordPress itself \u2014 px, %, em, rem, vw, vh \u2014 using WordPress's own native box-spacing and unit controls (with an automatic, seamless fallback to a plain pixel field on WordPress versions where those native components aren't available). Existing values (previously always plain pixel numbers) keep working exactly as before; they're simply treated as \"px\" going forward.<\/li>\n<li>Border width and radius, and question\/answer\/icon padding, now use WordPress's native linked\/unlinked spacing control, matching the \"Dimensions\" panel of core blocks.<\/li>\n<\/ul>\n\n<h4>3.3<\/h4>\n\n<ul>\n<li>Fixed a bug introduced in 3.2 where switching the new native border control into its \"split sides\" view and entering different width\/color values per side silently discarded every side except the first one, both in the editor preview and on the frontend. The border control now uses WordPress's single-border component instead of the multi-side one, which doesn't offer a \"split sides\" view in the first place \u2014 this class of bug can no longer occur, and border settings match this block's actual capability (one width\/color for all four sides) exactly.<\/li>\n<li>Fixed a bug introduced in 3.2 where switching the new native padding\/margin controls to \"Use size preset\" silently reset the value to 0, because WordPress's native spacing-preset system hands back a preset token rather than a plain pixel number, which this block couldn't store. The padding\/outer-spacing controls are now a self-built equivalent (link\/unlink icon plus slider, matching the same visual language) that never offers presets in the first place, so this bug can no longer occur either.<\/li>\n<li>Renamed the \"Border\" sidebar panel\/fields to \"Edges\" (previously inconsistently labeled \"Border\" in places), matching WordPress's own naming for this panel.<\/li>\n<li>Replaced the \"\u22ee reset\" menu implementation: it previously nested a full native WordPress panel-with-its-own-border inside this block's own sidebar sections, which visibly shrank the available width for no benefit. It's now a compact \"\u22ee\" button using a plain, long-stable WordPress menu component, with no extra panel chrome \u2014 this also applies the same compact reset menu to the icon padding control, which didn't have one before.<\/li>\n<li>Split the previous single \"Outer spacing\" concept into two clearly separate, independent controls, per feedback that they were conflated: \"Spacing between items\" (the gap between individual FAQ\/accordion entries \u2014 this is the exact same setting\/attribute this block has had since 3.0, now just using a clearer name and the native-style slider) and a new \"Outer spacing\" (a margin around the entire FAQ\/accordion block as a whole, all four sides, brand new, defaults to 0\/no effect on existing content).<\/li>\n<\/ul>\n\n<h4>3.2<\/h4>\n\n<ul>\n<li>Reworked the editor sidebar to be more compact and closer to WordPress's own native design language:\n\n<ul>\n<li>Question background\/text (and their hover variants), plus the icon's color\/background (and their hover variants), are now grouped into a compact \"Normal\/Hover\" switch instead of being listed one below the other.<\/li>\n<li>The question and answer padding now use WordPress's own native spacing control (linked\/unlinked sides, slider + number field) instead of four separate plain number fields.<\/li>\n<li>The border color\/width now use WordPress's own native border control, matching the look of core blocks.<\/li>\n<li>Added a new, fully independent top\/right\/bottom\/left outer spacing (margin) per item, replacing the previous single \"spacing between items\" value \u2014 the previous value is carried over as the new \"bottom\" spacing, so existing accordions keep their exact previous appearance after updating.<\/li>\n<li>Padding, margin, and the border settings now have WordPress's native \"\u22ee\" reset menu, letting you reset any of them back to their default in one click.<\/li>\n<\/ul><\/li>\n<li>All of the above native WordPress components are used with an automatic, invisible fallback to this plugin's own previously-existing controls if a given native component isn't available (e.g. on an older WordPress version) or fails to render for any other reason \u2014 the same safety approach already used for this plugin's gradient picker since 3.0. Nothing breaks either way; worst case, a field simply keeps its previous appearance instead of the newest native one.<\/li>\n<li>No stored data changes for anything other than the outer spacing (margin); every other setting keeps using exactly the same attributes as before, so existing accordions\/FAQs keep their exact appearance after updating.<\/li>\n<\/ul>\n\n<h4>3.1<\/h4>\n\n<ul>\n<li>Added a \"First item open on load\" option (Type panel, positioned directly above \"Automatically close other items\") \u2014 lets the first accordion\/FAQ item start already expanded when the page loads, on a per-block-instance basis, exactly like the existing open\/close behavior of individual items. Off by default, so existing content keeps its previous, fully collapsed starting state after updating.<\/li>\n<li>Accessibility: each answer now also carries <code>aria-labelledby<\/code>, pointing back to its own question, so screen-reader users navigating by landmark\/region get a distinct, meaningful name for every answer instead of a generic, indistinguishable \"region\" repeated for each item.<\/li>\n<li>Accessibility: fixed an edge case where an item rendered already open (see the new \"First item open on load\" option) could have its links\/buttons\/form fields inside the answer incorrectly excluded from keyboard (Tab) navigation until the item was manually closed and reopened once.<\/li>\n<li>Added a lazy-loading fallback for images, iframes (e.g. video embeds), and self-hosted videos inside an answer (<code>loading=\"lazy\"<\/code> \/ <code>decoding=\"async\"<\/code> \/ <code>preload=\"none\"<\/code>), applied directly when the block is rendered \u2014 on top of WordPress core's own automatic lazy-loading, and independent of whether the block is output via <code>the_content<\/code> (so it also covers block-theme template parts, widgets, and page builders that render the block directly). Existing <code>loading<\/code>\/<code>decoding<\/code>\/<code>preload<\/code> attributes are never overwritten, and media inside an item open by default is deliberately left to load immediately.<\/li>\n<li>Added a \"FAQ-Pr\u00fcfung\" (\"FAQ check\") sidebar panel, shown only when a block is set to \"FAQ\" mode, that flags common mistakes as an editorial aid: questions without text, questions without an answer, duplicate\/very similar questions, an accordion\/FAQ block nested inside an answer (not supported in the FAQ schema), and unusually short answers (under 40 characters \u2014 our own practical guideline, not an official Google requirement). Purely informational; never blocks saving or publishing, and has no effect on the saved markup or frontend output.<\/li>\n<\/ul>\n\n<h4>3.0<\/h4>\n\n<ul>\n<li>Renamed the plugin from \"Custom FAQ &amp; Accordion Block\" to \"EMN FAQ &amp; Accordion Block\" to meet WordPress.org's plugin-naming guidelines \u2014 cosmetic only, no functional change; all existing content, settings, and translations remain fully compatible.<\/li>\n<li>Fixed a bug where the answer's \"Text\" color setting had no visible effect in either the editor preview or the frontend \u2014 only the answer's background color was actually applied. The color picker itself worked correctly, but no styling rule ever read the resulting value. Existing pages that never set a custom answer text color are unaffected and keep inheriting their theme's normal text color exactly as before.<\/li>\n<li>Cleaned up the FAQPage JSON-LD output: the answer text no longer carries WordPress' own internal CSS classes and inline styles (e.g. <code>wp-block-paragraph<\/code>, <code>style=\"margin-top:0px\"<\/code>), only the small set of HTML tags Google's own FAQPage documentation lists as supported (headings, paragraphs, lists, links, bold\/italic, line breaks). The schema was already valid before, but this removes unnecessary markup noise for anything parsing it (search engines, AI assistants).<\/li>\n<li>Rebuilt block architecture: all styling is now rebuilt server-side from sanitized attributes on every page load, independent of what is stored in the post content.<\/li>\n<li>Added gradient background support (question and answer, including hover), configurable border width\/color\/hover color, and independent per-side padding for question and answer.<\/li>\n<li>Added a choice of icon (plus\/minus, chevron, arrow), with configurable icon color, background color, hover colors, size, background radius, padding, position (left\/right), and icon-to-text spacing.<\/li>\n<li>Added a choice of HTML element for the question (div\/p\/h2\u2013h6) with an optional custom font size.<\/li>\n<li>Added integration with the active theme's color palette and gradient presets.<\/li>\n<li>Added German and English translations, plus WPML compatibility via <code>wpml-config.xml<\/code>.<\/li>\n<li>Hardened output sanitization (colors, gradients, HTML tags, and numeric ranges are strictly validated on every render).<\/li>\n<li>Various editor UX improvements (clearer field grouping, dedicated \"Add item\" control, consistent field label sizing).<\/li>\n<li>The answer area now accepts any registered block (no longer limited to a fixed list), including blocks added by other plugins\/addons.<\/li>\n<li>Lightweight by design: no external libraries, a small dependency-free footprint, and assets that only load on pages actually containing the block.<\/li>\n<li>Default mode for new blocks changed from FAQ to Accordion.<\/li>\n<li>Added an \"Automatically close other items\" option (Type panel) \u2014 enabled by default, matching the previous fixed behavior; can be disabled to allow multiple items open at once.<\/li>\n<li>Accessibility hardening: ARIA roles\/states (role=\"button\", aria-expanded, aria-controls, role=\"region\", aria-hidden) are now written server-side directly into the rendered HTML, decorative icons are hidden from assistive technology, and the interaction pattern targets WCAG 2.1 Level AA.<\/li>\n<li>All CSS and JavaScript is now shipped pre-minified and served minified by default for faster page loads; the original source files are kept alongside and used automatically when <code>SCRIPT_DEBUG<\/code> is enabled.<\/li>\n<li>Hardened rendering against a further edge case: a FAQ\/Accordion block nested inside another block's answer no longer has its icon, HTML tag, or ARIA attributes incorrectly overwritten by the outer block's settings.<\/li>\n<li>Renamed the \"Question \u2013 Colors\" and \"Answer \u2013 Colors\" sidebar panels to simply \"Question\" and \"Answer\", since they also contain the padding controls, not only colors.<\/li>\n<li>Fixed an editor-only bug where the question's \"Text\" and \"Text (hover)\" color fields visually changed the +\/- \/ chevron \/ arrow icon's color instead of the question text's own color.<\/li>\n<li>Hardened the question text color (normal and hover) on the frontend against being overridden by a theme's own generic text-color styles, so it reliably reflects the \"Text\" \/ \"Text (hover)\" settings on every theme.<\/li>\n<li>Fixed an editor-only bug where the custom question font size had no visible effect in the block preview.<\/li>\n<li>Fixed a bug where a brand-new, unmodified block could show a different answer padding in the editor preview than on the actual frontend, because WordPress omits attributes matching their default value when saving; the answer padding default remains 10px, matching the question padding, and is now applied consistently in both places.<\/li>\n<li>Added separate desktop\/tablet\/mobile values for the question's custom font size, each falling back to the next larger breakpoint (and ultimately to the theme's own default) when left empty.<\/li>\n<li>Fixed a design bug where a block directly following the answer's last paragraph (e.g. a list) would stick to it with no spacing; the spacing removal now only applies when that paragraph is truly the last element in the answer.<\/li>\n<li>Moved the icon padding control directly below the icon background radius control in the Icon panel, ahead of the icon color fields.<\/li>\n<li>Increased the default spacing between the icon and the question text from 8px to 14px for better legibility.<\/li>\n<li>Added an admin notice that warns when the previous \"Custom FAQ Block\" plugin is still active alongside this one, since running both at the same time can stop the accordions from expanding on the frontend (see \"Updating from the old plugin\" below).<\/li>\n<li>Fixed a bug affecting content created with the very oldest plugin versions (before the icon got its own styling wrapper): the icon now reliably gets its color, background, size, and spacing on the frontend as well, instead of appearing as plain \"+\" text with no spacing from the question.<\/li>\n<li>Fixed a significant bug where a block created before version 3.0 that was left on its original \"FAQ\" mode (the default at the time) could silently lose its FAQPage schema output on the frontend after updating, while still correctly showing as \"FAQ\" in the editor. For the very oldest content, the mode wasn't even stored as an attribute at  &hellip;<\/li>\n<\/ul>","raw_excerpt":"Lightweight Gutenberg FAQ &amp; accordion block with automatic Schema.org FAQPage JSON-LD \u2014 no code required.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/349756","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=349756"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/beatcore"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=349756"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=349756"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=349756"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=349756"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=349756"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=349756"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}