Михаил

по коду похожи на самописцы

не обязательно обращаться к конкретному файлу, можно обратиться к любому url, прописав правила переадресации. Или можно даже на главную страницу обратиться "/" а на ней сделать обработку аякс запросов

если обращение напрямую к файлу, то параметр надо засунуть в скрытый input type=hidden
есть еще пару вариантов аякса:
1. обратиться к тойже странице где установлен компонент
2. если 1-й вариант не подходит(например на странице вызываются несколько компонентов, и построить структуру обработки запросов сложно), можно все аяксы пускать на один файл (я обычно кидаю его в /include/ajax.php) и в нем исходя из запроса вызывать необходимый компонент, так можно обрабатывать запрос на уровня ядра компонента, очень удобно если обработка аякса почти идентична обработки самого компонента.

проблема похожа на хреновый HDD, т.е. диск D
возможно браузер хранит кэш именно там, т.к. C маленький
с открытым диспетчером потыкай сайты, и смотри нагрузку при подвисаниях, в любом случае будет на чем то скачок.

особо вчитываться в код не стал, просто скажу методы:
1. выставить в тегах полей required, на стороне браузера форма не будет отправлена пока не будут заполнены все поля с этим параметром. форма должна отправляться через submit а не кликом по кнопке.
2. проверять js'ом .lenght>0 каждое поле, если lenght=0 вывести текст ошибки предварительно создав пустой тег(блок) под ошибку
3. можно проверить на стороне бэка и отдать в ответе ошибку, в ajax succes проверять ответ на ошибку или ее отсутствие и как в методе 2 выводить в пустой блок

а что если объединить эти функции?
при нажатии, проверка if keyCode == 48 потом проверка на количество введенных или lenght и если это 5й символ то return false или preventDefault

Если код имеет не стандартные решения, и в будущем планируете с него каким-либо способом получать прибыль, т.е. он часть бизнес-процесса, то не рекомендую при любых условиях, даже юридически оформленным, предоставлять полные доступы к исходникам.
у вас должна быть собственная "политика безопасности", (она может быть как прописана на бумаге, так и просто быть в голове), при которой вы должны понимать риски при определенных утечек информации, так вам будет проще понять, к чему именно, кого, при каких условиях можно допустить.

Если же код просто есть и с него нет прибыли и не планируется, то можно либо продать его, либо открыть доступ для развития сообществом заинтересованных. В таком случае он возможно будет использован где угодно, за что вам скажут спасибо, но при грамотном оформлении сообщества разработчиков ваш код будет быстро развиваться и возможно, каким-то образом принесет в дальнейшем прибыль. Главное удовольствие обеспечено будет точно.

Работал когда то с ВП
из плюсов:
быстро и удобно создавать шаблоны и плагины
легкая админка, ТОЛЬКО если не нагружена функционалом
из минусов:
Подходит только для простых решений
если проект более-менее серьезный, админка нагружается кучей плагинов, что приводит в непонимание со стороны клиента
Много дырок, которые залатывать замучаешься
Не все проекты можно сделать, т.к. некоторые по разработке индивидуального функционала не окупаются и становятся бессмысленными
очень дешево ценится в плане заказов, на ВП на жизнь не заработаешь, только на существование)

Друпал и Джумла: когда то были не плохие cms, когда еще не было нормальных готовых решений. Сегодня по своей структуре это запутанные и очень неудобные платформы, на которых не легко разрабатывать серьезные проекты. За бугром они очень ценятся и используются многими иностранными гос структурами, но если посмотреть на сами сайты, то видно не вооруженным глазом - "прошлый век разработок".

Если развиваться в качестве разработчика, рекомендую смотреть в сторону современных framework'ов (например laravel, Yii2) или Битрикс (Лично я ушел в это направление, о чем ни капли не жалею)
Главный плюс в фреймворках, на них можно создавать что угодно, при этом быстрее, чем внедрять в какую-либо cms, не имеющую в базе фреймворк.
Очень ценятся профильные разработчики, зарплаты выше среднестатистических в n раз
Минус перехода - нужно время на изучение и получение практического опыта (набивание шишок), очень трудно получить даже простенькие заказы на первый период, пока не будет хотя бы портфолио.

это еще цветочки, у меня такой момент был:
звонил по аренде квартиры, после чего мне несколько дней звонят рекламщики и предлагают приобрести квартиру, один из рекламщиков объяснил, что провайдер по ключевым словам передает информацию им, с именем и зашифрованным номером, т.е. они видят имя, тематика интереса и кнопка позвонить, сам номер они не знают, это как мне объяснили, но на мою просьбу удалить из базы, они согласились, отметив у себя, что не интересуюсь.

Получается ты верстаешь чуть ли не под каждую модель телефона и монитора. Зачем?
верстка делается под варианты: смартфоны, планшеты, мониторы, fullscreen. Делаешь контейнер, который будет иметь одинаковые размеры, например если у тебя экран 1000 или 1200, сам контейнер всегда 960 (просто грубый пример) а по краям отступы, т.е. берется размеры "от и до" и делается контейнер по минимальному размеру данного диапазона

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

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

1) на счет amoCRM не подскажу, но в Б24, то что писать кучу всего своего и "от базового продукта в лучшем случае останется половина" это не верное представление, хотя многие приходят к этому мнению. вам понадобиться разработчик, которые знает как использовать базовый функционал для достижения необходимых целей.
2) к мнению писать собственную CRM приходят многие, но в итоге это получается лишняя трата времени и денег.

теперь опишу разницу:
используя Б24 есть возможность использовать тот, функционал, который уже есть, если он соответствует требованиям. При этом функционал постоянно развивается. Помимо этого, делая самописец, некоторые функции придется писать месяцы, хотя на написание тех же функций в Б24 может уйти всего пару дней, т.к. в ядре заложено все необходимое, для сбора своей логической структуры.
Из опыта: заказчик попросил взять на развитие самописец (тоже CRM). С учетом больших планов на развитие, в которых я видел минимум полжизни написания кода, я предложил взять, готовое решение, на что был ответ "мы уже пробовали, у нас другая логика работы". Вообщем история развивалась долго, но в итоге оказалось, что достаточно было написать один модуль в Б24 и правильно настроить все остальное, и весь необходимый функционал теперь есть с необходимой логикой работы.

занижает конверсию просмотра в связи с привыканием пользователей к более простому и стандартному решению