SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Evangelist ikeo's Avatar
    Join Date
    Oct 2004
    Location
    Austin Texas
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Broken PEAR Install? ... need your opinions

    I have a client who set up an email form using the PEAR::DB http://pear.php.net/package/DB class. They were hosted on a virtual dedicated server and PEAR was already set up on their host.

    A couple of days ago the form stopped working .... it was failing to recognize functions that were available in the DB class and saying DB:setfetchMode() was not a defined function. The programmer responsible for setting up the form says that he uninstalled and reinstalled the php-pear classes and that fixed the problem.

    What I want to understand is why something like this would happen. No updates where made to any files on the server via FTP or SSH. My thinking was that the pear install (/usr/share/pear) is accessible by all the users on the server and that one of them unwittingly altered something that caused the problem for us, but the host (godaddy) says the pear install is only accessible by them (I wasn't entirely convinced of this). Any ideas why something like this would happen?

  2. #2
    SitePoint Member
    Join Date
    Jul 2004
    Location
    Budapest, Hungary
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My guess is that they have changed the include_path so that some other directory containing another DB.php preceded the PEAR path. This results in an include that goes fine because the file is found, but it won't find DB::setFetchMode since it has included another file.

    As a quick tip, I prefer installing PEAR locally inside my project dirs, which means that they are uploaded by me to any kind of (dedicated/shared) server environment. Then I always ini_set the include_path to ".:/home/myproject/external/pear" or whatever in my common includes.php file, which avoids this problem entirely.

    Additionally, because I install PEAR seperately inside the project dirs instead of doing a simple copy, I can upgrade PEAR installations seperately using the PEAR installer, which is very convenient. This saves time and stress that would come with the upgrades since I don't need to be afraid that something gets broken in another project when I run the upgrade or the hosting providers installation is upgraded.

    I have written about this in my blog: Updating PEAR Packages Within Your Applications
    This is a cross-platform solution of course.

  3. #3
    SitePoint Member
    Join Date
    Jul 2004
    Location
    Budapest, Hungary
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One more thing that comes to mind is that you didn't check the return value where you instantiated the DB object.

    PHP Code:
    $db =& DB::connect(.. dunno how this works ..);
    if (
    DB::isError($db)) { // or PEAR::isError
        
    die($db->getMessage());

    It is possible that the MySQL server was down or for some other reason it couldn't connect and returned a DB_Error object. Of course a DB_Error object doesn't have a setFetchMode() method.

  4. #4
    SitePoint Evangelist ikeo's Avatar
    Join Date
    Oct 2004
    Location
    Austin Texas
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the response norbert ..
    I have another question ...
    The client is hosted on a virtual dedicated server and I was wondering if other hosts on the server would be able to access and modify the shared PEAR installation which is at /usr/share/pear on this server?
    I've been told that this should not be the case but is it possible?

  5. #5
    SitePoint Member
    Join Date
    Jul 2004
    Location
    Budapest, Hungary
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sadly I have no idea about it. My guess is that the PEAR installer creates the files with proper permissions so that other users cannot modify them. I remember having a hard time always switching to root before updating the packages because the default permissions doesn't allow me to do that with my account.

    The sysadmin however can change any permissions anytime.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •