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

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

По вычисляемому хешкоду md5 файла. Возможно, в перспективе появятся другие методики, но сейчас так

Скорее всего, какие-то конфликты верстки и джаваскриптов. Какие именно — надо дебажить и смотреть.

А вот размазать контент по поддоменам с SEO точки зрения не совсем верно

Поддержу. В свое время развернуто высказал мнение здесь: altocms.ru/69.html

Контроль, описанный выше, работает при добавлении и обновлении топика. Поэтому старый мусор автоматически не будет собираться. Да и не должно этого быть в «коробке», ИМХО.

Для подобных случаев нужен плагин, который, используя «коробочный» функционал, отфильтрует зерна от плевел.

Поддоменов из коробки точно нет, так что плагин — это однозначно

Поскольку загрузка и хранение файлов вообще — это отдельный пул задач, не связанный напрямую с обработкой изображений, то этим занимается новый модуль под названием Uploader.

В простейшем варианте (если нужно просто загрузить изображение без какой-либо обработки) это может выглядеть примерно так:

// получаем параметры загружаемого файла
$aFile = $_FILES['image'];

// получаем папку хранения изображений для юзера $oUser
$sTargetDir = $this->Uploader_GetUserImageDir($oUser->GetId());

// загружаем файл
$sImageFile = $this->Uploader_UploadLocal($aFile, $sTargetDir);

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

Если нужно получить URL для этого файла, то в этом поможет такой код:

$sImageUrl = $this->Uploader_Dir2Url($sImageFile);

Если нужно не через POST загрузить картинку, а взять ее по URL, то вместо метода UploadLocal($aFile) можно использовать метод UploadRemote($sUrl).

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

Так годится?

Будет ли данная проблема решена?

Я считаю, что в новой версии такой проблемы нет в принципе. Модуль работы с изображениями был не просто «доработан», он был написан полностью с нуля — новая архитектура, новый набор методов. Я даже назвать решил его иначе, чтобы путаницы не возникало (старый — ModuleImage, новый — ModuleImg).

Сейчас в модуле реализованы базовые функции: resize и crop, будут еще flip и rotate (точнее, уже есть, только методы в интерфейс модуля не вынесены). Ясень пень, поддержка GIF-анимации тоже будет. Причем, операции все конентно-независимые, т.е. неважно, с каким изображением работаете — аватара, фотка в топике и т.д. Просто передается либо объект-изображение (который может быть создан как сам по себе, так и из файла), либо имя файла с картинкой, над которым выполнить операцию нужно.

Короче, я не могу себе представить, чтобы Вам потребовалось теперь в плагине полностью переписывать функционал работы с изображениями

Конкретно в нашем случае используется одно и то же изображение с разными размерами сторон. Но, наверное вы правы — правильно делать отдельное превью

Если изображений не очень много и/или их оригиналы не очень большие, то можно и одно изображение использовать. Но вообще разница есть — изображение 1000х800 и, скажем, 250х200. Сейчас для всякого рода альбомов и проч. часто используется код что-то типа такого:

<img src="picture.jpg-200x100.jpg" data-image="picture.jpg">

Т.е. в HTML-страницу встраивается мини-картинка (picture.jpg-200x100.jpg), при клике на которую уже открывается большое изображение picture.jpg.

И на большом трафике и/или при работе с большими фотоальбомами отдельное превью может дать очень хороший положительный эффект

Алена, честно скажу: я, наверное, не очень понимаю, о чем именно Вы говорите. Если речь конкретно про данный функционал — ресайзинг и кроп картинок — то да, пока в диалоговом окне вставки картинки в топик нет возможности указать желаемые размеры. Но вообще изменения в версии 1.0 не только с изображениями связаны.

… как сделать /uploads/images/000/picture.jpg для всех изображений загруженных пользователями /uploads/images/000/picture.jpg-200x100.jpg?

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

<img src="/uploads/images/000/picture.jpg">

то вы можете указать в этом месте

<img src="/uploads/images/000/picture.jpg-200x100.jpg">

и движок автоматически сгенерит и выведет картинку нужного размера. Если за вывод в шаблоне у вас отвечает код типа:

<img src="{$oTopic->getPictureUrl()}">

то вы можете его в таком виде представить:

<img src="{$oTopic->getPictureUrl()}-200x100.jpg">

Хотя я предпочитаю такие вещи лучше на уровне сущности отрабатывать, а не в код шаблона вшивать

А что, на Ваш взгляд, должен представлять из себя ватермарк? Как Алена предложила? Или что-то иное? Что у Вас ставят пользователи?

Ну вот да, как именно по умолчанию помечать загружаемые картинки — это тоже вопрос. Алена предложила вариант, но я чаще встречал, что пишется просто адрес сайта (без указания юзера) либо логотип сайта. Пока я склоняюсь к тому, что лучше плагин отдельный написать, где будет множество разнообразных настроек для того, чтоб «метить» загружаемые фотки

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

Кстати, подумываю о статье (или даже о серии статей «Конфигурация сайта на Альто — тонкие настройки»), ибо в конфиге громадное число параметров, людям неведомых (даже с ЛС оставшихся, не говоря уж о новых), и которые, скорее всего, не попадут в админку (во всяком случае — в ближайшее время).

делать несколько копий с разными размерами он не умеет, да и нужно ли это?

А как без этого реализовать «возможность показывать оригинал изображения по клику во всплывающем окне?»

Я ждал этих вопросов! ;)

… есть возможность показывать оригинал изображения по клику во всплывающем окне?
… будет ли управление изображениями? Например такое…

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

Про GIF услышал. Насчет ватермарк пока сомневаюсь, но может быть…

Вообще-то back-end и front-end в Альто уже разведены довольно четко. Или я Вас не понял и Вы что-то другое имеете ввиду?

Времени на эксперименты нет, но, по-моему, если использовать скины и плагины, где статика подключается правильно, то в версии 1.0 уже можно попробовать вынести весь движок за пределы корневой веб-папки. Т.е. оставить, как есть папки /_run/ и /upload/ и «точку единого входа» index.php, а остальные папки можно выносить, куда угодно.

Правда, делать это все нужно руками, нет смысла включать такую опцию в установщик.

Действительно — мудрено. То нужно, чтоб условие определенное проверялось, и чтоб по этому условию работало либо так, либо эдак. То пишете, что просто index.php заменить надо.

Вы бы определились, что нужно-то. Если просто заменить — ссылку выше дал. Если нужно логику определенную реализовать — надо плагин писать. Волшебной кнопки «Сделайте мне красиво» нет и не будет.

Конечно, это НЕ нормально. Скорее всего, нет нужных прав на папку /_run

Что значит «просто заменить пути»? Ведь Вам нужно проверять, первый это заход или нет, как-то где-то сохранять это (скорее всего, в куках). Т.е. Вам нужно реализовать определенную логику, а это уже надо делать плагином

Собственно, вот: altocms.ru/117.html