4
С исправлениями ошибок и недоработок авторских модулей.
Подвернулся тут модуль, где:
1. при отсутствии товара на складе клиент можен "подписаться на товар", задав свой емейл.
2. при появлении товара все подписанные получают емейл о том, что товар появился.
Идея хорошая, но реализация... эээ... как всегда.
1. поле, где хранится список емейлов, ожидающих поступления товара имеет тип VARCHAR(255). Его очень быстро перестает хватать на более-менее популярном товаре и емейлы новых клиентов уже никуда не заносятся невзирая на радостный рапорт о занесении в подписку.
Переделываем его в TEXT. 65535 байт тоже когда-то кончатся, но намного позже. Хотя, конечно, сам подход к хранению данных неизвестной длины в поле конечной длины идеологически неверен. Почему было не сделать отдельную кросс-таблицу productID<->email? Да и запрос емейла для ЗАРЕГИСТРИРОВАННЫХ пользователей (у которых он и так уже есть базе, зачем снова спрашивать) довольно странен.
Короче, кладем в core/includes/admin/ файл notice_user_correct.php следующего содержания:
<?php
db_query("ALTER TABLE ".PRODUCTS_TABLE." ADD temp_field VARCHAR(255)");
db_query("UPDATE ".PRODUCTS_TABLE." SET temp_field=notice_user");
db_query("ALTER TABLE ".PRODUCTS_TABLE." DROP notice_user");
db_query("ALTER TABLE ".PRODUCTS_TABLE." ADD notice_user TEXT");
db_query("UPDATE ".PRODUCTS_TABLE." SET notice_user=temp_field");
db_query("ALTER TABLE ".PRODUCTS_TABLE." DROP temp_field");
unlink("core/includes/admin/notice_user_correct.php");
?>
и заходим в админку. Затем удаляем этот файл, если он не удалился сам.
Конечно, преобразовывать поле VARCHAR в TEXT не совсем хорошо, т.к. первое фиксированной длины, а второе нет и замедляет работу с таблицей. Но в таблице продуктов и так уже есть пять (!) TEXT-полей, так что конкретно для нее это уже ни на что не повлияет.
2. При возврате товара на склад по отмене заказа емейл не рассылается, хотя товара стало больше нуля. Исправляем.
В файле order_status_functions.php в функцию _changeIn_stock
перед завершающими функцию строками
}
}
}
вставляем все тот же стандартный код, как и в других местах. Мне он тоже не нравится, но оптимизация выходила за рамки задачи.
//вставка уведомления о поступлении товара
$q = db_query("select * from ".PRODUCTS_TABLE." where `in_stock`>0 and (LENGTH(`notice_user`)>0)");
while( $subscriber = db_fetch_row($q) )
{
$emailarray = explode(";", $subscriber["notice_user"]);
foreach($emailarray as $em)
if(strlen($em) > 0)
xMailTxtHTMLDATA($em, "Уведомление о поступлении товара", "Уведомляем о поступлении товара:<br /><br /><b><a href='".CONF_FULL_SHOP_URL."index.php?productID=".$subscriber['productID']."'>".$subscriber['name']."</a></b><br /><br /><b>Цена:</b> ".$subscriber['Price']."<br /><br /><center>Удачных покупок!</center>");
db_query( "UPDATE ".PRODUCTS_TABLE." SET `notice_user` = '' WHERE `productID`='".$subscriber["productID"]."'");
}
//end
3. Ну и офигенно смотрится этот код (см. выше) в функции AddProduct
. Т.е. продукта еще нет, подписчиков на него явно и быть-то не может, но код на всякий случай вставлен. Зачем? Я так и не смог понять.
