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

[fu]

I suspect it's a tangle of different bugs in different areas, all manifesting the same symptom.

1) I'm not reproducing the behavior on post; the userpic "0" never gets attached to the entry in my database. Because the behavior happens on both versions of the update pages, I suggest looking at LJ::Protocol::postevent, see how the userpic prop is being set there. I'm pretty sure that the proper value is being POSTed, so it has to be something in how we're saving the userpic

2) Once you've got postevent fixed, I'd also look at LJ::Protocol::editevent; there should be an area with similar logic.... hopefully!

You can run a test that edits the entry by calling LJ::Protocol::do_request("editevent",... ). There's an example in t/protocol.t, which you can probably use.


I... just in case there's a display issue, I suggest looking at the database directly.

SELECT l.journalid, l.jitemid, l.value, p.prettyname from logprop2 l, logproplist p WHERE journalid=2 AND l.propid=p.propid AND p.name="picture_mapid";

3) Once you're sure everything is being set directly in the database, if it's still not working, then there's also issues with the display. Lucky!

(Umm I'm almost certain there will be, because I set some values manually in the database, and that didn't fix the display issues, so...)

For the new entry page, I'd look at how the select dropdown is generated: that's done by DW::Template::FormHTML. Note that any change here will require you to restart Apache (you can sometimes get away with not restarting, on other modules, but you absolutely need to with this one). I'd suggest looking at: the arguments passed in (warn Data::Dumper::Dumper( $args ); ), to start with, so you know for sure you're getting specific input.

_process_label_and_value is probably where you'll end up, since everything else is just a wrapper around it.

You might find t/template-plugin-formhtml.t useful; it'll probably be faster to run that than restart apache / reload pages all the time.


For the old entry page, that's in LJ::HTMLControls, and I'm not as familiar, but that's the place to start!

[purplecat]

Ooh! Knowing I may need to restart apache for some of this is a big help, because I wasn't sure what I'd done to fix the postevent issue, it just suddenly started working.

I was having trouble writing tests with do_request and ended up using post_fake_entry instead, but I'll take another look at it.

[purplecat]

Yes! stop and start apache and the edit form is doing the right thing to the database. So just the display of the icon on the edit form to fix.

(And then to worry about icons on PM which I've not even checked yet).

[fu]

Oho awesome!

Hopefully the display of the icons on the PM form will just work. No guarantees, but it's using the same functions as the others.

[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)