+5.69
Рейтинг
15.33
Сила

Гавка Сергей

Плагин «GMapPost» (планируемый апдейт)

Всем привет!
Я планирую опубликовать новую версию плагина «GMapPost». И хотелось бы узнать какие у вас есть пожелания к новой версии.

Кроме (эти уже будут):
— Добавить блок в правой колонке с выводом карты с пикером. Карта появляется только если топик был отмечен на карте;
— Карта для определенных типов топиков. В конфиге указывать типы топиков, в которых можно указывать местоположение. Или указывать в конфиге блоги топикам которых можно пиркреплять карту;
— Перенести поля плагина из таблицу prefix_topic в отдельную таблицу, со связкой к prefix_topic.
— Вывести список стран и регионов где есть топики (где-то так tema.ru/travel/countries/).

Нужен ли плагин "Семейное положение"? (да, да!)

Короче, есть кое какие наработки (не спрашивайте зачем) и хочется знать нужен ли такой функционал. Если да, то я допилю плагин и выложу (скорее платным), если нет — оставлю код валяться без толку.
Общие функции:
  • указание СП (привет, вк!);
  • в случае указания СП предусматривающее партнёра, указание оного;
  • подтверждение СП;

Плагин «GMapPost» (edition «GeoPost»)

Хочу вам представить плагин «GMapPost» (Карта топиков) — переделанный «GeoPost».
Основное отличие от прародителя в том, что тут используется Google Maps. Но, также можно подключать и другие карты, типа OpenStreetMap, через Google Maps API (ImageMapType).

Читать дальше →

Плагин «Знание языков»


Не давно был у меня «интересный заказ», и вот после него остались некоторые наработки. Одна из них, это плагин «Знание языков», который позволяет пользователям указывать языки которые они знаю, и после они будут отображаться в его профиле.

Читать дальше →

[Решено] Множатся сессии в БД

Возникла следующая проблема: в таблице prefix_session очень много наплодилось сессий для каждого пользователя при том отличается только session_date_create и иногда IP сессии. При том для этих всех сессий пользователя session_date_last одинаковое, а это создаёт проблему для раздела /people/online, поскольку один пользователь может занимать там аж 25 первых строчок… и таким образом только он будет показан в списке.
В чём может быть проблема?

UPD. Решение 1.
Пока решил следующим образом:
В файле User.mapper.php добавил, то что отмечено:
public function UpdateSession(ModuleUser_EntitySession $oSession) {
		$sql = "UPDATE ".Config::Get('db.table.session')."
			SET
				session_ip_last = ? ,
				session_date_last = ?
			WHERE user_id = ? 
                        AND session_key = ? -- тут
		";
		return $this->oDb->query($sql,$oSession->getIpLast(), $oSession->getDateLast(),
                        $oSession->getUserId(),
                        $oSession->getSessionKey() // и тут
                );
	}

Это позволяет обновлять только текущую сессию пользователя, таким образом остальные копии (дубликаты) сессии пользователя не будут обновлены и не будут мусорить. На только почистить старые сессии из БД.

UPD. Причина.
Причиной послужило то, что когда-то был включён плагин «Remember me», который преобразовывает таблицу сессий. Но после отключения он должен всё вернуть на место, чего по какой-то причине не произошло (из-за неправильного отключения плагина: из файла plugins.dat; или из-за неисправности кода плагина; не могу быть уверен в правильном варианте).
Спасибо, vdenu .

Решение 2 (правильное).
Сделать поле user_id уникальным. Перед этим может понадобится очистить таблицу.

В самом плагине есть такой запрос:
TRUNCATE TABLE `prefix_session`; ALTER TABLE `prefix_session` DROP INDEX `user_id` , ADD UNIQUE `user_id` ( `user_id` );

Плагин "My Login"


Основной функционал плагина:
  • Позволяет пользователям менять логин;
  • Поддержка коротких ссылок для профилей пользователей (site.com/user1);
  • Поддержка поддоменов для профилей пользователей (user1.site.com);

