Посмотрел, работать будет, но не целиком — оригинал изображения останется на сайте, а вот сгенерированные файлы (миниатюры и отображаемые пользователю) перенесутся.
Хотя плагин, честно говоря сыроват — удаление не поддерживается, плюс не перекрыты функции для работы с путями (GetWebPath и GetServerPath).
Персональные блоги в списке блогов не выводятся.
Для того, чтобы разрешить админу иметь персональный блог необходимо вместо удаления строки, обернуть ее проверкой:
Вы правы, данная проблема вызвана добавлением топика напрямую в БД из-за чего NiceURL не сформировал для него ссылку.
Способы исправления:
1) просто отредактировать топик — плагин сгенерирует ссылку;
2) деактивировать, а затем снова активировать плагин — ссылки будет перегенерированы для всех топиков (при большом числе топиков могут быть проблемы с временем выполнения скрипта);
3) вручную добавить поле в таблице «prefix_niceurl_topic» по аналогии с существующими.
Их — это настройки? Пользователи шаред хостинга не имеют доступа к настройкам PHP. В лучшем случае часть директив можно переопределить в файле ".htaccess" в корневом каталоге.
Например, на хостинге, который вообще не предоставляет доступа к логам, пришлось настроить вывод ошибок PHP в отдельный файл с помощью следующего набора директив в файле ".htaccess"
# PHP error handling for development servers
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag log_errors on
php_flag ignore_repeated_errors off
php_flag ignore_repeated_source off
php_flag report_memleaks on
php_flag track_errors on
php_value docref_root 0
php_value docref_ext 0
php_value error_log /var/sites/site.ru/htdocs/logs/php_errors.log
php_value error_reporting -1
php_value log_errors_max_len 0
Изменились директиры в файле настройки самого PHP, например. На хостинге тоже люди работают, могли просмотреть что-то…
Кстати проверить просто — с помощью PHP функции «error_log».
Надеюсь ты верно понял — установленный на том же сервере, где и само приложение, message сервер сильно сэкономит ресурсы.
Естественно.
Кароче, я хочу сказать, что для сайтов, использующих виртуальный хостинг, не понадобится подобный функционал, так как аудитории там и нет, да и не будет там 20 юзеров онлайн, а если есть столько, то врятли виртуальный хостинг нормально справляется.
А может уже успели собрать статистику по нагрузке на сервер при использовании Вашего плагина в зависимости от числа одновременно подключенных пользователей?
В чистом LS нет возможности удаления пользователей. Но их можно удалить из базы данных, только осторожно — если пользователь что-то писал, то можно поломать сайт неаккуратными действиями.
Хотя плагин, честно говоря сыроват — удаление не поддерживается, плюс не перекрыты функции для работы с путями (GetWebPath и GetServerPath).
Хотя, дайте ссылку, посмотрю.
Для того, чтобы разрешить админу иметь персональный блог необходимо вместо удаления строки, обернуть ее проверкой:
{if $oUserCurrent->isAdministrator()} <option value="0">{$aLang.topic_create_blog_personal}</option> {/if}Способы исправления:
1) просто отредактировать топик — плагин сгенерирует ссылку;
2) деактивировать, а затем снова активировать плагин — ссылки будет перегенерированы для всех топиков (при большом числе топиков могут быть проблемы с временем выполнения скрипта);
3) вручную добавить поле в таблице «prefix_niceurl_topic» по аналогии с существующими.
/** * Получаем список фото */ $aPhotos = $oTopic->getPhotosetPhotos(getRequestStr('last_id'), Config::Get('module.topic.photoset.per_page')); $aResult = array(); if (count($aPhotos)) { /** * Формируем данные для ajax ответа */ foreach($aPhotos as $oPhoto) { $aResult[] = array('id' => $oPhoto->getId(), 'path_thumb' => $oPhoto->getWebPath('50crop'), 'path' => $oPhoto->getWebPath(), 'description' => $oPhoto->getDescription()); } $this->Viewer_AssignAjax('photos', $aResult); }Используется функция «getDescription» класса «EntityTopicPhoto».
Самый простой способ — просто заменить в файле "/templates/skin/synio/header.tpl" строку
<div id="wrapper" class="{if $noSidebar}no-sidebar{/if}{hook run='wrapper_class'}">на строку
<div id="wrapper" class="{hook run='wrapper_class'}">Но это будет воздействовать на все страницы сайта…
Более корректный вариант — написать плагин, который будет вешать хук на «wrapper_class» и добавлять нужный класс для конкретных страниц.
Например, на хостинге, который вообще не предоставляет доступа к логам, пришлось настроить вывод ошибок PHP в отдельный файл с помощью следующего набора директив в файле ".htaccess"
Ошибки apache все равно не доступны, но хоть так.
1) поле `user_profile_avatar` — содержит полный веб-путь к файлу аватара;
2) поле `user_login` — логин пользователя;
и т.д.
Кстати проверить просто — с помощью PHP функции «error_log».
Ну, стопроцентной гарантии никто не даст, но вероятность напортачить с его использованием намного меньше.
А может уже успели собрать статистику по нагрузке на сервер при использовании Вашего плагина в зависимости от числа одновременно подключенных пользователей?