Александр Регидов: да, мысль вашу я ловлю. Но, ИМХО, если в стране есть банк-пионер (см. мой ответ на другой ваш коммент), то практически все, кому нужны продвинутые сервисы в ИБ, уже там. А те, кто не там - это клиенты, которым как правило такие плюшки не нужны.
Сергей Сергеев: ну вот я том же. Если это будет "все в одном" - PayPal, процессинг/биллинг для разрабов, оплата всевозможных услуг локально (от коммуналки до покупки билетов куда угодно), интеграция электронных кошельков, прием-отправка SWIFT и прочее, прочее, прочее - возможно я и посмотрю в эту сторону. Иначе - мне моего ИБ более чем достаточно, он у меня навороченный и функциональный.
kolovsky_alexander: Тогда может не Yii2 а Laravel? Если уж чистый фреймворк, то ларочка вне конкуренции для современных вебапов. По поводу допиливания - на фреймворке придется пилить заметно больше. Но и гибкость больше. Также нужно учесть еще 3 момента.
Первый - для того, чтобы запилить аналог того же WooCommerce на голом фреймворке (пусть даже и с готовыми либами), опыта чистого программинга должно быть предостаточно. Простой книжки на русском языке не хватит. Даже если в ней 1000 страниц и их все внимательно прочитать. Тут другой уровень нужен. Я уже молчу про весь LMS полностью.
Второй - WP и топовые популярные компоненты для него хорошо отлаженыы и оттестированы. Вы уверены что потянете такой же уровень? Одних только юнит тестов придется наколбасить столько, что мама не горюй.
Третий - дальнейшее сопровождение, апдейты, дополнения и расширения. Под WP если вдруг захотелось чего-то добавить - не вопрос. Нашли, скачали, установили. Не подошло что-то - залезли в код и переписали под себя. Open Source же. Тот же WooCommerce и другие крупные компоненты поддерживают и развивают другие люди, вы всего лишь качаете одним кликом обновления. А со своей системой на фреймворке - все ручками. Все самостоятельно.
Я бы сказал так - если есть от $10к и хотя бы 2-3 разраба в команде (плюс дизайнер наверное), то имеет смысл писать на фреймворке с нуля. Если одного из условий нет - берите WP.
80689248440: так я же выше скинул ссылку на stackoverflow, там именно прямым текстом написано как спровоцировать 404 именно через wp :)
На уровне htaccess тоже можно, по крайней мере часть проблемы закрыть. Но я по Nginx больше, так что не подскажу. Есть вот такое обсуждение, там про статику, но может что-то полезное есть:
Для отлова всех ситуаций как раз и пригодится Query Monitor + Rewrite Rule Inspector. Иначе я бы их не советовал) Это вообще 2 базовых инструмента, без которых разработка под WP не обходится.
Oleg: mysql_query вообще-то возвращает только resource. Последующие операции с ним идут без повторного запроса к бд. Если resource не используется, его отлавливает garbage collector и выпиливает из памяти. В данном случае я не совсем корректно написал выше. Если писать код правильно, то повторных запросов не будет, для этого все и делается. Если же макаронами отправлять запрос за запросом и без сохранения/использования ресурса, то runtime кеширование конечно будет - никуда не денется, но использоваться оно не будет, так как каждый запрос будет возвращать новый resource id. Установка лимита в запросе дополнительно помогла устранить возможность кеширования на уровне бд. Чтение всех ответов и комментов заварило немного кашу в голове)
Дмитрий Соломакин: куча сторонних сервисов, админок, логинов и счетов. Бесплатные версии совсем базовые, придется за часть сервисов платить. Часть заточены под конкретные паттерны, поменять не получится. Вы про бритву оккама слышали? Я не утверждаю, что такой подход не имеет права на жизнь, но судя по всему, автору нужно гибкое решение, под своим брендом (white label), с возможностью расширения. В этом случае выход только один - делать свое.
80689248440: позвольте, для начала спросить, а зачем это надо? Чисто из принципа? Эти несуществующие урлы нигде не светятся, в индекс не попадают. Устранять это нет острой необходимости.
Если зайти просто на страницу, например about, то WordPress будет искать 2 переменные:
Matched Query:
pagename=about
&page=
Поэтому цифры после названия страницы распознаются и принимаются - такая регулярка стоит в rewrite_rule. Потому что контент страницы можно разбить на несколько подстраниц. Ну а другие символы регулярку не проходят, поэтому получается 404. Контент не меняется, потому что страница все же одна. Если надо отрезать цирфы - по упомянутому мною выше способу проверяете ответ из БД, если там аргумент paged будет false - делайте редирект на уровень выше, избавляясь от цифр.
С категориями и другими таксономиями чуть сложней, но принцип тот же.
Установите себе плагин Query Monitor, поможет понять что происходит внутри. А также Rewrite Rule Inspector, в нем можно прямо повводить разные урлы и посмотреть, какое правило подхватывается, какие дальше по списку стоят (WP использует первое из списка которое удовлетворило запрос). Это все поможет отловить конкретные ситуации/условия, в которых нужно добавить 404, а как это сделать - см. через один ответ выше.
squirtazzer: поищите в папке с темой файл home.php или font-page.php. Если их нет - надо смотреть index.php, там скорее всего стоит динамическая выборка на уровне их фреймворка. Методом тыка можно определить безопасное место и в него вставить:
Oleg: при чем тут кеширование кода, я про opcache не говорил нигде. PHP кеширует результат конкретного запроса для последующей работы с ним в рамках текущего цикла выполнения (runtime). Дальше по строкам этого запроса он гуляет без обращения к БД, что вполне нормально, и если через пару строк кода нужен именно тот же запрос - будет использоваться он из runtime кеша (по сути - из переменной в памяти). Если запрос, как у автора, идентичен и повторяется раз за разом - да, это именно тот use case, но автор вопроса уже давно себя поправил и добавил изменяющийся лимит, чтобы запросы были уникальными.
80689248440: правильно, потому что там контент не найден, но подключен то по иерархии шаблон page.php, и берется контент с самого первого найденного фрагмента (остальные - это параметры, а параметры лишь модифицируют контент текущей страницы). Почитайте что ли про rewrite rules в WP. Про ЧПУ в целом, что это такое и как им пользоваться. Вам или какой-то странный роутинг урлов нужен, либо вы концепцию в целом не понимаете. Я потому и попросил вас выше написать кейс, для которого это нужно, так мне легче будет подсказать.
Максим Степанов: уже ближе, но уточню еще. Есть пост типа custom post type, например, product. К нему нужны отзывы покупателей (это могут быть отдельно отзывы или реализованы через обычные комменты), отзывы не являются уникальными (один пользователь может оставить несколько отзывов к одному и тому же продукту). Сам отзыв должен содержать определенныцй набор полей, среди которых - несколько оценочных (рейтингов). Правильно? Суммирование и вывод оценок - это уже отдельная кухня, там ничего необычного.
В папке темы должен быть файл 404.php. Если в .htaccess прописать:
ErrorDocument 404 /index.php?error=404
то сервер будет сам отправлять куда надо. Это раз. Два - можно использовать условие is_404() и редиректить куда угодно (хоть на статическую страницу ошибки), включать заголовки, грузить нужные темплейты. Подробнее тут:
Смысл в том, что на ранний action (который подходит для конкретной ситуации) хукается функция, которая отлавливает ошибку и дальше - делает что надо. Этим путем можно отслеживать все что угодно, и делать тоже все, что захочется. Важно понимать иерархию темплейтов а также WordPress Page Lifecycle. Например, в ссылке вверху, к моменту экшна template_redirect WP уже отпарсил урл, сгонял запрос в БД и содержит объект со всеми данными. Его можно в этом месте разобрать, посмотреть что там есть, чего нет, и соответственно, выдать нужные заголовки и подключить нужный шаблон.
Максим Степанов: платный плагин - тоже выход. Посчитайте, сколько времени он сэкономит и умножьте на свой рейт. Выйдет, что на общение на Тостере вы потратили больше, чем этот плагин стоит :)
По сути - я правильно понимаю, что должны быть отдельно комментарии, отдельно отзывы? Рейтинг отзывов - это рейтинг в отзыве (рейтинг выставляем посту), или рейтинг самого отзыва (то есть, можно оценивать отзыв)? Суммирование - самое простое здесь.
Да, иногда еще слайдер может быть виджетом. То есть, у вас в шаблоне в шапке на главной должен быть widget area (он же сайдбар), в который вы и включите нужный виджет.
squirtazzer: как правило плагины позволяют создать и настроить слайдер в админке, а потом либо автоматом его паяют, либо предоставляют шорткод (shortcode) и/или template tag. Шорткоды ставятся в контент страниц/постов, или выводятся в шаблон с помощью функции do_shortcode(). Template tags прописываются непосредственно в шаблон в нужном месте.
