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

Сначала решил, что самое простым решением будет оборачивать часть статьи в 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.*>/":""}

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

Часто возможность раздачи скидок выпадает из факторов, которые рассматриваются при выборе платформы. И зря. Трудно себе представить, какие фантазии могут придти в голову владельцам, маркетологам или рекламщикам магазина. Поэтому при выборе скриптов для интернет-магазина этот параметр никак нельзя упускать из виду. Во многих случаях я натыкался на жестко фиксированный набор различных скидочных программ, который причинял изрядные неудобства уже спустя несколько месяцев после запуска сайта. Зачем далеко ходить? Например, после установки модулей приема платежей с кредитных карт владельцу пришло в голову дать скидку за платежи наличными — те самые 3-4%, которые забирает себе эквайрер. А автор скрипта этого не предусмотрел. В таких случаях часто требуется вмешательство в основной код скрипта, что, конечно, расстраивает. И не просто расстраивает! Многие скрипты сейчас имеют возможность автоматического обновления, при котором либо все внесенные изменения, конечно, теряются, либо просто блокируют саму возможность обновления.

Модульность этого компонента скрипта интернет-магазина даст возможность комбинировать и видоизменять, гибко настраивать скидочную систему. Это очень важная составляющая, от которой, во многом, зависит успешность проекта.

Наиболее распространенные виды скидок, которые понадобятся:

1. Скидка на конкретный товар. Часто это реализуется в карточке товара хранением двух цен — «старая/новая цена». Точно так же это часто бывает неудобно, особенно если скидка на определенный товар для ограниченного круга посетителей. Лучше, если этот функционал будет реализован в разделе скидок, а не в карточке товара
2. Скидка на группу товаров или категорию или марку. В общем, на какие-то товары, объединенные общим признаком. В принципе, обходится редактированием скидок из первого пункта, но это может быть неудобно. Акция типа «распродажа всех MP3-плееров» заставит менеджеров изрядно потрудиться, указывая на каждый плеер отдельно скидку
3. Скидка по купону (промо-коду). Такая возможность обязательно должна быть. Купоны могут быть одноразовыми, многоразовыми, с или без ограничения по сроку действия. Еще лучше, если к этим возможностям добавляются возможности из первых двух пунктов, получается очень гибкая система
4. Скидка за количество заказов, за объем заказа, накопительная за общее количество потраченных денег. Самый часто встречающийся вариант, тут и объяснять ничего не надо
5. Подарочный сертификат. Также полезная вещь. Отличается от купона тем, что предоставляет не скидку, а определенную сумму, на которую покупатель может выбрать товар. Далеко не во всех скриптах реализовано, ведь для обработки таких купонов надо вести специальный «счет» пользователя, учитывать при оплате состояние этого счета и т.д. И еще неизвестно, что решит владелец магазина, вдруг некоторые товары, например, нельзя будет купить по такому сертификату. Или еще что-то.

Таким образом при выборе скрипта надо проверять наличие хотя бы первых четырех пунктов, особо отличать за наличие пункта номер 5 и за «модульность», если скидочные модули можно добавлять самостоятельно. Если в демо-версии непонятно, как реализована система скидок имеет смысл заглянуть на сайт разработчика и посмотреть есть-ли отдельно модули, реализующие какие-нибудь, неважно какие, скидки.

Отдельно еще надо обратить внимание на то, как комбинируются скидки. Как правило везде есть выбор из минимум двух опций: суммировать или выбирать наибольшую. Если кроме этих двух в скрипте предусмотрено что-то еще — можно считать плюсом и отмечать отдельно. Если наоборот, выбора нет — обратить особое внимание, отсутствие этого минимального функционала может создать проблемы при эксплуатации сайта.

При пристальном изучении обратить внимание на реализацию «модульности»: одно дело, если скидка рассчитывается только при оформлении заказа, другое — если есть возможность рассчитать и показать результат расчета при просмотре сайта или карточки товара: наглядно сообщение «цена с учетом Вашей скидки MMM руб., а не NNN как для остальных» также оказывает хорошее действие на принятие решения о покупке.

