Hey there,

not sure if there is an issue or if i did something wrong but with a regular text cck, checkbox / radio widget (specifically checkboxes in this case) i have 6 key|value pairs specified. for display of the field i have click to edit specified but while viewing the field on full node view, only the first checked item is displaying. all the other checked items are in the dom, they have the additional css classes of "editablefields_REMOVE editablefields-processed" which have style="display:none;" on them causing them to not display by default when they should be and are even being rendered.

notes of my setup: using jquery_update 6.x-2.0-alpha1 and a content template thats trying to output these checkboxes like the following

<?php foreach ((array)$node->field_creditcards as $item) { ?>
  <div class="field-item"><?php print $item['view'] ?></div>
<?php } ?>

any help would be much appreciated.

thanks

Comments

vishun’s picture

*and they also have style="display:none;"

rhymeswithcamera’s picture

I am having the same issue. I have a few CCK fields that each capture a max of 5 taxonomy values (via checkboxes). When the page initially displays these fields, only the first value (delta=0) is displayed. However, once I click [edit] and make a change (by checking or unchecking one item), the field automatically collapses and displays all the checked values for the field - which is what I would like to see initially. On a related note, I have to click [edit] each time I want to edit the field's list. I can't expand the list once, check/uncheck all the items (up to 5 in my case), and then collapse the field when I'm all done.

I am not a coder - so I apologize if I'm poking my nose where it shouldn't belong - but i did find this code in the editablefields.module (lines 128-135) that seems to be causing the extra values to not display initially. It's related to what vishun was saying. What is the purpose for this snippet?

...
      // CORE handling shoudl have a div on each,
      // MODULE handling should have a div surounding all elements (treat it as
      // one field) (So, we'll arrainge for the JS to remove the rest!)
      if (content_handle('widget', 'multiple values', $field) != CONTENT_HANDLE_CORE) {
        if ($delta != 0) {
          $class = "editablefields editablefields_REMOVE";
        }
      }
...

Any help on this issue is greatly appreciated. This is a great module that I'd love to roll out with our new website.

vishun’s picture

I also experienced that after the initial save that it displays/works fine. Not sure about that specific code but i think the removed and/or processed classes are used to hide/show the actual editing such as when you click on an item, it adds that class to the item to hide it so that it in can display the edit version, then vice versa once saved.

vishun’s picture

Pretty classic. Just encountered this issue again and completely forgot about my initial experience with it. It is still broken in 6x-2x-dev, though it seems to be removed or different in 6x-3x-dev.

rhymeswithcamera, you are right, it is that code that is causing this issue. Commenting it out makes it work fine except that when you click to edit the item, the additional editablefield divs do not get removed. I will probably be looking into a more permanent fix for this and will post my findings.

vishun’s picture

Status: Active » Needs review
StatusFileSize
new2.17 KB

Being that the output was as expected after you save something with clicktoedit, I focused on that being the approach to render the output on the initial load as well. The editablefields_view() function is responsible for rendering this output and it has been adjusted to maintain previous functionality while handling new requests from theme_editablefields_formatter_editable().

The only potential downside I see to this approach is that the initial render of this content cannot be easily themed with a theme() override, but, it is relatively negligible because after a save this output is already not capable of being themed.

Important: You need to clear your site cache for these changes to work properly as there is a change to hook_field_formatter_info()

vishun’s picture

Status: Needs review » Needs work
StatusFileSize
new867 bytes

Here is another change that appears to be needed on top of the previous patch. Will be merging the two.

joelpittet’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)

Last update was 2013, going to close as outdated because it's against 6.x branch.