Drupal是否修改了body的value与safe_value属性？技术咨询

Hey there, let's break down what's happening with your body field variables and how to avoid this issue going forward.

First, let's clarify the core difference between the two properties you're seeing:

• $variables["body"][0]["value"]: This is the raw, unfiltered input of your body field. If it's suddenly stripped of HTML tags, it's likely because your text format settings were modified (e.g., switching from Full HTML to a more restrictive format like Basic HTML) or Drupal's auto-escaping in templates is converting HTML entities (making tags look like they're stripped when they're actually just escaped). Either way, this property is never meant for direct front-end rendering of rich text—it's for accessing raw content if you need to process it programmatically.
• $variables["body"][0]["safe_value"]: This is the sanitized, format-compliant version of your content. Drupal generates this automatically when you use a text format with filtering enabled (which is almost always the case for rich text fields). It retains all HTML tags allowed by your chosen text format and is safe to render directly on the page without extra escaping.

Why did this change happen? #

Chances are, either:

1. Your site's text format settings were modified (someone restricted allowed tags, or switched the field's assigned format), causing the raw value to either be filtered before being passed to the template, or auto-escaped when rendered.
2. You're working with a newer Drupal version or updated module where the variable handling for raw values became stricter (a common security-focused change).

How to avoid this in the future #

• Always use safe_value for rich text rendering: This is the official, secure way to display formatted content. It ensures your HTML stays intact while protecting against XSS attacks.
• Skip direct variable access when possible: Instead of digging into $variables["body"][0], use the structured render array with {{ content.body }} in your template. This handles all filtering, formatting, and rendering automatically, so you don't have to worry about picking the right property.
• Lock down text format settings: Make sure only authorized users can modify text formats, and document which format your rich text fields use. This prevents accidental changes that break content rendering.
• Avoid manual escaping/filtering: Never use the |raw filter on value to "bring back" HTML—this exposes your site to XSS vulnerabilities. If you absolutely need to process raw content, use the |check_markup filter with your format ID (e.g., {{ body.0.value|check_markup('full_html') }}) instead of relying on raw values.

As for whether safe_value existed before: Yes, it's been a standard part of Drupal's field variable structure for years (since at least Drupal 7) whenever text formats are enabled. You just didn't need to use it until the raw value started being filtered/escaped.

内容的提问来源于stack exchange，提问作者gabrjan