ThunderCat

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

Зафиксировать высоту блока с текстом сверху на 2 строки текста (можно и снизу на 3 строки)
задать оверфлоу эллипс
сделать титл для просмотра полного названия при наведении.
Профит

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

Если задача именно получить урл, а не переходить по нему, то надо убрать CURLOPT_FOLLOWLOCATION и смотреть заголовки.

Из них уже тянуть урл редиректа. Если программный переход по этому урл нужен, то соответственно смотрите ответ nokimaro.

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

Открывайте инструменты разработчика, нетворк, и смотрите что возвращает ваш аяксовый запрос, скорее всего там у вас какой-то варнинг вылазит, или еррор.

Кроме того, парсить строку совершенно не обязательно, достаточно в аяксе указать тип возвращаемого значения.

отслеживать mouseup + keyup и проверять window.getSelection(), после чего document.getSelection().removeAllRanges();

Но смысла в этом имхо никакого...

Этих значений на фронте нет, их присылает только бэк.

У вас может не быть ТЕКУЩЕГО состояния, но список всех состояний на фронте должен быть, иначе как вы будете знать как должен выглядеть определенный статус?

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

То что вы так странно описываете, если я верно понял суть, называется ACL или RBAC, в зависимости от цели и логики приложения.

И вот эту таблицу нужно постоянно обновлять. но учитывая что отваров более 100 000 поштучно это делать как то не очень удобно.

Постоянно - это сколько? И почему не удобно?

Слыша что есть такое понятие как репликация баз данных, которая занимает секунды?

Слышали звон, но не потрудились даже загуглить что это. ок, гуглим за вас... TL;DR - реплика это не то что вы подумали, и к скорости обновления данных имеет весьма опосредованное значение.

Может на сервере где есть этот сервис завести тоже таблицу подобной структуры, в нее апдейтить цены а потом какой то хитрой методикой синхронизировать ее с основной базой? Но как быть с тем что в основной базе есть товары, которых нет в текущей порции данных? чтоб только частично базы синхронизировались по полю product_id к примеру?

И вот тут чтение про репликацию приобретает некоторый смысл... Но опять же, есть куча нюансов...

И еще вопрос. На какой языке программирование лучше это делать чтоб выиграть в скорости?

На любом, пхп+лара вполне норм. У вас в этом вопросе на самом деле 2 косяка по хотелкам:
первое - преждевременная оптимизация, так как судя по тому что никаких данных по томозам сервиса вы не привели, и скорее всего все работает нормально и так, а решения об оптимизации больше "стратегическое думанье в грядущее",
и второе - язык в любом конкретном случае выбирается по многим параметрам, но практически никогда по быстродействию. В 99% случаев расчеты на практически любом ЯП будут в разы быстрее, нежели операции с бд. Узким местом практически всегда будут сложные объемные выборки из бд, в то время как ЯП будет производить достаточно простые преобразования над ними (ну, если не рукопопы будут писать запросы и код).

Пример страницы, где свойства успешно работают

Не работают.

свойства max-width="100%";

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