Дмитрий

1. Зачем парсить, если существует куча сервисов с API?
2. По geoip или как-нибудь ещё узнаешь локацию пользователя, и сопоставляешь со страницами на сайте.
Например если пользователь в Алматы, то парсишь https://www.gismeteo.kz/weather-almaty-5205/
А если в Астане, то парсишь https://www.gismeteo.kz/weather-astana-5164/

У проца TDP меньше 100 Вт. Подойдет любая жижа сомнительного происхождения.

$result = preg_replace('~^(.{8})(.{4})(.{4})(.{4})(.*)~', '$1-$2-$3-$4-$5', $str);

Это что у вас вообще такое?
count($translit>0)
Ну и собственно текст вашей ошибки: Argument #1 ($value) must be of type Countable|array, bool given

Вы в count передаёте в параметр булево значение, которое функция не поддерживает. Она ожидает получить в параметрах либо объект, который реализует интерфейс Countable, либо массив.

https://www.php.net/manual/ru/function.count.php

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

Ничем не опасно, эта фигня у многих появляется, у меня в том числе. Забей или через редактирование конфига Grub просто скрой вывод ошибок при загрузке, они всеравно в логе тоже видны.

Тут подходит любая реляционная SQL БД потому что нет противопоказаний. Реляционку мы выбираем
уже более 30 лет как default вариант и почти не ошибаемся.

Когда задача имеет признаки ярко выраженной high-load системы - мы делаем ей частичную денормализацию
и раскладываем ее в NoSQL Key-Value решение. Но это не про улучшение а это про неизбежность. У нас нет выхода просто.
Иначе мы клиенту не сможем быстро отдать какой-то резуальтат.

Когда задача имеет ярко выраженную документную природу (нет спецификации на values) - мы берем MongoDb/CouchDb.

Когда задача хранит граф и ищет в графе и вообще требует графовых алгоритмов - то мы берем Neo4j или ей подобные.

Когда задача хранит данные измерений (телеметрия) - то предпочтительно взять InfluxDb или ей подобные. Здесь-же мы предполагаем что у нас - не будет joins а будет только измерения в диапазоне времени.

Но в данном ТЗ и на картинке обычная SQL БД (MySQL/Postgres) вполне себе нормально справляется.

Используйте что-то типа bootstrap

у вас не много вариантов.

1. Нанять/объединиться с фротнэндером
2. Использовать какой-то фронтэнд фреймворк. Типа бутстрапа.

Почему-то никто не предложил самое лобовое и просто решение - low-code. Современный low-code достаточно гибкий, чтобы делать UI для прототипов довольно сложных штук.
На каком-нибудь Retool или подобном сервисе можно быстро собрать фронт без геморроя и упарывания по развертыванию среды для разработки фронта.

array_column() чтобы получить все значения из полей quantitiy и array_sum() чтобы сложить их.

Ну либо циклом перебрать, array_reduce либо обычный foreach.

Надо в настройках системы отыскать эту комбинацию и выключить - тогда заработает.