Вообще есть один или несколько плагинов, продаваемых умельцами, которые позволяют делать такую ленту с анонсами и даже прикреплять картинку к анонсу. Этот вариант я запомнил и решил, что если быстро ничего не придумаю, то куплю.

Сначала решил, что самое простым решением будет оборачивать часть статьи в DIV и в CSS прописать ему свойство ‘display:none;’. Грубо, но должно получиться. Единственное, что меня остановило — статьи пишу не я, а объяснять как «оборачивать в DIV» мне очень не хочется. И еще контролировать, чтоб вложенность тэгов соблюдалась.

Тогда я обратил внимание, что при написании постов никто не пользуется тэгом HR (горизонтальная линия) и решил, что это будет отличный разделитель. Кнопка для вставки этого тэга есть в стандартном визуальном редакторе, так что проблем у авторов статей возникнуть не должно.

Файл с шаблоном списка статей (/published/SC/html/scripts/templates/news.frontend.list.tpl.html) поменял как-то так: на показ статей там цикл {section}{sectionelse}{/section}. Вот сразу после {section} и добавил пару строк — тут создаются полезные переменные: URL статьи и ссылка «читать дальше».

{assign var=article_url value="?ukey=news&blog_id="|cat:$news_posts[i].NID|set_query_html}
{assign var=readmore value="<p class=\"readmore\"><a href=\""|cat:$article_url|cat:"\">Читать полностью &raquo;</a></p>"}

а там, где выводится текст новости, т.е. просто показывается переменная $news_posts[i].textToPulication, заменил ее на 2 такие строки:

{assign var=textToPublication value=$news_posts[i].textToPublication|regex_replace:"/[\n\r]/iu":""}
{$textToPublication|regex_replace:"/<hr.*>.*/iu":$readmore}

После этого в файле шаблона, который отвечает за показ одной статьи блога (/published/SC/html/scripts/templates/news.frontend.post.tpl.html) добавил код, просто убирающий сам тэг HR. Вместо

{$news_posts[0].textToPublication}

написал вот так:

{$news_posts[0].textToPublication|regex_replace:"/<hr.*>/":""}

Вот и все. Обошлись малой кровью, все довольны, все смеются :)

Во первых есть функция _testStrInvalidSymbol($str). Проверяет строку на наличие неправильных символов. Неправильные символы, с точки зрения авторов скрипта: одинарные и двойные кавычки, знаки больше и меньше, а также обратный слэш — всего пять. Угадайте с одного раза сколько раз в теле функции проверяется условие if. :) Если в строке найден «неправильный» символ, то функция возвращает FALSE, если все в порядке — TRUE.

Заменил все внутренности на равноценную регулярку:

return preg_match('/\'\\\"\<\>\`/', $str) == 0;

Заодно добавил символ обратной кавычки или как оно там называется — то что на клавиатуре, левее кнопки с цифрой 1? :)

Ну, раз занялся регулярками и проверками, вернулся к упомянутой на форуме функции regVerifyContactInfo() — там есть странное условие: первый символ логин должен быть латинской буквой. Почему буквой? Почему если буквой, то именно латинской, если дальше могут быть любые символы, кроме пяти «запрещенных»? Было бы логично требование, чтобы логин состоял из букв латинского алфавита, цифр, знаков тире, подчеркивания и точки. Или даже без точки :) Оставил это решение на совести разработчиков скрипта, но мимо самой проверки пройти не смог спокойно. вместо сложновложенного if (ord($login) <’a'… тоже сделал регулярку (исходную строку найдете по имени константы):

if (preg_match('/^[a-z]/i', $login) == 0)
$error = ERROR_LOGIN_SHOULD_START_WITH_LATIN_SYMBOL;

Заодно, раз уж открыл файл, заменил пяток вызовов функции ereg() – она считается устаревшей и неподдерживаемой с версии PHP 5.3

В отчете рассматривался Shop-Script Free — это как раз бесплатная версия того, что ходит по интернету огромным тиражом. На Free версии основана наиболее цельная и популярная доработка под названием «Shop-Script Free Lego Edition».

Вывод неутешительный. На 14 апреля в скрипте имелось 27 уязвимостей, позволяющих атакующему получить доступ к базе данных, манипулировать данными и скомпрометировать систему.

В частности ошибки, позволяющие выполнять команды SQL, в обработке параметров, передаваемых в скрипт: (1) add2cart, (2) c_id, (3) categoryID, (4) list_price, (5) name, (6) new_offer, (7) price, (8) product_code, (9) productID, (10) rating, and (11) save_product. Пруфлинк.

В ShopScript есть 2 пути не дать заказать пользователю отсутствующий товар — включить в разделе «Настройки ->Корзина и оформление заказов» опцию «Вести учет товаров на складе» и тогда в свойствах товара надо будет вести количество по каждой позиции. Второй путь проще: установить товару нулевую цену, тогда ShopScript не будет показывать для этого товара ссылку на добавление в корзину.

Лично я предпочитаю второй путь, он для меня немного проще.

Однако, при показе товаров в категории ShopScript сортирует их по полям sort_order (порядок сортировки) и name (название). Из-за этого отсутствующие товары идут вперемешку с наличиствующими. Хотелось бы наоборот, чтобы те товары, которых в данный момент нет в наличии отображались бы в конце списка и на это не влиял выбор порядка сортировки (по имени, по цене и т.п.). То есть, чтобы все типы сортировок, которые науказывал посетитель применялись к тем товарам, которые можно заказать, а отсутствующие были все равно в конце списка.

Соседи вчера попросили сделать для них такой тип отображения. Чтобы не мучиться, я решил его сделать неотключаемым, просто добавить в запрос к базе данных на выборку товаров из категории еще одно правило. Оно должно быть первым, чтоб было самым главным :-) Вероятно я мог что-то упустить, но, с виду все работает как ожидается. Для сортировки по условию «поле Price равно нулю или нет» я использовал функцию MySQL IF(). Должен получаться вот такой запрос:

