логи php ошибок не содержат? Время работы скриптов достаточно большое? Может оно по таймауту отваливается? (медленная система, длительное время отработки скриптов обрабатывающих загрузку?)

вы не ответили на мой вопрос. вопрос был таким: какое расширение? Хорошо. будем считать что расширение роли не играет (в действительности движок обрабатывает разные типы содержимого в графических данных по разному, соответственно от того какая версия у вас php или конкретной библиотеки — могут быть неожиданности). Тогда надо искать проблемное место как описано выше.

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

какое расширение? что в логах?

Это какая версия движка? Показанный вами шаблон не является шаблоном experience-simple версий 1.1.х . Во первых конверта там где он у вас- в шаблоне experience-simple нет, во вторых кнопки «создать» справа от админа — тоже в шаблоне experience-simple нет.
Либо ваш движок кто-то пилил, и тогда про конверт надо спрашивать у автора, либо вы что-то путаете...

вы не находите противоречия в сформулированном вами вопросе? вы хотите не авторизовывать пользователя, но вы хотите чтобы он был авторизован.

Число «И» у подписчиков — величина мнимая.

понятно. спасибо.

ясно. спасибо

Поле типа «файл» это вполне конкретное доп. поле. Их может быть много.
Упомянутые «Дополнительные поля» — это именно что дополнительные поля, которых может быть сколько угодно почти каких угодно.

Так что какой вопрос такой ответ.

Логика работы CMS с дополнительным полем типа файл — несколько иная чем с другими типами дополнительных полей. Например с текстовыми.

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

Но ведь дополнительные поля топика где-то регистрируются? Следовательно где то обязана быть сущность которая будет отлична от нуля если есть хотя бы одно любое дополнительное поле?

То есть в cms нет такой сущности, которая бы была отлична от нуля если у топика существует хотя бы одно, любое, дополнительное поле? Поиск этого хотя бы одного, любого дополнительного поля надо делать перебором?

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

а без $iFileFieldId нельзя? мне ведь не важно какие там поля и сколько их. важно что они есть — любые...

включите в админке объединение их в один файл, отдайте его nginx0-ом и забудьте о что вы когдато мечтали об отдельном домене для «не всех css и js »

кстати, если решать задачу через 302 или 301 код вебсервера — то можно в несколько строчек сделать пул доменов для статики — отдельно для js,css, img, отдельно для картнок лежащих по пути .../2016/04/... отдельно для .../2016/05/... .../2016/06/... и т.д. Фича с доменом для статики насколько я понимаю таким богатством выбора не балует?

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

Но я честно говоря не вижу особого смысла в этой фиче, потому что:
1) аналог этого на уровне веб сервера- одна строка с 302 или 301 кодом...
2) в случае nginx — обработка php и так по умолчанию делается через сеть — теость пул воркеров может быть разбросан по десятку серверов, а сам nginx отдает ту самую статику...
3) один домен -это не решение проблемы. если нужен отдельный домен для статики — то там на самом деле должен быть пул доменов... а ни тот плагин, ни altocms пула доменов для статики не дают...

В общем фича забавная, но с практической точки зрения малополезная.

разве это не работает изкаропки? посмотрите конфиг altocms

Как это изменение повлияет на плагины для ветки 1.1.* ?