Nick Murzin

А причем тут Laravel?

Что такое brand_name и model_name? Они есть в БД? От куда они берутся?
Если они есть в БД, то в чем проблема доставать данные по model_name например? Чем это отличается от получения данных по ID?

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

А на стороне сервера прирутить кеширование:
1. Запросов к БД (memcached например)
2. Запросов к API, там где не критично каждый раз получать самые новые данные. Например используете видео с Vimeo, а также его данные о кличестве просмотров. Чем дергать каждый раз эти данные закешируйте их на час.

На ленту вопросов отдельного тега можно подписаться по ссылке https://toster.ru/rss/tag_questions/###, где решётки - id тега (напр. про Google).

Symfony Validator https://github.com/symfony/validator

Пока не смог найти условий, которые бы он не смог проверить :) Но нужно учесть, что это не столько валидатор форм, сколько валидатор объектов.

Тут 2 варианта:

1. Заказывают верстку, подразумевают создание шаблона/темы для CMS. По хитрости, по не знанию, по глупости - не важно. Важно не подписаться пилить это по цене только верстки.

Верстка - это когда макет превращается в набор html/css/js файлов.

Да, могут быть вариации. Может быть сразу под движок: Smarty, Twig, Jade, или все шаблоны в Handlebars, или сразу чтобы всё под Angular было. Но это всё частные случаи, требующие более высокой квалификации, или находящиеся уже где-то во front-end разработке.

2. Просят учесть особенности CMS.

Маленьких нюансов может быть много.

Вот Битрикс, например, и его Эрмитаж (тыкнул в блок - тут же его отредактировал если по простому). Где-то лишняя обертка элемента, чтобы в режиме редактирования не разваливалось. Везде - z-index меньше 1000, чтобы Эрмитаж не перекрывало.

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

Если я верстал и без проблем натягивал свои макеты на Wordpress - могу ли сказать что у меня есть опыт верстки под Wordpress?

Могу.
Так же как могу сказать что есть опыт верстки под Drupal (не знаю натягивали ли какие-то из моих работ на Drupal, но чё бы нет).

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

.nav
    .nav__list
        .nav__item

Когда ему движок выдаст меню в виде

.menu
    ul
        li

Но я не считаю это своей проблемой.
Когда понадобилось, оказалось нет ничего сложного 1 раз потратить время и написать свой вывод меню в Wordpress, чтобы можно было любую верстку натянуть. Почему так не может сделать тот кто натягивает? Почему в ТЗ об этом не предупредили?

Уменьшает ли "опыт верстки под CMS" время верстки?
Если не были оговорены нюансы (те же меню WP) - то нет.
Может увеличиться время натягивания верстки на движок, но это уже проблемы заказчика, который не озвучил требования заранее.

Таким образом, хотя в идеале на движок должно быть возможным натянуть любую верстку, действительно некоторые имеют CMS особенности.
Об этих особенностях следует договариваться заранее. Должно быть конкретное ТЗ на верстку.
В остальном как правило речь об "опыте верстки под %CMS%" - просто болтовня.

реддит.

WPML проверен временем. Очень удобный плагин. Советую...

Я использую WPML с выводом языков в поддомены. Типа ru.site.com для русского и site.com для англ. Удобно.

https://github.com/nikic/FastRoute

Самыми быстрыми и максимально простыми считаются микрофреймворки, которые берут начало от рубишной синатры (www.sinatrarb.com/). Они практически не отличаются друг от друга, знаете один знаете все другие на всех других языках). В php популярны два www.slimframework.com и lumen.laravel.com/.

Как минимум с них стоит начинать изучение если вы до этого с фреймворками не работали.

psliwa - хорошая, пользую достаточно часто.
tinypng - нормальный вариант для блогов, с не сильно большим количеством фотографий, для больших фоток тоже норма но уже надо костыль, надо получать много Api ключей, и ставить счетчик, после каждых 500 картинок в месяц подставлять другой ключ
kraken - не супер вариант, но там в платном варианте идет уже счет за вес картинок, а не количество 9$ за 2 гига не много, но результат у него не супер, часто для нормальной минимизации требуется по 2 - 3 прогона картинки

вы нагуглили то что нужно.

Еще есть частично бесплатная API у tinyjpg.com: https://tinypng.com/developers
500 картинок в месяц, но нужно быть осторожным с png с прозрачностью.

Для написания кода в нашей команде все использую Vim (хоть и на PHP проектов уже нет, но когда были — тоже использовался исключительно Vim). Наш техдиректор Кирилл Мокевнин рассказывал про свой любимый редактор в одном из вебинаров.

Ну и Vagrant + Docker (как для локальной разработки, так и для прода и самого процесса деплоя).