This should be fixed now, so if you were having problems, update to at
least r2905 to see if the problem still exists for you. As arthus
said, and lildude's trace shows, the problem related to the attempted
creation of an anonymous user.
Rick
On Nov 28, 12:29 pm, Arthus Erea <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
