Blog not remembering field entries (like tags)

[Ottens]

Hello all,

A couple of weeks ago I started to have problems with my blog
http://www.ottens.co.uk/gatehouse/ User log-ins weren't remembered
anymore and tags weren't displayed. As a result of this, user avatars
arent' showing up anymore. When I give a new "Portrait URL" and "Save"
the field appears empty again. The same happens with tags. I can enter
tags and it *does* save them (for if I click to see all posts tagged
"Architecture" for example, the latest posts do show up) but when I go
back to "Edit" a post, the tag fields underneath is empty again.

I have already upgraded to the latest version of Habari, thinking that
might be the problem, and over IRC, have established that in all
likelihood, this is not a database problem.

Any thoughts?

Thanks!

[Ian Barber]

I've got this as well. I notice that the dashboard doesn't seem to be saving the options properly either, is showing the welcome screen, and I've got some disappearing tags on posts.

The tags issue seemed to be fixed in classes/post.php line 1012 by changing
    $result = Tags::get_associations( $this->fields['id'] );

to
  $result = Tags::get_associations( $this->id );

(I'd submit a patch, but I thought I'd wait for someone here to tell me I'm doing something dumb first)

With the dashboard and the user options thing, it looks like the fields value isn't being set. The user is being created through users get, but it looks the 'fields' property is filled with empty values, but the 'newfields' property has the data we'd want. Anyone got any thoughts on that?

Ian 

[Ian Barber]

On Thu, Jan 7, 2010 at 9:47 PM, Ian Barber <ian.b...@gmail.com> wrote:

I've got this as well. I notice that the dashboard doesn't seem to be saving the options properly either, is showing the welcome screen, and I've got some disappearing tags on posts.

The tags issue seemed to be fixed in classes/post.php line 1012 by changing
    $result = Tags::get_associations( $this->fields['id'] );

to
  $result = Tags::get_associations( $this->id );

(I'd submit a patch, but I thought I'd wait for someone here to tell me I'm doing something dumb first)

With the dashboard and the user options thing, it looks like the fields value isn't being set. The user is being created through users get, but it looks the 'fields' property is filled with empty values, but the 'newfields' property has the data we'd want. Anyone got any thoughts on that?

Ian 

Interesting, in query record changing 'loaded' to false in the constructor fixes this (it's in there being set to 'true' each time at the moment). That doesn't seem like a very safe fix though!

Ian

[Ottens]

Thanks for your help! I'm afraid I'm not so dexterous however: what is
the "query record" you're referring to?

--Nick

On Jan 7, 10:49 pm, Ian Barber <ian.bar...@gmail.com> wrote:

[Ian Barber]

I wouldn't actually try that one! It's a pretty bad idea.

The queryrecord is the class which User extends, system/classes/queryrecord.php. It looks like a generic data holding class, and when data is added to it with __set it checks whether its 'loaded' property is set. If it is, then it puts the data into a property called 'newfields', else into one called 'fields'. Loaded is set to true in the constructor, so when the User object is constructed, it's marked as loaded. When something tries to set the properties from the row of data, __set sticks them in newfields. 

Now, looking at it today I notice that there's a comment in QueryRecord:

private $loaded = false;  // Set to true after the constructor executes, is false when PDO fills data field

I have updated PHP recently, and I'm wondering if what has happened is that the way PDO fills the data has changing - it used to not call the constructor, so the data would be set to the right place. I can see this in the changelog:

http://bugs.php.net/bug.php?id=49521

Which is about calling __construct before __set on fetchObject. I wonder if that's what's happened here?

If so, not sure what the proper fix is - perhaps just having loaded as an optional parameter defaulting to true and passing it through as false from PDO.

Anyone with QueryRecord know-how want to chime in?

Ian

--
To post to this group, send email to habar...@googlegroups.com
To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/habari-dev

[rick c]

This appears to be related to PHP 5.2.12 somehow. My host upgraded
yesterday, and I started experiencing similar problems. Talking to
Ottens on irc, his host is also running PHP 5.2.12.

Rick

[Ian Barber]

 Apparently, the bug I referenced was fixed for 5.2.10, I upgraded straight from 5.2.8 to 5.2.12, so that would fit with my experience. If that is the problem, I think the way of doing it as before, with the property declared false then set true in the constructor, is out, but I'm not sure what the ideal replacement is. Passing an argument might be the best available way, though less elegant than the previous method.

Ian