Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi there!
I´ve noticed that if the editable field is left blank, it cannot be changed.
It appears this error:
No field found, of name: field_my-field-name
It won´t happen if I try to change an already filled field.
Thanks for your help!
Comment | File | Size | Author |
---|---|---|---|
#21 | error.PNG | 27.16 KB | hash6 |
#19 | 734888.patch | 656 bytes | xandeadx |
#18 | Screen shot 2012-03-20 at 2.38.23 PM.png | 39.44 KB | doublejosh |
#2 | fields-example.png | 47.84 KB | stevector |
Comments
Comment #1
LEternity CreditAttribution: LEternity commentedDuplicate #703988: No way to edit empty fields? Except that the error is kind of strange...
Comment #2
stevectorI don't think this is a duplicate.
I think this is related to the way CCK handles fields that are used on multiple content types.
For example, I'm working on a theater site that has a content type called "Calendar Items." There is a Calendar Item node for each performance of a production. This content type has a CCK date field so that it will appear on the Views-powered Calendar. It also has a node reference field to relate to the node that is the theatre production.
And for the moment it has two fields for performance-specific ticket links.
One of those fields, field_link, is used on multiple content types and is therefore held in it's own database table, content_field_link.
I also have a field specific to the content type: field_cal_link. This field lives in the database table content_type_cal as the column field_cal_link_value.
So, if I create a node in the Calendar Item content type and leave both field_link and field_cal_link blank, the database will have a NULL value for field_cal_link in the content_type_cal row for this new node. However it won't enter any record at all in the table content_field_link.
When this node is then edited using editablefields, there is no database row to target in content_field_link and the error is produced. However, if field_link has a value, and therefore a db record to update, the module behaves normally.
Having not looked extensively through the code on this module I can't say for certain if this is the root cause, but it seems like a likely candidate. I've attached a screenshot that will help to illustrate the scenario I described above.
Comment #3
p4trizio CreditAttribution: p4trizio commentedHi I have the same problem.
Did you solve it?
Updated Firefox to 3.6 and using last dev
Thank you
Comment #4
Rosamunda CreditAttribution: Rosamunda commentedI know I haven´t...
Comment #5
druvision CreditAttribution: druvision commentedsubscribing. This still doesn't work for me. The only bypass was to assign a non-blank default value to the field (e.g. '*').
Comment #6
Murzsubscribe. Solution "assign a non-blank default value" works, but not works with views "Empty text", editablefields ignores this views option. Issue about this: http://drupal.org/node/913204
Comment #7
andreiashu CreditAttribution: andreiashu commentedHi,
I just tested both 6--2 and 6--3 dev branches and this issue should be fixed. I would appreciate any testing on this and a confirmation.
Cheers,
Andrei
Comment #8
jimurl CreditAttribution: jimurl commentedmay not quite be fixed. I am using the 6.x-3.x-dev version from Nov. 15, and CCK 2.8, and had the same error. This field is being used in two different content-types, as mentioned in #2. If I remove the field from the other content-type, it works fine, so I think that is where the issue lies. Easy to work around.
Thanks for this module it is really cool, just what I needed.
Comment #9
andreiashu CreditAttribution: andreiashu commented@jimurl: thanks for this, to be honest I didn't really read all the comments (I just tested and it seemed fixed). Your explanation and pointing to #2 comment definitely helps.
I'll have a look soon.
Cheers,
Andrei
Comment #10
itserich CreditAttribution: itserich commentedThis is the error I am getting when I try to edit a field in a view that is currently value N/A.
However, the edit works in some content types. I have the field in three content types and get the error in two, in the other content type the edit works.
However, in the content type which works, I have three N/A fields and only two fields work. None of the three fields work in the other two content types.
Comment #11
rjbrown99 CreditAttribution: rjbrown99 commentedThis has been a long standing issue for me. In my case, I'm using it with the 2.0 release version of the module, content taxonomy field, shared field (i.e. the field uses its own table), DHTML. If the field has a value, any value, it can be changed with editablefields. If the field is blank it pops an error.
Comment #12
rjbrown99 CreditAttribution: rjbrown99 commentedMore info. My field is called field_type, and per #11 it's a content taxonomy field and it is shared between multiple content types, so it has its own table in the database (content_field_type).
When I try to make a change (looking at the Firebug console), I see this:
POST http://mysite.com/editablefields_submit 404 not found
... and the reply from the server says "No field found, of name: field_type".
Ok, so heading over to the module, function editablefields_submit(), we see the field coming in as variable $field_name. Then we get to this if statement:
That's going to fail because $node->{$field_name} does not exist since it's empty, so it's not going to be an array. So the logic falls through to the 404.
Not sure what the right approach is, but my probably-incorrect hack to make it work is just to make empty fields an array.
Comment #13
itserich CreditAttribution: itserich commentedI have been using Editable Fields for a couple months now, and generally the editable field works even if the field is blank.
I have not found a pattern for when it works or when it does not, but it does seem to work by node field, i.e. if the field works it works whether it is blank or not.
Also, there is a new editable field type "Editable Modal Widget" perhaps that works 100%?
Comment #14
rjbrown99 CreditAttribution: rjbrown99 commentedAnother note about this. I'm using a shared field in the DB (content taxonomy field), and my db schema looks like this:
table: content_field_myfield, then fields vid, nid, delta, field_myfield_value
Standard stuff, nothing special. Now, editablefields works if the node in question has an entry, including NULL entries. Like this:
VID = 168995
NID = 168995
DELTA = 0
FIELD_MYFIELD_VALUE = NULL
BUT... if the field in question isn't present at all for the NID in question, the content isn't even loaded into the view. So you get an empty DIV. I can't quite pinpoint where a change is needed, but I thought this was worth adding to the discussion.
My completely unscientific hack to fix this was to use views_bulk_operations to load up all nodes with a field of type field_myfield_value, where the field value is NULL. Then I selected the field (with no term selected), selected the nodes, and told it to update. Again, I'm updating the empty fields with an empty field. Even though the updated nodes are still empty, it does add a NULL DB record for them so they are properly picked up via editablefields.
Comment #15
asb CreditAttribution: asb commented@#7:
For me, this issue has not been fixed in editablefields-6.x-2.x-dev from 2011-Jul-12; I tried this on an empty text field from CCK core that is used to build the node title (via Auto Node Title); the CCK fields are listed in a Views table. Error message like in earlier versions:
No field found, of name: field_my-field-name
.However, it does work for me with editablefields-6.x-3.x-dev from 2011-Jul-07 and Views2. The modal dialog is pretty slow, much slower than just clicking into a field in a table, and the display is not updated after the field value has been changed, but besides this drawbacks, the 3.x-dev branch works for me.
BUT there is another issue; after enabling editablefields-6.x-3.x-dev, the contents of all node title fields dissappears from all views, no matter is these views even use editablefields. Scary. Since the modal dialog is so slow, and most of all because of the node-title-"sideeffect", it's currently still a better option to "bulk" edit through nodes via
./admin/content/node
.Comment #16
Rosamunda CreditAttribution: Rosamunda commentedI´ve latest 6.x.2 dev version and the issue is still there.
Comment #17
jhrizz CreditAttribution: jhrizz commentedSubscribing..
Comment #18
doublejosh CreditAttribution: doublejosh commentedI have the same issue. Similar screenshot (to others in this thread).
Presume this is due to the multiple content types using the field and the assumption this module makes about updating the data.
Comment #19
xandeadx CreditAttribution: xandeadx commentedCheck patch for 2.x branch. Works for me.
Comment #20
MBroberg CreditAttribution: MBroberg commentedI can confirm that so far this patch works for me when using a shared CCK text field.
Comment #21
hash6 CreditAttribution: hash6 commentedI added the above one line patch and I got the below error
The image link is given below
https://www.drupal.org/files/issues/error_22.PNG
Comment #22
joelpittetLast update was 2013, going to close as outdated because it's against 6.x branch.