This should be fixed in r2905. The installer uses Theme::display() to
show it's templates, but the default Theme::display() tries to create
an anonymous user if no on is logged in, an impossibility during
installation. The fix overrides Theme::add_template_vars() to not try
to create a User object. Good work tracking down the source of the
error, lildude. Thank you.
Rick
On Nov 28, 6:11 am, Colin <[EMAIL PROTECTED]> 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-dev
-~----------~----~----~----~------~----~------~--~---
