Выведите сам $this->configParams['username'].':'.$this->configParams['password'] - данные ожидаемые? Без аномалий?
Ну и на всякий случай - сервис точно требует basic auth? Может быть что-то другое
(SELECT count(id) FROM blacklist WHERE userID = user.id OR objectID = user.id )=0
Не надо так делать. Нет нужды перебирать и считать всё подходящее, когда заведомо известно, что проверяем существование хотя бы одной строки. Есть куда более подходящие exists/not exists.
andrewkard пишет:
SELECT * FROM match WHERE id NOT IN ( SELECT id FROM email WHERE id IS NOT NULL)
Честно уже не помню насколько внятно это умеет выполнять mysql.
Есть весёлое ограничение из стандарта SQL о том, как именно IN должен обрабатывать ситуацию если в строках подзапроса будет хотя бы один NULL: как NULL всего выражения, независимо от прочих результатов. Из-за этого например в postgresql in хуже эквивалентного exists.
Вспомнил как собирать, в мастере уже починили, может и в уже вышедшем 7.3.1 исправлено, собирается пока. У меня 7.3.0 ещё был (Добавление)
7.3.1 так же баг, исправление есть в ветке 7.3, то есть войдёт в 7.3.2 релиз и далее.
Anguis пишет:
по всей видимости пых переживает не лучшие времена...
Это фигня. В первых минорных релизах всегда что-нибудь весёлое может случиться.
Для первых минорных релизов мы и postgresql не советуем ставить свежей major версии в бой. А там код поприличнее на мой субъективный взгляд автора пары патчей.
сдаётся мне путь вам прямиком в bugs.php.net
Это чудесный пример регрессии с простым и понятным reproducer, при том явно не запрещённым в документации.
На 7.2.4 похоже ещё работало (из ближайшего online sandbox), а я что-то разучился php компилировать
Не "md5 файлы", а "md5 файла", это единственное число, а не опечатка. Одного конкретного, того который отправляете и который получается на ftp сервере.
Любой реализацией md5 посчитайте хэш файла. Можно любым другим алгоритмом, sha1, md5, да хоть crc32. Если хэш совпадает, значит файл (скорей всего) не был искажён при передаче.
Включите error_reporting в адекватный E_ALL и отлаживайте скрипты только так.
В частности, $name вы определяете используя переменную $type, которую определяете после. Конечно это работать не будет.
А файлы без расширений ничем не отличаются от файлов с расширениями. Это лишь часть имени файла.
Это как?
В вызов функции вы передаёте массив. Массив вам и доступен.
Вероятно какой-нибудь extract хотели сделать.
Но даже при наличии extract это не отвечает на вопрос, откуда должна взяться $var. $info с копией $var получить можно, а вот $var - нет такого.
Так и задавайте вопрос не про вообще не к месту упомянутый JSON, а про синтаксис строковых литералов PHP.
Синтаксис строк вполне описан в мануале: http://php.net/manual/en/languag...types.string.php
Запишите нужные для переменной данные синтаксически корректно. Ну или читайте из файла либо ещё откуда извне текста скрипта.
Поясните в чём вы видите проблему и что тут надо исправлять.
Если закрыть { добавив в конец }, то будет синтаксически корректный JSON, успешно разбирается в том числе PHP