• I include WordPress code for a php routine in a table on my home page (which is outside of WordPress) to display the 6 latest post titles. When the database server is down, WordPress includes a complete web page, with header and footer. The header is noted as another error, since the home page has already established it, but the real problem is that the footer ends the home page, messing up the layout.

    I’m new to php, and there doesn’t appear to be a simple “onerror” control structure to put around the code. How can I (simply) control the display when the database server is down?

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter ericr23

    (@ericr23)

    I’d still like a simple php error handler (because alongside the WordPress post titles is a sampling of photos from Coppermine), but meanwhile, how does this inelegant hack sound?

    In wp-db.php, I removed everything from the bail($message) function except echo $message; and die();. That should keep it from messing up the page it’s embedded in.

    (I also changed the error message in the wpdb() function to something more relevant to the public, including a note to try again shortly and a mail link to the webmaster if the problem persists.)

    I altered the wp-config (on a not-yet public database) to test it, and it appears to work.

    Well, that sounds pretty good to me! May try that myself, y’know?

    Thread Starter ericr23

    (@ericr23)

    My efforts continued, following many examples from the web, since I still have those pictures from the Coppermine database. But all my efforts were never able to capture the errors. Then I noticed that the PHP manual says, “The following error types cannot be handled with a user-defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.” So that’s why WordPress checks the database in a way that doesn’t raise a PHP error and it can display its own error page.

    Because both the Coppermine and the WordPress databases are likely to be down at the same time, I’ll rearrange the home page so that WordPress is called first (Coppermine lacking the database access check that WordPress does).

    Thread Starter ericr23

    (@ericr23)

    Well, I thought (slow on the uptake), why not do what wpdb.php is doing — just test the database connections?! I’m working that out now, using mysql functions. If anyone can save me some time, I sure would appreciate it.

    Thread Starter ericr23

    (@ericr23)

    I’ve come up with this, which seems to work:

    <?php
    error_reporting(0);
    if (! mysql_connect('db1host', 'db1user', 'db1pass') || ! mysql_connect('db2host', 'db2user', 'db1pass'))
    {
    echo ("blah blah blah");
    include_once('nwwfooter.inc');
    echo ("</body></html>");
    die();
    }
    error_reporting(E_ALL ^ E_NOTICE); //default restored
    ?>

    I put it in a separate file called from the index page (<?php include_once(‘thefile.php’); ?>).

    Try this in regards to the error level:

    <?php
    $olderrorlevel = error_reporting(0);
    if (! mysql_connect('db1host', 'db1user', 'db1pass') || ! mysql_connect('db2host', 'db2user', 'db1pass'))
    {
    echo ("blah blah blah");
    include_once('nwwfooter.inc');
    echo ("</body></html>");
    die();
    }
    error_reporting($olderrorlevel); //default restored
    ?>

    Thread Starter ericr23

    (@ericr23)

    That looks like a good suggestion, but I must be missing something about it. It appears to set the $olderrorlevel variable to the new error_reporting() level (0, to turn it off), not to the pre-existing level.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Error handler for WordPress include on home page?’ is closed to new replies.