1. Использовать плагин CakePHP Queue. Мне не нравится в нем то, что он постоянно крутится отдельной задачей, проверяя каждые N минут наличие новых заданий. С одной стороны заданий планируется не так много, чтоб опрашивать каждые 10 минут, с другой — хочется, чтоб исполнение начиналось сразу после поступления нового. И задания должны быть оформлены в виде Tasks, но у меня уже есть консольные скрипты со своими tasks.
2. Можно добавлять в отдельную таблицу задание (название скрипта и параметры) и запускать в бэкграунде (через exec(‘nohup…’) скрипт-диспетчер, который проверяет, выполняется-ли уже он сам и, если нет, начинает запускать скрипты, доставая их из этой таблицы. Запускать по-простому, с помощью exec(…). Если будет запущена вторая копия диспетчера, она сразу завершится. Так и будут выполнятся поочередно все задания, пока очередь не очистится. Можно добавлять задания из cron’а, можно из приложения. Раз задание хранится в БД, то можно и лог привязать к номеру этого задания, что тоже приятно. В этой схеме мне нравится все, кроме того, что для выполнения любого консольного скрипта будет запущено 2 копии php с cake. Одна для выполнения диспетчера, вторая — для выполнения задания.
3. Диспетчером может быть не шелл-скрипт на Cake, а обычный bash-скрипт. Вот только доступа к БД у него нет и задания, наверное, придется записывать построчно в текстовой файл. Отслеживание блокировки файла, удаление строк с выполненными заданиями и прочее совсем не внушают оптимизма.

Я ничего не упустил? Может, есть еще какие-то более красивые и удобные варианты?

Есть два плагина: PluginOne и PluginTwo. У первого две связанные модели: PluginOneModelOne belongsTo PluginOneModelTwo. У второго плагина одна модель, связанная с первой моделью первого плагина (пусть тоже будет belongsTo, неважно): PluginTwoModelOne belongsTo PluginOneModelOne. Соответственно, объявлено все это вот так:

Файл /plugins/plugin_one/models/plugin_one_model_one.php

class PluginOneModelOne extends PluginOneAppModel {
 
	var $belongsTo = array('PluginOneModelTwo');
 
}

Файл /plugins/plugin_one/models/plugin_one_model_two.php

class PluginOneModelTwo extends PluginOneAppModel {
	var $actsAs = array('Tree');
}

Файл /plugins/plugin_two/models/plugin_two_model_one.php

class PluginTwoModelOne extends PluginTwoAppModel {
 
	var $belongsTo = array(
		'PluginOneModelOne'=>array(
			'className'=>'PluginOne.PluginOneModelOne'
		));
 
}

Создадим в контроллере второго плагина тестовый метод:

Файл /plugins/plugin_two/controllers/plugin_two_model_ones_controller.php

class PluginTwoModelOnesController extends PluginTwoAppController {
 
	function typeofmodel() {
		die(get_class($this->PluginTwoModelOne->PluginOneModelOne->PluginOneModelTwo));
	}
 
}

Опачки! Третья модель типа AppModel, а не PluginOneModelTwo! Соответственно, не загружаются behaviours, перечисленные в $actsAs, не работают методы модели, не обрабатываются правила валидации. Хитрый Cake молча создает объект базового класса, чтоб связь работала для стандартной выборки, записи и все.

Достаточно в описании связи моделей первого плагина полностью указать какой класс использовать — все отлично начинает работать. Меняем код PluginOneModelOne

Файл /plugins/plugin_one/models/plugin_one_model_one.php

class PluginOneModelOne extends PluginOneAppModel {
 
	var $belongsTo = array(
			'PluginOneModelTwo'=>array(
				'className'=>'PluginOne.PluginOneModelTwo'
		));
 
}

и запускаем снова тестовый метод. Вот теперь все как и ожидается.

Если подумать, то поведение фреймворка в общем-то логичное. Он ищет класс в текущем плагине и у самого приложения. Хотя мог бы и предупреждать, пусть бы и только в отладочном режиме, что есть проблема.

Во первых есть функция _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

Сейчас хочу остановиться конкретно на блоке данных с почтовым адресом. Обычно это адрес доставки, но также это может быть адресом плательщика и отличаться от адреса доставки. Платит один человек, получает другой или как-то так. Не важно.

Здесь также пользователь должен с минимумом усилий указать максимум полезной информации. Во всех скриптах обычно заполняются такие поля:

1. Почтовый индекс
2. Страна
3. Регион, штат или другая территориальная единица (если есть)
4. Город
5. улица, дом, квартира и т.д.

Для крупных городов, например, для Москвы или Санкт-Петербурга можно дополнительно спросить ближайшую станцию метро. В Webasyst Shop-Script это реализуется дополнительным полем.

Применительно к России возникает вопрос к 3-му пункту, у нас весьма пестрое административное деление. Самое простое — воспользоваться списком кодов субъектов РФ из Википедии. Но тут надо иметь в виду, что некоторые субъекты могут входить в состав других — автономные округа могут входить в состав краев и областей. Большинство реализаций скриптов этого не предусматривают, а зря. Деление на регионы должно быть не плоским списком а древовидным!. Стоп, не надо бежать срочно добавлять поле «parent_id» в существующую базу. Надо сначала погуглить на тему nested sets и проникнуться.

При этом регион «Москва» не идентичен городу Москва. При заполнении списка регионов об этом тоже надо помнить, Зеленоград также входит в состав Москвы, а доставка туда, как правило, отличается ценой.

Также имеет смысл хранить список наиболее крупных населенных пунктов каждого региона, чтобы пользователь мог выбрать город из списка или написать, если в списке нет нужного населенного пункта. Минимум опечаток — максимум точности при определении стоимости доставки.

Update. Раз уж речь зашла о древовидном хранении, то список страны-регионы_(области, края и т.д.) можно хранить в единой таблице. В ней корневыми элементами или элементами первого уровня (корень тогда будет «World» :) ) будут страны. Для классификации можно воспользоваться стандартом ISO 3166 и его подразделами относительно административных единиц.

