Gossamer Forum
Home : Products : Gossamer Links : PHP Front End :

problems after moving to new host

Quote Reply
problems after moving to new host
I realize the PHP front end is no longer being supported (a true shame), but hopefully these errors and warnings ring a bell for someone. I couldn't find anything relevant in old posts.

After transferring the site to a new host, most stuff appears to be functioning correctly. One problem is this error log warning every time a page is loaded:

Only variable references should be returned by reference in /.../cgi-bin/links/admin/Links/PHP/adodb/drivers/adodb-mysql.inc.php on line 423

The bigger problem I discovered is the Jump links don't work.

PHP Fatal error: Call to a member function fetchrow_one() on a non-object in /.../cgi-bin/links/admin/Links/PHP/Jump.inc.php on line 120

Any ideas?

I'd much prefer salvaging the old install rather than upgrade to the new one, if at all possible. Integrating a CGI script into a PHP site and templates is never fun.

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
Hi,

Mmm.. it *almost* sounds like an issue with the DB connection - but seems weird that it would work for most of the other stuff, but not the Jump etc

I havn't used the PHP file for ages. From memory, I think there was a new "connection" system in the PHP scripts .... Maybe try doing a "grep" in SSH for your OLD DB details, and see if any other files come up with it?

Cheers

Andy (mod)
andy@ultranerds.co.uk
Want to give me something back for my help? Please see my Amazon Wish List
GLinks ULTRA Package | GLinks ULTRA Package PRO
Links SQL Plugins | Website Design and SEO | UltraNerds | ULTRAGLobals Plugin | Pre-Made Template Sets | FREE GLinks Plugins!
Quote Reply
Re: [Andy] problems after moving to new host In reply to
Andy wrote:
Maybe try doing a "grep" in SSH for your OLD DB details, and see if any other files come up with it?
Could you be more specific? I don't quite know what that means to do or what I would be looking for.

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
Hi,

Are you on a UNIX server?

If so, login via SSH/Telnet, and run:

Code:
grep -r -l 'old_db_name' .

(the . at the end is important :))

Then see if it comes up with any files (depending how large your site is, it may take a while to run this command)

Cheers

Andy (mod)
andy@ultranerds.co.uk
Want to give me something back for my help? Please see my Amazon Wish List
GLinks ULTRA Package | GLinks ULTRA Package PRO
Links SQL Plugins | Website Design and SEO | UltraNerds | ULTRAGLobals Plugin | Pre-Made Template Sets | FREE GLinks Plugins!
Quote Reply
Re: [Andy] problems after moving to new host In reply to
Gotcha, thanks. Probably easier to use EditPlus to check the files locally... Sure enough, there are a few that didn't get updated! I'll probably have to reinstall after an attempted v3.3 upgrade to that folder, so it'll be a bit before I know if that was the full problem...

Is there a publicly available reason why development was abandoned on the PHP front end? It seemed like a very popular option at the time, but people must have lost interest somewhere along the line, either developers or users.

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
Hi,

Ok cool :)

Re why the PHP was removed - not sure there is a major reason - but found this:

http://www.gossamer-threads.com/.../?page=unread#unread

Quote:
The PHP front-end is no longer supported due to miniscule usage by client base.

To be honest, most stuff you wanna do with PHP can be done just as easily using globals + mod_rewrite .... I posted quite a few threads about how this can be done - for example:

Code:
sub {
return system("php /path/to/run/script.pm");
}

...and this retuns the content of what that script outputted

I never really got on with the PHP system - was too "different" to the Perl version - and also had quite a few limits, such as plugins not be usable, globals not working, etc .... which is why I never really got into it at all =)

Cheers

Andy (mod)
andy@ultranerds.co.uk
Want to give me something back for my help? Please see my Amazon Wish List
GLinks ULTRA Package | GLinks ULTRA Package PRO
Links SQL Plugins | Website Design and SEO | UltraNerds | ULTRAGLobals Plugin | Pre-Made Template Sets | FREE GLinks Plugins!
Quote Reply
Re: [Andy] problems after moving to new host In reply to
Well, no luck with the reinstall. Same error and warnings as before. Frown It seems to be specific to the PHP files. I'm not getting errors with the CGI scripts, such as accessing jump.cgi directly. As far as I can tell, the problem is with the PHP code. Perhaps something deprecated in newer versions like the login problem I had earlier this year?

From the linked release announcement:

Quote:
The PHP front-end is no longer supported due to miniscule usage by client base.
Weird. Any idea what that assumption was based on? I know I was never surveyed... In looking for solutions to these host migration problems, I've seen lots of comments on various forums about abandoning Links because of the discontinued PHP front end support, with the majority of dynamic sites being PHP-driven and not using Perl anymore. I'm hoping I don't have to resort to that, but it's a very real possibility.

