Needs review
Project:
Nodes In Block
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Reporter:
Created:
20 Sep 2009 at 04:05 UTC
Updated:
10 Mar 2015 at 01:27 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
swentel commentedCan confirm this, I commited a fix on the drupal 6 branch. Can you try out the next development build (probably available in 8 hours) and see if the error goes away ? If all goes wall, an urgent bugfix release will roll out after that.
Comment #2
mediboard commentedI am seeing this as well. The dev version from 20-9-2009 did not fix the problem. I am running Druipal 6.14.
There doesn't seem to be a way to "Disable" it in which case we get that error message for every node when we try to edit.
Comment #3
aturetta commentedRe #2
I can confirm: for example, if you say that 'story' nodes can go in a 'nodesinblock' block, from then on there is no more a way to create a story with no 'nodesinblock' setting.
More: if you later disable the story content-type from the nodesinblock admin menu, the 'queue' page will still show all 'story' nodes.
Seems to me that now it requires dedicated content types to put in blocks.
Comment #4
swentel commentedYep, I'm going to revert that change this weekend together with another pretty anoying bug. Saturday or sunday, I'll let you guys know!
Comment #5
swentel commentedCan you guys test out the next build of the development release. All should be working fine again. I reverted some stuff I introduced in the latest release. If all goes well, a new release will be out somewhere next week.
Comment #6
JamesAn commentedI was having the same bug with editting existing nodes (or creating new nodes) of the content type that I previously specified to use with nodesinblock. I worked around the issue by setting nodes of this type to a block that wasn't in use, as the 'Visibility field is required' error was flagged since there was no 'None' option in v1.3.
The fix found in 1.x-dev works perfectly for me. Inspecting the code, the addition of
$block_options[-1] = t('None')and the checks for$node->nodesinblock_delta != -1make sense.Comment #7
swentel commentedOk, marking this as fixed. There will be another commit tomorrow fixing another small bug (which has nothing todo with this, don't worry), a new release will be out end of november.
Comment #8
aturetta commentedI confirm it is fixed in CVS
Thanks
Comment #9
greta_drupal commentedAny chance of getting a patch (I'm without CVS client at the moment) or code line repair -- if only a few?
Comment #10
swentel commentedA new release is out, have fun!
Comment #12
eric_a commentedSomehow my scenario must be different form the ones above because the same error bit me today.
Today I installed 6.x-1.4 and then in admin/settings/nodesinblock I configured my single block to ''display on every page except..." I then went back to an existing node, assigned it to the block and tried to save.
I had to workaround it by entering a none-existing path, because I needed it on every page...
Comment #13
swentel commented@Eric_A : if you want it to show up everywhere, you'll be better of choosing the 'Show on only on the listed pages' as the other way won't work correctly, simply because of the way that Drupal Core works. I'm thinking to remove the other option anyway since this is confusing a lot of people (including me) during the setup and testing.
Comment #15
hydra commentedFor me this issue happens, when I have a user, who only is allowed to create and edit a certain content type. If this content type uses nodesinblock, the message appears and the user is not able to save the node. As admin all works fine.
Comment #16
remaye commentedI can confirm :
it happens to an user when "Deny configuration on node form" has been selected for this user.
The "node in block" tab doesn't appear in the node edit form but the visibility field is still tested.
We should probably test if "Deny configuration on node form" is set to "on" in "_nodesinblock_validate" function
adding : && $node->nodesinblock_enable == 1
It works for me, unfortunately I don't know how to make a patch... and also I can't be sure the fix is totally safe...
Hope that helped saving time anyway.
Comment #17
hydra commentedWell I'm not really sure where the problem begins. I fixed it by setting the default value in the formular to -1 if nothing is already selected. I think swentel knows better which solution is the right one..
Comment #18
cwsites commentedI'm new to Drupal, and I have a site in 7.2.1 and this issue has resurfaced. I removed the old page image and uploaded a new one and when I click on "Save" I get the error "Visibility field is required"
Comment #19
kingfisher64 commentedUnchecking "Deny configuration on node form" as #16 suggested fixes this. This allows all roles that user to save any changes.
Comment #20
ronline commentedWorking patch attached.
Comment #21
triple5 commentedSorry, but the patch is not working for me. Who is maintaining this module now?
Comment #22
jvandooren commentedI have a potential fix in the -dev branch of my fork. You can try it out: https://github.com/Ozmodiar/nodesinblock/tree/7.x-1.x-dev
or zip: https://github.com/Ozmodiar/nodesinblock/archive/7.x-1.x-dev.zip
Be sure to test as many use-cases as you can. I don't know if I tried them all...
I'll try to provide a patch for this -dev version later.
Comment #23
jvandooren commentedPatch attached...
Again... test this patch thoroughly before applying this into a production environment.
Comment #24
Jean-Francois commentedSorry, I had written that the bug appears in 7.x-1.0 as well but just saw that the 7.x-1.x-dev version is more recent...