Смотрим файл wa-data/public/shop/products/thumb.php
Видим там
$file = dirname(__FILE__)."/../../../../"."/wa-apps/shop/lib/config/data/thumb.php";
Не всякий сервер понимает такую конструкцию. Ко мне очень часто обращаются клиенты, у которых нет эскизов нужного размера. И несколько раз уже заводил темы о том, что не генерируются эскизы. Думал я не верно создаю изображения. Оказывается причина в этом файле.
Если разобраться глубже, то этот файл вызывается из класса shopImage, который знает где лежит wa-apps/shop/lib/config/data/thumb.php
Можно просто передать в параметрах этот путь. Ну или вообще убрать этот костыль и напрямую вызывать wa-apps/shop/lib/config/data/thumb.php из shopImage
creativ.it вон даже плагин сделал для внутреннего использования, который фиксит эту проблему. а такого быть не должно вообще!
Считаю это багом и прошу исправить в ближайшем обновлении.
24 комментария
какой пример? это же синтаксис PHP 5.2
и куда http сервер будет перенаправлять запросы на получение несуществующиx thumbnail файлов?
во-первых там не все гладко со слешами. они там могут удваиваться.
во-вторых например голый апач не понимает такой конструкции.
в третьих представьте себе, что на сервере не хватает места на основном диске, и папку wa-data поместили на другой диск.
в wa-apps/shop/lib/config/data/thumb.php вы догадались обработать симлинки, а в wa-data/public/shop/products/thumb.php этого не делается.
Я не нашел готового решения, но у вас на модерации находится плагин от creativ.it, который решает проблему. В принципе можно всем, у кого данная проблема, советовать покупать его. Но вы бы присмотрелись... Потестите с симлинками, посмотрите что будет.
symlink в помощь
голый апатч вообще никакой php код не понимает, этим занимается php установленный как его модуль
я?
всмысле? realpath() преобразует символические ссылки хотя не знаю при чем тут ссылки - это же прост обертка wa-apps/shop/lib/config/data/thumb.php
Этот разговор уходит куда-то в сторону. Я уже все расписал довольно четко и сказал что нужно сделать чтобы клиент мог нормально работать и не обращаться за помощью к разработчикам, которые, если не в теме, все зубы обломают, пытаясь отдебажить эту ситуацию.
Опишите, пожалуйста, подробно условия, при которых у вас возникает ошибка. И опишите, как именно она у вас проявляется.
Самый простой вариант я уже описал. Попробуйте папку wa-data создать как символическую ссылку на другом диске. В моем случае - это сайт для торговли цифровыми товарами, которому нужен большой объем диска для работы. Так же я замечал такое же поведение на хостинге, который работает без nginx на голом апаче под управлением virtualmin с настройками из коробки без всяких допилов и дополнительных настроек.
Какое решение проблемы удалось найти в этих случаях?
Самое логичное, как по мне, так это передать в wa-data/public/shop/products/thumb.php во время его вызова из shopImage абсолютный путь к wa-apps/shop/lib/config/data/thumb.php каким угодно способом. О чем я и написал в первом посте. Тогда никаких проблем не будет.
не работает скорее всего потому, что, по умолчанию, php ограничивает доступ за пределы сервера.
симлинк находится в пределах веб сервера, и вебасист прекрасно работает на такой конфигурации. просто его нужно вызывать изнутри сервера, а не снаружи. у вас в wa-apps/shop/lib/config/data/thumb.php есть обработка симлинков, о чем вы заранее подумали. посмотрите, может забыли...
я не сотрудник WA, т.ч. ни о чем заранее я не думал (:
речь не о линке, а о том куда он ведет, диск не может быть в пределах сервера.
проверил на локалке: перенес на другой диск wa-data, сделал линк и все заработало без проблем, пришлось только поправить настройки php/apache.
Сорян, бро, я попутал.
Да мы можем хоть что поправить. Я говорю о не опытном пользователе. Ко мне много раз обращались с этим потому, что я продаю несколько плагинов синхронизации с производителем. Я раньше советовал сначала прописать все эскизы в настройках, а потом запускать синхронизацию с принудительной генерацией эскизов. А сейчас на теме proStore понял что там @2x везде и обычные эскизы опять же не подходят. Вот и начал копаться.
неопытных пользователей linux серверов я еще не встречал (:
я так и не понял что конкретно ты предлагаешь?
передавать в wa-data/public/shop/products/thumb.php
абсолютный путь к wa-apps/shop/lib/config/data/thumb.php
когда он вызывается из класса shopImage
shopImage знает все пути изнутри движка и не нужно вот этих слешей
$file = dirname(__FILE__)."/../../../../"."/wa-apps/shop/lib/config/data/thumb.php";
а где ты в shopImage нашел вызов thumb.php?!
откуда и как передавать путь? ты же не будешь в каждом запросе его передавать...
в нормальных приложениях генерация эскизов реализуется через контроллер/действие с роутом типа 'wa-data/<visible:(?:protected|public)>/<app:\w+>/thumbs/', но из-за проблем с обратной совместимостью врядли реализуют
ну посмотри. если файл эскиза найден в shopImage, то он загружается сразу, если не найден, то выщывается thumb.php.
зачем? thumb.php использует shopImage для создания эскизов
shopImage использует thumb.php в том случае, если не находит изображение на диске, а не наоборот. поэтому здесь вполне возможна передача данных. можно даже в сессии хранить этот путь и не передавать каждый раз.
В любом случае багрепорт принят и разработчики Webasyst что-то сделают чтобы решить проблему. Как они это сделают, уже не важно :)
Описанная вами ситуация выглядит нестандартной. В обычных условиях у пользователей нет возможности создавать символические ссылки — это какая-то частная работа администратора. Но раз администратор частным образом иногда выполняет такую работу, то в эту работу можно включить и замену пути в файле thumb.php.
Из этих соображений проблема пока что признана мало влияющей на большинство пользователей, а это значит, то шансов на её исправление немного.
не найдут где копать и будут долбить в поддержку.
Если проблема станет заметно массовой, то подумаем, как можно минимизировать её масштаб или предотвратить её возникновение. Спасибо за сообщение в любом случае!