ThunderCat

Опять 25... Учимся искать свои косяки:
0)

Есть форма, я вставил туда код чтобы брать метки

В коде у вас нет формы...

1) проверяем что поля формы содержат нужные данные (открываем страничку с меткой, смотрим форму инспектором, проверяем что в нее что-то вообще попало)

2) Открываем в браузере инструменты разработчика, вкладку нетворк, при отправке формы смотрим что форма отправила все данные нужным методом и с нужными данными.

3) На сервере через var_dump() проверяем какие переменные пришли постом/гетом

Но метки не приходят

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

PS: утм метки обычно пишутся один раз при заходе с ней в куку/сессию, чтобы не приходилось вот так их тащить через жеппу, а иметь к ним доступ в любой точке кода, и трекать что юзер делал после перехода на сайт.

Да, это нормальное поведение, но мне хотелось бы, чтобы запись имела id 9.

Вам не приходило в голову, что это нормальное поведение не просто так? На моей памяти это уже 5 или 6 раз когда приходится объяснять что "это жжж неспроста...", в 7 раз уже лениво, просто прими как данность что так должно быть.
Идиотский, но понятный даже чайникам пример - если это список пользователей, и ты удалил №9, а затем добавил нового с этим номером, у предыдущего пользователя могут остаться данные, которые к нему привязаны именно по этому номеру, и они (внезапно!) перепривяжутся к вновь созданному юзеру, что не есть хорошо. Механизм автоинкремента как раз гарантирует неповторяемость идентификаторов, для вот таких случаев.

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

ошибки нет,данные верные,

Святая наивность...
1) Включите вывод ошибок
2) 99% что все работает на свежей версии пхп, где давно забыли что такое mysql_query
3)

или еще что-то

Да, наверняка еще что-то, смотрите п.1

Не удалось воспроизвести ваши глюки... на телефоне тоже все ок.

открыть вашу пхп страницу в браузере и ctrl+s не подходит?

Если следовать букве вопроса - да, с нодой на бэке вполне норм, бывают.
Если имелось в виду именно "неуправляемые" сайты, голый фронт - тоже дофига, миллиард лэндингов и персонал пэйдж, ну или 3 статичных странички микрофирмы - главная, прайс, контакты...

Кодировка страницы + кодировка соединения + кодировка таблицы в бд + желательно дефолтная кодировка в пхп.ини = utf-8

Сессии, токены... Методов много, самый простой - сессия.

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

Есть несколько подходов, каждый по своему хорош в той или иной ситуации.
1) Забить на все эти куки/ип и считать каждый заход, что по сути нормально, я вполне могу зайти посмотреть какой-то материал 2-3 раза, а просто тупо рефрешить страничку редко кто будет. То есть это вполне нормальный способ без заморочек, тупо +1 на просмотр.

2) Считать куку в отдельной таблице айди | кука | айди статьи , где кука будет уникальным полем, пишете запрос с он дупликэйт игнор, и потом тупо селект суммы по айди статьи. Это накладнее по ресурсам, как по месту, так и по процу, но считает чисто уников. Считать по айпи - глупо, ибо 80% траффика на сегодня - мобила, а при переподключениях к сети айпи будет меняться у одного пользователя, короче это нифига не уникально.

3) Забить на подсчет своими силами, и ориентироваться на профессиональные счетчики а-ля яндекс гугл. Просто, качественно, весьма достоверно. Графики, аналитика и прочие плюшки бонусом.

https://www.php.net/manual/ru/function.array-column.php

Простое/тупое решение: Сдублируйте код, поменяйте во второй форме айдишник поля на phone1, и поменяйте var phoneInputID = "input#phone1";.

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

присылать уведомление, если цена изменилась более чем на 2%

Во первых откуда берутся изменения? Если у вас они происходят программно - проще во время обновления в бд проверить расхождение с предыдущей ценой, и в случае разницы в эн процентов оповещать всех подписанных на событие клиентов по сокету.
Во первых обновления будут приходить сразу, а не каждые 10 секунд,
во вторых не придется выбирать ВСЕ товары и сверять с каким-то хранимым массивом (его еще и хранить где-то надо чтобы разницу считать),
и в третьих нагрузка при этом на порядки ниже, так как у вас на руках сразу все изменения, и ничего дополнительно выбирать не надо.

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

Емнип скролл евент не имеет "направления" в жс, можно только отследить перемещение элемента относительно предыдущей позиции, так что никак, только если добавить 1 пиксель, и уже по нему отслеживать сдвинулось на 1 пиксель вверх/вниз или осталось прежнее направление.