Gorets
-
Публикации
116 -
Зарегистрирован
-
Посещение
-
Дней в лидерах
1
Сообщения, опубликованные пользователем Gorets
-
-
При формировании define( 'DOMAIN', $domain_cookie ); учитывать возможные настройки сервера, иначе куки и сессии выставляются для www.site.org.ua и на info.site.org.ua уже не доступны.
Я у себя прописал в .htaccess
php_value session.cookie_domain .site.org.ua
необходимо проверять:$currentCookieParams = session_get_cookie_params(); $currentCookieParams["domain"];
и если домен задан настройками сервера, то отдавать этим настройкам предпочтение.
-
Сделать единую точку входа для всех AJAX запросов сайта!
Ну это же просто идиотизм во всех файлах /engine/ajax/ дублировать один и тот же код!
Как вариант все запросы отсылать на /index.php а потом по заголовку HTTP_X_REQUESTED_WITH отлавливать AJAX и перенаправлять в нужное место.
-
запрос для извергов
зато прекрасно справляется со свое задачей
-
В мастере оптимизации есть пересчёт статистики, если не ошибаюсь он произведёт обновление кол-ва ПМ.
ошибаетесь... я предложил этот вариант разработчику скрипта включить в ДЛЕ, но получил отказ.
Я прекрасно понимаю, что это может понадобиться единицам, но всё же...
-
Мастер оптимизации -> 4. Очистка персональных сообщений пользователей
Вы можете очистить все персональные сообщения ваших пользователей
А не сильно ли кардинально? В базе полно нормальных сообщений!
-
После массовой рассылки спамерских ПМ пользователям сайта пришлось вручную в таблице dle_pm удалять строки т.к. другого иного стандартного способа управления ПМ в DLE не существует.
После удаления записей возникла необходимость пересчитать общее количество и количество непрочитанных ПМ в таблице пользователей dle_users
Предлагаю вниманию один из возможных вариантов решения данной задачи. Достаточно выполнить один запрос к базе данных:
update `dle_users` u left join ( select usr.user_id, usr.name, CASE WHEN ISNULL(pm.kvo) THEN 0 ELSE pm.kvo END as pm_all , CASE WHEN ISNULL(pm_unread.kvo) THEN 0 ELSE pm_unread.kvo END as pm_unread from `dle_users` usr left join ( select `user`, count(`user`) as kvo from dle_pm p where p.folder='inbox' group by p.`user`) pm on usr.`user_id` = pm.`user` left join ( select `user`, count(`user`) as kvo from dle_pm p2 where p2.folder='inbox'and p2.pm_read='no' group by p2.`user`) pm_unread on usr.`user_id` = pm_unread.`user` ) pm_select on pm_select.user_id = u.`user_id` set u.`pm_all` = pm_select.pm_all, u.`pm_unread` = pm_select.pm_unread
код приведен для стандартного префикса таблиц 'dle_'
Тестировалось на DLE 9.4, но быстрее всего будет актуально для всех версий скрипта за последние пару лет.
-
Временное решение нашел, отключил блокировку после 3 ошибок авторизации, но почему оно возникает, если включено?
Быстрее всего проблемы в настройках хостинга. Для движка все пользователи видны с одного IP, а не со своих реальных, вот и происходит блокировка для всех после того, как хоть кто-то один введет 3 раза неверный пароль.
Так что трясите админов, пусть нормально настраивают хостинг.
-
Разделить понятия "Включить поддержку регистрации и авторизации на сайте" на два отдельных. Мне нужно, чтобы пользователи могли авторизовываться, но не регистрироваться. Регистрировать я их буду сам в админке.
-
Последовательность шрифтов в дефолтовых шаблонах и в админке сменить на font-family: verdana,arial,Tahoma,helvetica,sans-serif; а то под линуксом всё смотрится очень некрасиво.
-
Так намного удобнее будет работать с авторизацией на поддоменах сайта, т.е. авторизовавшись на основном сайте site.ru эта-же авторизация будет актуальна и на help.site.ru
Это давно уже стандартная возможность скрипта и ничего не нужно делать или дописывать. Авторизация автоматически распространяется и домен и все его поддомены.
К сожалению Вы немного ошибаетесь. Cookie dle_user_id действительно устанавливаются для домена .site.ru а вот куки сессий устанавливаются жестко www.site.ru и соответственно потом не доступны на help.site.ru
В итоге залогиниться получается и на сайте и автоматом на поддоменах по ($_COOKIE) , а вот выполнить logout получается только в одном месте т.к. не доступна кука с сессией, которую надо бы удалить, и во втором месте идет авторизация по этой оставшейся сессии.
-
По аналогии с функцией set_cookie() сделать функцию set_session() и все вызовы в скриптах @session_start (); делать через новую функцию.
Пример функции:
define( 'DOMAIN', ".site.ru" ); set_session() { $currentCookieParams = session_get_cookie_params(); session_set_cookie_params( $currentCookieParams["lifetime"], $currentCookieParams["path"], DOMAIN, $currentCookieParams["secure"], $currentCookieParams["httponly"] ); }Так намного удобнее будет работать с авторизацией на поддоменах сайта, т.е. авторизовавшись на основном сайте site.ru эта-же авторизация будет актуальна и на help.site.ru
-
1
-
-
На сколько я вижу, то проблеме уже как минимум месяц Bug #4306, но решения еще нет. Может стоит временно откатиться на старую версию редактора с внесением в него тега media?
У меня на сайте оперой пользуется порядка 35% пользователей и все они не смогут добавить новость...
-
www.stakhanov.org.ua
ДЛЕ 9.3 в админке в визинг редакторе не вставляется текст по ctrl+v
Браузер Опера 11.10
-
1. Систему кэширования ДЛЕ переписать в отдельный класс с возможностью выбирать тип кэша: на файлах, как сейчас или к примеру memcached.
2. Для снижения нагрузки на базу данных таблицу dle_users разделить на 2 таблицы к примеру dle_users и dle_users_info. В первой таблице оставить поля, необходимые для авторизации пользователя и все часто меняющиеся поля, а во вторую таблицу вынести поля, которые изменяются очень редко: info, signature, fullname, foto и т.д.
3. Данные из таблицы dle_users_info кэшировать, чтобы снизить нагрузку mysql.
-
Сделать систему приватных сообщений наподобии как сейчас сделано на одноклассниках.
-
Функция API change_user_name
Оригинал в админке:
$editlogin = $db->safesql( $parse->process( $_POST['editlogin'] ) );
Через API$new_name = $this->db->safesql( $new_name );
Оригинал в админке:$db->query( "UPDATE " . PREFIX . "_post SET autor='$editlogin' WHERE autor='{$row['name']}'" ); $db->query( "UPDATE " . PREFIX . "_comments SET autor='$editlogin' WHERE autor='{$row['name']}' AND is_register='1'" ); $db->query( "UPDATE " . USERPREFIX . "_pm SET user_from='$editlogin' WHERE user_from='{$row['name']}'" ); $db->query( "UPDATE " . PREFIX . "_vote_result SET name='$editlogin' WHERE name='{$row['name']}'" ); $db->query( "UPDATE " . PREFIX . "_images SET author='$editlogin' WHERE author='{$row['name']}'" ); $sql_update .= ", name='$editlogin'";Через API всего лишь$q = $this->db->query( "update " . USERPREFIX . "_users set name = '$new_name' where user_id = '$user_id'" );
Уважаемый автор API, обратите пожалуйста внимание на эти различия. Это первое, что бросилось в глаза.
Так-же очень хотелось бы услышать коментарии celsofta.
DLE и iframe в новой версии DLE
в DataLife Engine (Общие вопросы)
Опубликовано:
http://maps.visicom.ua