From a brief glance, it seems this may be an issue with the new
anonymous users.
Now, on every load, a new UserObject is created. In doing so, I
imagine the constructor would be called. The constructor will
naturally attempt to look up the info from the database, thus leading
to the problem of the database not existing yet.
I have no idea if this is correct and what the solution might be.
On Nov 28, 2008, at 5:11 AM, Colin wrote:
> First off, this issue comes to light long before Postgres comes into
> play and thanks to my dear friend DTrace, I think I've managed to
> workout where the problem is, however I'm not sure how it should be
> resolved. I've also included habari-dev for visibility (just in
> case there are devs who aren't on the user list) and further
> discussion.
>
> First, I set off a simple dtrace script as follows:
>
> # dtrace -x bufsize=300m -n function-entry'{printf("called %s() in
> %s at line %d\n", \
> copyinstr(arg0), copyinstr(arg1), arg2)}' -q -o file.out
>
> The output is a bit confusing and not quite 100% accurate in some
> places, eg the "line 88" lines, but it does provide enough
> information to trace the function call ordering.
>
> I then searched for the first instance of db.php in the resulting
> output file and back tracked a couple of steps and this is what we
> see (output and paths truncated for brevity):
>
> ---
> [...]
> called main() in /.../hb/system/classes/user.php at line 88
> called class_exists() in /.../hb/index.php at line 90
> called method_exists() in /.../hb/index.php at line 90
> called identify() in /.../hb/system/classes/user.php at line 106
> called __construct() in /.../hb/system/classes/user.php at line 89
> called default_fields() in /.../hb/system/classes/user.php at line 57
> called array_merge() in /.../hb/system/classes/user.php at line 58
> called __construct() in /.../hb/system/classes/queryrecord.php at
> line 59
> called get_params() in /.../hb/system/classes/utils.php at line 28
> called is_array() in /.../hb/system/classes/utils.php at line 29
> called array_merge() in /.../hb/system/classes/queryrecord.php at
> line 29
> called exclude_fields() in /.../hb/system/classes/queryrecord.php at
> line 60
> called is_array() in /.../hb/system/classes/queryrecord.php at line 85
> called __autoload() in /.../hb/index.php at line 61
> called strtolower() in /.../hb/index.php at line 55
> called main() in /.../hb/system/classes/userinfo.php at line 88
> called class_exists() in /.../hb/index.php at line 90
> called method_exists() in /.../hb/index.php at line 90
> called __construct() in /.../hb/system/classes/userinfo.php at line 61
> called __autoload() in /.../hb/index.php at line 11
> called strtolower() in /.../hb/index.php at line 55
> called main() in /.../hb/system/classes/db.php at line 88
> called __autoload() in /.../hb/index.php at line 9
> called strtolower() in /.../hb/index.php at line 55
> called main() in /.../hb/system/classes/singleton.php at line 88
> called class_exists() in /.../hb/index.php at line 90
> called method_exists() in /.../hb/index.php at line 90
> called class_exists() in /.../hb/index.php at line 90
> called method_exists() in /.../hb/index.php at line 90
> called table() in /.../hb/system/classes/db.php at line 11
> called instance() in /.../hb/system/classes/db.php at line 81
> [...]
> ---
>
> In the output we can see our call to table() (2nd last line), but
> it's the further up in this output that it gets interesting. The
> constructor for userinfo.php seems to have initiated the autoloading
> of db.php. Why?
>
> Well, the constructor in userinfo.php calls DB::table():
>
> ---
> class UserInfo extends InfoRecords
> {
> function __construct ( $user_id )
> {
> // call parent with appropriate parameters
> parent::__construct ( DB::table('userinfo'),
> 'user_id', $user_id );
> }
> }
> ---
>
> This is happening before any instance of DB has been instantiated,
> which makes sense as we're only running the installer code and
> haven't even reached the point of selecting a database, so won't
> have setup a DB connection yet.
>
> Commenting out the line (and reversing the previous suggested
> change) allows the installer to continue and work as expected,
> however it's not a usable solution as you then get PDO errors when
> logging in.
>
> So I followed back through trying to workout why we're trying to
> call userinfo anyway, and found that the user.php constructor is
> responsible for this:
>
> ---
> public function __construct( $paramarray = array() )
> {
> // Defaults
> $this->fields = array_merge(
> self::default_fields(),
> $this->fields );
> parent::__construct($paramarray);
> $this->exclude_fields('id');
> $this->info = new UserInfo ( $this->fields['id'] );
> <<<------ HERE
> /* $this->fields['id'] could be null in case of a new user.
> If so, the info object is _not_ safe to use till after set_key has
> been called. Info records can be set immediately in any other case. */
> }
> ---
>
> What is interesting is the comment immediately below it. Putting in
> a simple check for null allows the installer to continue and
> display, however it doesn't seem to work correctly when you click
> submit as you then get a "Call to a member function set_key() on a
> non-object in /.../hb/system/classes/user.php on line 122" error,
> which isn't surprising as it's expecting $this->info to already
> exist. A screen refresh seems to then get things working as expected.
>
> So, should this be fixed:
>
> a) in user.php where an instance of UserInfo is being created in
> the constructor by moving the creation elsewhere in the class?
> b) in userinfo.php where the actual DB::table() call is taking
> place by adding a check for a DB instance?
> c) in db.php where the table method is being defined by having it
> check for a DB instance?
> d) else where?
>
> What does everyone else think?
>
> I'm pretty confident this is a bug, so have raised ticket #779 with
> the general contents of this email.
>
> Cheers,
> Colin
>
>
>
> On Fri, Nov 28, 2008 at 2:23 AM, Chris Meller
> <[EMAIL PROTECTED]> wrote:
> For the record, Postgres requires version 8.3 to run currently, and
> no one has fixed the Postgres schema since all the ACL and timezone
> changes were made.
>
>
> On Thu, Nov 27, 2008 at 1:49 PM, D'alessandro <[EMAIL PROTECTED]>
> wrote:
>
> Well i am up and running. Thanks again to everybody that chipped in.
> And thanks Colin for that line of code.
> Will try everything out and report if there are any issues.
>
> Cheers,
> D
>
> On Nov 27, 11:31 am, "D'alessandro" <[EMAIL PROTECTED]> wrote:
> > Colin,
> >
> > thanks a lot for the tip. I will try it out and let you know what
> > happens on my end.
> > Hope this can be ironed out since i got another friend with the same
> > problem on a different hosting company...
> >
> > Cheers,
> > D
> >
> > On Nov 27, 11:15 am, Colin <[EMAIL PROTECTED]> wrote:
> >
> > > Well, initial testing seems to indicate something appears to be
> calling
> > > "DB::table()" before the "DB::instance()->connection" object has
> been
> > > created, though I've not been able to identify what yet.
> >
> > > Changing the table() function in db.php to the following:
> >
> > > ---
> > > public static function table( $name )
> > > {
> > > if ( NULL == DB::instance()->connection ) {
> > > return TRUE;
> > > }
> > > return DB::instance()->connection->table( $name );
> > > }
> > > ---
> >
> > > ... seems to allow things to continue and work, however I've not
> tested much
> > > more than attempting to insert a couple of posts and comments.
> >
> > > Maybe someone with a bit more knowledge of this part of the code
> could
> > > comment.
> >
> > > I'll keep looking into this tomorrow.
> >
> > > HTH,
> > > Colin
> >
> > > On Thu, Nov 27, 2008 at 3:47 PM, Colin <[EMAIL PROTECTED]> wrote:
> > > > Oh yes, my testing is on a standalone Solaris system that is
> already
> > > > running an instance of Habari that was installed quite some
> time ago, not
> > > > the MT server.
> >
> > > > Will let you know how I get on.
> >
> > > > On Thu, Nov 27, 2008 at 3:10 PM, Colin <[EMAIL PROTECTED]>
> wrote:
> >
> > > >> I've just attempted a new install of Habari using the latest
> SVN code and
> > > >> I've encountered the same issue.
> >
> > > >> I'll do some digging and see what I come up with.
> >
> > > >> On Thu, Nov 27, 2008 at 2:23 AM, Matt Read
> <[EMAIL PROTECTED]> wrote:
> >
> > > >>> Try getting the latest version from SVN. the installer was
> broken a
> > > >>> couple of revisions ago.
> >
> > > >>> On Wed, Nov 26, 2008 at 8:35 PM, D'alessandro
> <[EMAIL PROTECTED]>
> > > >>> wrote:
> >
> > > >>> > On Nov 26, 6:29 pm, "Michael Harris"
> <[EMAIL PROTECTED]>
> > > >>> > wrote:
> > > >>> >> 2008/11/27 D'alessandro <[EMAIL PROTECTED]>:
> >
> > > >>> >> > On Nov 26, 6:02 pm, "Michael Harris" wrote:
> >
> > > >>> >> >> Habari doesn't show SQLite as an option ? Odd. Sure,
> try with
> > > >>> MySQL.
> >
> > > >>> >> > Well the thing is i do not even get to the installer
> screen... i get
> > > >>> >> > that error i mentioned in my first post.
> >
> > > >>> >> My mistake, I thought this was after you were trying to
> install.
> >
> > > >>> > No worries, i got carried away too.
> >
> > > >>> >> > I did setup a postgreSQL and a MySQL on my server but
> like i said i
> > > >>> >> > can't even get to the installer screen for habari when
> i go to my
> > > >>> >> > install place. So i can't do anything... alredy tried
> to to the
> > > >>> >> > checkout again and i get the same thing.
> >
> > > >>> >> If you don't even get to the installer, Habari doesn't
> know anything
> > > >>> >> about your databases. I'm stumped for the moment, I'm
> afraid.
> >
> > > >>> > Yeah i have seen the installer screen and i know that you
> pick your db
> > > >>> > etc there, so yeah i guess the db type at the moment is
> not the issue.
> >
> > > >>> >> Is this a completely fresh install ? Do you have a
> config.php file
> > > >>> already ?
> >
> > > >>> > Completely fresh. No config file.
> >
> > > >>> > --
> > > >>> > D
> >
> > > >>> --
> > > >>> Matt Read
> > > >>>http://mattread.com
> >
> > > >> --
> > > >> Colin Seymour
> > > >> Blog:http://www.colinseymour.co.uk
> > > >> Tech Stuff:http://www.lildude.co.uk
> >
> > > > --
> > > > Colin Seymour
> > > > Blog:http://www.colinseymour.co.uk
> > > > Tech Stuff:http://www.lildude.co.uk
> >
> > > --
> > > Colin Seymour
> > > Blog:http://www.colinseymour.co.uk
> > > Tech Stuff:http://www.lildude.co.uk
>
>
>
>
> --
>
> Woody Allen - "I will not eat oysters. I want my food dead. Not
> sick. Not wounded. Dead."
>
>
>
>
> --
> Colin Seymour
> Blog: http://www.colinseymour.co.uk
> Tech Stuff: http://www.lildude.co.uk
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/habari-users
-~----------~----~----~----~------~----~------~--~---
