N

Звучит как ларавель + рбак + что-то типа вояджера. По описанию в 10 строчек звучит как распространенная задача, на деле ВСЕГДА всплывает миллион нюансов и "мы думали это само собой разумеется", по этому 99,9% что подходящего готового решения "искаропки" под ваши хотелки нет.

Сокеты невозможно сериализовать. Придумай другую термиологию или другую идею.

Возможно ты хотел что-то другое?

"Run you fools!" (c)
Единственная причина связываться с Битриксом - это вендор-лок на его систему.
То, что они потроха своего чудовищного продукта называют модным словом "фреймворк" - это маркетинг и... только маркетинг.
Если вы готовы работать с фреймворком - берите фреймворк. Настоящий, нормальный фреймворк, как Симфония или Ларавель. А на копролит Битрикса даже не оглядывайтесь.

Трата времени на анализ и уточнение ТЗ это необходимые шаги для выполнения задачи. То есть, это время, потраченное на задачу. Это время должно быть оплачено.

на клиентской машине:
ssh-keygen -t rsa

sh-copy-id -i ~/.ssh/id_rsa.pub ИМЯ_ПОЛЬЗОВАТЕЛЯ@АДРЕС_СЕРВЕРА

радуемся жизни.

Делайте новый проект. Как раз с учетом ошибок предыдущего.

Самый лучший способ это Event Storming! Это как раз будет связующее звено для понимания и вами и программистами. Конечно, лучше найти такого специалиста - Архитектора.

По сути техника Event Storming — это воркшоп с простой структурой, на котором эксперты по предметной области и разработчики совместно исследуют эту самую предметную область. По мере исследования участники раскрывают всё больше неопределенности и скрытой сложности, сверяют предположения с реальностью и снижают влияние предположений на качество продукта.

Event Storming применяется в исследованиях клиентского опыта, проектировании новых сервисов, получении знаний о работе legacy-систем, моделировании сложных предметных областей и проектировании микросервисной или событийной архитектуры.

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

Из своего опыта могу сказать, что ни раз даже помогало увидеть полную картину своего бизнеса. Сразу вырисовывается организационная структура, разграничение ответсвенностей и другое. Проводится довольно быстро. Это легче чем написать ТЗ. После проработки Event Storming можно уже давать задания для программистов, дизайнеров, маркетологов и др. Очень полезная техника для автоматизации. Всегда проще сначала нарисовать бизнес, а потом его автоматизировать.

Если вы автоматизируете уникальный продукт, где есть своё ноу хау, то без этой техники не обойтись. Ведь выбирая что-то за основу и копируя её вы не доносите ценность вашего бизнеса. Для примера, ваша ценность может быть вовсе не в качественных и вкусноприготовленных блюдах, а в грандиозном сервисе подаче этих блюд. Тогда автоматизацию следует делать с большим упором на услуги. Или ваш ресторан наоборот может иметь самый быстрый сервис и подачу блюд. В этом случае упор будет другим. А может быть у вас в целом подход будет заключаться в управлении другими ресторанами (сеть). В общем брать что-то за основу и тем более слушать программистов не стоит. Программисты делают всегда то, как им удобнее и проще. Для вас же важно решить свои проблемы. Удвоить бизнес.

8 - мало в любом случае, 15-20 по моим грубым, ориентиров по прайсу на такое быть не может, аудитория и специфика бывает разной.
если есть сайт или возможность управлять этими 125к - им можно предложить продукт за 500, и если хотя бы 16 из них купят - человек отбил вложения. Чуть чуть прикинь и посчитай как можно этот ресурс трансформировать в прибыль, и примерно узнаешь сколько это может стоить.
Другая сторона - тебе самому этот актив не нужен, извлекать прибыль не хочешь / не умеешь, но считаешь что оно должно стоить дороже предложенного?
Другой вопрос - вместе с расширением тебе судя по всему придется отдавать аккаунт. Далее загружается обновление или используется какая нибудь уязвимость, и расширение становится разносчиком вредоносного кода, крадет деньги, следит за пользователями. Оно ж еще наверняка дырявый manifest v2?) А ты, получается, не просто соучастник, а аккаунт-то вовсе полностью твой, и вот ты уже закрыл себе въезд в многочисленное количество стран и нажил проблем на задницу за 8000.

Чо бы я тебе посоветовал - не продавать, а нанять человека и за процент вместе с ним попробовать трансформировать этот актив в прибыль. И сам больше заработаешь, и риск подконтролен тебе.

На сервере делаете очередь задач, которые должны быть напечатаны, и API, по которому локальный компьютер может обратиться, забрать задачу и отметить ее напечатанной.
На локальной машине можно запускать буквально одну HTML-страницу в браузере, в которой JavaScript обратится к серверу, получит PDF, откроет окно печати. Или загрузит все задания, объединит их в одну PDF-ку и уже тогда откроет окно печати. Потом выведет подтверждение пользователю - отметить эти задания как выполненные или повторить печать.
Полностью автоматизировать печать так не получится, но это и не нужно - за этой капризной скотиной-принтером все равно должен постоянно следить оператор...

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

Я периодически вижу в интернете странные попытки настраивать локаль и использовать модификатор u и говорят даже работает, но документации для этого мне найти не удалось

Но зато есть штатный механизм работы с кодировками - это расширение Multibyte String, пользуйтесь им и все будет работать как ожидается. В частности использовать нужно mb_ereg_replace

Мать моя женщина про нормализацию ни кто не вспоминает итак

Вам нужно как минимум 2 таблицы

Domains
id
domainname

Customers
id
domainId
email
firstName
lastName

NoSQL использовать не нужно.

Во-первых, id поста не относится к данным для валидации.

Во-вторых, если таки хочется велосипедить на квадратных колёсах и валидировать через реквест — ответ есть в документации.

В-третьих, чем не устраивает в контроллере что-то типа Article::query()->findOrFail($id), что более правильно?

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