просто вызвать событие

Суть то не в событии, а в том, что после него.

?

сам то логин происходит в \plugins\user\joomla\joomla.php

Сам логин проиходит вот тут https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Authentication/Authentication.php

нет

нет

Да =)

в \plugins\user\joomla\joomla.php

в \plugins\user\joomla\joomla.php

Это логин joomla

это юзер Joomla

а у нас все юзеры это юзеры жумлы

это юзер Joomla

Вот функция логина https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Application/CMSApplication.php#L787

та ну нет конечно :) это метод аутентификации

а не логина

а у нас все юзеры это юзеры жумлы

увы нет, все равно дергается ядро

а логин происходит в \plugins\user\joomla\joomla.php

ничего не дергается :)

та ну нет конечно :) это метод аутентификации

Это фукция aplication login

плаг только оболочка для cms

достаточно вызвать событие onUserLogin

проще посотрите метод onUserLogin в \plugins\user\joomla\joomla.php

а что делает onUserLogin?

собственно логин :)

а что делает onUserLogin?

Зависит от плагина. Joomla ставит сессию

создает запись в базу в таблицу сессий

и прочее

т.е. какие-то действия в процессе авторизации, но не саму авторизацию

как раз саму авторизацию

это и есть авторизация

факт поднятия сессии не означает факта авторизации

создает запись в базу в таблицу сессий

Я понял ты предлаешь. вот этот кусок https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Application/CMSApplication.php#L834-L859 Вписать в плагин

та ну зачем? :)

просто вызвать событие :)

просто вызвать событие :)

А остальные плагины куда

проверка ответа от социалки все равно проихсодит в плагине

какие остальные?

мы ж говорим о логине из социалки?

какие остальные?

Вот эта часть: if ($response->type === 'Cookie') { $user->set('cookieLogin', true); } if (in_array(false, $results, true) == false) { $options['user'] = $user; $options['responseType'] = $response->type; // The user is successfully logged in. Run the after login events $this->triggerEvent('onUserAfterLogin', array($options)); }

ответ от социалки мы проверим все равно в плагине, так ведь?

а зачем они нужны нам в данном случае не могу понять?

ответ от социалки мы проверим все равно в плагине, так ведь?

А после логина?

а после если ответ нас устроит - вызываем onUserLogin

все :)

обхъект $user мы создадим по ответу из социалки

Я же говорю ты предлагаешь. Засуть почти всю функцию авторизацию, а именно такой кусок $results = $this->triggerEvent('onUserLogin', array((array) $response, $options)); /* * If any of the user plugins did not successfully complete the login routine * then the whole method fails. * * Any errors raised should be done in the plugin as this provides the ability * to provide much more information about why the routine may have failed. */ $user = \JFactory::getUser(); if ($response->type === 'Cookie') { $user->set('cookieLogin', true); } if (in_array(false, $results, true) == false) { $options['user'] = $user; $options['responseType'] = $response->type; // The user is successfully logged in. Run the after login events $this->triggerEvent('onUserAfterLogin', array($options)); } В плагин

а, ну можно и так, да

а, ну можно и так, да

А смысл?

смысл в том что нам в данном случае не нужны все равно остальные плагины аутентификации

они бесполезны, они не сработают все равно

ну и в одном плагине смысл :)

смысл в том что нам в данном случае не нужны все равно остальные плагины аутентификации

Так отлкючить их и все.

так не...

юзер же может и просто по мылу залогиниться...

это ж всего один из вариантов

но просто если работает логин по социалке - то можно и без плагина группы authentication обойтись

это ж всего один из вариантов

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

та ну вызов события же :)

не, может и перебор конечно

чисто архитектурно не очень правильно просто

но зато технически будет 1 плагин :)

чисто архитектурно не очень правильно просто

О том и речь. Кроме того придеться следиться за изминениями и все-таки вызывать не одно событие, а три.

но зато технически будет 1 плагин :)

Если говорить о социалках, то и целый компонент не повредит или как в акееба отдельная библиотека.

Но мысль забавная =)

О том и речь. Кроме того придеться следиться за изминениями и все-таки вызывать не одно событие, а три.

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

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

Но зато ты доказал, что такое сделать возможно и по кол-ву кода выйдет столько же сколько и отдельный плагин.

О кстати, надо записать в todoist исправить версию fb api в своем компоненте профилей.

опять что то поменяли?

опять что то поменяли?

