The following error appears when one tries to save/update a node that is set to "Never Protected" under the content type settings page ( e.g. admin/structure/types/manage/page). This error prevents the user from saving the node and it appears the temporary fix is to just enable password protection for that content type.

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'protected_node_is_protected' cannot be null: INSERT INTO {protected_nodes} (protected_node_is_protected, protected_node_passwd, protected_node_show_title, nid, protected_node_hint) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => 3 [:db_insert_placeholder_4] => ) in _protected_node_save() (line 718 of /sites/all/modules/protected_node/protected_node.module).

Comments

idflood’s picture

I quickly stumbled upon this issue after configuring the module. Here is a simple patch that should fix the issue. It makes the assumption that if $node->protected_node_is_protected is not set then the node type is configured to "never protected".

idflood’s picture

Status: Active » Needs review
idflood’s picture

There was another notice when updating an existing node (unprotected content type). The new patch adds the same condition on the protected_node_node_update function.

idflood’s picture

Found one more issue when viewing a node from a "never protected" node type as anonymous. I've added a modification to a condition in the protected_node_is_locked function:

// before
if (!$node->protected_node_is_protected) {

// after
if (isset($node->protected_node_is_protected) == FALSE || !$node->protected_node_is_protected) {
sachbearbeiter’s picture

testet patch #4 + looks good + so far no messages anymore ...
continue testing ...

thanks a lot ...

zilverdistel’s picture

Status: Needs review » Needs work

This also seems to fix an issue with importing nodes using the feeds module. I'd like to commit this, but I still have some questions/remarks about the patch.

+++ b/protected_node.moduleundefined
@@ -230,7 +230,7 @@ function protected_node_is_locked($nid, $op = 'access') {
+  if (isset($node->protected_node_is_protected) == FALSE || !$node->protected_node_is_protected) {

Is there a reason why not to use if (!isset($node->protected_node_is_protected) || !$node->protected_node_is_protected) instead?

Also, I see you use 2 "=" here, while in all other chunks of the patch you are using 3 "=". Is there any reason for this?

+++ b/protected_node.moduleundefined
@@ -410,6 +410,11 @@ function protected_node_node_load($node, $types) {
+  // The node type is never protected if $node->protected_node_is_protected is not set

Following the drupal code standards, Comments should start with a capital and end with a period (or a question mark). See http://drupal.org/node/1354.

Greetz,

Diederik

idflood’s picture

Status: Needs work » Needs review
StatusFileSize
new2.28 KB

Hi, thanks for the review.

I think I've used the "== FALSE" instead of "!isset" since it's more explicit and more easily readable. The 3 "=" (strict equality) are not necessary since isset() will always return true or false.

Here is an updated patch. Let me know if you prefer that I change the "== FALSE" by the shorter "!isset" version, I can do that quickly if needed.

zilverdistel’s picture

Status: Needs review » Fixed

Committed. I decided to go for the !isset() since it's more commonly used and because it makes the code lines shorter (which also adds to readability).

http://drupalcode.org/project/protected_node.git/commit/4ad3d6e

Thanks for the good work on this!

Greetz,

Diederik

sachbearbeiter’s picture

please have a look for:

http://drupal.org/node/1577682

zilverdistel’s picture

Please don't mention unrelated issues, or if you think it is related at least explain why you think it is.

Thank you,

Diederik

Status: Fixed » Closed (fixed)

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