How to reproduce

  1. Enable core Locale module (I think it'll be enough, but in my case, I've also added another language to Drupal and made this language the default one)
  2. Define a content type and disable multilingual support for it (in "publishing options")
  3. Configure Antispam to check node content of content type
  4. Create a new node of content type with body through Drupal web interface

Expected result

Antispam should load the body of the node and perform the checks.

Outcome

Notice: Undefined index: ... in function antispam_node_validate() (line 890 in /etc/drupal/7/sites/default/modules/antispam/antispam.module).

Antispam can't load the body of the node and can't perform the checks at all. It's impossible to manually submit ham or spam to the back-ends selected.

Root cause

This happens because Antispam is wrongly handling node language.

When Locale module is enabled, new nodes are being created with "language" property set to the "default language".

When a content type has multilingual support disabled, new node's fields are being created under language key "und".

Here is an example:

stdClass Object
(
    [vid] => 227
    [uid] => 1
    [title] => noc
    [log] =>
    [status] => 0
    [comment] => 1
    [promote] => 0
    [sticky] => 0
    [nid] => 227
    [type] => honey_pot
    [language] => ru
    [created] => 1412942003
    [changed] => 1412942003
    [tnid] => 0
    [translate] => 0
    [revision_timestamp] => 1412942003
    [revision_uid] => 1
    [body] => Array
        (  
            [und] => Array
                (
                    [0] => Array
                        (
                            [value] => noc
                            [summary] =>
                            [format] => 1
                        )

                )

        )  
...

See Language support for entity fields for detailed explanations. Briefly, language "und" for body means that language is defined by the parent node's language, not vice versa.

In other words, you can't take node's language and look up for the same body language - it doesn't make sense. See What Developers Need to Know about Multilingual Drupal 7 Sites for suggestions.

Same logic applies to comments.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

btbroot’s picture

FileSize
3.97 KB
btbroot’s picture

FileSize
3.97 KB
manyk’s picture

Your ideea is good but the implementation reduces the chance for some Drupal installations to work on versions prior to PHP 5.4 because the way you referenced the array element.

[PHP Parse error: syntax error, unexpected '[' in sites/default/modules/antispam/antispam.module on line 890

See this: http://php.net/manual/en/language.types.array.php#example-102

manyk’s picture

Status: Patch (to be ported) » Reviewed & tested by the community

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 2: locale.patch, failed testing.

marcoscano’s picture

Title: Incompatible to core Locale module » Issues when used in multi-lingual sites
Status: Needs work » Needs review
FileSize
10.51 KB
10.38 KB

True, we shouldn't assume the entity's language when checking field values.

Re-rolled the patch in #2.

(Note: sorry about the trailing whitespaces fixes, my IDE did it automatically and I didn't bother to prevent it :)