У меня прописана v2.12. Написали что поддержка заканчивается.

В целом, все так же, пишите сочинение на тему зачем вам эти данные и функции, показывайте как используется и т.д Стало хуже чем у instagramm. Мое самое любимое api - это api vk. Печислил какие права нужны, получил токен и делай что хочешь.

Угу во ВКонтакте хоть особо ничего не меняется...а самое главное товарищи из Фейсбука убили по сути то к чему стремились )) хотя... Не исключено что сейчас им выгодно отключить все левые приложения... Так как ресурсов на них наверняка много уходит

Угу во ВКонтакте хоть особо ничего не меняется...а самое главное товарищи из Фейсбука убили по сути то к чему стремились )) хотя... Не исключено что сейчас им выгодно отключить все левые приложения... Так как ресурсов на них наверняка много уходит

Суть не удобства API FB не в отключении приложений, а в том как они сделали запрос разрешения. Надо показывать уже готовое использование, той или иной функции. Так что запросить права на "все" по принципу потом может пригодиться уже не получиться. Кроме того по каждому "разделу" api отдельно заявку писать. В общем жутко не удобно.

Угу а список чего можно запросить очень узок

Без модерации

Без модерации

Вроде в новых приложениях уже все с модерацией, даже base (имя фото id)

С другой стороны они действительно проверяют и делают это быстро.

Суть не удобства API FB не в отключении приложений, а в том как они сделали запрос разрешения. Надо показывать уже готовое использование, той или иной функции. Так что запросить права на "все" по принципу потом может пригодиться уже не получиться. Кроме того по каждому "разделу" api отдельно заявку писать. В общем жутко не удобно.

ну их дрючат же

Вроде авторизацию можно провести... Хотя хз... Просто подключение Фейсбук было и так не простым кантом теперь его пройти можно только если очень надо... Плюс как это защитит от сбора данных не понятно... Ну скажу что я делаю мобильное приложение и может быть его даже сделаю... ))

Но данные от этого не перестанут мне доступны

То есть заинтересованные товарищи все равно пройдут квест

То есть заинтересованные товарищи все равно пройдут квест

Так всегда и бывает. Заинтересованых людей ничего не остановит, а обычные люди страдают. Но все равно это мелочи по сравнению в ok.ru где сформировать запрос это отдельный "челендж"

Так всегда и бывает. Заинтересованых людей ничего не остановит, а обычные люди страдают. Но все равно это мелочи по сравнению в ok.ru где сформировать запрос это отдельный "челендж"

Ну да тот ещё квест )) за то если аккаунт одобрили клепай не хочу )

Вроде в новых приложениях уже все с модерацией, даже base (имя фото id)

не, основные пока без модерации

@ArkadiySedelnikov что думаяешь? теги имхо более правильно, а метки более подходит для понятия badges

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

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

Ассоциация верная и там и там tags. Но при этом мы не говорим html метки. И так же мы не говорим хешметки.

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

у меня как у человека знакомого с интернет магазинами - метки вызывают двойственные ассоциации.

точнее вообще непонятно что такое метки

а вот теги есть везде и понятны

еще со времен "облако тегов"

ну с таким же успехом можно интерпретирвать значение fields: и в xml поля, и плагины-поля, и в базе поля... вот только 90% сайтоделов в разметку даже не лезут, еще раз: перевод не для разработчиков, которые в подавляющем большинстве знают английский и корректно интерпретируют любые понятия, перевод для простых пользователей

У меня же были проблемы с путаницей с метками на яндекс картах в одном из заказов. Так и появился этот гист.

У меня же были проблемы с путаницей с метками на яндекс картах в одном из заказов. Так и появился этот гист.

+

метки - слишком много двойственных значений

а вот со времен "облака тегов" - они понятны даже на интуитивном уровне

метки - слишком много двойственных значений

именно для пользователя

Но так или иначе даже в текущей версии местами tags переведены как теги.

предлагаю замутить голосовалку на гугл-формс, ссыль на нее так же во флейм на форуме закинуть почему гуглл? да потому что яндекса в украине нет

Ну давайте поголосуем и решим раз и навсегда как правильно. Метки даже не я придумал, они очень давно. Я просто придерживаюсь codestyle перевода.

предлагаю замутить голосовалку на гугл-формс, ссыль на нее так же во флейм на форуме закинуть почему гуглл? да потому что яндекса в украине нет

два варианта?