Попытки выполнить php wa.php compress ... крашатся с сообщениями вида
ERROR: Empty or invalid item config
PHP Notice: Undefined variable: pipes in /var/www/vhosts/22/126887/webspace/httpdocs/domokeys.net/wa-system/webasyst/lib/cli/webasystCompress.cli.php on line 669
PHP Warning: proc_open() has been disabled for security reasons in /var/www/vhosts/22/126887/webspace/httpdocs/domokeys.net/wa-system/webasyst/lib/cli/webasystCompress.cli.php on line 669
PHP Notice: Undefined variable: pipes in /var/www/vhosts/22/126887/webspace/httpdocs/domokeys.net/wa-system/webasyst/lib/cli/webasystCompress.cli.php on line 670
PHP Warning: stream_get_contents() expects parameter 1 to be resource, null given in /var/www/vhosts/22/126887/webspace/httpdocs/domokeys.net/wa-system/webasyst/lib/cli/webasystCompress.cli.php on line 670
PHP Notice: Undefined variable: pipes in /var/www/vhosts/22/126887/webspace/httpdocs/domokeys.net/wa-system/webasyst/lib/cli/webasystCompress.cli.php on line 671
и т.д.
14 комментариев
tar czvf ...
Я разве спрашивал как тарить? Или для Вас ломающийся код движка - это норма?
<sarcasm>Ух ты! У вас включен вывод ошибок вида Notice</sarcasm>
По сути: за Notice спасибо, исправим, а вот с ошибкой ERROR: Empty or invalid item config вам придется разобраться самостоятельно.
Без сарказма. Я не согласен с тем, что у меня ошибка. В продолжении темы о том, что после обновления нав shopscript 7 и движка у нас перестал правильно формироваться файл для яндекс маркет штатным плагином.
Здесь аналогичная ситуация. За день до обновления я отправлял компрессировал и отправлял плагин на проверку. После обновления отозвал плагин, внёс исправления в классе, но никак не в конфигурации, после чего и попытался сжать и отправить заново. И получил вдруг ваши нотисы (вывод которых я отнюдь нигде не включал по отношению к позавчера) и сообщение об ошибке в конфиге. Поскольку конфиг я не правил, то может это ваш скрипт чего-то не того стал хотеть. ИЛи если изменились правила/конфигурации, то где написано как? Что надо было поменять
прошло больше 20 дней, а ОШИБКА так и не исправлена. Просто удивительно какая двойственная политика в данных разработчиков. грубая ошибка в коде своего ядра их не смущает, а сторонних просто гнобят мелочным и придирками типа нельзя неопределённую переменную считать как фалсе в проверке. Простите, но это уже на грани откровенного хамства.
Вышло обновление движка. Но ошибка так и не исправлена. Понятно что можно и вручную. Но сдаётся мне это не лучшим образом рекламирует сам продукт. 2 месяца, а фатальная ошибка не исправлена
Покажите номер версии установленного у вас Вебасиста и точное сообщение об ошибке, которое вы видите прямо сейчас.
Версия Вебасиста 1.5.12.50
Вот весь вывод
Но проверку доступности proc_open в код мы добавим
Уточню: а вы обновляли код из github-а (это решает вывод notice)?
Конкретно по вашей проблеме: вы запускаете утилиту сжатия на хостинге, где запрещена функция proc_open (используется для запуска php для валидации синтаксиса файлов), вместо того, чтобы запускать её в среде разработки, что собственно и приводит к ошибке.
Установка была из дистрибутива с нуля. К сожалению у нас один хостинг на всё. Не заметил в документации, что есть требования к среде разработки иные чем для эксплуатации
Эмм... Конфигурация development и production серверов отличается всегда — это касается MySQL, Apache, PHP и остального. Всё названное имеет два варианта конфигурационных файлов в поставке или рекомендациях по настройке (как пример: php.ini-development, php.ini-production — сильно разные опции по отображению ошибок). Вести разработку на "боевом" сервере — моветон (исключение - финальная проверка работоспособности интеграции, когда всё остальное уже проверено в песочнице).
Сервера разные, виртуальные. А хостинг один. Провайдерский. Или моветон у одного хостера и разрабатывать и пользоваться? По моему опыту как раз большинство проблем в эксплуатации порождало то, что рпзработчики создают себе идиализированную среду с библиотеками, которых не будет у заказчика и потом масса сил тратится на вычленение несовместимостей кода. Именно как здесь.
Разработчики устанавливают себе библиотеки для разработки. Например xdebug. Эта библиотека очень даже вредна на продакшене т.к. меняет ответы некоторых утилит, которые могут использоваться в коде. Да и не нужна она на продакшене. Про несовместимости - это Вы загнули. Мы все прекрасно знаем что можно и что нельзя. Особенно когда вставляем в код нечто заковыристое. Лучшей практикой является найти нужный метод в фреймворке и использовать его.
Я тут недавно видел плагин от https://experts.webasyst.ru/directory/908690/zhmih...
Так там для создания юзера человек целую телегу написал (http://pastebin.com/QyKvvnia) вместо того, чтобы использовать встроенные средства фреймворка. При таком подходе конечно могут повылазить несовместимости где угодно. Но, слава богу, такие вещи модераторы сейчас не пропускают.