SELECT
	categoryID, name, brief_description,
	customers_rating, Price, in_stock,
	customer_votes, list_price, productID,
	default_picture, sort_order, items_sold,
	enabled, product_code, description,
	shipping_freight
FROM SS_products
WHERE enabled=1 AND categoryID=3
/* Здесь может быть много категорий */
ORDER BY
	IF(`Price`,1,0) ASC,
	sort_order, name;

Если используется учет количества товаров, то вместо поля `Price` надо использовать поле `in_stock`, как я понимаю.

За получение списка товаров для показа отвечает функция prdSearchProductByTemplate в файле core_functions/product_functions.php. Функция здоровая, из нее нам нужен кусок, который начинается с:

$order_by_clause = "order by sort_order, name";

Вот эту строчку и всю ересь далее удаляем, вплоть до строчки

$sqlQueryCount = "select count(*) from ".PRODUCTS_TABLE.

Строка выше должна остаться. ;-) Перед ней вставляем вот такой код:

$order_by_clause = "order by IF(`Price`,1,0) DESC, ";
if (
	isset($callBackParam["sort"]) &&
	in_array($callBackParam["sort"], array(
		"categoryID", "name", "brief_description",
		"in_stock", "Price", "customer_votes",
		"customers_rating", "list_price",
		"sort_order", "items_sold", "product_code",
		"shipping_freight")
	)
)
{
	$order_by_clause .= $callBackParam["sort"];
	if ( isset($callBackParam["direction"]) && $callBackParam["direction"] == "DESC")
	{
		$order_by_clause .= " DESC";
	}
}
else
{
	$order_by_clause .= "sort_order, name";
}

Не идеально, но на скорую руку сойдет. Вот и все, собственно. Теперь все товары с нулевой ценой будут в конце списка. Как сделать различие по другоу полю я уже написал.

Attention please. Не успел достаточно это протестировать, возможно эта функция вызывается еще откуда-нибудь. Перед внесением изменений сделайте себе про запас копию оригинальных файлов, которые собираетесь изменить. ;-)

Весь этот чудесный функционал находится в файле /core_functions/functions.php. Интересующая нас функция называется _formatPrice(). Все содержимое этой функции надо закомментировать и написать только одну строчку:

return number_format((float)$price,2);

Закомментированные 32 строки, в том числе 3 цикла делали то же самое. :-)

1. Добавил недостающие индексы в разные таблицы с товаром, параметрами товара, категории, валюты и т.д.
2. Убрал подсчет запросов категорий и товаров. Во-первых это оказалась бесполезная фича, во-вторых это было просто.
3. Закэшировал несколько запросов.

Эти три пункта помогли решить проблему. Не знаю, какой оказал бОльшее влияние, но первого точно было недостаточно.

Объяснять как установить PEAR, добавить в include_path путь до него не буду.

Первый вариант кэширования я сделал с помощью класса Cache_Lite из PEAR. В общем-то можно было бы обойтись и просто сохранением в файл, но мне не улыбалось писать код для сравнения даты создания файла, вычисления устаревания кэша и т.д. – все это уже сделано, зачем мне писать то же самое?

Что бы нам такого закэшировать? Посмотрим код ShopScript’a. Ух-ты! Есть вот такой перл в самом index.php:

