Вообще, в плане оптимизации скриптов — поле непаханное.
Например, кроме разбивки на два блока скриптов, как писал выше в комментах (т.е. что-то грузим в хедере, что-то в футере), можно (нужно) еще поэкспериментировать с атрибутами defer и async, объединяя скрипты в группы с одинаковыми атрибутами. Например, если используется какой-то скрипт без зависимостей — можно смело ему ставить async — пусть браузер сам решает, когда его грузить и выполнять. А jquery-плагины можно объединять в группу с defer, подключая их после jquery.
Думаю, можно таким способом оптимизировать: общий набор скриптов так и оставить единым для всех страниц, но разбить его на две части — первую (базовую) загружать в хедере, а вторую в футере. И хоть файлов из одного станет два, но на всех страницах они будут одни и те же
Если речь про значение «full time», которое выводится в футере, то у Альто там два числа: первое считается, как у ЛС, а второе — «по чесноку». Но это, в любом случае, не связано с js, т.к. считается время обработки на сервере, а the-boss ведет речь о файлах, которые грузятся на странице в браузере у юзера
Я так понимаю, правили файл /common/templates/language/ru.php? Все файлы, которые редактируете, нужно обязательно сохранять в формате «UTF-8 без BOM». Откройте файл и пересохраните его в правильном формате.
Могу предположить, что из-за этого возникают проблемы с куками или с переменными сессии, и это выходит боком при загрузке изображений.
Многие вещи, на мой взгляд, становятся очевидными, стоит лишь глянуть на структуру базы данных.
Данные пользователей хранятся в таблице с названием prefix_user. Е-мейл, логин и имя — в колонках user_mail, user_login, user_profile_name соответственно.
Пароль — в user_password, хеш пароля — это комбинация md5 и sha1 с солью. Но для целей обратной совместимости движок понимает и обычный md5 без всяких довесков.
Да в том-то и дело, что есть: demo.altocms.com/new/
Но вот конкретно этот баг ни там не вылезал почему-то, ни локально у меня :(
Пока скрин с текстом в шаблоне не показали, не мог понять, в чем проблема
Я же ответил: Это какой-то баг шаблона, но на чистом движке такого не вижу. Возможно, какой-то плагин это дает. Попробуйте их попеременно отключать и проверять.
MenuTest — это демонстрационный плагин для работы с меню. Вы им как пользуетесь?
Counters и Просмотры — они разве не одно и то же делают?
Рейтинговая система и Простая рейтинговая система — это же взаимоисключающие плагины. Они не могут работать корректно вместе по определению. Определитесь, какая рейтинговая система нужна, а другую непременно отключите.
Но вот что я заметил когда редактирую Топик...
Это какой-то баг шаблона, но на чистом движке такого не вижу. Возможно, какой-то плагин это дает. Попробуйте их попеременно отключать и проверять.
$config['widgets'][] = array(
// здесь настройки плагина
);
В версии 1.1.х они должны задаваться так:
$config['widgets']['stream'] = array(
// здесь настройки плагина
);
Т.е. не пустые квадратные скобки, а с идентификатором виджета. Можно посмотреть идентификаторы в файле common/config/widgets.php и задать их в конфигах других плагинов или если задавали свои параметры виджетов в app/config/widgets.php.
В таблице ?_topic_content в поле topic_extra хранятся сериализованные (упакованные) данные. Если при записи/чтении текст обрезался, то данные корректно распаковаться не могут и возникает такая ошибка.
Проблема может быть, как ни странно, в Юникоде. По умолчанию используется кодировка MySQL utf8_general_ci. Но она не поддерживает полноценный Юникод. Если в записываемых данных есть символы, которые в UTF-8 кодируюися четыремя байтами (например, символы-эмотиконы, emoji), то при кодировке utf8_general_ci записываемая строка будет обрезаться. Соответственно, при чтении она получается урезанной и не может быть корректно распакована.
Если проблема в этом, то решение:
1) Убедиться, что используется MySQL версии 5.5.3 или выше
2) Преобразовать в таблице ?_topic_content поле topic_extra в кодировку utf8mb4_unicide_ci
3) В app/config/config.local.php добавить строку
$config['db']['params']['charset'] = 'utf8mb4';
Чего я не знаю наверняка: можно ли оставить кодировку базы в целом и таблицы в целом utf8_general_ci, а только одно конкретное поле задать в utf8mb4_unicide_ci, или обязательно нужно таблице и/или базе тоже задавать эту кодировку.
Но после этой манипуляции данные нужно еще раз перенести из старой базы, т.к. в таблице они уже записаны «криво». Можно вручную перенести только таблицу ?_topic_content.
И одно замечание: данные в кодировке utf8mb4_unicide_ci занимают в базе (И, соответственно, на диске) больше места.
А денверу — увы! — пора на свалку истории.
Например, кроме разбивки на два блока скриптов, как писал выше в комментах (т.е. что-то грузим в хедере, что-то в футере), можно (нужно) еще поэкспериментировать с атрибутами defer и async, объединяя скрипты в группы с одинаковыми атрибутами. Например, если используется какой-то скрипт без зависимостей — можно смело ему ставить async — пусть браузер сам решает, когда его грузить и выполнять. А jquery-плагины можно объединять в группу с defer, подключая их после jquery.
Могу предположить, что из-за этого возникают проблемы с куками или с переменными сессии, и это выходит боком при загрузке изображений.
Данные пользователей хранятся в таблице с названием prefix_user. Е-мейл, логин и имя — в колонках user_mail, user_login, user_profile_name соответственно.
Пароль — в user_password, хеш пароля — это комбинация md5 и sha1 с солью. Но для целей обратной совместимости движок понимает и обычный md5 без всяких довесков.
Но вот конкретно этот баг ни там не вылезал почему-то, ни локально у меня :(
Пока скрин с текстом в шаблоне не показали, не мог понять, в чем проблема
Counters и Просмотры — они разве не одно и то же делают?
Рейтинговая система и Простая рейтинговая система — это же взаимоисключающие плагины. Они не могут работать корректно вместе по определению. Определитесь, какая рейтинговая система нужна, а другую непременно отключите.
Это какой-то баг шаблона, но на чистом движке такого не вижу. Возможно, какой-то плагин это дает. Попробуйте их попеременно отключать и проверять.
В версии 1.1.х они должны задаваться так:
Т.е. не пустые квадратные скобки, а с идентификатором виджета. Можно посмотреть идентификаторы в файле common/config/widgets.php и задать их в конфигах других плагинов или если задавали свои параметры виджетов в app/config/widgets.php.
Проблема может быть, как ни странно, в Юникоде. По умолчанию используется кодировка MySQL utf8_general_ci. Но она не поддерживает полноценный Юникод. Если в записываемых данных есть символы, которые в UTF-8 кодируюися четыремя байтами (например, символы-эмотиконы, emoji), то при кодировке utf8_general_ci записываемая строка будет обрезаться. Соответственно, при чтении она получается урезанной и не может быть корректно распакована.
Если проблема в этом, то решение:
1) Убедиться, что используется MySQL версии 5.5.3 или выше
2) Преобразовать в таблице ?_topic_content поле topic_extra в кодировку utf8mb4_unicide_ci
3) В app/config/config.local.php добавить строку
Чего я не знаю наверняка: можно ли оставить кодировку базы в целом и таблицы в целом utf8_general_ci, а только одно конкретное поле задать в utf8mb4_unicide_ci, или обязательно нужно таблице и/или базе тоже задавать эту кодировку.
Но после этой манипуляции данные нужно еще раз перенести из старой базы, т.к. в таблице они уже записаны «криво». Можно вручную перенести только таблицу ?_topic_content.
И одно замечание: данные в кодировке utf8mb4_unicide_ci занимают в базе (И, соответственно, на диске) больше места.
А у вас site.com/feed/ доступно для незарегистрированных юзеров?