Hi,

when I go to "admin/config/system/mail-edit/subscriptions_mail_node-type-MYNODETYPE/de" or anywhere else where I can change the mail texts I get the following error messages:

    Notice: Undefined index: decimal in subscriptions_token_info_alter() (Line 397 von /sites/all/modules/subscriptions/subscriptions.tokens.inc).
    Notice: Undefined index: text in subscriptions_token_info_alter() (Line 397 von /sites/all/modules/subscriptions/subscriptions.tokens.inc).

Best,
Tobias

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

salvis’s picture

I'm not sure what is happening, but you seem to have a conflict with some other contrib module that tries to define tokens of type list<decimal> and list<text>.

EDIT: see http://drupalcode.org/project/subscriptions.git/blob/52234d5dc6bd5280ea3... for the line in question.

A-snowboard’s picture

Hello,

A solution has been found for this problem?

salvis’s picture

Status: Active » Postponed (maintainer needs more info)

No. Only those who have the problem can work on it...

A-snowboard’s picture

ok no worries.

Unfortunately I do not have the skills to try to fix the bug.

With apologies.

brad.bulger’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Active
FileSize
712 bytes

i'm getting this as well, on the latest dev. in my case, the source is a text list field in a content type, nothing unusual.

but in any case, i think the problem is Subscription's expectation that it will find an English name for the type. since it seem to only be a label, i would think that an acceptable fallback is to use the type as its own name:

    $type_name = isset($data['types'][$type]['name']) ? $data['types'][$type]['name'] : $type;
cvining’s picture

I was experiencing this same issue using the latest dev versions of Subscriptions & Mail Edit

Notice: Undefined index: text in subscriptions_token_info_alter() (Line 401 in /sites/all/modules/subscriptions/subscriptions.tokens.inc).

brad.bulger's solution worked for me.

I'm not sure where the problem came from exactly. To test, I set up a sandbox site with pretty much the same modules and configuration using Features. Of course 'pretty much' can be the whole game, but the sandbox site threw no errors at all. So I'm using brad's suggestion and moving on with life!

Thanks for all the fish!

-- Cronin

salvis’s picture

Thanks, brad.bulger and cvining!

in my case, the source is a text list field in a content type, nothing unusual.

Where does that come from? contrib?

I've added a core text list field to the core blog content type, created a blog post with one of the items, added the corresponding token to the template, and previewed the post. All this works as expected, no notices, and the label shows just fine.

salvis’s picture

Version: 7.x-1.1 » 7.x-1.x-dev

I'm getting only three list<> types, namely

  • list<subs_item>
  • list<file>
  • list<term>

You seem to get list<text>, but where does that come from???

brad.bulger’s picture

i am not sure - this was an upgraded 6.x database. but that's why as i was tracking it down it struck me that, really, it didn't matter where it came from. the real problem at hand to be fixed was the expectation about the data.

salvis’s picture

Status: Active » Needs review

I don't think the D6 origin would make any difference here. There was no Token support in Subscriptions/MailEditor for D6 (they use !variables).

I've tried to reproduce this issue, but without any luck. #5 may improve the behavior, but as long as we don't understand the error condition, we can't be sure that it's the correct fix.

cvining’s picture

I think you're right resist incorporating poorly understood 'hacks' like this until you actually understand the problem. In mean time, I'll just live with it. Thx!

brad.bulger’s picture

i did some more digging. an example of a field that triggers this is a checkbox field from a Drupal 6.x database that has been migrated to Drupal 7.x. the field's property_type is "text", and so the type ends up as "list<text>". if you create a list text field from scratch in Drupal 7.x the type is just "text", so you don't get this problem.

i guess you could say that this is a problem with CCK's content_migrate module, but people are not going to go back and re-migrate their databases with a future fixed version just to make an undefined index notice go away...

salvis’s picture

[...] people are not going to go back and re-migrate their databases with a future fixed version just to make an undefined index notice go away...

I agree, but list<text> could at some point be legitimate.

Implementing a hack in Subscriptions to accommodate broken third-party data caused by a buggy migration in a third-party module is a very slippery slope.

How can it be that this bothers only Subscriptions, but not CCK? Is CCK more tolerant? If it knows about the broken data, should it not take care of fixing it?

roball’s picture

I am getting the same PHP notice with the latest dev versions of Subscriptions and Mail Editor (as reported at https://drupal.org/comment/8511011#comment-8511011) whenever I view admin/config/system/mail-edit/subscriptions_mail_.DEFAULT/en.

It's on a fresh cleanly installed D7 site, so no update from D6 happened.

salvis’s picture

As stated in #10, I haven't been able to reproduce this, and I'm not convinced that this is a bug in Subscriptions that needs to be fixed.

Where does that list come from and what's the intention?

roball’s picture

Where does that list come from and what's the intention?

Which list do you mean?

salvis’s picture

This issue is about some module injecting bogus tokens of type list&lt;something>.

roball’s picture

After disabling the Profile 2 module, loading admin/config/system/mail-edit/subscriptions_mail_.DEFAULT/en no more triggers the PHP notice, so it seems to be caused by that module.

roball’s picture

Title: Error messages when editing subscription mail text » PHP notice on viewing subscription mail text edit page when Profile2 module is enabled

Updating Title. Is the Status still accurate?

salvis’s picture

I'm not sure — has anyone tried to ask the Profile2 maintainers why they're using tokens of the form list<something> and how these work?

vitalik_m’s picture

Version: 7.x-1.x-dev » 7.x-1.1

I'm running Dev and Production server and was getting the same error on the Production server but not the Dev.

Notice: Undefined index: text in subscriptions_token_info_alter() (line 397 of /var/www/html/sites/all/modules/contrib/subscriptions/subscriptions.tokens.inc)

The difference was the memory_limit on Production it was 128m and it was 512m on Dev. Once I dropped the limit to 128 on the Dev the error appeared.

It's not a solution (to increase the limit), but it may help to re-create the error on the developer's machines.

p.s. i don't have the Profile2 installed on any of my machines

  • salvis committed 248dac4 on 7.x-1.x
    #2023013: Avoid a conflict with Entity API's list<> tokens.
    
salvis’s picture

Version: 7.x-1.1 » 7.x-1.x-dev
Status: Needs review » Fixed

For the record: line 397 in 7.x-1.1 is the same as line 401 in 7.x-1.x-dev:

$type_name = $data['types'][$type]['name'];

On my development machine, Devel shows me a memory consumption of 19+M. I can get down to 20M and still Preview the template. At 19M it crashes with out of memory.

I've installed Profile2, but didn't get that notice.

Finally, the key ingredients seem to be having a Text field in a node and having the Entity API module installed.

vitalik_m: I don't see how the amount of memory could make that kind of a difference here.

Please try the -dev version (give it up to 12h to be repackaged) and let us know how it goes.

salvis’s picture

Title: PHP notice on viewing subscription mail text edit page when Profile2 module is enabled » Notice: Undefined index: text in subscriptions_token_info_alter()
roball’s picture

Bingo! Just updated Subscriptions from 7.x-1.1+22-dev to 7.x-1.1+23-dev, and the PHP notice indeed no more occurs. And I also have the Entity API module enabled. So you seem to be right that this module was the reason. Excellent catch!

Thank you for finding the cause and fixing it.

salvis’s picture

Thank you for the confirmation, roball!

(Correction: The conflict was with the Entity Tokens submodule of the Entity API module, something along the lines of #1272560: Entity tokens duplicates field tokens created by token module.)

Status: Fixed » Closed (fixed)

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

tammo’s picture

Could all this great work be baked into a new release, please?

Thanks in advance!