For some reason, the node save wasn't working unless the first image was manually selected. So the auto selection wasn't applying at all.

I've included a patch that sets the default to the first image in the form to fix this.

Comments

mshick’s picture

Big +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!

p55mac’s picture

Also seconding a big +1 to this.

...had to apply the patch manually for some reason though. As I had various errors through terminal.

cameron tod’s picture

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

cameron tod’s picture

Status: Active » Needs review
StatusFileSize
new1.48 KB

Re-rolled the patch against 7.x-1.x, and made it relative to the module directory rather than a Drupal install.

jamix’s picture

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

cameron tod’s picture

Patch looks great from here.

mshick’s picture

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

mshick’s picture

An 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

drakythe’s picture

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

Anonymous’s picture

Same issue! Will try the patch, thanks!

Anonymous’s picture

Priority: Normal » Critical

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

doublejosh’s picture

This one is a serious pain!
Throw one more "pretty please" on the pile for a new release.

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community

I just deployed that patch in #9 about an hour ago and it works well.

Changing status to pretty please with community approval!

FooZee’s picture

Will this ever get committed please ? :) it has been more than a year ... and yes I confirm the patch @ #9 is working :)

FooZee’s picture

also validated the scenario in #8 (but this leaves me confused whether the patch worked or not :) )

raprieto’s picture

#9 works for me. Thanks @drakythe and @jamix.

maximilianmikus’s picture

edited #9 to check if the default value exists in the options list.

ashwinsh’s picture

New patch file added with proper formatting for resolving default selected image radio button issue.

torotil’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Status: Reviewed & tested by the community » Fixed

I've committed a fix for that to 7.x-1.x this week.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.