Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Berdir’s picture

Issue tags: +Entity Field API

Tagging

klausi’s picture

Status: Active » Needs review
FileSize
2.14 KB

First patch that adds a constraint for the node title length and a test.

Looking at NodeFormController there are some open questions:
* The title is required if the content type supports the title property. How do we implement that as validation constraint?
* The node changed date must not be lower than the changed date in the DB, otherwise the form submission gets rejected. Do we want to have that as generic constraint?
* The node author must be a valid user reference, do we have an entity reference legit value constraint already somewhere?

Berdir’s picture

For the user reference, I think the issue that converts the entity reference field to a plugin adds a validator to check that.

fago’s picture

* The node changed date must not be lower than the changed date in the DB, otherwise the form submission gets rejected. Do we want to have that as generic constraint?

Sounds reasonable!

* The title is required if the content type supports the title property. How do we implement that as validation constraint?

We can conditionally add in the constraint in the title's getConstraint() method.

+++ b/core/modules/node/lib/Drupal/node/NodeStorageController.php
@@ -155,6 +155,11 @@ public function baseFieldDefinitions() {
+      'constraints' => array(
+        'ComplexData' => array(

this should use property_constraints

klausi’s picture

Now using property_constraints.

Implemented a node_title data type to handle the content type specific title constraint. Does not work right now because the field item is never null (always contains an array value with one key). How is the NotNull constraint supposed to work on field items?

Status: Needs review » Needs work

The last submitted patch, node-validation-2002156-5.patch, failed testing.

klausi’s picture

Status: Needs work » Needs review
FileSize
3.68 KB
3.75 KB

Ok, I think I know what went wrong: if the field is empty then the field item class never gets called in PropertyContainerMetadata::accept() to validate the constraints.

So the solution is to override on the field level, not the field item level.

This patch should pass the test now.

TODO:
* node author reference validation
* node updated date validation
* checking the node edit from array for #maxlength or #required or any other restrictions

Status: Needs review » Needs work

The last submitted patch, node-validation-2002156-7.patch, failed testing.

Berdir’s picture

klausi’s picture

Status: Needs work » Needs review
FileSize
5.07 KB
7.13 KB

Fixed title constraint in case we cannot load the node type.

Added constraint validator for the node changed date.

TODO:
* node author reference validation
* checking the node edit from array for #maxlength or #required or any other restrictions

klausi’s picture

I checked the form array in NodeFormController:form() and did not find any additional constraints, except for data type and option restrictions, but those should be covered elsewhere with the data type anyway.

So the node author reference validation remains, but that is also a general data type specific constraint, which is not node specific and should also be handled elsewhere.

fago’s picture

+++ b/core/modules/node/lib/Drupal/node/Field/TitleField.php
@@ -0,0 +1,32 @@
+ * Defines the 'node_title' field with an extra constraint.

Maybe call it a custom constraint, because something extra can live in the field definition also?
Or a field generating custom constraints.

+++ b/core/modules/node/lib/Drupal/node/Plugin/Validation/Constraint/NodeChangedConstraint.php
@@ -0,0 +1,25 @@
+ * Supports validating all primitive types.
+ *
+ * @Plugin(
+ *   id = "NodeChanged",

Wrong docs.

+++ b/core/modules/node/lib/Drupal/node/Tests/NodeValidationTest.php
@@ -0,0 +1,77 @@
+    $violation = $violations->get(0);

You can use array access here.

+++ b/core/modules/node/lib/Drupal/node/Field/TitleField.php
@@ -0,0 +1,32 @@
+ * Defines the 'node_title' field with an extra constraint.

Maybe call it a custom constraint, because something extra can live in the field definition also?
Or a field generating custom constraints.

+++ b/core/modules/node/lib/Drupal/node/Plugin/Validation/Constraint/NodeChangedConstraint.php
@@ -0,0 +1,25 @@
+ * Supports validating all primitive types.
+ *
+ * @Plugin(
+ *   id = "NodeChanged",

Wrong docs.

+++ b/core/modules/node/lib/Drupal/node/Tests/NodeValidationTest.php
@@ -0,0 +1,77 @@
+    $this->assertEqual(count($violations), 1, 'Violation found when title is too long.');
+    $violation = $violations->get(0);
...
+    $violation = $violations->get(0);

You can use array access here.

+++ b/core/modules/node/lib/Drupal/node/Field/TitleField.php
@@ -0,0 +1,32 @@
+    // If the node type is configured to have a title field then it should be
+    // required.

What is saved as node title if the title is not required?
I'd expect 'required' => TRUE to be on the node title usually?

Looks like we could really need a way to customize/override field definitions by bundle... :/

+++ b/core/modules/node/lib/Drupal/node/Tests/NodeValidationTest.php
@@ -0,0 +1,77 @@
+    $this->assertEqual(count($violations), 1, 'Violation found when title is too long.');
+    $violation = $violations->get(0);

On the issue introducing validation we agreed on checking the violation message also - so we are sure the right constraint failed.

$this->assertEqual($violations->count(), 1, 'Validation failed.');
$this->assertEqual($violations[0]->getMessage(), t('This value should not be null.'));

klausi’s picture

Fixed issues from #12.

The node title is not required per se, so we cannot specify that on the entity base properties.

fago’s picture

Status: Needs review » Needs work

The node title is not required per se, so we cannot specify that on the entity base properties.

Yes. But I'm wondering whether it isn't still required. Looking at the schema I think it technically is required:

      'title' => array(
        'description' => 'The title of this node, always treated as non-markup plain text.',
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
      ),

So let's follow that? Make it required + provide a default value of '' i.e. you may not unset it. Then the node type setting influences the form behaviour, while at storage level a titel is required?

Without that, I think you could unset it and trigger storage exceptions.

+++ b/core/modules/node/lib/Drupal/node/Field/TitleField.php
@@ -0,0 +1,32 @@
+ * @file
+ * Contains \Drupal\node\Plugin\DataType\TitleField.

I realized this is in the wrong namespace - it's not a data type plugin.

klausi’s picture

Status: Needs work » Needs review
FileSize
1.56 KB
7.65 KB

Ok, fine with me wither way.

fago’s picture

+++ b/core/modules/node/lib/Drupal/node/Field/TitleField.php
@@ -18,7 +18,9 @@ class TitleField extends Field {
-    $constraints = parent::getConstraints();
+    // Don't call parent::getConstraints() here, we have our own handling for
+    // required title fields.
+    $constraints = array();

So why do we skip required validation here then? With '' it should pass?

klausi’s picture

So you are saying that we don't need a custom TtitleField at all, just always make it required and let the default required implementation handle this?

If a content type has no title configured then the field would get populated with the default empty string, so I guess that would be fine too.

Could you confirm that this is what you meant before I roll a patch?

fago’s picture

Yes, exactly!

klausi’s picture

Status: Needs review » Needs work
Issue tags: -Entity Field API, -Entity validation

The last submitted patch, node-validation-2002156-19.patch, failed testing.

klausi’s picture

Status: Needs work » Needs review

#19: node-validation-2002156-19.patch queued for re-testing.

moshe weitzman’s picture

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

Code looks good and retest is green.

alexpott’s picture

Title: Convert form validation of nodes to entity validation » Create validation constraints on nodes to entity validation
Status: Reviewed & tested by the community » Fixed

Retitled as we're not actually doing any conversion here as the conversions will occur when entity forms support validation.

Committed 2ea2cf6 and pushed to 8.x. Thanks!

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

Anonymous’s picture

Issue summary: View changes

added meta issue, development branch.