Используйте компонентный подход. Многие фреймворки официально позволяют выборочно использовать свои библиотеки, например тот же Symfony. Использовать только какой-то определенный фреймворк - это сильно себя ограничивать. Так поступают только новички или адепты, у которых на все одно решение.
Совсем уж "зоопарк" тоже устраивать не нужно, а то "натянете" много лишнего и "конфликтного".
PHP-фреймворк для фронтэнда? 😊
В CMS (в смысле в панелях управления содержимым, в административных панелях) сейчас многое делается "на фронте". В головной части тоже, если нет цели придерживаться какой-то совместимости. Можно даже двойственное поведение реализовать для поддержания совместимости.
Конечно, мы все примерно понимаем, о чем вы пишете, но все-таки вы слишком вольно используете термины.
CMS создаются с использованием фреймворков. Фреймворки бывают "самописные".
Не суть. Можно и так, если это проще реализовать. Хотя я писал о специальных "категориях", так что можно и так: /category/krasnye-sloniki. А если магазин поддерживает теги, то и никакие специальные "категории" не нужно выдумывать: /tag/krasnye-sloniki. Причем вовсе не обязательно использовать типичную теговую реализацию для таких случаев. Можно опять-таки внедрить в теги обычный фильтр для получения части результатов.
В общем же отдельные результаты фильтрации можно открывать для индексации, что по моим критериям позволяет использовать просто /krasnye-sloniki 😉
Ничто этому не мешает. Я писал о специальных "категориях", которые совпадают лишь с некоторыми результатами фильтрации. По сути это такие же результаты обычного фильтра, только немного "причесанные" (с простыми адресами, заголовками страниц и т.п.). Результаты, не имеющие специальных "категорий", будут выводиться в обычном виде (с более сложными адресами, заголовками страниц и т.п.).
Думаю, пользователь будет чувствовать себя увереннее, работая со ссылкой с адресом /krasnye-sloniki вместо /filter/page?category=slon&color=red и т.п. 😉