В отчете рассматривался 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. Пруфлинк.

http://www.example.com/products/prices

http://www.example.com/products/prices/index/order:price

http://www.example.com/products/prices/index/order:title

Мне кажется, что поисковому роботу такое может и не понравится, уж больно это смахивает на попытку заспамить поисковик. Я раздумывал о том, что,наверное, такие страницы, в URL которых указаны подобные параметры неплохо бы, наверное, закрывать от индексирования. Обычными директивами meta в заголовке страницы.

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

Совсем небольшая заковыка в разрезе CakePHP состояла в том, что для кейка без разницы URL http://www.example.com/products/prices и http://www.example.com/products/prices/index — надо было бы как-то эту ситуацию обрабатывать.

Совсем недавно наткнулся на решение этой проблемы «похожих страниц» в гугловской документации к платформе Blogger. Не совсем понятно, почему они именно там это разместили, поскольку это было бы полезно всем владельцам сайтов, а не только авторам блогов на платформе Blogger.

Оказывается Google отлично понимает атрибут rel="canonical". Т.е. в заголовке (в разделе <head>) страниц размещаем элемент:

<link rel="canonical" href="http://www.example.com/prices" />

и больше не паримся. В атрибуте href этого элемента указан адрес «основной» («канонической» в терминах Google) страницы. Поисковик обещает учитывать такие ссылки и стараться выдавать клиентам адрес именно этой страницы.

Ссылка может быть как относительной, так и абсолютной. Но Google рекомендует ставить абсолютную. Можно, кстати, попробовать указать страницу на другом домене — это тоже не возбраняется.

