Difference between icon selection when posting and when editing a post

[purplecat]

A while back I tackled a bug in which icons could not have "0" as a keyword. The problems were all caused by the fact that perl treats "0" as false, so a lot of checks for the existence of a keyword on the icon were failing.

Having fixed that particular problem a host of others have been revealed when someone tries to use an icon with a 0 keyword and I've been working through these.

At present, in my dreamhack, it is possible to make a post with a 0-keyword-icon selected and view that post. However if you then try to edit the post the icon gets replaced by the default icon, and if, in the edit page, you attempt to select a 0 keyword icon, it doesn't get attached to the post in the database.

I'm tearing my hair out over this because I can not identify how icon selection differs in the edit form from the post form. The bug appears both using the new and old versions of the post form so I'm assuming it isn't in the javascript or template toolkit and I'm going cross-eyed grepping the codebase.

One of my problems is I'm not even entirely clear where may be a good point to start inserting some "warn" statements, or how to simulate post editing within the test suite.

Any hints, suggestions or pointers much appreciated.

Comments

[purplecat]

Out of interest where does icons.size (from module-icons.tt) get set?

EDIT: scratch that, I think defaulticon in Entry.pm is the problem... somehow

[fu]

How's it going? It might not be the default icon; that just gets shown as a fallback. Maybe we're not properly setting "selected" when the value is 0. (I suggest a lot of warns processlabel_and_value)

(Also just so you know: icons.size is standard / available in template toolkit because icons is a list. It doesn't need to be set anywhere)

[purplecat]

I've had a fiddle with process_label_and_value but I don't think the problem is getting as far as there - the problem isn't the select box but the div above it.

I do keep finding instances of (effectively) if ( $kw ) and changing to if ( defined $kw ) (including one in process_label_and_value) I'd just sort of be happier to have located the point where it goes missing and trace forwards rather than changing random things which look wrong in the hopes that something somewhere will suddenly start working.

I've established that _backend_to_form is working properly and all the instances of $vars->{formdata} seem to be being handled correctly so I think the issue is occurring somewhere between there and module-icons.tt - I just can't find where...

I'll try to have another fiddle this evening.

[denise]

I think you might be the new "person with the greatest knack for picking a bug that seems simple until you dig into it a bit". :)

[purplecat]

I'm doomed really, though I am learning loads about the code base.

Just fallen down version management hell at work. This is clearly not my week.

[denise]

You totally deserve cookies for this!

[purplecat]

Well there was a problem in process_label_and_value, it's not solved things mind - I think LJ::html_select is my next culprit. But we're getting there!

EDIT: Bug squished!!! At least in the new edit page - yet to check the old edit page.

[fu]

Yes! Awesome!

[fu]

Awesome! Congrats!

[purplecat]

Wrong icon displaying in PMs :(

I'll dig around again today but off-hand, do you know which database tables I should look at for PMs.

[fu]

I think usermsgreceived but I'm not sure off the top of my head! (Spelling might be off too)