Если из кода, то я пользуюсь swiftmailer - хорошая либа по отправке сообщений в любом формате, с вложениями и любого провайдера.
Если глобально для функции mail(), то можно изменить настройку в php.ini например на msmtp вместо локального sendmail или exim
У Вас форма отправляет методом GET, а значения вы ищите в массиве POST. Где логика?
если вам не хватает шаблонизатора, суть которого выводить данные, то значит вы в шаблоны пытаетесь засунуть бизнес логику, а это уже тупик проекта. Php был шаблонизатором до тех пор, пока на нем делали только персональные странички
Каким ... надо быть чтоб ради 50-100р обречь клиента на страдания? И при этом скорее всего потерять его лояльность?😂
А гнать трафик нет смысла, если люди после 1-2 месяцев будут сливаться, то невыгодное вложение получается.
В любом случае нужны, если поле учавствует в фильтрации. Просто там много ньюансов, которые не знают начинающие разработчики, типо берется только первое поле за индекс или в выборке поля должны быть в том же порядке что и в составном индексе. Опять же индексы вредны в таблицах, где больше записи, чем чтение потому что перестроение индексов в такой таблице будет дольше чем селекты к ней. В остальных случаях они помогают при выборке сократить результатирующий набор для обхода. Почему ходит мнение, что индексы полезны на миллионах строк, тут все просто, mysql работает с большой таблицей блоками, то есть загрузили блок в память, проверили, выгрузили, загрузили новый блок в память, проверили, выгрузили и вот чтоб не грузить все блоки (а операция довольно дорогая), индексами находят нужный, но это, так сказать, лишь один из способов их применения, mysql использует деревья, то есть по индексам он может выбрать нужную ветку дерева и сократить порядок обхода в разы. Пример ТС, как раз когда из 2х табличек по 7000 записей получаеться выборка на 32 миллиона строк, ему конечно не помогут они, но вводить в заблуждение других участников форума не очень хорошо.
Там в любом случае есть контентный блок, без сайдбаров, шапки и футера, хэшировать тогда только его. Ну или проверять, если сменились больше N хэшей подряд, то скорее всего изменился элемент дизайна/добавили ссылку/написали новость ну и так далее, то есть изменения прошли сразу на всех страницах. Вот тут надо просто понять допустимое значение N
Довольно простая задача, даже на том же php. Сложить требуемые файлы в одну директорию, а потом циклом пройтись по ней и вставить в начало файла и конец нужные вам строки.
А в чем проблема не понимаю? Тащите страницу всю каким нибудь file_get_contents (PHP), запихиваете в md5 (PHP) и складываете все в базу вида url|hash
И парсите хоть каждые 5 минут, md5 быстрый алгоритм и не грузит железо, и сравнивайте хеши, изменился ли хэш или нет. Если изменился - шлите email
UPD: Есть более короткая запись md5-file
PS. Только используйте sleep чтоб не ложить сайт туроператора и запускайте из командной строки обернув все это в цикл, там (cli) обычно не ограничено время выполнения скрипта, и вот у вас уже "демон" болтается и следит за обновлениями. Можно пойти дальше и повесить мониторинг работы скрипта и если не работает перезапускать процесс :))
Magistr, Моё предложение остаеться в силе, сделайте несколько запросов просто с ON email = email_N, а потом данные объедините в приложении
Из 7000 строк, выбираеться 3697 строк по where, а потом каждая из этих строк в джоин сравнивается с !каждой строкой во второй таблице, то есть 8738 раз, как думаете это быстро? Индексы помогают уменьшить результатирующую выборку для сравнений, у ТС на первом скрине ключ email в столбце ref имеет значение NULL, что говорит о том, что сравнивается со всей таблицей и чем больше таблица, тем дольше будет работать запрос при том по экспоненте, тем более IN работает только с проиндексированными полями, иначе он убивает любой селект - так в документации написано, не мои слова )))---------- Добавлено 21.07.2016 в 20:12 ----------
Поверьте, вы ошибаетесь :)