Update. Метод Folder::findRecursive возвращал слишком много файлов, в том числе и ненужных. Переписал немного, теперь опрашиваем только директорию с плагином и его контроллерами.

/**
 * Lists the names of controllers including plugin controllers
 * 
 * @return array
 */
static function listControllers()
{
    App::import('Core', array('File', 'Folder'));
 
    $controllers = Configure::listObjects('controller');
 
    $config = Configure::getInstance();
 
    foreach ($config->pluginPaths as $pluginPath)
    {
        $folder = new Folder($pluginPath);
        list($plugin_dirs) = $folder->read();
        foreach($plugin_dirs as $plugin_dir)
        {
            $pluginName = Inflector::camelize($plugin_dir);
            $folder->cd($pluginPath . $plugin_dir);
            $controllerFiles = $folder->find('.*_controller\.php');
            $folder->cd(Folder::addPathElement($folder->path, 'controllers'));
            $controllerFiles = array_merge($controllerFiles,$folder->find('.*_controller\.php'));
            foreach ($controllerFiles as $file)
            {
                $file = basename($file);
                $controllers[] = $pluginName . '.' .
                    Inflector::camelize(substr($file, 0, strlen($file)-
                    strlen('_controller.php')));
            }
        }
    }
    return $controllers;
}

Сегалович:

Ровно в этих рамках (борьба с «глупостью») мы относительно недавно реализовали алгоритм определения запросов и ответов, которые можно трактовать двояко: и как поиск эротического и порнографического содержания, и как невинный информационный запрос. Например, запрос [девочки] может быть поиском повести Людмилы Улицкой, а вовсе не «девочек по вызову». Для человека, ищущего Улицкую, ответ с порнографией не просто нерелевантен, он «явная глупость».

Опираясь на классификаторы запросов и сайтов по порнографическому и непорнографическому содержанию, и построив соответствующие метрики, отражающие долю резко нерелевантного поведения нашей системы по «двояким» запросам, мы смогли реализовать механизм понижения в выдаче сайтов порнографического содержания.

Было бы логично, если бы Яндекс подсовывал разным посетителям разные варианты выдачи, основываясь на данных предыдущих запросов, статистики из Метрики и т.д. Не специально для каждого пользователя, а для каких-то условных групп, типа «любитель клубнички», «книжный червь» или каких-то таких. А что? Статистика по запросам есть, статистика посещенных сайтов и проведенного на них времени — то же (Метрика, различные кнопки ТИЦ, блогов и т.д.) — нарисовать схему интересов пользователя можно. И потом соотнести с какой-то своей внутренней классификацией. А вот слова о том, что ответ не подвергается модификации — это, возможно, и временно. На паре «порно/непорно» алгоритм просто обкатывается.

Если Яндекс все-таки реализует модификацию выдачи в зависимости от вычесленных предпочтений пользователя — вот будет головная боль оптимизаторам! Почистил куки, походил по сайтам с пластиковыми окнами — получи выдачи про строительство и остекление балконов, почистил куки, походил по сайтам с программным обеспечением — получи выдачу про Windows. И все в ответ на один и тот же запрос «окошки».

Сегалович:

по ряду запросов мы мониторим выдачу других поисковых машин, всех, кто хоть как-то ищет по-русски, включая все версии самого Яндекса — рабочую версию и внутренние, экспериментальные (у Яндекса много версий). И складываем все результаты в один котел. Если какой-то сайт присутствует в этом «котле», если он там имеет достаточно хорошие оценки, и при этом отсутствует в Яндексе, мы начинаем разбираться – почему

Садовский:

Чтобы было понятно, «котел» какого объема оценивается, подчеркну, что это речь идет о десятках тысяч запросов, которые мы проверяем таким образом. Мы проверяем первые 30 позиций по каждому запросу. Считайте: десятки тысяч запросов, умножить на 30 первых позиций, умножить на количество версий, — это десятки миллионов URL.

