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. Удалить всегда успеете.

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

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

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

Ох, Денис, Вы смешной такой иногда. Когда не выспитесь, наверное
UPDATE.txt

update.php

При чем тут 5.4->6.0..?

=

Да ну? А ну-ка, ну-ка? Это какой же файл?

Нельзя обновить 5.3 до 6.0, пропустив 5.4. Сначала 5.3 до 5.4 вручную, а затем уже до 6.0 автообновлением.

C 5.4 до 6.0 только через автообновление, как мне еще сказать?
Автообновление работает только online и только для лицензий.
6.0 - это обновление для 5.4 и отдельной самостоятельной версией не является, ядро у 6.0 и 5.4 одинаковое, т.е. 6.0 - это 5.4. Это я тоже говорил раз надцать только за последний месяц, наверное.
Стыдно, партнер, не знать этого!

=