While the installer was running I used PHPMyAdmin to add the “ip_address” field to “exp_mailing_list” that the installer could not find, then backed out. The script ran again and the error evaporated. Now I have another database error to fix.
******************
The function in upd_mailinglist.php that is failing and BLOCKING UPGRADE is the following. See my last two posts for the error messages.
See “// Update ip_address column” below.
There IS in fact NO “ip_address” column in the table as I see it PHPMyAdmin. So how did the script decide that it was supposed to be there? I generally don’t use PHPMyAdmin to mess with database details in the middle of installations, but perhaps I should add the field and see if that satisfies EE’s update script.
I see that we have no entries in the table, since we are not using mailing list functionality. I would guess that if I deleted the table, the installer would have just created it anew (I did another new installation on my computer to test the installer, and THAT worked). But you wouldn’t necessarily want to delete a table if it has data just to make a defective upgrade process work.
However, I cannot be sure that doing that and rerunning the installer would have the same effect.
class Mailinglist_upd {
. . . .
/**
* Module Updater
*
* @access public
* @return bool
*/
function update($current='')
{
if (version_compare($current, '3.0', '<'))
{
$this->EE->db->query("ALTER TABLE `exp_mailing_list` MODIFY COLUMN `user_id` int(10) unsigned NOT NULL PRIMARY KEY auto_increment");
$this->EE->db->query("ALTER TABLE `exp_mailing_list` DROP KEY `user_id`");
$this->EE->db->query("ALTER TABLE `exp_mailing_list_queue` ADD COLUMN `queue_id` int(10) UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY FIRST");
}
if (version_compare($current, ‘3.1’, ‘<’))
{
// Update ip_address column
$this->EE->dbforge->modify_column(
'mailing_list',
array(
'ip_address' => array(
'name' => 'ip_address',
'type' => 'varchar',
'constraint' => '45'
)
)
);
}
return TRUE;
}