Мониторят конкурентов. Очевидно, Google, Bing и Рамблер. Наверное и Yahoo. Об остальных можно только догадываться. Составляют множество сайтов, попадающих в выдачу всех или бОльшей части конкурентов. Потом сравнивают со своими результатами. Конкретная позиция, наверное, не очень важна — главное присутствие в первых 30-ти результатах. Смотрят, какие сайты попали к ним — если различие сильное, это повод задуматься. Т.е. если после получения результатов от конкурентов оказывается, например, что 22 сайта присутствуют у всех, а у Яндекса только 5 из этих сайтов — это повод побеспокоиться.

Сразу возникает интересная идея — путь к первой странице выдачи Яндекса может лежать и через результаты выдачи его конкурентов.

Сегалович:

Так вот, практически все обращения в службу техподдержки — я думаю, в цифрах это будет более 90% — касаются именно таких сайтов из «серой зоны». Пишут грамотные аргументированные письма: «А вот смотрите, почему вы этот сайт выбросили, он качественный, контент уникальный, ссылки по теме. Объясните почему.» Цель таких писем – методом перебора уточнить безопасные границы в этой «серой зоне». Предприняли какое-то действие – смотрят результат. Если результат отрицательный, сайт попал под санкции, они пытаются получить от нас обратную связь, проанализировать причины.

Певцов:

…как показывает практика, большинство сайтов, по поводу отсутствия которых в выдаче к нам обращаюся вебмастера, создавались специально с целью обмана поисковой системы и манипуляции результатами поиска…

Садовский:

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

Ну все уже догадались? Жаловаться на то, что сайт выпал из индекса, хотя соответствует «техническим параметрам» — ссылки, качество контента и т.д. — не надо. Ищите другую аргументацию. Вам же не робот отвечает, человек. И он понимает, что вебмастер беспокоящийся о технической стороне вопроса — не их союзник. И еще. Удалось убедить, что «сателлит» белый и пушистый? Будьте готовы к тому, что из под санкций могут выползти и «сателлиты» конкурентов. Любите жаловаться на «сателлиты» конкурентов, присутствующие в выдаче? Будьте готовы к тому, что вместе с ними пойдут ко дну и ваши такие-же.

Певцов:

уникальность контента совсем не определяющая вещь. О ней много говорят, но более важная характеристика — не уникальность, а полезность контента [и далее по тексту]

«У вас на сайте неуникальный текст! Ужас-ужас-ужас!» — страшилка. То есть, если скопировать все подряд, санкции будут. Но умеренное разбавление своих статей статьями, взятыми из других источников, может не повлечь никаких санкций. Таким образом, если где-то в интернетах нашлась удачная статья, подходящая сайту и автор не против ее распространения, можно спокойно скопировать ее к себе или процитировать. Ссылка на оригинал, как мне кажется, в данном случае будет лишним подтверждением «добрых намерений».

Четвертая часть о воровстве контента. Авторам стОит отдавать свои статьи в RSS. Не жмотитесь, отдавайте всю статью. Роботы, сканирующие блогосферу быстрее и чаще забирают контент. Если статья у кого-то скопирована, не надо расстраиваться, страница с этим текстом не первая в выдаче. Еще не факт, что посетителя заинтересует первый сайт. 2-5 место тоже хороши. И до конца первой страницы — нормально. Кроме того, скопированная страница может придать общий тематический вес сайту, подняв его по другим, похожим, низкочастотным запросам.

Торговля и обмен ссылками яндексоидов раздражают. Но, если уж они научились находить «продажные ссылки», то зачем банить всю страницу, она может оказаться вполне нормальной, а ссылки — результатом баловства наемного вебмастера. Ну неучитывали-бы тихонько эти самые ссылки молча. Дятлы бы продолжали бы заниматься бесполезным трудом и не искали бы каких-то иных методов воздействия на поисковик.

Ну вот как-то вот так. Спасибо, что дочитали до конца. :)