А Петр ни разу не конкретизировал претензии к шаблону. Это во-первых. Во-вторых, кроме Петра шаблон купили еще 12 человек, и у них претензий нет, их сайты работают, не кривые и никого не отпугивают. Может быть, проблема не в шаблоне?
И я вот себя на место Петра ставлю... Блин, ну явно речь о каких-то недочетах. Их исправить самому усилий нужно явно меньше, чем он тут воюет несколько месяцев. Ну не хочешь сам, ну доплати ты к этим 3 тыщам ещё 2, найди другого и он тебе исправит эти мелочи...

Это я уважаю. Это хорошо. Тут я согласен.
Тока мы всё равно официально повлиять на возврат денег, которые Александр получил от Вас напрямую, не сможем, к сожалению.
А косвенно мы его уже наказали

Была беда с новой библиотекой Imagic, которая быстрее и как бы лучше, чем GD. Мы пока их обе оставили в пакете, чтобы если есть на хостинге одна, она работала, нету - работала старая.
Вносили правки мы в неё, косячила она, да. В 6.0.0.6 и 6.0.0.7 есть изменения в ней, вроде все норм должно быть.
Обновитесь до последней, попробуйте еще раз. Я так и не понял из стартового поста, какой версией Вы делали

Наоборот, надо GD оставить. Он же был один в 5.4
В /includes/image.php там выбор идет, но я точно не могу сказать, одной строчкой переключить, или нет. Лучше баг сделать в пожеланиях, или в ТП запрос, указав доступы к сайту и причины косяка

Скока??? Это же 32Мб! Такой файлище и комп не всякий в фотошопе обработает, а Вы хотите, что бы какая-то захудалая библиотечка РНР его переварила??? Я не знаю точно, но мне кажется, не только memory_limit нужен для обработки этого дела. И таймлимиты хостинга, и временные папки, и еще чего. Зачем на сайт грузить такие размеры фоток, я вот не пойму? Для превью фотографий? То, что ниже, достаточно 1000 пикселей, чтобы все рассмотреть.

Перемножьте пиксели. 5281 х 6265 = 32М
Именно этот массив пикселей и обрабатывает алгоритм ресайза, обрезки и пр..

4 - это jpg, чисто для экрана. Массив точек же никуда не девается, он же разворачивается при обработке

Но кстати, что можно сделать. Поставить условие перед тем, как кормить файл на обработку в библиотеку GD, сколько там у него пикселей в размере. Если более 2000, то пропускать. И это уже можно конкретно в доках описать, мол, более 2000 пикселей файлы пропускаются, дабы не насиловать хостинг. И указать место в файле, где это условие можно убрать или увеличить лимит, у кого свой сервак.
Тогда как минимум система в ошибку и подвисание вылетать не будет. Так хорошо?

На всякий случай поясню существующий алгоритм.
1. Сортировка мышкой какой была с 5.0, такой и осталась в 6.0, это сортировка с помощью JS. Мы её в 6.0 вообще не трогали. Эта сортировка ничего не обновляла после каждого перетаскивания, а просто запоминала массив с новым порядком и после ухода со страницы отправляла его в БД. За сортировку отвечает поле sort. В 5.х оно было невидимое. Т.е. зашел в список, текущие поля sort передались в JS, ты его мышкой перетусил несколько раз, ушел со страницы, оно все махом запомнилось.
При этом был косячек, если несколько одинаковых полей sort, поля не всегда вставали куда надо. Ты вроде одно поле выше другого ставишь, но оно ниже и все тут. Это потому, что sort у них одинаковый.

2. В 6.0 мы вывели поля sort на редактирование. Теперь можно сортировать как раньше, и при этом видеть, что кое-где sort одинаковый, и его можно поменять вручную. Каждое ручное изменение-созранение сразу обновляет страницу, чтобы видеть результаты. И в этом разница.
Сортировка мышкой работает в браузере, групповым образом и никак внешне не влияет на поле sort, пока не сохранишь(уйдешь или обновишь).

Это, кстати, вообще что? Это не наш интерфейс в целом. Вкладки похожи на 5.4, и только

