Wouldn't it be nice...

if we could add validation functions to check the content of each editable field? I'm currently working on a hook_form_alter solution. Has anybody tried this before? I'd like to find a solution where I don't have to hack the editablefields module itself.

CommentFileSizeAuthor
#15 editablefields_validate.patch966 bytesmatteogeco

Comments

batje’s picture

The 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.

LEternity’s picture

I 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...

LEternity’s picture

Version: 6.x-1.2 » 6.x-2.x-dev
mstef’s picture

I 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.

mstef’s picture

Well 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?

markfoodyburton’s picture

The 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.

mstef’s picture

{edit out}

mstef’s picture

Is what using the wrong hook?

markfoodyburton’s picture

It 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.

LEternity’s picture

Mark, are you in San Fran for Drupalcon? If so, let's meet and I'll show you what I did.

LEternity’s picture

I 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.

mstef’s picture

Since I was using just checkmark fields, and was only concerned with access, i used hook_field_access() from CCK.

scarvajal’s picture

I 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.

NaX’s picture

It 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_validate through hook_form_alter.

matteogeco’s picture

StatusFileSize
new966 bytes

I 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.

mengi’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)

Per 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.