Problem/Motivation

Domain records entities are validated on a form using a service. Drupal is moving towards config validation, see #3427641: [meta] Config validation for a more reliable Drupal + reliable Recipes from the start

Proposed resolution

Move DomainValidator logic to Constraints

Remaining tasks

  1. Write a merge request
  2. Review
  3. Commit

User interface changes

None

API changes

To be determined

Data model changes

None

Issue fork domain-3574840

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

idebr created an issue. See original summary.

mably made their first commit to this issue’s fork.

mably opened merge request !317

mably’s picture

mably commented
Status: Active » Needs review

Commit 1: Move DomainValidator logic to Constraints

Adds two entity-level constraint plugins to the domain entity:

  • DomainHostname — validates hostname syntax (dots, colons, port, valid characters, lowercase, www prefix). Fires hook_domain_validate_alter so existing alter implementations keep working.
  • DomainUniqueHostname — validates hostname uniqueness, skipping the current entity on re-save.

Both constraints are declared on the Domain entity annotation and covered by a new kernel test (DomainHostnameConstraintTest).

This commit is purely additive — no existing code is modified.

Commit 2: Wire form and Drush to use entity constraint validation

Replaces the direct DomainValidator::validate() calls in DomainForm and DomainCommands with entity constraint validation via $entity->getTypedData()->validate(), removing the duplicated hostname checking logic.

  • DomainForm::validateForm() now runs entity constraints and maps DomainHostname / DomainUniqueHostname violations to form errors. The RendererInterface dependency is removed (was only used to render the error item list). The checkResponse() and getRequiredFields() calls are unchanged.
  • DomainCommands::add() now calls validateDomain() which returns a ConstraintViolationListInterface instead of a string[]. The manual hostname uniqueness loop is removed (handled by the constraint); only the id uniqueness check remains.
  • DomainValidator::validate() and DomainValidatorInterface::validate() are deprecated with a @trigger_error notice. The method body is kept intact for backward compatibility.

BC breaking changes

  • DomainForm constructor signature changed — RendererInterface was removed and parameter order shifted. Any code extending DomainForm with a parent::__construct() call will need updating.
  • DomainCommands::validateDomain() return type changed — from string[] to ConstraintViolationListInterface. The method is protected, so only subclasses overriding or calling it are affected.

All 54 domain tests pass (1912 assertions).

idebr’s picture

idebr commented
Status: Needs review » Needs work

The constraints for properties are typically added on the property level, see for reference #3379091: Make NodeType config entities fully validatable and #3447286: Add validation constraints to image.style.*

Ideally all properties have validation, which would enable the config entity to be FullyValidatable. The https://drupal.org/project/config_inspector provides Drush integration to check the constraints are properly applied.

For scheme and domain_id, this can be done in a follow-up as these properties currently have no validation.

mably’s picture

mably commented

Hi @idebr, not sure to fully understand, could try to explain a bit more in details or eventually provide an MR?

EDIT: Ok, I think I got it, you suggest to apply the constraints at the property level, not the entity level.

Will work on it.

mably’s picture

mably commented
Status: Needs work » Postponed (maintainer needs more info)
mably’s picture

mably commented
Status: Postponed (maintainer needs more info) » Needs work
mably’s picture

mably commented
Status: Needs work » Needs review

@idebr looks like domain records are now fully validatable in Config Inspector.

mably’s picture

mably commented

Let's also fix the domain alias records validation.

idebr’s picture

idebr commented

The DomainUniqueHostname can extend the Drupal\Core\Validation\Plugin\Validation\Constraint\UniqueFieldConstraint to remove some boilerplate, see for reference https://git.drupalcode.org/project/drupal/-/blob/main/core/modules/file/...

mably’s picture

mably commented

Doesn't seem possible.

Here is what Claude says:

These two constraints operate in fundamentally different contexts:

UniqueFieldConstraint (core) is for content entity fields:
- Its validator receives a FieldItemListInterface (via $items)
- Uses $items->getEntity(), $items->getFieldDefinition(), getAggregateQuery()
- Queries content entity tables in the database

DomainUniqueHostnameConstraint is for a config entity property (typed config):
- Its validator receives a plain string $value
- Gets the entity ID from $this->context->getObject()->getRoot()->get('domain_id')->getValue()
- Queries config entity storage via loadByProperties()

idebr’s picture

idebr commented
Status: Needs review » Reviewed & tested by the community

Oh I see, good to go then!

  • mably committed 9c1ed50d on 3.x 
    task: #3574840 Move DomainValidator logic to Constraints

By: idebr
By:...
mably’s picture

mably commented
Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.