Closed (won't fix)
Project:
Editable Fields
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
24 Nov 2009 at 20:18 UTC
Updated:
14 Mar 2014 at 22:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
batje commentedThe way it works is that the original field provider (either core, or CCK) will validate the node and raise errors or other messages.
In the latest dev branche we implemented these messages to actually show! So if you now fill in characters in an integer field, you will see the error after editablefields tries to post your change, right above the field in question.
We have tested this only within our own little environment, so more feedback is welcome.
Comment #2
LEternity commentedI just downloaded the dev. I like that it shows the messages now.
I'd like to have error messages and the description (i.e. the help text) of the field pop up in a separate div though. This is currently the case, but the div description always shows up right underneath the field. That potentially destroys the flow of the site. If I use editablefields in a views table it'll squeeze the description into the table, with all pretty side effects...
Comment #3
LEternity commentedComment #4
mstef commentedI haven't yet upgraded to the dev. Will it only work with CCK-shipped validation functions (putting letters in a numeric field) or custom validators I added myself, via form_alter or nodeapi? The latter is very important.
Comment #5
mstef commentedWell it doesn't go through hook_nodeapi() so I can't use that with the 'validate' $op. It doesn't work with hook_form_alter() at all. What's the way to do it then?
Comment #6
markfoodyburton commentedThe handling of this is all (pritty much) left to CCK core - so - in principle, whatever CCK does...
Minor problem - your mileage may vary - mine did :-(
is it just using the wrong hook?
Cheers
Mark.
Comment #7
mstef commented{edit out}
Comment #8
mstef commentedIs what using the wrong hook?
Comment #9
markfoodyburton commentedIt should go through _form_alter I guess - actual - I thought it did, but it's ages since I looked at that code.
Anyway, if you find a solution - let me know :-)
Cheers
Mark.
Comment #10
LEternity commentedMark, are you in San Fran for Drupalcon? If so, let's meet and I'll show you what I did.
Comment #11
LEternity commentedI was able to use Validation API to add custom validation. Since the module is no longer being maintained, I abandoned that solution. I ended up writing a custom module for the whole process.
Comment #12
mstef commentedSince I was using just checkmark fields, and was only concerned with access, i used hook_field_access() from CCK.
Comment #13
scarvajal commentedI created a new content type with a numeric field.
In the configuration of the field I had indicated minimum and maximum values.
Nonetheless if I edit the field while viewing the node the validation didn't work.
Comment #14
NaX commentedIt sounds like some people have found a solution to this problem. It would be nice if some of this wisdom was shared with the rest of the thread.
I ended up working up a solution using
#element_validatethroughhook_form_alter.Comment #15
matteogeco commentedI also have the problem at comment #13.
I found that the execution flow doesn't call CCK number_field() function, because the $form array misses the
'#validate' element, that should contain an array with a value that should be 'node_form_validate'.
I tried a patch (see the attachment). Now, the execution flow calls content_nodeapi() (the function that would call content_validate() and then, _content_field_invoke() and then number_field()) but now the $node object miss the "type" property, so content_nodeapi() doesn't call content_validate().
I tried to add it to $form_state in editablefields_form_builder() but I found that later (in drupal_process_form()) $form_state gets rebuilt and it looses the property I've tried to add to it.
I hope my investigations could help someone to reach the solution.
Comment #16
mengi commentedPer https://drupal.org/node/2148735, 6.x is longer maintained so issue is closed. If you wish to be a maintainer of the 6.x branch please create a new issue.