I've done more debugging and research. I'm still getting a blank screen but I've made progress. I have found that my code is now hanging in common.php at "session_start();", just following the call to "session_set_save_handler(...)". I've read in the "user contributed notes" for session_start() at http://us2.php.net/manual/en/function.session-start.php#61347 that "the session_start() function needs a directory to write to". I don't understand how this works. Can someone please explain how this would apply to a XOOPS installation? Thanks! --SG

These were excellent suggestions but they didn't help. I cleared out the cache and templates_c directories but that didn't help. The path specified in mainfile.php is correct as it was generated from a clean install of XOOPS prior to me copying over the database from my old server and (I think - not sure) copying over the files. If I copied over the files I had enough sense to overwrite the mainfile.php with the clean-install version as the paths are correct for the new server. I know this is true because the clean install of XOOPS worked fine - it wasn't until I copied over the database/files that the bottom line of the following portion of mainfile.php stopped working:



if ( !defined("XOOPS_MAINFILE_INCLUDED") ) {
define("XOOPS_MAINFILE_INCLUDED",1);
echo ("mainfile.php-1 ");
// XOOPS Physical Path
// Physical path to your main XOOPS directory WITHOUT trailing slash
// Example: define('XOOPS_ROOT_PATH', '/home/u2/xxxxx/html');
define('XOOPS_ROOT_PATH', '/home/u2/xxxxx/html');

// XOOPS Virtual Path (URL)
// Virtual path to your main XOOPS directory WITHOUT trailing slash
// Example: define('XOOPS_URL', 'http://xxxxx.web.cedant.com');
define('XOOPS_URL', 'http://xxxxx.web.cedant.com');
echo ("mainfile.php-2 ");
define('XOOPS_CHECK_PATH', 0);
die ("2");
// Protect against external scripts execution if safe mode is not enabled
if ( XOOPS_CHECK_PATH && !ini_get('safe_mode') ) {
echo ("mainfile.php-3 ");
die ("3");



I know the problem is in the bottom line because if I take out the die ("2") debugging statement I no longer see the debugging messages. If I leave it in the see debugging messages up to and including the die ("2").

As you can see I even took out the @ in front of the ini_get in the hopes that I would get an error message but all I get is the blank screen.

Does anyone have any suggestions?

Thanks!

SuperGeek

In order to add more disk space to my web hosting account my host (CEDANT.COM) forced me to move to a different server. This is a gigantic pain as you can imagine. I first installed a clean version of XOOPS 2.0.13.2 and all was fine. Then I brought over all my files and the database and I got the dreaded "blank screen of death". After several hours of debugging I determined that the problem is that mainfile.php dies at the following line:

if ( XOOPS_CHECK_PATH && !@ini_get('safe_mode') ) {

Can anyone provide some explanation as to why this particular piece of code might cause a problem?

I cannot get any sort of debugging or anything else to work. I know that it "dies" at that point because I put debugging messages throughout mainfile.php, so I am certain that the line I included is the problem.

Please help!

Thanks!

SuperGeek

I've been working on this FOR DAYS with no luck and I'm not happy with the results, so I'm asking for help.

I'm attempting to use $xoopsDB (as provided in class\database\mysqldatabase.php - the typical database class XOOPS uses to access mySQL) to insert a row into a table I created named XOOPS_registration, and if a duplicate would be the result of the insert report an error that I can trap so I can update the existing row of data with any changes.

When you look at the code I added to include/functions.php (see below), you'll see that I populate the variable $sql with the SQL statement used to attempt to insert data into XOOPS_registration. Pretty standard stuff. What I expect to happen when I use $result = $xoopsDB->query($sql); is for $result to contain FALSE (because the SQL failed due to the duplicate key) and $xoopsDB->error() to display "Duplicate entry 'duplicate@x.com' for key 2" and $xoopsDB->errno() to display 1062. I get those results using $result = mysql_query($sql); but not when I use $result = $xoopsDB->query($sql); When I use $result = $xoopsDB->query($sql); I get blank for $xoopsDB->error() and 0 for $xoopsDB->errno().

Using queryF (as in $xoopsDB->queryF($sql);) changes nothing.

phpMyAdmin reports: MySQL 4.0.24-log running on localhost as kcoug@localhost
phpinfo() reports:
PHP Version: 4.3.11
SERVER["SERVER_SOFTWARE"]: Apache/1.3.33 (Unix) mod_fastcgi/2.4.2 FrontPage/5.0.2.2635 mod_jk/1.2.5

Here is how my function is called in modules/reg/reg4.php:
insert_or_update_registration($_POST);

The data in $_POST comes from my form in modules/reg/reg3.php, which is set up as follows:
echo "

";

Here is the code I've added to include/functions.php:

function insert_or_update_registration($data) {
    global $xoopsDB, $xoopsConfig, $xoopsLogger;
    $sql = sprintf("INSERT INTO %s (evt_code, eMail, fName, ...similar... ) 
                        VALUES (%s, %s, %s, ...similar...)", 
        $xoopsDB->prefix("registration"),
        $xoopsDB->quoteString($data['evt_code']),
        $xoopsDB->quoteString($data['eMail']),
        $xoopsDB->quoteString($data['fName']),
        ...similar...);
echo "";
echo "RESULTS:";
$result = $xoopsDB->query($sql); //Yes, I've tried queryF($sql) here - doesn't help
//$result = mysql_query($sql);   //<- Results in duplicate key error-but doesn't use $xoopsDB :(
if ($result) { // With xoopsDB, I do NOT see the following:
    echo "INSERT succeeded";
    echo "mysql_affected_rows=".mysql_affected_rows();
}
else { // With xoopsDB, I DO see the following:
    echo "INSERT failed";
    echo "mysql_affected_rows=".mysql_affected_rows();  
                  // With xoopsDB, mysql_affected_rows() shows "1"
}
echo "";
echo "xoopsDB->error:";
echo $xoopsDB->error();  // with xoopsDB, nothing shown here.  
                         // With mysql_query, I see "Duplicate entry 'duplicate@x.com' for key 2"
                         // as expected.
echo "";
echo "xoopsDB->errno:";
echo $xoopsDB->errno();  // with xoopsDB, shows "0".  
                         // With mysql_query, I see "1062", as expected.
echo "";

//    return $xoopsDB->query($sql); // Instead of most of the above, 
                                  // I just want to do this, but it doesn't work!
}

What I need to be able to do is when the duplicate key is detected ($xoopsDB->errno()=1062), I want to do an update to the existing registration data. But since I can't even get the duplicate key to be detected when using $xoopsDB I haven't coded the update part yet.

What I've found works is modified include/common.php, per https://xoops.org/modules/newbb/viewtopic.php?topic_id=15804&forum=3&post_id=66234#forumpost66234

//    if (!defined('XOOPS_XMLRPC')) {
//        define('XOOPS_DB_CHKREF', 1);
//    } else {
        define('XOOPS_DB_CHKREF', 0);
//    }

This solves my problem. Great! But now my system is open to the Cross-Site Scripting attacks. So it appears that I can either issue an insert/update to the database, or I can have a secure website, but not both.

For now I'll use the "force XOOPS_DB_CHKREF to zero" workaround. If that proves to be too much of a security risk I can switch to using mysql_query($sql) instead of $xoopsDB->query($sql) but I don't like it. It's bad style to jump between using $xoopsDB and the standard PHP mySQL interface. I might as well just use standard PHP, and if I'm going to do that then perhaps I should just scrap using XOOPS altogether!

My preference is to use XOOPS, and have it secure, so I would appreciated it if someone can provide some insight!

Thanks!

SuperGeek

Don't forget to go to Administration ... System / Modules / and click the "update" icon in the "action" column for the "system" module.

-SG

The dreaded blank page. Turn on debugging and add some echo "step 1
"; debug messages to your code (probably in mailusers.php) to see if you can figure out where the problem is. It might be a simple typo. Don't give up yet! It's worth fighting for!

-SG

My problem appears to be solved. I modified \modules\system\admin\mailusers\mailusers.php to only send mail to 10 users at a time. It was hard-coded to send to a subset of 100 at a time. For me 100 at a time would require me to click the "NEXT" button six times to get the message sent to all 600 of my users. Since my server times out long before 100 are sent I've hard-coded it to send to a subset of 10, so I'll have to press "NEXT" sixty times. It's not pleasant but at least it works! Maybe in the future someone will add some code to skip the "NEXT" button pressing but still have the same "subset" functionality. The prospect of pressing "NEXT" 1200 times for indream to get email to his 12k users sounds unpleasant. Maybe he can change the 10 to 20, 30 or even 50.

Hopefully my code change will help. Please note: The following is not the complete mailusers.php script, just lines 149-160.

.
.
.
        $added_count = count($added);
        xoops_cp_header();
        //OpenTable();
        if ( $added_count > 0 ) {
            $mail_start = !empty($_POST['mail_start']) ? $_POST['mail_start'] : 0;
//            $mail_end = ($added_count > ($mail_start + 100)) ? ($mail_start + 100) : $added_count;
            $mail_end = ($added_count > ($mail_start + 10)) ? ($mail_start + 10) : $added_count;
            $myts =& MyTextSanitizer::getInstance();
            $xoopsMailer =& getMailer();
            for ( $i = $mail_start; $i < $mail_end; $i++) {
                $xoopsMailer->setToUsers($added[$i]);
            }
.
.
.

Instead of hard-coding the 10, 100 or whatever, my opinion is that this should be a XOOPS config option.

- SuperGeek

I don't think set_time_limit is going to work. At first it looks good, but the error message you're getting is indicating that there are only certain times you're going to get it to work.

If your server is running IIS (like me), you have an additional problem: near the bottom of the comments at http://us3.php.net/set_time_limit is the following note:

Quote:

To answer your question, the file where it cycles through all the selected mail recipients (which in your case will be an array of 12,000 email addresses) is \modules\system\admin\mailusers\mailusers.php. Around line 157 is where the mailer object's TO array is populated.

for ( $i = $mail_start; $i < $mail_end; $i++) {
                $xoopsMailer->setToUsers($added[$i]);
            }

This won't work for more than just a few users at a time because the script will timeout, unless you are able to get set_time_limit to work. I know it won't work for me, so I'm going to have to modify the class to send the email to one recipient at a time.

- SuperGeek

I'm not sure the part about not being able to find the SMTP server is correct, but the part about php.ini is. In php.ini the timeout setting by default is only 30 seconds. That is not nearly enough time to send email to my 600 users, much less 12,000.

The problem is that the script that does the looping to send email to all the selected users does so in a single execution of the script. If it's not done in 30 seconds (or whatever your php.ini says) it fails. Even worse, you won't know who actually got the email and who didn't.

Another problem: If you use shared/virtual hosting for your website (most do) you'll have a hard time convincing the system admin to change the default timeout period to much more than 30 seconds. The reason is because the php.ini applies to ALL the hosted accounts, not just yours. A few runaway scrips would cripple their server.

The only solution is to rewrite Xoops' email script, so that it sends a few emails and then calls itself, looping until all emails have been sent. Each time it calls itself it sends a few more emails, with a new 30 second timeout period within which to do so. Somehow it would have to keep track of who has already received the email and who has not.

Unless there is an existing solution I'm going to have to do this for my own websites. Has anyone else discovered a solution to this timeout issue?

-SuperGeek

My debugging efforts have resulted in a work-around for the "Could not instantiate mail()" error raised by \class\mail\phpmailer\class.phpmailer.php

This appears to be a problem with the value of the $header variable in the class. My work-around is to simply set the value of $header to "". I believe a better solution to the problem is required but it is beyond my current expertise.

Here is my workaround:

/**
     * Sends mail using the PHP mail() function.  Returns bool.
     * @access private
     * @return bool
     */
    function mail_send($header, $body) {
        //$to = substr($this->addr_append("To", $this->to), 4, -2);

        // Cannot add Bcc's to the $to
        $to = $this->to[0][0]; // no extra comma
        for($i = 1; $i < count($this->to); $i++)
            $to .= sprintf(",%s", $this->to[$i][0]);

        if ($this->Sender != "" && PHP_VERSION >= "4.0")
        {
            $old_from = ini_get("sendmail_from");
            ini_set("sendmail_from", $this->Sender);
        }
$header="";  ////// This is my work-around
        if ($this->Sender != "" && PHP_VERSION >= "4.0.5")
        {
            // The fifth parameter to mail is only available in PHP >= 4.0.5
            $params = sprintf("-oi -f %s", $this->Sender);
            $rt = mail($to, $this->encode_header($this->Subject), $body, $header, $params);
        }
        else
        {
            $rt = mail($to, $this->encode_header($this->Subject), $body, $header);
        }

        if (isset($old_from))
            ini_set("sendmail_from", $old_from);

        if(!$rt)
        {
            $this->error_handler("Could not instantiate mail()");
            return false;
        }

        return true;
    }

I've submitted this as a bug in the XOOPS Bug Tracker at SourceForge. See https://sourceforge.net/tracker/index.php?func=detail&aid=1235649&group_id=41586&atid=430840 for details.

I hope others find this helpful!

-SuperGeek