Hi,

I am the author of Drigg. For Drigg, I use a custom-made node type, "drigg", which works great.
What I am _really_ missing is a hook which should be called by node_save() to see if it's actually *OK* to save a node *before* the initial INSERT (into the table 'node') is done to the database.

The reason? Well, the node_drigg table (which extends "node") has a constraint: the "link" field is a unique key. So, two nodes CANNOT have the same link. However, when my module's nodeapi hook gets finally called, the initial insert has already happened!

Basically, I need Drigg to be able to *veto* the save. Yes, I know that hook_nodeapi is called with $op "validate", but that only happens in forms. Modules like Mailhandler, or node_import, DON'T do that - they just hit node_save(), and that basically creates problems.

I am happy to write the patch (which really is tiny) for this to happen. I can't think of a good name for $op though.

Now... ideas? Comments?

Thanks a lot,

Merc.

Comments

mercmobily’s picture

Hi,

Am I the only module developer who could possibly want this...?
(Not complaining... it might well be!)

Merc.

tstoeckler’s picture

Title: Enhancing hook_nodeapi with a 'db_validate' $op » Allow modules to veto in node_save()
Version: 7.x-dev » 8.x-dev

Still valid.
There is now hook_node_presave, but the node gets saved nonetheless.

marcingy’s picture

Shouldn't this be being done a form validation step? ie module X does a check on field or what and says hey you can't save because X already exists. Once node_save process starts ineffect we are saying we are happy with the data we have and it is valid. I'm tempted to mark as won't fix because the attempt to incept is too late in the life cycle but want some agreement first.

This is reason also why a programatic form submission exists.

tstoeckler’s picture

I think the use-case is pretty valid.
If you have a module which imposes certain restrictions on node properties or fields, there is no way to enforce them.
Right now you node_save() fails if you set a nid but not a vid. What if I create a super_revisions module which uses svid and I would like to impose the same restriction?

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

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should 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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dpi’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

Hurrah, Entity validation!