The site-wide social login system is now backwards-compatible with how
the social_login_active core pref worked since commit
3b2d8333b62290688f64e061023669463fd8f04c.
social_login_active's least significant bit is now treated as a global
bit, so if it's not set, no other bits are allowed to be set. This
un-breaks all existing checks for whether social_login_active is empty.
Except in themes, the social_login_active check has been replaced with
an e_user_provider API to check if social login is enabled site-wide.
- MOD: Replaced e107::getPref('social_login') with
SocialLoginConfigManager::getValidConfiguredProviderConfigs()
- FIX: signup_shortcodes updated with new social login providers
- MOD: e107::filter_request() code de-duplication: HTTP 400 exits
- MOD: Deprecated e107::getHybridAuth() to discourage direct access to
third-party dependency Hybridauth
- FIX: Updated e_user_provider for Hybridauth 3
- FIX: e_user::tryProviderSession() and Hybridauth 3
- NEW: Dynamic auth provider support in social_adminarea
- NEW: Database migration for social plugin's social_login pref
I think the logic for setting og:image in social plugin is to be used site wide when no other is defined, but currently it's set too early in header so for example if we looking at news item which have some images, the social plugin og:image is grabed first by fb sharer since it came first in page output. My modification check if there is og:image defined and if there is already, skips adding the social plugin one.
I think the logic for setting og:image in social plugin is to be used site wide when no other is defined, but currently it's set too early in header so for example if we looking at news item which have some images, the social plugin og:image is grabed first by fb sharer since it came first in page output. My modification check if there is og:image defined and if there is already, skips adding the social plugin one.
