Closed (fixed)
Project:
Open Graph meta tags
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 May 2012 at 13:27 UTC
Updated:
24 Jul 2015 at 17:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mshick commentedBig +1 for this patch. I spent almost an hour trying to debug this — my nodes kept saying "An illegal choice has been detected" and failed to highlight the collapsed Opengraph fieldset. This patch solves the issue. Please incorporate!
Comment #2
p55mac commentedAlso seconding a big +1 to this.
...had to apply the patch manually for some reason though. As I had various errors through terminal.
Comment #3
cameron tod commentedVery big +1 from here too. I've fixed it locally in a form alter, but it would be great to see this committed and pushed to a stable release soon.
Comment #4
cameron tod commentedRe-rolled the patch against 7.x-1.x, and made it relative to the module directory rather than a Drupal install.
Comment #5
jamix commentedThe description for the thumbnail image element explicitly says that it can be left unset, in which case the first available image will be used. Therefore defaulting the form element to have the 1st image selected is not the right solution to the problem.
Instead, the original issue was caused by the form element's #default_value property being set to an empty string. The attached patch fixes it, while still allowing you to have no image selected for the node if you wish.
Comment #6
cameron tod commentedPatch looks great from here.
Comment #7
mshick commentedPatch in #5 worked for me and I agree, it seems cleaner.
Looking at form.inc, the _form_validate() behavior is pretty strange. It seems that setting no #default_value allows it to go through validation writing a NULL to the value, which makes some sense. The weird part is, I tried debugging and can't get that logic to trigger, even though the element passes through from beginning to end and has image => NULL set.
Rough bug for the stable release. This should get patched soon.
Comment #8
mshick commentedAn update on this problem. I just noticed another condition that can trigger it erroneously.
1. The user uploads an image to an image field.
2. User (or someone) sets an uploaded image to the OG thumbnail.
3. The user then deletes that original image and saves the node, without updating OG tags.
4. OG module does not check for valid entries on save, keeps the original, now invalid image path in the db.
5. Subsequent attempts to edit the node will not save, failing with the "Invalid entry..." error.
I haven't had time to delve into this, but again, this is a common user behavior.
I believe a custom validation or presave operation verifying the selected thumbnail (if set) against the currently available images is needed.
UPDATE: I just created an issue over here, with a patch that attempts to solve this problem #1617206: Deleted image can cause OG Meta to have the wrong thumbnail URL stored
Comment #9
drakythe commentedThanks for the patch #5, it works great. I've re-rolled the patch to comply with naming/coding standards. Also will make it easier to use with makefiles and the like.
Comment #10
Anonymous (not verified) commentedSame issue! Will try the patch, thanks!
Comment #11
Anonymous (not verified) commentedSetting priority to critical per the guidelines because this module prohibits editors from publishing content if the content type is not set to mark content as "published" by default. Since it disallows modification, and does not correctly identify which field is causing the error, it causes a lot of problems.
Comment #12
doublejosh commentedThis one is a serious pain!
Throw one more "pretty please" on the pile for a new release.
Comment #13
Anonymous (not verified) commentedI just deployed that patch in #9 about an hour ago and it works well.
Changing status to pretty please with community approval!
Comment #14
FooZee commentedWill this ever get committed please ? :) it has been more than a year ... and yes I confirm the patch @ #9 is working :)
Comment #15
FooZee commentedalso validated the scenario in #8 (but this leaves me confused whether the patch worked or not :) )
Comment #16
raprieto commented#9 works for me. Thanks @drakythe and @jamix.
Comment #17
maximilianmikus commentededited #9 to check if the default value exists in the options list.
Comment #18
ashwinshNew patch file added with proper formatting for resolving default selected image radio button issue.
Comment #19
torotil commentedI've committed a fix for that to 7.x-1.x this week.