В данной статье (уровень веб-мастера - продвинутый) речь пойдёт о, пересекающейся по разным признакам, т.н. "фасетной" навигации. Для упрощения усвоения материала рекомендую пробежаться по статье в Википедии "Фасетная классификация " и публикации на английском языке (но с картинками!) "Design better faceted navigation for your websites ".
Фасетная навигация с фильтрацией по цвету или ценовому диапазону может быть полезна для ваших посетителей, но зачастую вредит в поиске из-за того, что создаёт множество комбинаций адресов с дублирующимся контентом . Из-за дублей поисковые системы не смогут быстро сканировать сайт на предмет обновлений контента, что соответственно влияет и на индексацию. Чтобы минимизировать эту проблему и помочь веб-мастерам сделать фасетную навигацию дружелюбной в отношении поиска, мы бы хотели:
Идеально для пользователей и поиска Google
Чёткий путь к продуктам/страницам статьи:
Представление URL для страницы категории:
http://www.example.com/category.php?category=gummy-candies
Представление URL для конкретного продукта:
http://www.example.com/product.php?item=swedish-fish
Нежелательные дубликаты, вызванные фасетной навигацией
Одна и та же страница доступна с различных веб-адресов:
Каноническая страница
URL: example.com/product.php? item=swedish-fish
Дублированная страница
URL:example.com/product.php? item=swedish-fish&category=gummy-candies&price=5-10
category=gummy-candies&taste=sour&price=5-10
Ошибки:
- Бессмысленно для Google, так как пользователи редко ищут [мармелад по цене 9:55 долларов].
- Бессмысленно для поисковых роботов, которые обнаружат один и тот же элемент ("фруктовый салат") от родительских страниц категорий (либо "Жевательный мармелад" или "кислый Жевательный мармелад").
- Отрицательный момент для владельца сайта, потому запросы на индексацию разбавляются многочисленными версиями одной и той же категории.
- Отрицательный момент для владельца сайта, потому что это бесполезная и лишняя нагрузка в пропускной способности сайта
URL: example.com/category.php? category=gummy-candies&taste=sour&price=over-10
Ошибки:
- Неправильно отдаётся код для поисковых систем (в таком случае страница должна отдавать код 404)
- Пустая страница для пользователей
Наихудшие решения (не дружелюбные в отношении поиска) фасетной навигации
Пример №1 : В составе URL применяются не стандартные параметры: запятые и скобки, вместо ключ=значение& :
- example.com/category? [ category:gummy-candy ][ sort:price-low-to-high ][ sid:789 ]
- example.com/category?category , gummy-candy , sort , lowtohigh , sid , 789
example.com/category?category=gummy-candy&sort=low-to-high&sid=789
Пример №2
: Использование каталогов или путей к файлам, а не параметров в списках значений, которые не изменяют содержание страницы:
example.com/c123
/s789/
product?swedish-fish
(где /c123/ категория, /s789/ ID сессии, что не изменяет содержимое страницы)
Хорошее решение:
- example.com /gummy-candy/ product?item=swedish-fish&sid=789 (каталог, /gummy-candy/, меняет содержимое страницы в значимым образом)
- example.com/product?item=swedish-fish&category=gummy-candy&sid=789 (параметры URL дают большую гибкость для поисковых систем, чтобы определить, как эффективно сканировать)
Общие значения, которые не меняют содержимое страницы и должны быть перечислены в качестве параметров URL, включают:
- ID сессии
- Отслеживание идентификаторов
- Referrer идентификаторы
- Отметки времени
Использование незначительных данных, генерируемых пользователями сайта (например, как долгота/широта или "дней назад"), в сканируемых и индексируемых адресах:
- example.com/find-a-doctor? radius=15&latitude=40.7565068&longitude=-73.9668408
- example.com/article?category=health& days-ago=7
- example.com/find-a-doctor?city=san-francisco&neighborhood=soma
- example.com/articles?category=health&date=january-10-2014
- example.com/filtering/ find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
- example.com/filtering/ articles?category=health&days-ago=7
User-agent: *
Disallow: /filtering/
Пример №4 . Добавление параметров URL без логики.
- example.com/gummy-candy/lollipops/gummy-candy/ gummy-candy/product?swedish-fish
- example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy &cat=gummy-candy&item=swedish-fish
- example.com /gummy-candy/ product?item=swedish-fish
- example.com/product?item=swedish-fish&category=gummy-candy
Пример №5 : Предлагать дальнейшие уточнения (фильтрация), когда есть нулевые результаты.
Плохо:
Разрешать пользователям выбрать фильтры, когда существуют нулевые элементы для уточнения.
Уточнение к странице с нулевыми результатами (например, price=over-10), что расстраивает пользователей и вызывает ненужные запросы для поисковых систем.
Как надо:
Создавать ссылки только тогда, когда есть элементы для выбора пользователем. При нулевом результате ссылку помечать "серой" (т.е. недоступной для клика). Для дальнейшего улучшения юзабилити рассмотреть вопрос о включении показателя количества доступных элементов рядом с каждым фильтром.
Вывод страницы с нулевыми результатами (например, price=over-10) не допускается, плюс запрещается пользователям делать ненужные клики, а поисковым система сканировать эту не полезную страницу.
Необходимо предотвращать появление ненужных адресов и минимизировать пространство для посетителя, создавая URL только при наличии продукции. Это поможет пользователям оставаться занятыми на вашем сайте (меньше кликов по кнопке назад, когда не находится ни одного товара), уменьшит число возможных URL, известных поисковым системам. Кроме того, если страница не просто "временно нет в наличии", а вряд ли когда-нибудь будет содержать релевантную информацию, стоит рассмотреть возможность сделать для неё код ответа 404 . На 404-ой странице вы можете оформить полезное сообщение для пользователей с большим количеством опций в навигации или окно поиска, чтобы пользователи могли найти родственные продукты.
Для новых сайтов, веб-мастера которых рассматривают внедрение фасетной навигации, есть несколько вариантов оптимизации сканирования (совокупность адресов на вашем сайте, известных роботу Google) уникальных страниц контента и уменьшения попадания в индекс поисковой системы дублирующихся страниц (консолидация сигналов индексации).
Определите, какие параметры URL требуются для поисковых систем, чтобы сканировать каждую индивидуальный страницу с контентом (то есть, определить, какие параметры необходимы для создания, по меньшей мере одного клик-пути к каждому пункту). Обязательные параметры могут включать в себя item-id , category-id , page т.д.
Определите, какие параметры будут полезны для посетителей с их запросами, и какие скорее всего только вызовут дублирование при сканировании и индексировании. В примере с кондитерскими товарами (мармелад) параметр URL "taste " может быть ценным для пользователей с запросами в примере taste=sour . Тем не менее, логично посчитать параметр "price" вызывающим лишнее дублирование category=gummy-candies&taste=sour&price=over-10 . Другие распространенные примеры:
- Ценные параметры для поисковиков: item-id , category-id , name , brand ...
- Ненужные параметры: session-id , price-range ...
Вариант 1: и внутренние ссылки
Пометьте все ненужные URL-адреса атрибутом . Это уменьшит трудозатраты поискового робота и предотвратит снижение частоты сканирования. Глобально управлять сканированием нужно через robots.txt (Примеч. переводчика: см. статью " ").
Воспользуйтесь атрибутом rel="canonical", чтобы отделить страницы для поискового индекса от страниц, не нужных там (например на странице price=5-10
можно прописать атрибут rel="canonical", указывающий на категорию всего кислого мармелада example.com/category.php?category=gummy-candies&taste=sour& page=all
).
Вариант 2: Robots.txt и Disallow
URL-ы с ненужными параметрами включают в директорию /filtering/
, которая будет закрыта в robots.txt (запрет disallow). Это даст всем поисковым системам сканировать только "правильное" внутриссылочное (содержимое) сайта, но будет блокировать разом сканирование нежелательных URL. Например (example.com/category.php?category=gummy-candies
), если ценными параметрами были item, category и taste, и лишними были идентификатор сеанса и price, то URL будет для taste таким:
example.com/category.php?category=gummy-candies&taste=sour
,
но все ненужные параметры, такие как price, URL включит в предопределенный каталог - /filtering/:
example.com/filtering/
category.php?category=gummy-candies&price=5-10
,
который затем через robots.txt будет запрещен:
User-agent: *
Disallow: /filtering/
Вариант 3: Раздельные хосты
Убедитесь, что лучшие решения, перечисленные выше (например, для ненужных адресов) все еще применяются. В противном случае поисковые системы уже сформировали большую ссылочную массу в индексе. Таким образом, ваша работа будет направлена на снижение дальнейшего роста ненужных страниц, просмотренных с помощью робота Google и консолидацию сигналов индексации.
Используйте параметры со стандартной кодировкой и форматом ключ=значение (key=value).
Убедитесь, что значения, которые не меняют содержимое страницы, такие как идентификаторы сеансов, реализованы в виде ключ=значение, а не каталогов.
Не позволяйте кликать и не генерируйте URL-адреса, когда не существует элементов для фильтра.
Добавьте логику в отображение параметров URL: удалите ненужные параметры, а не добавляйте постоянно значения (например, избегайте такой генерации ссылки: example.com/product?cat=gummy-candy&cat=lollipops &cat=gummy-candy&item=swedish-fish ).
Сохраняйте ценные параметры в URL, перечислив их в первую (так как
URL видны в результатах поиска) очередь и менее уместные параметры в
последнюю (например, идентификатор сессии).
Избегайте подобной структуры ссылок: example.com/category.php?session-id=123&tracking-id=456
&category=gummy-candies&taste=sour
Настройте параметры URL в Инструментах для веб-мастеров, если имеете чёткое представление о работе ссылок на вашем сайте.
Убедитесь, что при использовании JavaScript для динамического управления контентом (sort/filter/hide) без обновления URL, есть реальные веб-адреса на вашем сайте, имеющие ценность в поиске, например, это основные категории и страницы продуктов, которые доступны для сканирования и индексирования. Старайтесь не использовать только домашнюю страницу (т.е. один URL) для всего вашего сайта, а через JavaScript динамически изменять контент навигацией - это, к сожалению, выдаст в поиске пользователям только один URL. Кроме того, проверьте, чтобы производительность не повлияла на работу динамической фильтрации в худшую сторону, так как помешает пользователю работать с сайтом.
Улучшите индексацию различных страниц одного контента указанием атрибута rel="canonical" на привилегированную версию страницы. Атрибут rel="canonical" может быть использован внутри одного и нескольких доменов.
Оптимизируйте индексацию контента, разбитого на страницы "паджинации" (например, page=1 и page=2 из категории "gummy candies") посредством (либо):
- Добавьте атрибут rel="canonical" в серию страниц с указанием канонической категории с параметром “view-all” (например, page=1, page=2, и page=3 из категории "gummy candies" с with rel=”canonical” на category=gummy-candies&page=all ), удостоверившись, что страница необходима пользователям и загружается быстро.
- Используйте разметку разбиения на страницы rel="next" и rel="prev" , чтобы указать на связь между отдельными страницами (см. статью "Paginaton with rel="next" and rel="prev" ") .
Для каждого поста и записи wordpress пользователь может задавать одну или несколько рубрик (категорий). Эта возможность позволяет сгруппировать близкие по смыслу записи и предоставить возможность посетителям читать и просматривать только те рубрики, которые им нравятся. Например, когда я создавай свой основной блог Tod’s Blog, то собирался писать обо всех нюансах интернета — начиная с дизайна и заканчивая программированием. Допустим, человек пришел из поисковика на статью про wordpress и захотел бы почитать про систему еще больше – ему пришлось бы рыться в архивах, повторно использовать поиск либо просматривать все посты подряд. Разумеется, этого всего можно было избежать, зайдя в специальную категорию под названием wordpress. Или, например, для те, кто увлекается лишь дизайном, могла быть интересна рубрика для блога.
Если внимательно посмотрите на шапку блога, то можете увидеть своего рода меню, где рубрики wordpress выступают в роли разделов проекта. Как по мне, это достаточно удобный и наглядный способ разделения тематики записей.
В самом центре страницы вы увидите форму для добавления новой категории. Здесь нужно указать ее название (имя), ярлык (часть ссылки url для чпу), родительскую категорию (если такая есть), а также можно задать краткое описание. Родительская категорий позволяет создавать в wordpress разделы с несколькими уровнями вложенности – например, для категории «водрпресс» на каком-то ИТ блоге можно добавить те же шаблоны, плагины и т.п.
Справа на странице Рубрики отображаются все категории wordpress, с возможностью из редактирования либо удаления. Чтобы произвести действия достаточно подвести курсор мышки на имя той или иной категории, после чего увидите небольшое всплывающее меню.
При редактировании вы увидите в одном из информационных блоков тот, где можно будет выбрать одну или несколько категорий для статьи. Просто поставьте галочки напротив нужных имен.
Здесь же можно добавлять новые рубрики – кликнув по соответствующей ссылке. Единственный недостаток этого механизма в том, что при создании можно указать лишь имя и родительскую категорию, тогда для как задания поля ярлык придется переходить в раздел «Рубрики» и редактировать информацию там.
Кроме того редактировать категории для постов в блоге можно через их список в меню Записи – Изменить. Там при наведении на ту или иную публикацию вы увидите ссылку «Быстрое редактирование». Нажимаем по ней и видим форму для правки:
Здесь можно изменить и категории, и теги, и всю дополнительную информацию по статье. Вещь очень удобная + работает без перезагрузки страницы.
Функция wp_list_categories для категории wordpress
По традиции рассматриваю не только вопрос работы с теми или иными элементами системы, но и привожу специальные функции для шаблонов. Точно также как я рассказывал про . Итак, для вывода списка категорий со ссылками на них используется wp_list_categories . Она имеет целый ряд аргументов:
- show_option_all – отображает ссылка на все категории, если в качестве стиля отображения выбрал список.
- orderby – сортировка для категорий по ID, имени (name), ярлыку (slug), количеству постов (count).
- order – порядок сортировки (ASC – по увеличению, DESC – по уменьшению).
- show_last_updated – показывать дату последнего обновления.
- style – стиль оформления: список (list), разделение через
(none). - show_count – отображать количество постов в категории.
- hide_empty – скрывать пустые рубрики, где нет записей.
- use_desc_for_title – использовать описание для атрибута title в ссылке.
- child_of – вывод только категорий для заданной родительской рубрики.
- feed – отображение ссылку на фид для категорий.
- feed_type – тип фида.
- feed_image – картинка для значка rss.
- exclude – исключение категорий из списка, при этом параметр child_of автоматически отключается.
- exclude_tree – исключения целой ветки рубрик.
- include – обратный параметр, который включает только указанные категории wordpress в список.
- hierarchical – параметр для отображения подкатегорий.
- title_li – заголовок списка рубрик.
- number – количество категорий для отображения (если их слишком много).
- echo – выводит рубрики, по умолчанию равен True.
- depth – указывает количество уровней для подкатегорий для вывода.
Напоследок приведу ряд примеров использования wp_list_categories. Во-первых, вариант из шапки этого блога.
| "hide_empty=1&exclude=1&title_li=&orderby=count&order=desc&use_desc_for_title=0" ) ; ?> |
Здесь задано отображение скрытых категорий, исключение из списка рубрики с, пустая строка для заголовка блока, сортировка по количеству статей и по уменьшению (то есть больше всего статей у меня в разделе ). Последний аргумент не подставляет описание категории в title для ссылки.
Ну и еще парочку простых ситуаций. Использование исключений и включений категорий.
Если есть что дополнить про рубрики и категории wordpress, пишем в комментариях.
Update: Также вам может пригодится небольшой хак чтобы . В wordpress по умолчанию определяется текст title что-то вроде «просмотреть все записи в рубрике ….», можно вместо этого просто оставить название рубрики — читаем статью по ссылке выше.
Возвращает массив объектов содержащих информацию о категориях.
Параметры передаваемые этой функции очень похожи на параметры передаваемые функции wp_list_categories() и могут быть переданы как в виде массива, так и в виде строки запроса: type=post&order=DESC .
✈ 1 раз = 0.005625с = очень медленно | 50000 раз = 11.98с = медленно | PHP 7.1.11, WP 4.9.5
Использование
$categories = get_categories($args);Шаблон использования
$categories = get_categories(array("taxonomy" => "category", "type" => "post", "child_of" => 0, "parent" => "", "orderby" => "name", "order" => "ASC", "hide_empty" => 1, "hierarchical" => 1, "exclude" => "", "include" => "", "number" => 0, "pad_counts" => false, // полный список параметров смотрите в описании функции http://wp-kama.ru/function/get_terms)); if($categories){ foreach($categories as $cat){ // Данные в объекте $cat // $cat->term_id // $cat->name (Рубрика 1) // $cat->slug (rubrika-1) // $cat->term_group (0) // $cat->term_taxonomy_id (4) // $cat->taxonomy (category) // $cat->description (Текст описания) // $cat->parent (0) // $cat->count (14) // $cat->object_id (2743) // $cat->cat_ID (4) // $cat->category_count (14) // $cat->category_description (Текст описания) // $cat->cat_name (Рубрика 1) // $cat->category_nicename (rubrika-1) // $cat->category_parent (0) } } taxonomy(строка) Название таксономии, которую нужно обрабатывать. Добавлено с версии 3.0.По умолчанию: "category" type(строка)
- post - категории для постов (по умолчанию);
- link - разделы ссылок.
По умолчанию: "post"
По умолчанию: "" orderby(строка)
Сортировка полученных данных по определенным критериям. Например, по количеству постов в каждой категории или по названию категорий. Доступны следующие критерии:
- ID - сортировка по ID;
- name - сортировка по названию (по умолчанию);
- slug - сортировка по алт. имени (slug);
- count - по количеству записей в категории;
- term_group - по группе.
По умолчанию: "name"
Order(строка)
Направление сортировки, указанной в параметре "orderby":
- ASC - по порядку, от меньшего к большему (1, 2, 3; a, b, c);
- DESC - в обратном порядке, от большего к меньшему (3, 2, 1; c, b, a).
По умолчанию: "ASC"
Hide_empty(логический)
Получать или нет пустые категории (не имеющие записей):
- 1 (true) - не получать пустые,
- 0 (false) - получать пустые.
По умолчанию: true
Hierarchical(логический)
Если параметр установлен в true
, то в результат будут включены пустые дочерние категории, дочерние категории которых имеют записи (непустые).
По умолчанию: true
exclude(строка/массив)
Исключить какие-либо категории из списка. Нужно указывать ID категорий через запятую или в массиве. Если этот параметр указан, параметр child_of будет отменен.
По умолчанию: ""
include(строка/массив)
Вывести списком только указанные категории. Указывать нужно ID категорий через запятую или в массиве.
По умолчанию: ""
number(число)
Лимит. Число категорий, которые будут получены. По умолчанию без ограничений - будут получены все категории.
pad_counts(логический)
Если передать true, то число которое показывает количество записей в родительских категориях будет суммой своих записей и записей из дочерних категорий.
По умолчанию: false
Примеры
#1 Выпадающий список
Для того, чтобы создать выпадающий список из категорий мы можем воспользоваться другой специальной для этой цели, функцией wp_dropdown_categories() :
Wp_dropdown_categories(array("hide_empty" => 0, "name" => "category_parent", "orderby" => "name", "selected" => $category->parent, "hierarchical" => true, "show_option_none" => __("None")));
однако с таким подходом мы лишимся определенной гибкости в настройке списка, так как мы получи уже полностью сформированный список.
Поэтому, в некоторых случаях будет логичнее создать выпадающий список с помощью функции get_categories() . Вот пример (предполагается что нам нужно вывести подкатегории (дочерние) категории 10):
#2 Список категорий и их описание
Этот пример покажет нам как можно вывести списком ссылки на категории, где сразу после каждой ссылки будет идти описание категории (указывается при создании/редактировании категории):
"name", "order" => "ASC")); foreach($categories as $category){ echo "
"; echo "Description:". $category->description . "
"; echo "Post Count: ". $category->count . "
"; } ?>Заметки
- Смотрите: get_terms() Type of arguments that can be changed.
Список изменений
| С версии 2.1.0 | Введена. |
Код get categories : wp-includes/category.php WP 5.3.2
"category"); $args = wp_parse_args($args, $defaults); /** * Filters the taxonomy used to retrieve terms when calling get_categories(). * * @since 2.7.0 * * @param string $taxonomy Taxonomy to retrieve terms from. * @param array $args An array of arguments. See get_terms(). */ $args["taxonomy"] = apply_filters("get_categories_taxonomy", $args["taxonomy"], $args); // Back compat if (isset($args["type"]) && "link" == $args["type"]) { _deprecated_argument(__FUNCTION__, "3.0.0", sprintf(/* translators: 1: "type => link", 2: "taxonomy => link_category" */ __("%1$s is deprecated. Use %2$s instead."), "type => link",
"taxonomy => link_category"));
$args["taxonomy"] = "link_category";
}
$categories = get_terms($args);
if (is_wp_error($categories)) {
$categories = array();
} else {
$categories = (array) $categories;
foreach (array_keys($categories) as $k) {
_make_cat_compat($categories[ $k ]);
}
}
return $categories;
}
Я взялся за написание класса, реализующего изложенные в ней идеи.
А точнее, поскольку ключевой функционал уже использовался в рамках рабочего фремворка, я занялся выделением его в самостоятельный класс. Пользуясь случаем, хочу поблагодарить участников PHPClub-а за помощь в исправлении нескольких критических ошибок и полезные замечания. Ниже я постараюсь описать основные особенности, но сначала небольшой
дисклеймер
Есть несколько способов работы с SQL - можно использовать квери-билдер, можно ORM, можно работать с чистым SQL. Я избрал последний вариант, потому что мне он ближе. Я совсем не считаю первые два плохими. Просто лично мне всегда было тесно в их рамках. Но я ни в коем случае не утверждаю, что мой вариант лучше. Это просто ещё один вариант. Который можно использовать, в том числе, и при написании ORM-а. В любом случае, я считаю, что наличие безопасного способа работать с чистым SQL не может принести какой-либо вред. Но при этом, возможно, поможет последним оставшимся приверженцам использования mysql_* в коде приложения, отказаться, наконец, от этой порочной практики.
В двух словах, класс строится вокруг набора функций-хелперов, позволяющих выполнять большинство операций с БД в одну строку, обеспечивая при этом (в отличие от стандартных API) полную защиту от SQL инъекций, реализованную с помощью расширенного набора плейсхолдеров, защищающих любые типы данных, которые могут попадать запрос.
В основу класса положены три базовых принципа:
- 100% защита от SQL инъекций
- При этом защита очень удобная в применении, делающая код короче, а не длиннее
- Универсальность, портабельность и простота освоения
Безопасность
обеспечивается теми самыми двумя правилами, которые я сформулировал в статье:- Любые - без исключений! - динамические элементы попадают в запрос только через плейсхолдеры.
- Всё, что не получается подставить через плейсхолдеры - прогоняется сначала через белый список.
Поэтому, чтобы сделать защиту полной, пришлось отказаться от заведомо ограниченной концепции prepared statements в пользу более широкого понятия - плейсхолдеров. Причём плейсхолдеров типизованных (эта вещь всем нам известна по семейству функций printf(): %d - плейсхолдер, который подсказывает парсеру, как обрабатывать подставляемое значение, в данном случае - как целое число). Нововведение оказалось настолько удачным, что разом решило множество проблем и значительно упростило код. Подробнее о типизованных плейсхолдерах я напишу ниже.
Поддержка же фильтрации по белым спискам обеспечивается двумя функциями, несколько притянутыми за уши, но, тем не менее, необходимыми.
Удобство и краткость кода приложения
Здесь мне также здорово помогли типизованные плейсхолдеры, которые позволили сделать вызовы функций однострочными, передавая сразу и запрос, и данные для него. Плюс набор хелперов, напоминающих таковые в PEAR::DB - функций, сразу возвращающих результат нужного типа. Все хелперы организованы по одной и той же схеме: в функцию передаётся один обязательный параметр - запрос с плейсхолдерами, и сколько угодно опциональных параметров, количество и порядок которых должны совпадать с количеством и порядком расположения плейсхолдеров в запросе. У функций семейства Ind используется ещё один обязательный параметр - имя поля, по которому осуществляется индексация возвращаемого массива.Исходя из своего опыта, я пришёл к следующему набору возвращаемых значений (и, как следствие - хелперов):
- query() - возвращает mysqli resource. Может использоваться традиционно, с fetch() и т.д.
- getOne() - возвращает скаляр, первый элемент первой строки результата
- getRow() - одномерный массив, первую строку результата
- getCol() - одномерный массив скаляров - колонку таблицы
- getAll() - двумерный массив, индексированный числами по порядку
- getInd() - двумерный массив, индексированный значениями поля, указанного первым параметром
- getIndCol() - массив скаляров, индексированный полем из первого параметра. Незаменимо для составления словарей вида key => value
$data = $db->getAll("SELECT * FROM ?n WHERE mod=?s LIMIT ?i",$table,$mod,$limit);
В этом коде есть только необходимые и значащие элементы, но нет ничего лишнего и повторяющегося. Все потроха аккуратно упрятаны внутрь класса: хелпер getAll() позволяет получить сразу нужный результат без написания циклов в коде приложения, а типизованные плейсхолдеры позволяют безопасно добавлять в запрос динамические элементы любых типов без прописывания привязок (bind_param) вручную. Extra DRY код! В случаях использования плейсхолдеров?a и?u разница в количестве кода становится ещё больше:
$data = $db->getAll("SELECT * FROM table WHERE category IN (?a)",$ids);
Универсальность и простота освоения
стоят на трех китах:- Очень маленький API - пол-дюжины плейсхолдеров и столько же хелперов.
- Мы работаем со старым добрым SQL, который не надо заново учить.
- На первый взгляд незаметная, но невероятно полезная функция parse(), которая изначально предназначалась только для отладки, но в итоге выросла до ключевого элемента при составлении сложных запросов.
Приведу небольшой пример (примеры посложнее можно найти в документации по ссылке внизу статьи):
Довольно частый случай, когда нам надо добавить в запрос условие при наличии переменной
$sqlpart = "";
if (!empty($var)) {
$sqlpart = $db->parse(" AND field = ?s", $var);
}
$data = $db->getAll("SELECT * FROM table WHERE a=?i ?p", $id, $sqlpart);
Здесь важно отметить несколько моментов.
Во-первых поскольку мы не связаны родным API, никто не запрещает нам пропарсить не весь запрос целиком, а только его часть. Это оказывается супер-удобно для запросов, собирающихся в соответствии какой-либо логикой: мы парсим только часть запроса, а затем она подставляется в основной запрос через специальный «холостой» плейсхолдер, чтобы избежать повторного парсинга (и соблюсти правило «любые элементы подставляются только через плейсхолдер»).
Но, к сожалению, это является слабым местом всего класса. В отличие от всех остальных плейсхолдеров (которые, даже будучи использованы неверно, никогда не приведут к инъекции) некорректное использование плейсхолдера?p может к ней привести.
Однако защита от дурака сильно усложнила бы класс, но при этом все равно никак не защитила бы от тупой вставки переменной в строку запроса. Поэтому я решил оставить как есть. Но если вы знаете способ, как без слишком большого оверинжиниринга решить эту проблему - я был бы благодарен за идеи.
Тем не менее, в итоге мы получили мощный и лёгкий генератор запросов, который с лихвой оправдывает этот небольшой недостаток.
Мощный потому, что мы не ограничены синтаксисом квери-билдера, «SQL-ем, написанным на PHP» - мы пишем чистый SQL.
Лёгкий потому, что весь API составления запросов состоит из полудюжины плейсхолдеров и функции parse()
Вот мой любимый пример - вставка с использованием функций Mysql
$data = array("field"=>$value,"field2"=>$value);
$sql = "INSERT INTO table SET ts=unix_timestamp(), ip=inet_aton(?s),?u";
$db->query($sql, $ip, $data);
С одной стороны, мы сохраняем синтаксис SQL, с другой - делаем его безопасным, а с третьей - капитально сокращаем количество кода.
Подробнее о типизованных плейсхолдерах
Сначала ответим на вопрос, почему плейсхолдеры вообще?Это, в общем, уже общее место, но, тем не менее, повторюсь - любые динамические данные должны попадать в запрос только через плейсхолдеры по следующим причинам:
- самое главное - безопасность. Добавив переменную черз плейсхолдер, мы можем быть уверены в том, что она будет корректно отформатирована.
- локальность форматирования. Это не менее важный момент. Во-первых, данные форматируются непосредственно перед попаданием в запрос, и не затрагивают исходную переменную, которая потом может быть использована где-то ещё. Во-вторых, данные форматируются ровно там, где нужно, а не до начала работы скрипта, как при magic quotes, и не в десяти возможных местах кода несколькими разработчиками, каждый из которых может понадеяться на другого.
Тут я бы хотел ненадолго остановиться, и проследить историю развития программистской мысли в области защиты от инъекций.
Сначала был хаос - вообще никакой защиты, пихаем всё как есть.
Дальше стало не сильно лучше, с парадигмой «искейпим всё, что пришло в скрипт от пользователя» и кульминацией в виде magic quotes.
Дальше лучшие умы пришли к тому, что правильно говорить не об экранировании, а о форматировании. Поскольку форматирование не всегда сводится к одному искейпингу. Так в PDO появился метод quote(), который делал законченное форматирование строки - не только экранировал в ней спецсимволы, но и заключал её в кавычки, не надеясь на программиста. В итоге, даже если программист использовал эту функцию не на месте (например, для числа), то инъекция всё равно не проходила (а в случае с голым экранированием через mysql_real_escape_string она легко проходит, если мы поместили в запрос число, не заключая его в кавычки). Будучи же использованной для форматирования идентификатора, эта функция приводила к ошибке на этапе разработки, что подсказывало автору кода о том, что он немножечко неправ.
К сожалению, на этом авторы PDO и остановились, поскольку в головах разработчиков до сих пор крепко сидит мысль о том, что форматировать в запросе надо только строки. Но на самом деле в запросе гораздо больше элементов самых различных типов. И для каждого нужен свой собственный тип форматирования! То есть, единственный метод quote() нас никак не устроит - нужно много разных quotes. Причём не в качестве исключения, «нате вам quoteName()», а как одна из главных концепций: каждому типу - свой формат. Ну а раз типов форматирования оказывается много - тип надо как-то указывать. И типизованный плейсхолдер для этого подходит лучше всего.
Кроме того, типизованный плейсхолдер - это ОЧЕНЬ удобно!
Во-первых, потому что становится ненужным специальный оператор для привязки значения к плейсхолдеру (но при этом сохраняется возможность указать тип передаваемого значения!)
Во-вторых, раз уж мы изобрели типизованный плейсхолдер - мы можем налепить этих плейсхолдеров огромное количество, для решения множества рутинных задач по составлению SQL запросов.
В первую очередь сделаем плейсхолдер для идентификаторов - нам его отчаянно не хватает в реальной, а не воображаемой авторами стандартных API, жизни. Как только девелопер сталкивается с необходимостью динамически добавить в запрос имя поля - каждый начинает извращаться по-своему, кто в лес, кто по дрова. Здесь же всё унифицировано с остальными элементами запроса, и добавление идентификатора становится не сложнее добавления строки. Но при этом идентификатор форматируется не как строка, а в соответствии со своими собственными правилами - заключается в обратные кавычки, а внутри эти кавычки экранируются удвоением.
Дальше - больше. Следующая головная боль любого разработчика, когда-либо пытавшегося использовать стандартные prepared statements в реальной жизни - оператор IN(). Вуаля, у нас есть плейсхолдер и для этой операции! Подстановка массива становится не сложнее любых других элементов, плюс она унифицирована
с ними - никаких отдельных функций, меняется всего лишь буква в плейсхолдере.
Точно таким же образом делаем и плейсхолдер для SET. Не удержусь и продемонстрирую, насколько простым становится код для такого замороченного запроса, как INSERT… ON DUPLICATE:
$data = array("offers_in" => $in, "offers_out" => $out);
$sql = "INSERT INTO stats SET pid=?i,dt=CURDATE(),?u ON DUPLICATE KEY UPDATE ?u";
$db->query($sql,$pid,$data,$data);
В данный момент классом поддерживается 6 типов плейсхолдеров
- ?s («string») - строки (а также DATE, FLOAT и DECIMAL).
- ?i («integer») - целые числа.
- ?n («name») - имена полей и таблиц
- ?p («parsed») - для вставки уже обработанных частей запроса
- ?a («array») - набор значений для IN (строка вида "a","b","c")
- ?u («update») - набор значений для SET (строка вида `field`="value",`field`="value")
Автоматическую трансляцию PHP-шного NULL в SQL-евский NULL я решил не делать. Возможно, это чуть усложнит код (в тех редких случаях, когда это нужно), но зато уменьшит его неоднозначность.
Кстати, как многие могли заметить, этот класс во многом напоминает библиотеку DbSimple Дмитрия Котерова. Но у меня есть принципиальные расхождения с некоторыми идеями, заложенными в неё.
Во-первых, я противник любой магии, когда одна и та же функция может возвращать различный результат в зависимости от типа переданных данных. Это, возможно, чуть упрощает написание, но при этом чудовищно затрудняет сопровождение и отладку кода. Поэтому в моем классе вся магия сведена к минимуму, а все операции и типы данных всегда прописываются явно.
Во-вторых, в DbSimple немного, на мой взгляд, переусложнённый синтаксис. С одной стороны, фигурные скобки - гениальная идея. С другой - а зачем, если в нашем распоряжении вся мощь PHP? Поэтому я решил пойти другим путём и весто «внутренней» - заведомо ограниченной - логики ввёл «внешнюю», ограниченную лишь синтаксисом РНР. Главное, чтобы любые динамические элементы попадали в запрос только через плейсхолдеры, а остальное зависит лишь от фантазии разработчика (и функции parse()).
Код класса доступен на Гитхабе, github.com/colshrapnel/safemysql/blob/master/safemysql.class.php
Cheat sheet с основными командами и примерами: phpfaq.ru/misc/safemysql_cheatsheet_ru.pdf
Хорошее представление о возможностях можно получить на странице примеров документации (к сожалению, ещё не законченной), phpfaq.ru/safemysql
Там же есть ответы на часто задаваемые вопросы, такие как «почему ты не используешь родные prepared statements?» и пр.
Тем не менее, буду рад ответить на любые вопросы в комментариях, а так же улучшить по вашим замечаниям как сам класс, так и эту статью.