How to Add Reviews to Drupal: Full HTML or Nothing

There is a specific way that adding an embed to Drupal fails, and it is the reason most people end up reading an article about it. You paste the code into a block, you save, Drupal reports success, and the page shows nothing. Nothing is broken and you did not lose the code. A text format filter removed it on the way out. Drupal runs body content through a filter chain on render, and the formats meant for untrusted input strip any tag not on their allow list, silently, at output rather than at save. Once you know that, adding reviews to Drupal is about ten minutes of work: a custom block on Full HTML, placed in a region or a Layout Builder section. Here is the whole path, including the part where Full HTML is a privilege rather than a checkbox.

Why Your Embed Code Disappeared

Because Drupal filtered it. Every piece of body content carries a text format, and that format is a chain of filters applied when the content is rendered. The formats designed for untrusted input remove tags that are not on their allow list, so an iframe or a script pasted into a block on Basic HTML is stripped on the way to the page.

The reason this is so confusing is the timing. The filtering happens on output, not on save, so Drupal reports a successful save, the editor often still shows your markup when you go back in, and only the rendered page is missing it. Every instinct says the save failed, and it did not.

The names differ by version. Drupal 7 ships Filtered HTML and Full HTML; Drupal 8 and later ship Restricted HTML, Basic HTML and Full HTML. The mechanism is the same in all of them, and so is the fix.

It is worth appreciating that this is Drupal working correctly. A CMS that let any editor paste arbitrary markup into a page would be a CMS with a stored cross-site-scripting problem, and the filter chain is what prevents that.

Which Text Format Do You Actually Need?

Full HTML, in practice. It applies no markup filtering, so the embed survives to the page intact. In the block edit form it is the Text format select underneath the body field, and switching it and re-saving is usually the entire fix.

Full HTML is restricted to trusted roles by default, and that restriction is doing real work. Permission to use it is effectively permission to put arbitrary markup on the site, so it is granted per role at Configuration, Content authoring, Text formats and editors rather than handed out broadly.

On a site with an editorial team, the right pattern is for an administrator to create and place the block once, and for editors to keep working in Basic HTML. The reviews block is a piece of site furniture rather than something writers should be editing, so nobody needs a permission upgrade.

If your organisation will not grant Full HTML at all, the alternative is a dedicated format with an allow list that covers exactly the tags the embed needs. That is more work to set up and more to maintain, but it keeps the blast radius small, and it is the correct answer on a site with a strict security posture.

Block, Layout Builder, or Node?

A custom block is the default answer, and on Drupal 8 and later it lives at Content, Blocks, or in the block library depending on your version. Create it, paste the embed into the body with Full HTML selected, and save. Then place it through the block layout into whichever region of your theme you want it in, with visibility conditions controlling which pages it appears on.

Layout Builder is the modern alternative and it is the better fit when the reviews belong inside a specific page rather than in a sitewide region. Enable it for the content type, edit the layout, add a section, and drop the custom block into it. You get placement inside the content flow rather than in a theme region, which is usually what you actually wanted.

Pasting the embed directly into a node body works and is the option to avoid on a site of any size. It ties the widget to one piece of content, it needs Full HTML on that node, and it puts a piece of site furniture into an editorial field where the next writer will delete it by accident.

None of these routes needs a contributed module, which is worth stating because the first search result usually recommends one. A contrib module is another dependency to audit, patch and carry through the next major version upgrade, in exchange for a text field you already have.

Does It Work the Same on Drupal 7 Through 11?

The mechanism does. Text formats, custom blocks and region placement exist across the whole range, so the shape of the work is identical: permissive format, custom block, region.

What differs is the administrative path and the naming. On Drupal 7 you are in Structure, Blocks, adding a block with an input format of Full HTML. On 8 and later you are in the block library and then Structure, Block layout, and the format names shifted with the addition of Restricted HTML and Basic HTML.

Layout Builder is the real dividing line: it arrived in Drupal 8 and is not available on 7. On a Drupal 7 site the region placement is the route, and that is fine, because a reviews block in a content region is a perfectly good outcome.

One version-independent point: because the embed is markup rather than a module, a major version upgrade does not break it. That is not true of a contributed reviews module, which is exactly the kind of dependency that holds sites back on old major versions.

How Do You Build the Widget?

Paste your Google, Trustpilot or Facebook profile URL, preview your real reviews and rating, then pick from over 100 layout styles across slider, marquee, grid, list, masonry and badge families. Colours and fonts adjust so it matches your theme rather than announcing itself as an embed.

The rating comes from the profile's own aggregate rather than from the cards on screen, so the figure on the page matches what a visitor finds if they check. Free plan, unlimited widget views.

The output is one line of HTML. It goes into the block body with Full HTML selected, and that is the last Drupal-specific step there is.

Where Should the Reviews Go?

Drupal sites tend to be organisational rather than transactional, so the useful placement is usually next to whatever action the site is asking for: the enquiry form, the application page, the service detail page. A reviews block in a sidebar region on every page is the default that nobody reads.

Use visibility conditions rather than placing the block everywhere. Restricting it by path or content type keeps it meaningful, and it stops the block competing with the primary content on pages where proof is not the question.

If you are on Layout Builder, prefer putting the block into the content flow of the pages that need it over a global region placement. Reviews immediately after the service description do more than reviews in a right rail the visitor has already tuned out.