Vale 1.0 Adds Server-Side Style Checks to Drupal Publishing

The Vale contributed module reached its first stable release on 28 October 2026, bringing configurable prose style checks into Drupal's server-side content validation. Maintainer Stuart Clark published version 1.0.0 and explained its operation in a companion technical blog post.

For Drupal publishers accepting content through conventional editing forms and decoupled applications, the module provides a common place to apply selected editorial rules. Rather than requiring each frontend to implement its own terminology and style checks, Vale runs during Drupal's content validation process. Error-level violations can prevent content from being saved, while warnings and suggestions provide feedback without blocking the operation.

The module uses the external Vale prose linter, which supports configurable rules for terminology, style and language consistency. Administrators enable checking on individual text fields and can adjust rule severity, reporting thresholds and profiles. Organisations can use published styles or maintain their own rules for product names, preferred terminology and expressions they want editors to avoid. Vale checks content against those rules rather than assessing factual accuracy or determining whether text was generated by artificial intelligence.

For JSON:API submissions, the checks run when Drupal validates the content being saved. When an error-level violation causes a write to be refused, Drupal returns an HTTP 422 response identifying the affected field. According to the tagged release documentation, warnings and suggestions can also be returned in the response metadata when a save succeeds. A separate POST /vale/check endpoint allows authorised applications to request findings before saving content, giving external editors a way to display feedback earlier.

Vale also supports workflows in which editors save drafts before publishing. With publish_only enabled, draft saves can proceed despite style errors, while publication is subject to the configured checks. The module integrates with Drupal's Content Moderation and Workspaces systems, allowing teams to check staged changes before they go live. Workspace settings determine whether findings are advisory or blocking, with publish-only mode applying additional restrictions at publication.

Beyond individual saves, Vale includes tools for checking existing content. A prose linting report lists findings by content item, rule and severity, with filtering and CSV export options. Drush commands can scan stored content or selected bundles, including from automated workflows. The stable release also adds Drupal 12 support, improves field identification in error messages and resolves certain workspace publishing problems.

Deployment requires more than installing the Drupal module. Version 1.0.0 supports Drupal 10.3, 11 and 12, requires PHP 8.3 or later, and depends on the Vale 3 executable being available on every relevant web server and command-line environment. Site builders must deploy the Vale configuration file and style rules, configure the executable path and enable checks on the required fields. Clark documents a drush vale:install command that downloads the executable and verifies its published checksum.

The module's failure behaviour is another configuration decision. By default, ordinary content saves proceed if Vale is unavailable, times out or cannot complete a check, with a notice indicating that the text was not checked. Enabling fail_closed instead refuses the save when validation cannot be completed. Drush linting and workspace blocking mode have stricter failure behaviour, but ordinary saves are not automatically protected against an unavailable executable.

Coverage is limited to fields explicitly enabled for prose checking and operations that invoke Drupal's validation process. Title base fields and body summaries are outside the documented field coverage. Drupal Canvas component properties are also excluded, although supported node text fields rendered through Canvas templates can still be checked. Content saved without invoking validation, including some migration operations, bypasses the checks.

A further limitation affects a specific combination of Paragraphs, JSON:API and publish-only mode. In an issue opened on 28 October 2026, Clark documented how a direct API update to a Paragraph already displayed on a published page could succeed despite an error-level finding. Because the standalone Paragraph save does not create a new revision or trigger the page's publishing operation, the changed text can become publicly visible without publication being blocked. Clark reported that the problem does not occur in the same way inside a tracked workspace or when publish-only mode is disabled.

A proposed fix addresses this Paragraphs behaviour, but it had not been merged at the time of review on 29 October 2026. The issue illustrates why publishers need to examine the content-saving paths used by their applications rather than assume that publish-only validation covers every route to publicly visible content.

Clark reported approximately 55 milliseconds of additional processing time for one uncached JSON:API save of a short paragraph on a test site, but broader production performance has not been independently established. The Vale project is also not covered by Drupal's security advisory policy. Publishers considering the stable release therefore need to account for its executable requirements, selected field coverage, validation boundaries and failure settings when deciding where editorial rules can be enforced.