Resorting to mod_rewrite might work but isn't available to everyone and generally comes with a heavy word of caution...

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
Since it's an error with ADOdb, one thing you might try is to upgrade ADOdb:

http://adodb.sourceforge.net/

Adrian
Quote Reply
Re: [brewt] problems after moving to new host In reply to
Quote:
Since it's an error with ADOdb, one thing you might try is to upgrade ADOdb:
Thanks, that seems worth a try. Getting rid of all those error log warnings would be nice!

Only problem is, that broke everything. Smile Blank category listings and error pages, with the logs filled up with stuff like:

PHP Notice: Undefined index: ID in /.../cgi-bin/links/admin/Links/PHP/Utils.inc.php on line 164
PHP Notice: Undefined index: Name in /.../cgi-bin/links/admin/Links/PHP/Utils.inc.php on line 166

Is there anything that needs to be done to tie in an upgraded ADOdb? I ran one of the recommended test scripts and ADOdb itself is working.

As for the fetchrow_one() fatal error in Jump.inc.php, I found the same thing happens when rating a link:

PHP Fatal error: Call to a member function fetchrow_one() on a non-object in /.../cgi-bin/links/admin/Links/PHP/Rate.inc.php on line 82

I haven't seen that happen with any of the other fetch* functions, so it appears to be specific to the fetchrow_one() behavior. I tried tweaking a few things with $this->$row type assignments but had no luck...

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
I believe there is one thing that you do need to do to get ADOdb working. There's a patch in the admin/Links/PHP/adodb directory adodb.inc.php.patch, though I doubt it patches cleanly. The patch just turns off forcing upper/lower case of the column names.

Note that the adodb that LinksSQL came with was 2.40 released in Sept 2002! It's now at 5.11, so I'm not sure if they kept compatibility all that time. You might need to read through the changelogs:

http://phplens.com/adodb/change.log.html
http://phplens.com/adodb/old-changelog.htm

For the fatal errors, I think you need to figure out why the $DB object isn't set. fetchrow_one() is defined in SQL.inc.php and is essentially the same thing as a fetchrow().

Adrian
Quote Reply
Re: [brewt] problems after moving to new host In reply to
Quote:
There's a patch in the admin/Links/PHP/adodb directory adodb.inc.php.patch
I don't see any such file in the old or new versions of adodb... Are you sure it's in there by default?

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
I solved the fatal error in Jump.inc.php and Rate.inc.php! In both cases, $sth was returning false and needed an if() check in order to successfully execute fetchrow_one(), i.e.:

Code:
if ($sth) {
$rows = $sth->fetchrow_one();
}

I'm not sure if that's a PHP or MySQL difference resulting in the false return value...

I'll have to do more interface testing to see if the problem exists in any of these other files that contain fetchrow_one():

Add.inc.php, Authenticate.inc.php, Modify.inc.php, Page.inc.php, Review.inc.php, Search.inc.php, Subscribe.inc.php, Utils.inc.php, User.inc.php

That's a major issue checked off the list! Now if I can just figure out the adodb piece and clean up all those error log warnings...

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
Hmm, I may have come up with a simple solution to the adodb warnings ... just copy the v5 function from adodb-mysql.inc.php over to the v2 function of the same name! There's a couple other spots that produce the same warnings (just in lesser numbers), so I'll have to go through and try swapping out more functions. If you have any further suggestions for tying in the v5 adodb altogether, I'm all ears.

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
It's a simple patch:

Code:
--- adodb.inc.php.old Mon Sep 9 00:45:06 2002
+++ adodb.inc.php Mon Sep 9 00:45:28 2002
@@ -2118,7 +2118,7 @@
$this->bind = array();
for ($i=0; $i < $this->_numOfFields; $i++) {
$o = $this->FetchField($i);
- $this->bind[($upper) ? strtoupper($o->name) : strtolower($o->name)] = $i;
+ $this->bind[($upper) ? strtoupper($o->name) : $o->name] = $i;
}
}

Adrian
Quote Reply
Re: [brewt] problems after moving to new host In reply to
How would that get tied in? Does it get added to one of the files or placed in a new adodb.inc.php.patch file? If the latter, does adodb automatically know to load it if present?

Dan
Quote Reply
Re: [Dan Kaplan] problems after moving to new host In reply to
That patches the adodb.inc.php file in the adodb directory.

Adrian
Quote Reply
Re: [brewt] problems after moving to new host In reply to
Thanks, it seems like that might have done the trick.

Still a hiccup here and there to iron out, but it appears that Links SQL 2.1 has been salvaged and will survive the move intact!

Dan