Это уже давно забытая 5.4. Эти многочисленные мелочи, которые еще можно было как-то CSS-ами решить, но были и покрупнее косяки в верстке, костыль на костыле, что уже давно пора было новый диз и верстку, поэтому мы ввязались в 6.0.
В 6.0 же нет таких косяков?

Ну смотря что Вы имеете ввиду под "JS"
Когда я говорю, что "мы не правили JS сортировки", я имею ввиду функции, за неё отвечающие. Файлы JS мы перелопатили, конечно, дописали, расширили и подкрутили основательно.
А то знаю я вас, ща быстро скриншот сравнения файлов JS 5.4 и 6.0 приложите

Кеш отключен?

Вопросы: а вот "добавляю, перехожу в режим HTML, обратно" - переходите в HTML как? Нашей галкой, или Тиневской кнопкой? И когда сохраняете, в режиме хтмл сохраняете или в обычном визуальном?

Убирали в 6.0.0.0, так подняли бунт, верните.
У нашей галки и подсветка кода есть, и нумерация строк, и она запоминается, да. Но в публичной части нет её, вот беда, там только тиневая

Так оно в исходном коде не сохраняется? Ссылки на картинки, что ли? Вставляете три img src в ячейки таблиц, видите их в источнике визуальника, жмете сохранить и две последние img src исчезают из кода после сохранения?

Index.html - это кеш главной страницы, делается ежедневно. Нужен для того, чтобы если на хостинге сбоит бд, то на сайте не выходило "ошибка подключения к бд", а выходила морда сайта, и сайт не выпал из поиска.
Удалять его нельзя.

Какая-то конкретная беда с доступом цмс к файлам, как будто есть какие-то ограничения на хостинге на деятельность скриптов. Бывает такое, когда исполеяемые скрипты имеют отдельного пользователя в системе, отличного от фтп#пользака. И тогда скрипты могут создавать свои файлы и править их, но править другие файлы хостинг не дает. Что за хостинг? Какие параметры?
Попробуйте воткнуть 777 на все файлы админки

А это говорит о том, что Cache-Control: no-cache который CMS отдает в header, не пашет, т.к. перекрывается глобальными настройками хостинга.
В общем, надо разбираться. Давайте в ТП доступы к хостингам, раздеремся, исправим.

Другой - какой?

Очень хорошо, что локализовали причину, у нас везде РНР5.4 стоит, я сейчас посмотрел.
С шаблонами глюки, видимо, из той же оперы корнями.
Проверим на 5.5, внесем исправления в ближайшей сборке.

В общем, какое дело. Косвенно подтвердилось предположение

В действительности оказалось, если PHP 5.5 собран с поддержкой OpCache, то бывают такие ошибки. При разработке OpCache на хостинге лучше отключать. Так как этот режим сохраняет в памяти прекомпилированный байт-код скрипта.
Как это работает. Например при установке системы файл config.php пустой, и в пустом виде сохраняется OpCache-м на хостинге, а после установки системы config.php заполняется параметрами, но хостингу уже пофиг, у него в OpCache старая пустая версия, поэтому ошибка подключения и прочие глюки.
И этот OpCache как раз с 5.5 используется.
В общем, будет что-то подобное, пишите в ТП хостинга, просите убрать OpCache.
А мы в технические требования хостинга изменения внесем.

В OpCache? А он там корректируется?

Хотя достаточно в .htaccess строку

Перед установкой системы и шаблона это сделали?

А нафиг он тогда вообще нужен? Если он по факту ничего не кеширует, но еще и сам себя проверяет каждый раз, сервак грузит?

Да когда тему применяешь, система видит этот sql и предлагает его выполнить.

Ой, да, я забыл, тема затерялась, тут у нас инцидент на форуме обсуждается. Отвечу там

Вообще нет, но лучше не удалять, а переименовывать добавляя 1. Удалить всегда успеете.

На самом деле мы знаем об этом как бы косяке и разбираемся с ним. Так что не торопитесь пока

Спустя пару дней. Конечно.

Очевидно, просто обновиться