То есть, плагин позволяет пользователю изменять свой логин. Эта функция доступна в настройках аккаунта. В совокупности с остальным функционалом плагина, мы получаем полезный инструмент для поднятия мини соц. сетей. Ведь, мы все этим занимаемся! ;D

Так же тут учтено то, чего нет в shortprofile: при регистрации или изменении логина не возможно выбрать такой логин, какой бы вёл на существующие разделы сайта, например, не можно зарегистрировать пользователя с логином blogs.

С ссылками на профиль дело обстоит так: мы можем включить одну из функций, или короткие URLs, или поддомены, или оставить как есть, используя при этом только функцию изменения логина. А можно и наоборот: включать только ссылки.

При этом, для работы поддоменов вы должны настроить сервер так, чтобы все запросы с поддоменов передавались на основной домен. То есть, нужно прописать alias вида *.site.com. Дальше скрипт всё сделает сам.

При всём этом, я постарался сделать плагин совместимым с NiceURL. Тут основным условием является, то что надо обязательно указывать в NiceURL постфикс для ссылок (.html, .htm или .php). А также, добавил фикс для того, чтобы подружить NiceURL и RusURLs, но для этого плагин «My Login» должен всегда быть выше в списке plugins.dat, чем NiceURL

Установка:
После активации плагина, получаем ошибку 404, и это нормально. Так происходит потому, что в плагине меняется адрес админки: site.com/admin на site.com/ls_admin. Это нужно для того, чтобы не было конфликта между коротким адресом профиля админа и админкой. То же самое происходит и при дезактивации.

При активации все сессии пользователей удаляются, то есть все пользователи будут разлогинены. Это надо для того, чтобы записать правильную сессию для поддоменов.

Для правильной работы плагина нужно в config.local.php указать вручную `path.root.web` (настоящий адрес сайта, например: «site.com.ua»).

Настройка:
Плагин настраивается в config/config.php.
$config['functions'] = array(
    'change_login' => true, // изменение логина
    // тип ссылки на профиль
    'profile_type' => 'subdomain',   // 'default' - site.com/profile/admin/
                            // 'subdomain' - admin.site.com/
                            // 'short' - site.com/admin/
);

// не допустимые логины
$config['banned_logins'] = array(
    'www',
    'error',
);

[Решено] Очистка кеша после сохранения настроек

Прошу помочь.
Я пишу плагин и мне пришлось вклиниться в уже существующею форму настроек профиля (добавляя новых инпутов), а потом по хуку в евенте ловлю значения и сохраняю их в базе. Но, почему-то изменения не отображаются сразу после редиректа назад в настройки профиля, а только после обновления страницы.
Пробовал вроде как чистить кеш программно, но не получилось, видно не так делаю.

UPD. Никто не знает/поможет?
UPD2. Перед сохранением, надо было, передать в сущность текущего пользователя новые данные.
— есть текущий пользователь, полученный из бд (сущность)
— вы получаете сабмит формы и обновляете В ТАБЛИЦЕ данные настроек сущности пользователя
— но текущая сущность пользователя $this->User_GetUserCurrent() все также остается со старыми настройками, её никто не обновлял
Спасибо PSNet .

Плагин "Время прочтения и просмотра" (обновление)

Всё не угомонюсь я со своим плагином. Вот и обновление.


Теперь плагин умеет считать не только время нужное для прочтения топика, но и время для просмотра видео из топика.
К тому же, я вывел информацию в хук topic_show_info. Есть также указать и другие хуки (несколько сразу), в которых есть объект $oTopic.

Плагин может считать видео с таких ресурсов как Youtube, Vimeo, Rutube и Coub. При этом ссылки на видео должны быть вставлены через тег video.

GitHub: github.com/sgavka/lsplugin-time-of-reading
В каталоге: catalog.livestreetcms.com/addon/view/503/