Hello thanks for the awesome module.

I am not 100% sure this issue is caused by token but token is the common link along with views.

When I use token to pass on an argument to views from either "views attach" or rules bonus pack's "check number of items in a view". The body content and all fields on content types that are affected disappear.

If I disable the rule or change the views attach argument to other than token content returns. The content is under both dev load and render tabs.

Does anyone here know what could be going on?

Comments

CraigBertrand’s picture

CraigBertrand commented

Changing the rule to use php to pass on the term id instead of the token fixed the issue with those content types. However the issue still remains with the views attach module when trying to use a token to pass on an argument.

So either views doesn't like tokens at the moment or something in token is not working correctly?

I am not a developer so please advise me if this issue should be here or in views?

Thanks

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

I have no clue why Token would be responsible here. It's just an API.

jim kirkpatrick’s picture

jim kirkpatrick commented
Title: Disapearing node content » Disapearing node content; #childen empty on elements within fieldsets
Version: 6.x-1.18 » 6.x-1.x-dev
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

Argh.... just found this after a day of fruitless debugging. Me too...

After updating to 6.x-1.18, this code: 

$node->content['group_related']['group']['field_areas']['#children'];

Suddenly returned NOTHING, but only on certain nodes -- I think it's just those with fieldgroups. The latest DEV does this too.

It seems that the settings in admin/content/node-type/[NODE TYPE]/display are no longer being treated properly, and everything that's not 'excluded' is taken from the $FIELD_NAME_rendered and $node->content['group_xxx']['group']['field_yyy']['#children'] and stuffed into the $node->content['body']['#value'] variable instead.

This is a certainly a critical bug that breaks the layouts of template-based field displays. I assume it's an interaction with the fieldgroup because my other content types that share the same fields but DON'T have them in a fieldgroup works fine.

Rolling back to 6.x-1.17 fixed the issue for me.

jim kirkpatrick’s picture

jim kirkpatrick commented

Further to my last: 6.x-1.17 at least showed the fields but had issues with Custom Breadcrumbs... Downgrading again to 6.x-1.16 means the whole site is working as it once was.

@Dave Reid: Mate, I couldn't believe it was token either which is why I spent an embarrassing amount of hours tracing code and outputs around content.module and in core, flushing caches and scanning various database tables. Nothing I did fixed it, except downgrading Token.

It's worth pointing out that #children was filled in and working within content.module's content_field() function, but only for some operations: appeared fine for 'view' and 'alter', but by the time 'preprocess_node' was called, #children was empty and had been stuffed into the body node's body...

Dunno, perhaps there's a spurious assignment (=) instead of a comparison (==) or some similar oddity somewhere in later token versions when fieldgroups are rendered...

Hope the above helps, shout if you need any further info.

jim kirkpatrick’s picture

jim kirkpatrick commented

And further to my further to my last (!): I don't think fieldgroup is the cause now... Not sure why it only affected some content types but not others, perhaps it's to do with the field types in each.

Again, shout if you want me to test/debug further.

jim kirkpatrick’s picture

jim kirkpatrick commented

It appears #1354618: CCK $<field_name>_rendered fields not available to node template is dupe of this too.

CraigBertrand’s picture

CraigBertrand commented

I just worked around this with some views args when using views attach and php in rules. Would much rather use tokens for simplicity and security. Is there something a non coder could do to help debug?

Craig

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Category: bug » support
Priority: Critical » Normal
jim kirkpatrick’s picture

jim kirkpatrick commented

I didn't think it was a support request ;-)

In a nutshell, code that worked before and is referred to in many theme docs/tutorials and that had worked for ~2 years suddenly stopped when I upgraded from 6.x-1.6 -> 1.8. Further, the behaviour of $node->content['body']['#value'] changed too.

If you have any ideas, I'm all ears Dave... Thanks.

CraigBertrand’s picture

CraigBertrand commented

It seems to me that notifications was declaring duplicate tokens.

http://drupal.org/node/1412882

The patch provided fixed the disappearing content (although I still have some notifications bugs with token.)

Perhaps if someone else experiences the phantom content they will need to check if there are duplicated tokens.

Someone more php savvy could perhaps say this a bit better. All I know is that content is back. :)

jim kirkpatrick’s picture

jim kirkpatrick commented
Project: Token » Notifications
Category: support » bug
Status: Active » Closed (duplicate)

Confirmed: Not a support request, but a bug in notifications_content module that manifests with Token 6.x-1.17+ only.

Marking as dupe of #1412882: Broken node rendering AND GIVING MASSIVE PROPS TO CraigBertrand! Thanks man, this bug has been a right pain for me.

CraigBertrand’s picture

CraigBertrand commented

I am glad to help Jim it was a huge pain to me too!