Menu

#702 BVlank page when invoking a new MRBS installation

open
nobody
None
1
2020-12-03
2015-03-11
Ken Winter
No

I've made it through the MRBS installation process (http://mrbs.sourceforge.net/view_text.php?section=Documentation&file=INSTALL), but when I invoke MRBS, what comes up is a blank page. That is, the source HTML is nothing but:

<html>
<head></head>
<body></body>
</html>

I'm not sure what else to tell you that might help, but here are some possible clues:

  1. My database tables (PG) were created, but they all are all still empty. I don't know if this could cause the blank page. (I tried to run sample-data.sql, but got "Error: null value in column 'sort_key' violates not-null constraint".)
  2. The most recent entries in the file "access_mrbs.log" on my server are:
    107.5.46.133 - - [11/Mar/2015:19:53:48 +0000] "GET / HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0"
    107.5.46.133 - - [11/Mar/2015:20:16:06 +0000] "GET / HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0"
  3. In a response to a recent ticket here, you advise the user to " Have a look at your PHP error log". I don't know where my "PHP error log" is.

If I can give you any more info to solve this, RSVP.

~ Thanks in advance
~ Ken

Related

Support Requests: #702

Discussion

<< < 1 2 (Page 2 of 2)
  • Anonymous

    Anonymous - 2015-03-13

    As i mentioned earlier, the tables are all empty. Trying to run the sample data script, I hit an error (see details earlier in this thread).

     
  • Campbell Morrison

    Can you do two things:

    (1) Empty all your tables except mrbs_variables. There are some problems with the sample data, so this will clean things up.
    (2) Add the line

        debug_print_backtrace();
    

    just after line 438 in pgsql.inc, so the code should now look like this:

      $res = sql_pgsql_query1($sql, $db_conn);
      if ($res < 1)
      {
        trigger_error(pg_result_error($res), E_USER_WARNING);
        debug_print_backtrace();
        fatal_error(TRUE, get_vocab("fatal_db_error"));
      }
    
     
  • Campbell Morrison

    Actually could you make that code:

      $res = sql_pgsql_query1($sql, $db_conn);
      if ($res < 1)
      {
        trigger_error(pg_last_error($db_conn), E_USER_WARNING);
        debug_print_backtrace();
        fatal_error(TRUE, get_vocab("fatal_db_error"));
      }
    

    I've just realised that there's a bug in the error handling code. The code above should at least give us a clue as to what is happening

     
  • Ken Winter

    Ken Winter - 2015-03-13

    I commented out the existing code and added the new, so that passage looks like:

    // $res = sql_pgsql_query1($sql, $db_conn);
    // if ($res < 1)
    // {
    // trigger_error(pg_result_error($res), E_USER_WARNING);
    // fatal_error(TRUE, get_vocab("fatal_db_error"));
    // }
    $res = sql_pgsql_query1($sql, $db_conn);
    if ($res < 1)
    {
    trigger_error(pg_last_error($db_conn), E_USER_WARNING);
    debug_print_backtrace();
    fatal_error(TRUE, get_vocab("fatal_db_error"));
    }

    And this evoked a bit more information:

    Warning: in /home/sunward/webapps/mrbs/pgsql.inc on line 444

    0 sql_pgsql_table_exists(mrbs_variables, ) called at [/home/sunward/webapps/mrbs/dbsys.inc:668] #1 sql_table_exists(mrbs_variables) called at [/home/sunward/webapps/mrbs/dbsys.inc:791] #2 require_once(/home/sunward/webapps/mrbs/dbsys.inc) called at [/home/sunward/webapps/mrbs/defaultincludes.inc:18] #3 require(/home/sunward/webapps/mrbs/defaultincludes.inc) called at [/home/sunward/webapps/mrbs/index.php:10]

    Fatal error: Call to undefined function getUserName() in /home/sunward/webapps/mrbs/Themes/default/header.inc on line 22

     
    • Anonymous

      Anonymous - 2015-03-13

      There was a "#" before that "0" in the error message. Apparently this forum took it to be a formatting character :p

       
  • Campbell Morrison

    Thanks. The only thing I can think of is that for some reason the query used to determine if a table exists is returning false even when the table does exist. The query is

      $sql = "SELECT COUNT(*)
                FROM information_schema.tables
               WHERE table_name ='" . sql_pgsql_escape($table_parts['table_name']) . "'";
      if (isset($table_parts['table_schema']))
      {
        $sql .= " AND table_schema = '" . sql_pgsql_escape($table_parts['table_schema']) . "'";
      }
    

    When you use your PG tool, does mrbs_variables show up in information_schema.tables?

     
  • Campbell Morrison

    If you want to get going with MRBS then my guess is that you could do so just by putting

      return TRUE;
    

    at line 421 in pgsql.inc so the code looks like this

    // Check if a table exists
    function sql_pgsql_table_exists($table, $db_conn = null)
    {
      return TRUE;
      sql_pgsql_ensure_handle($db_conn);
    

    That should work because we know your table exists. However it doesn't solve the root cause. I might think over the next few days about some test programs for you to try in order to understand why the code is failing.

     
  • Ken Winter

    Ken Winter - 2015-03-14

    That got me going, sort of.

    See attached for screen prints of the screens I saw. On screen 2, when I click "return to calendar view", I get screen 1 again.

    I'll be traveling tomorrow (Saturday), and less frequently online for the following week. So it's a good time for you to think things over. I'm still enthusiastic about MRBS, so glad to hang in for this debug process.

     
  • Campbell Morrison

    Does your database user have rights to access the database? In other words have you granted that user the appropriate privileges?

     
  • Ken Winter

    Ken Winter - 2015-03-14

    Eureka! That was it. I ran the script to create the tables before I created the 'mrbs' user, and made mrbs the owner of the database. I forgot that that didn't retroactively make mrbs the owner of the tables.

    Anyway, as you can see from the URL I gave you, it's now up and running, and you can close this ticket.

    Thanks for your patience and persistence in this.

    ~ Ken

     
  • Campbell Morrison

    Excellent. Don't forget to remove all the debugging changes.

    I'll see if I can make the code handle this error case a bit more helpfully.

     
  • Campbell Morrison

    I've now improved the error handling in the trunk in Rev 3013.

     
<< < 1 2 (Page 2 of 2)