Максим Тимофеев

форма заявки на Yii

так не бывает. Yii не язык программирования, не язык разметки - это php framework. Так что форма видимо на html + возможно к ней есть css и js. Но точно не на yii. Это как сказать: "у меня компьютер сделан из китайцев."
Приведу аналогию:
Вы взяли гвоздь из синей коробочки и пытаетесь прибить его к стене. Не получается (хз миллион причин), но вы вместо того, что бы описывать реальные проблемы (ошибки в консоле например), говорите что он из синей коробочки. Не Важно из какой он коробочки, важно что это гвоздь, важны материалы, характер проблем и т.д.
В yii есть хелперы, которые строят формы. Но формы в итоге состоят из html+css+js, wp тоже так делает. Да и все, что написано на php по сути преследует цель сгенерить html+css+js и отдать бразеру, который на базе html сформирует разметку, на базе css стилизует ее и исполнит программы из js. Не важно что там на сервере и как, в итоге получаем html+css+js и не имеет значения из какой коробочки его достали. Соответственно и ошибки надо искать в браузере, который работает с этим итоговым html+css+js.

Собственно вопрос, как сделать такую интеграцию?

общая база данных, проще и оптимально, если не планируете обновлять cms или уверенны, что структура базы не изменится. Иначе api.

Возможно уже существуют какие-либо готовые решения либо вообще нет смысла тянуть сюда Yii2 и лучше дорабатывать функционал магазина?

возможно, кто ж знает что Вы делать планируете. "систему для обработки заказов" - это ни о чем. Гугол вариантов.

Хотелось бы узнать мнения специалистов на этот счёт.

На какой счет? Как определить инструмент для разработки не имея ТЗ? Специалисты так не делают. Хотя бы бриф. Нельзя выбрать framework для "что-то про crm"

Поисковики для разных тематик имеют разные алгоритмы ранжирования, в том числе они понимают, что характеристики товара и подобная тех документация не может быть уникальной. Тем более что Ваши конкуренты в том же положении.
Однако тут не стоит забывать что есть rel=canonical и если у Вас на сайте дубли типа товар 1, а модификаций 100, то неплохо было бы сделать 1 вариант каноническим.

Есть сайт с огромным каталогом товаров.

огромный это когда несколько миллионов, у Вас крошечный.

Движек не справляется, нагрузка на базу очень большая

оптимизировать надо - "40000 товаров и 300 категорий" это вообще не о чем. Тут еще надо бы указать количество посетителей сайта. Так как нагрузка именно от них в большей части зависит, чем от размера базы.

В общем думаю разделить сайт на несколько на поддоменах с одним дизайном, но разными товарами и каталогами.

Это лечение головной боли гильотиной

стоит ли вообще или пытаться что-то оптимизировать.

конечно стоит, но оптимизация сайта и разделение его на несколько - это совершенно разные вещи. Какой движок?

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

Какими должен владеть знаниями верстальщик?

как минимум: html и css на достаточно хорошем уровне + хотя бы минимально js и/или jquery
Тут еще куча не обязательных для новичка, но желательных для плодотворной работы знаний: спрайты, svg, framework-и, media запросы, flex, понимание как работает динамический web сайт в целом, какие бывают cms и еще два вагончика технологий
Сюда же опыт работы с разными js плагинами можно добавить. Это приходит с опытом, Вы обрастете кучей знаний api разных слайдеров (типа slick, owl и т.д.), разных построителей графиков, библиотек для работы с canvas и svg (типа konvajs, threejs и т.д.), всяких select2 и т.д. Но все это не сразу, постепенно. Но чем больше опыт, тем быстрее Вы будете работать, тем меньше велосипедов делать и тем дороже стоить.

Какие нужны инструменты для быстрой вёрстки?

framework-и, сборщики, препроцессоры, нормальное IDE

Скажите, пожалуйста, подробный алгоритм вёрстки, чтобы страница правильно работала в браузере?

Что бы страница правильно работала, надо ее правильно и кроссбраузерно сверстать. Какой тут может быть "алгоритм"?

1. отслеживать скрол, проверять offset, примеров в сети куча
2. запускать вначале случайные цифры, а после n итераций запускать Ваш таймер с нужными датами

работа с расширением экрана может идти в браузере, сервер не знает какое там расширение. Поэтому придумали медиазапросы в css:

.someMydiv {display: none;} //обычно не виден
@media (min-width: 999px) and (max-width: 1001px) {
.someMydiv {display: block;} //виден при ширине экрана от 999 до 1001 px
}

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

тогда формировать блок через js. Есть массив товаров в json, есть шаблон формирования, после загрузке страницы формируем нужное. Но если покажите шаблоны, которые верстаете, возможно подскажем более адекватный подход.

foreach (chastrechiRUS($tred['text']) as $key => $value) {
       $tt= "['$key' => $value,'у' => 1];"; //тут вы создали строку, Вы же понимаете. что это строка будет, а не массив
}
echo $tt; //тут вы вывели последнюю интеграцию цикла, так как при каждом проходе цикла, вы перезаписывали содержимое $tt новой строкой и осталось там последнее

$maps должен выглядеть так $maps=['ч' => 0, 'л' => 9, 'в' => 1, 'к' => 8, 'е' => 5, 'о' => 2];

совершенно не понятно с чего вдруг он должен там выглядеть. Переменные $res и $words из воздуха появились. Такое ощущение, что это не только плохой код, но еще и не целый, а произвольные куски.

Как только почтовик попал в интернет - спам обеспечен.
Что же делать?
Формируем список email, которые нужны. Заводим новый ящик, сообщаем им рассылкой, что заведен новый ящик. Новый ящик не используем для регистраций и не вставляем в формы на сайтах.
При таком подходе спама будет не много и можно будет обучать спам фильтр. Иначе не один фильтр не поможет.

Есть расширение для этого и есть доки к нему:
https://github.com/yiisoft/yii2-sphinx/blob/master...

Чем вы пользуетесь для организации знаний?

мозгом
А для организации информации есть googleDocs, пробовал другое ПО. Не удобно. А главное докс везде под рукой. Менеджеры закладок в браузерах - вообще мрак, корявее убитых встроенных. Всякие блокноты - тоже кучу перебрал. Все равно возвращаюсь к тому, что в докс удобнее.
lukoie упомянул CintaNotes, я не юзал, но по его описаниям может быть архи удобен для закладок

сайт с 50k+ посетителей в день и достаточно необычным для cms функционалом вряд ли юзает готовую cms. Наверняка писали под себя на каком-то framework.

а каждое право доступа есть своя ячейка,

выносите в отдельную таблицу, а не ячейки плодите.

Вот здравая и гибкая структура таблиц для RBAC


В ростом выражении как у вас сейчас, только в две таблицы, это будет
table1: id | username | ...
table2: user_id | rule_name

Кэшировать права, если их много конечно можно, но лучше не использовать сессию для этого. Сессия просто имеет id пользователя, а права могут рядом лежать в кеше, так что при смене прав, просто сбрасывается кеш, а не авторизация пользователя. Но так как у Вас 1 таблица - то большой вопрос, а быстрее ли кеш, возможно тут запрос в бд будет быстрее (выборка прав по id). Это когда сложные запросы из-за многих таблиц, тогда есть смысл, а так не вижу.