Hi, I'm not sure this belongs here, but it seems like the logical place to start. I'm using your formatter_selector module (along with the custom formatter module) to theme a number of nodereference fields in an "edition" content type. The formatter selector works like a charm when I save the page, and when I go back and edit and save again. No problems. But, when I try to incorporate a triggered Rule Set (intending to "Publish" the edition node based on a CCK date field), it seems as though the link between the formatters and the fields disappears. When cron runs, and the page is published (according to the date field), and you visit the page, it is simply the non-themed node-title-link for the nodereferenced page that shows up. Clearing the cache, reloading the page and even adding a "forced re-save of the node" in the rule set does nothing to re-associate the custom formatter with the field.

The only thing that seems to work is going back into "edit" the edition (which is now published) and saving the edition again. Then, on this "save" the formatters are applied--unfortunately, the formatter-selector isn't "defaulting" to the formatters chosen in the database--so all of my choices are lost and I have to re-format the edition to make it look right.

I was wondering whether you have seen anything like this before and whether you might have an idea why the triggered-rule-"publish" action is treating the save node differently; or whether there is another way to accomplish what I am looking to do?

Thanks.

Comments

dellis’s picture

Title: Triggered Rule -> Publish removes formatter-formatting? » Publishing removes formatter-formatting

***Update--I've re-titled this issue based on new information:
So it turns out that the triggered rule has nothing to do with it. If I save a node that is using CCK formatters that have been assigned with CCK formatter Selector in an unpublished state, and then publish it via the admin/content drupal interface, none of the formats are saved and the node exactly resembles the one described above: all nodes are simply listed with titles (not even titles as links)... there is no formatting on the nodereferenced nodes.

As a result, I can't schedule nodes to be published that are using Formatter Selector--because it requires re-editing the page and re-selecting formatter options after the page has been published.

dellis’s picture

When I manually "unpublish" and save a published and manually formatted node, the formatters are still showing up. But when I go back and re-publish that node, the formatting disappears again.

It looks as though something about the publish action removes references to custom formatters set by the selector--are the formatters not being incorporated into the node object?

dellis’s picture

Category: support » bug
ndeschildre’s picture

Hello!

Thanks for the detailled bug report. That's the kind of bug report I like :)
Do you by chance use the module (which I don't remember the name) which put a "publish" tab near "edit" and "view" on top of the node? And do you use this link to trigger the bug?

With the standard publish operation (check/uncheck the "Published" checkbox on the "Publishing options" fieldset of the node form), I do not see the bug happen.

BUT I remember having seen this bug one time, and I believe the journalist used this "publish" tab.

Can you confirm?

dellis’s picture

hmm... no, just "Save" and "preview" buttons... I'm using the Rubik theme (for admin). I use the standard checkbox "publish" that comes with drupal to manually simulate the problem I had experienced with the triggered action of "publish node."

Yeah, it is the weirdest thing. It is like drupal doesn't realize that the node contains those formatter references when it publishes the node.

I have noticed that sometimes when I don't remove the focus of the field before hitting submit it sometimes won't save either, almost like the spinning circle/availability of the preview option is saving the connection to that nodereference field value, and that the connection is saved in the db by the removing focus event (I don't know whether this is true, but it "seems" true).

Thanks for looking into this--it is the weirdest thing...

Here are a list of modules I'm using:
Formatter Selector 6.x-1.2
Uberimage 6.x-1.2
Utilities 6.x-1.3
Views CCK Formatter 6.x-1.3
Content Access 6.x-1.2
Admin 6.x-2.0-beta2
Ajax 6.x-1.14
Ajax ui 6.x-1.14
CCK 6.x-2.6 (and other typical cck fields)
Custom Formatters 6.x-1.4-beta1
Emfield 6.x-1.18
Field Permissions 6.x-1.0
Form Markup 6.x-1.1
Markup 6.x-1.x-dev
Multiselect 6.x-1.6
Content Profile 6.x-1.x-dev
Custom Breadcrumbs 6.x-2.x-dev
Date 6.x-2.4
Devel 6.x-1.18
Image 6.x-1.6
ImageCache 6.x-2.0-beta10
Modal Frame 6.x-1.6
Advanced Profile Kit 6.x-1.0-beta2
AJAX Comments 6.x-1.8
Automatic Nodetitles 6.x-1.2
Backup and Migrate 6.x-2.2
CKEditor 6.x-1.0
Clone Module 6.x-1.0
Jquery Tools 6.x-1.x-dev
Masquerade 6.x-1.3
Nodeaccess 6.x-1.3
Secure Site 6.x-2.4
Poormanscron 6.x-2.2
Token 6.x-1.12
Rules (the suite) 6.x-1.1
AutoModal 6.x-1.x-dev
jQ 6.x-1.2
jQuery UI 6.x-1.3
jQuery Update 6.x-2.x-dev
Modal Node References 6.x-1.x-dev

dellis’s picture

Another Follow-up: Cloning the Node also removes the formatting selections... seems that something about Drupal programmatically saving the node forces it to lose the formatter value... any ideas?

ndeschildre’s picture


If I save a node that is using CCK formatters that have been assigned with CCK formatter Selector in an unpublished state, and then publish it via the admin/content drupal interface, none of the formats are saved and the node exactly resembles the one described above

Aah, read too fast.
I am also able to reproduce by publishing via the admin/content drupal interface.

Looking into it.

ndeschildre’s picture

Okay, the output is, if you save a node with node_save() while not using the classic node form, then the formatter data is lost.
That is of course not ok, and this will require some work.

I will review the others bugs, and then take care of it.

Cheers,
Nicolas

ndeschildre’s picture

Oookay, here is a patch

Index: aef_formatter_selector.module
===================================================================
--- aef_formatter_selector.module	(revision 4759)
+++ aef_formatter_selector.module	(working copy)
@@ -647,6 +647,31 @@
   if ($op == 'view') {
     $node->content['#pre_render'][] = 'aef_formatter_selector_composite_data_alter';
   }
+  if ($op == 'load')
+  {
+    $formatter_selection = _aef_formatter_selector_node_formatters($node->nid);
+    if(is_array($formatter_selection))
+    {
+      foreach($formatter_selection as $field_id => $data)
+      {
+        if($node->{$field_id})
+        {
+          if($data['global'])
+          {
+            $node->{$field_id .'_formatter'} = $data['global'];
+          }
+          if(is_array($formatter_selection[$field_id]['fields']))
+          {
+            foreach($formatter_selection[$field_id]['fields'] as $delta => $ind_data)
+            {
+              if($node->{$field_id}[$delta])
+                $node->{$field_id}[$delta]['formatter']['formatter'] = $ind_data;
+            }
+          }
+        }
+      }
+    }
+  }
   if ($op == 'insert' || $op == 'update') {
     $options = array();
     $type = content_types($node->type);

Could you please test it and check your usecases?

Seems to fix the problem here, and I would like to be sure before rolling a new version.

Cheers,
Nicolas

dellis’s picture

Fantastic! This did the trick with the scheduled edition triggered rule and drupal's content admin screen publish/unpublish actions.

Many thanks!

dellis’s picture

Status: Active » Fixed
ndeschildre’s picture

Rolled 1.3.

Careful, I have changed the patch for a safer one.

Thanks for your bug report!
It has in fact let me found a bug that puzzle us for quite some time. Having the frontpage of www.france24.com transformed into links everywhere instead of images+title+intro, without any apparent reason, was quite troubling :)

dellis’s picture

Thanks. I really appreciate your modules. They are all of really high quality and quite valuable. Many thanks for your work.

Status: Fixed » Closed (fixed)

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