Adamos

Пишешь JS-скриптик, в котором дергаешь аяксом страничку на РНР, передавая ей параметром N и М.
В РНР пропускаешь N * М строк, обрабатываешь следующие М, возвращаешь ОК.
В JS ловишь ответ, увеличиваешь N и запускаешь следующий цикл.
Будет и правильно, и наглядно.

В конфиге PMA есть пункт:

RTFM

Начиная с версии 2.3.0, можно проигнорировать эту переменную и поставить в этой строке пробел - в большинстве случаев phpMyAdmin автоматически определяет правильный параметр. Подробнее читайте в конфигурационном файле.

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

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

$contacts_fields = array(
    "site_telephone_2" => ['value' => "телефон 2", 'type' => 'phone'],
    "site_email_2"     => ['value' => "почта 2", 'type' => 'email'],
);

function decorator($name, $value, $type) {
  switch($type) {
   ...
  }
}

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

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

Количество вариантов = (кол-во вариантов выбора в строке) в степени (кол-во строк).
Генерировать все возможные варианты - угрепаешься даже на небольших числах. Да никому это и не нужно.
Сгенерировать произвольный вариант - элементарно.
Берете массив длиной в кол-во строк, заполняете его случайными числами от 1 до кол-ва вариантов.
Потом в заполненных позициях заменяете это значение на номер выбранного ответа.
Вот и вся комбинаторика.

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

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

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

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

Никакой информации о часовом поясе пользователя скрипт, исполняющийся на сервере, не имеет.
Более того - она намеренно не предоставляется.
Вы можете попытаться угадать зону по айпишнику, но не удивляйтесь, если будете часто промахиваться, особенно при входе с мобильного интернета.
Вы можете предложить пользователю самому указать эту информацию.
Можете вынести окончательное формирование времени на фронтенд, передавая ее в GMT и преобразуя уже в браузере.
Или просто можете при первом входе юзера запускать JS, определять зону и сообщать ее серверу ;)

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

Выбрать из базы страны и список городов по ним, сохранить в JSON.
Отложить PHP и бекэнд, перейти к JS на фронте.
Подгружать этот JSON и скармливать его любому решению по запросу "chained select" (или, если настаиваете, "chained dropdowns"), которое вам больше понравится. На изменение второго повесить обработчик, заносящий его значение в input.