//load all categories to array $cats to avoid multiple DB queries
//(frequently used in future - but not always!)
  $cats = array();
  $i=0;
  $q = db_query("SELECT categoryID, name, parent, products_count, description, picture FROM ".
    CATEGORIES_TABLE." where categoryID<>0
    ORDER BY sort_order, name")
   or die (db_error());
 
   while ($row = db_fetch_row($q))
   {
      $cats[$i++] = $row;
   }

Загружаются подряд все категории товаров! Когда это 5-10 категорий – не очень страшно. Если общее количество категорий приближается к сотне, да еще есть описания, то общий объем данных получается очень приличным. Да еще этот код срабатывает при каждом запуске скрипта, нужен-не нужен – пофиг.

Категории меняются редко, поэтому вполне достаточно выполнять такой запрос, скажем, раз в сутки. Вот этим и займемся.

Создадим директорию cache и разрешим скрипту туда запись. Если директория в корне сайта, лучше в нее добавить файлик .htaccess со строчкой ‘Deny from all’.

В начало index.php добавим подключение класса Cache_Lite и создание экземпляра класса. У меня получилось вот так:

$cache_options = array(
  'cacheDir'=>$_SERVER['DOCUMENT_ROOT'] . '/cache/',
  'lifeTime'=>86400);
$cache_categories_id = 'category';
require_once('Cache/Lite.php');
 
$CacheLite = new Cache_Lite($cache_options);

В переменной $cache_categories_id – метка, по которой будет извлекаться данные из кэша. В общем, доку по Cache_Lite надо хотя-бы просто просмотреть.

А код, где делается запрос к БД на выборку изменим на такой:

//load all categories to array $cats to avoid multiple DB queries
//(frequently used in future - but not always!)
 
 if ($cats_str = $CacheLite->get($cache_categories_id))
 {
   $cats=unserialize($cats_str);
 }
 else
 {
   $cats = array();
   $i=0;
   $q = db_query("SELECT categoryID, name, parent,
                 products_count, description, picture
                 FROM ".
                 CATEGORIES_TABLE."
                 where categoryID<>0
                 ORDER BY sort_order, name")
       or die (db_error());
 
   while ($row = db_fetch_row($q))
   {
     $cats[$i++] = $row;
   }
   $CacheLite->save(serialize($cats), $cache_categories_id);
 }

Вот и все. Еще в том же index.php есть запрос на выборку всех валют – тоже хороший кандидат на кэширование.

Еще можно внимательно рассмотреть запросы при выводе информации о товаре (includes/produc_detailed.php) и подумать о том, что информацию о товаре тоже можно кэшировать. Но в случае изменения неплохо бы и сбрасывать кэш.

Схема с PEAR::Cache_Lite прожила довольно долго. VDS я сменил на другой, у которого памяти побольше было и это позволило установить кэшер байткода XCache. А некоторое время назад я обнаружил, что ZendFramework научился работать с этим самым XCache. И я переделал работу с Cache_Lite на Zend_Cache с бэкендом XCache. Теперь переменные хранятся вообще в памяти.

— Как же так, Родион, старушку – всего за 20 копеек!!!
— Ну не скажите, Порфирий Петрович… Пять старушек – уже рупь…

Сначала обоснование. Счетчик показов информации о товаре и показов категории – обычное целочисленное поле в БД. Каждый раз когда запрашивается категория или просмотр информации о товаре, Shop-Script прибавляет к значению единицу. В теории должна получиться статистика просмотров и распределение товаров по популярности. Но кроме людей сайт посещает еще много разной живности, да и, скажем троекратный, просмотр товара одним пользователем не может считаться тремя просмотрами. В итоге такие сомневающиеся пользователи вместе с шумной и прожорливой толпой поисковых ботов накручивают эти счетчики. Как следствие — наиболее точно эти самые счетчики показывают погоду на Луне.

Сэкономить миллисекунды на 1 запросе – тоже хлеб.

Отключаем счетчик просмотра информации по товару. Для этого в файле /includes/product_detailed.php закомментариваем строчки:

if ( !isset($_GET["vote"]) )
      IncrementProductViewedTimes($productID);

Отключаем счетчик просмотра категорий. Для этого в файле /includes/category.php надо закомментировать строчку:

IncrementCategoryViewedTimes($categoryID);

Можно порадоваться, какие мы экономные. ;-)

Самые частые пути:

www.shopscripsite.ru/index.php?productID=nnnn
www.shopscripsite.ru/index.php?productID=nnnn&discuss=yes
www.shopscripsite.ru/index.php?categoryID=nnnn

Создадим в корне сайта файл .htaccess, если, конечно, его еще нет. И добавим в него такие строчки:

<IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteRule ^product/([^/]*)/discuss /product/$1/?discuss=yes [QSA,NE,L]
      RewriteRule ^product/([0-9]*) /index.php?productID=$1 [QSA,NE,L]
      RewriteRule ^category/([0-9]*) /index.php?categoryID=$1 [QSA,NE,L]
</IfModule>

Скажу честно – я не профессионал в составлении правил для mod_rewrite и Perl-овые регулярки знаю поверхностно. Наверняка эти команды можно оптимизировать, но надо же с чего-то начинать.

Собственно добавлением этих строчек все и заканчивается. Теперь вместе с теми URL, которые я написал выше будут работать и такие:

www.shopscripsite.ru/product/nnnn
www.shopscripsite.ru/product/nnnn/discuss
www.shopscripsite.ru/category/nnnn

А дальше надо править шаблоны. И, кое-где, файлы скрипта. Искать строчки типа

index.php?productID={$product_info.productID}

и заменять на

/product/{$product_info.productID}

Переменная у Smarty может называться и по-другому – зависит от шаблона. В общем смотреть, где формируются ссылки на категории и продукты. А также менять относительные ссылки на картинки и т.п. на абсолютные. В смысле

<img src="producst_pictures/{какая-то_переменная_Smarty}" alt="" />

на

<img src="/producst_pictures/{какая-то_переменная_Smarty}" alt="" />

Какие еще URL перезаписать? :-)