Let's convert the form validation logic of vocabularies to validation constraints + test that. We can keep the existing form validation in place until we leverage the entity validation for forms and remove it then.

Comments

Berdir’s picture

vocabularies are config entities now, not sure this is possible yet?

Berdir’s picture

Issue tags: +Entity Field API

Tagging anyway.

fago’s picture

Status: Active » Postponed
ianthomas_uk’s picture

This issue is part of a D8 critical meta, but is postponed against a D9 issue.

fago’s picture

Given entity validation works on typed data validation, we don't necessarily need entity fields to be able to use it. Given that I think this should be postponed on #1928868: Typed config incorrectly implements Typed Data interfaces.

effulgentsia’s picture

Priority: Normal » Critical
Berdir’s picture

I don't think this issue should be part of that meta anymore, while there might be possibilties to do validation, it's no longer a content entity and not special in any way compared to other config entities, so they should either be all in that meta or none of them.

effulgentsia’s picture

Title: Convert form validation of vocabularies to entity validation » Convert form validation of vocabularies to config validation
Priority: Critical » Major
Issue tags: -Entity Field API, -Entity validation +CMI, +config validation
Parent issue: #1696648: [META] Untie content entity validation from form validation » #2164373: [Meta] Untie config validation from form validation

Per #7.

xjm’s picture

Version: 8.0.x-dev » 8.1.x-dev
xjm’s picture

Title: Convert form validation of vocabularies to config validation » Allow vocabularies to be validated via the API, not just during form submissions
xjm’s picture

So I'm not actually finding any validation logic in VocabularyForm that would be missing elsewhere; is this issue still relevant?

xjm’s picture

effulgentsia’s picture

So I'm not actually finding any validation logic in VocabularyForm that would be missing elsewhere; is this issue still relevant?

Good question. Looks to me like the last form validation of this was removed in #1978112: Convert taxonomy admin path to follow other core entity patterns, which landed 3 weeks before this issue was opened.

effulgentsia’s picture

A bit more info:

  • VocabularyForm::form() invokes protectBundleIdElement(), and that is also validated at the API level via ConfigEntityBundleBase::preSave().
  • VocabularyForm::form() sets the #maxlength of 'name' to 255, but I don't think anything validates that at the API level. I bet we have a similar lack of length validation for many configuration values throughout all of Drupal, but I don't know to what extent that's really a problem.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.