It doesn't exist. When I query it, I provide a default value to use when the actual config is not found. I do the same with SyncScreen, and as such could probably remove it from config-defaults.
I'm not sure which way is 'better' from a clarity standpoint. What do you think?
The SyncScreen setting is perfectly fine. There might be reasons to just create a wp-account that's not linked to vanilla.
But here's another concern:
Would be possible to remove the 'Edit my account' and 'Change password' menus when ProxyConnect is enabled and maybe display a link to wp's profile page instead? It might be confusing if users tried to change their credentials from within vanilla.
SyncScreen = FALSE doesn't disable linking, it disables link prompting. What actually happens is that when a user arrives at vanilla with a valid WP cookie, instead of asking them what username / email they want to create (as before), we go directly to creating an account for them using whatever we got back from Wordpress - username and email.
If the username / email is already in use, we fail silently and the user is not logged in.
3) i'm stilling getting pushed to the DefaultController regardless of original page requested, so i needed to change the following line and comment out the redirect
if ($AuthResponse == Gdn_Authenticator::AUTH_SUCCESS) { #Gdn::Request()->WithRoute('DefaultController'); Gdn::Request(); }
@binhdo With regard to overriding links from Vanilla to WP
This is of course possible, as you know. The only hesitation I have is as follows:
Currently ProxyConnect for Wordpress (and by extension for any other external application) consists of only 2 parts. 1) the Vanilla-side ProxyConnect plugin which handles all of the authentication and user creation from Vanilla's perspective, and 2) the remote plugin, which allows Wordpress to output the correct information for Vanilla's backchannel socket connection when requested.
The Vanilla-side plugin is currently extremely generic and has no concern about what type of remote authenticator is being plugged into it. The Wordpress-side plugin is very Wordpress specific (as you would expect), but this is OK since it is being installed only in Wordpress and has just one very specific set of tasks.
In order to modify links on Vanilla's side, we have 2 options:
1) Require a 3rd plugin, on Vanilla-side, specific to Wordpress (or whatever application was being "SSO'd"). This plugin would take control of the specific links we wanted to override (Edit my Account, Change Password, etc) and forward them to WP. No configuration would be necessary, but installing ProxyConnect plugin would have an additional step and thus be more complicated.
2) Add additional generic fields in the ProxyConnect dashboard config area, containing links to the User Account and Change Password pages of the remote authenticator site (WP in this case). These fields would not be specific to Wordpress, but rather apply broadly to any foreign application being SSO'd and allow forum administrators to conditionally override these links. The down side is that the config form would get much larger and more complex, and we would lose the ability to customize Vanilla specifically for WP SSO.
I hope I've been able to explain this properly, let me know if anything is unclear. What are your opinions as the potential users of this software? Which way is better/easier/clearer?
@Tim I clearly understand what you mean, but I was totally focused on the integration with WordPress. If I were to choose, I'd prefer the second option you mentioned in order to maintain an all-in-one look & feel. I guess it would need maybe three additional settings fields, so it should not become too complex.
Otherwise, where would I start if I wanted to change the way the user menus are displayed? Does it need to be an add-on or could this be achieved by creating a customised theme?
As I'm not really that PHP type of guy, I like the way you can modify or filter almost everything in WordPress via a 'functions.php' file in your theme folder. Does Vanilla offer a similar functionality?
This is working for me now - I'd had lots of issues before, but 1.6 and 3.02 seem to have solved them. I appreciate the way you've simplified the system, Tim. I'm also glad that this is getting your attention now with frequent fixes - this feature is one of the primary reasons I'm assessing Vanilla for my site.
Regarding the Edit My Account and Change Password options, I'd like to strongly vote for option 2. I'm using Vanilla with a custom website, not WP, and I want to be sure our users are not confused about their email and password existing in two locations. Since authentication is cookie based and we're not sharing passwords, there's no actual changeable password for them in Vanilla, and it would be best to keep the email the same on both databases.
Ideally if they clicked on either of these links they'd go to the corresponding locations in the account page we've created for them. Adding a few more optional fields to the ProxyConnect page would be the simplest solution and I don't think it would overly clutter the page. Perhaps if they were in an box to show that they were optional?
ditto for what madel says. i like how i currently i can add a "sign up" link to proxy connect, and now when a user clicks on "sign up" in vanilla, it gets sent to my sign up page.
having that analogy exists for when a user clicks "change my password/email" would be quite complementary to this.
I'm having difficulty understanding how this works. What's the difference between "password" and "proxy"? (version 1.0.6 on Vanilla 1.0.3). How can I create a single page for user data? What if I have a dozen logged-in users wanting to go to the forums? At what point do I create this page? On user login? The page the link to the forums points to has the code to create the user data page, then redirects to the forum?
@tim I am migrating a forum from bbPress to Vanilla 2.10.18b2. I´m using embed vanilla + proxy connect. I have imported all users and discussions from bbPress with some hacks (user table wp_users -> bb_users + assign roles to imported users) and everything rocks now(except logout problems). I use "Proxy" and the existing users have accounts in both WP and Vanilla(imported users). Is there some way to skip the step where Vanilla asks for link accounts? The members already have accounts and don't want to put in the password again + they get confused about the choice 'New account' or 'Link account' I would like to thank the Vanilla team for a great piece of software and awesome WP integration. /T
Tim, Does ProxyConnect work with Vanilla 2.0.1.7.10? I have been trying to setup it up but I get an error message when I click on Settings from the plugin list.
Your help is appreciated. Does this look like a permissions issue?
This is the ERROR MESSAGE:
FATAL ERROR IN: Gdn_PluginManager.xAvailablePluginFolders(); "The "Gdn_PluginManager" object does not have a "xAvailablePluginFolders" method." LOCATION: C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php > 163: // Make sure that $ActualMethodName exists before continuing: > 164: if (!method_exists($this, $ActualMethodName)) { > 165: // Make sure that a plugin is not handling the call > 166: if (!Gdn::PluginManager()->HasNewMethod($this->ClassName, $ReferenceMethodName)) >>> 167: trigger_error(ErrorMessage('The "' . $this->ClassName . '" object does not have a "' . $ActualMethodName . '" method.', $this->ClassName, $ActualMethodName), E_USER_ERROR); > 168: } > 169: > 170: // Make sure the arguments get passed in the same way whether firing a custom event or a magic one. > 171: $this->EventArguments = $Arguments; BACKTRACE: [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php] PHP::Gdn_ErrorHandler(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php 167] PHP::trigger_error(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php 167] Gdn_Pluggable->__call(); [C:\wwwroot\mydomain.com\SubDomains\forum\plugins\ProxyConnect\class.proxyconnect.plugin.php 58] Gdn_PluginManager->AvailablePluginFolders(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluginmanager.php 432] ProxyConnectPlugin->SettingsController_ProxyConnect_Create(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.dispatcher.php 290] Gdn_PluginManager->CallNewMethod(); [C:\wwwroot\mydomain.com\SubDomains\forum\index.php 38] Gdn_Dispatcher->Dispatch();
Comments
I'm not sure which way is 'better' from a clarity standpoint. What do you think?
Vanilla Forums COO [GitHub, Twitter, About.me]
haven't figured it out fully, but the problems i stated seem to be related to other things...
But here's another concern:
Would be possible to remove the 'Edit my account' and 'Change password' menus when ProxyConnect is enabled and maybe display a link to wp's profile page instead? It might be confusing if users tried to change their credentials from within vanilla.
If the username / email is already in use, we fail silently and the user is not logged in.
Vanilla Forums COO [GitHub, Twitter, About.me]
1) git pull on vanilla master is only 2.0.1 right now, had to switch to branch unstable to get 2.0.3
2) my proxy auth page uses json instead of ini, any chance the following snippet can make it into the next update of ProxyConnect? 3) i'm stilling getting pushed to the DefaultController regardless of original page requested, so i needed to change the following line and comment out the redirect in the end it all works, thanks for the update!
This is of course possible, as you know. The only hesitation I have is as follows:
Currently ProxyConnect for Wordpress (and by extension for any other external application) consists of only 2 parts. 1) the Vanilla-side ProxyConnect plugin which handles all of the authentication and user creation from Vanilla's perspective, and 2) the remote plugin, which allows Wordpress to output the correct information for Vanilla's backchannel socket connection when requested.
The Vanilla-side plugin is currently extremely generic and has no concern about what type of remote authenticator is being plugged into it. The Wordpress-side plugin is very Wordpress specific (as you would expect), but this is OK since it is being installed only in Wordpress and has just one very specific set of tasks.
In order to modify links on Vanilla's side, we have 2 options:
1) Require a 3rd plugin, on Vanilla-side, specific to Wordpress (or whatever application was being "SSO'd"). This plugin would take control of the specific links we wanted to override (Edit my Account, Change Password, etc) and forward them to WP. No configuration would be necessary, but installing ProxyConnect plugin would have an additional step and thus be more complicated.
2) Add additional generic fields in the ProxyConnect dashboard config area, containing links to the User Account and Change Password pages of the remote authenticator site (WP in this case). These fields would not be specific to Wordpress, but rather apply broadly to any foreign application being SSO'd and allow forum administrators to conditionally override these links. The down side is that the config form would get much larger and more complex, and we would lose the ability to customize Vanilla specifically for WP SSO.
I hope I've been able to explain this properly, let me know if anything is unclear. What are your opinions as the potential users of this software? Which way is better/easier/clearer?
Vanilla Forums COO [GitHub, Twitter, About.me]
Otherwise, where would I start if I wanted to change the way the user menus are displayed? Does it need to be an add-on or could this be achieved by creating a customised theme?
As I'm not really that PHP type of guy, I like the way you can modify or filter almost everything in WordPress via a 'functions.php' file in your theme folder. Does Vanilla offer a similar functionality?
http://vanillaforums.org/discussion/12341/single-sign-on-proxyconnect-instructions-out-of-date-/#Item_2
http://vanillaforums.org/discussion/12318/proxyconnect-doesnt-redirect-to-login-page/#Item_8
I also responded to your other question regarding the signinloopback issue. Please get back to me asap.
Vanilla Forums COO [GitHub, Twitter, About.me]
Regarding the Edit My Account and Change Password options, I'd like to strongly vote for option 2. I'm using Vanilla with a custom website, not WP, and I want to be sure our users are not confused about their email and password existing in two locations. Since authentication is cookie based and we're not sharing passwords, there's no actual changeable password for them in Vanilla, and it would be best to keep the email the same on both databases.
Ideally if they clicked on either of these links they'd go to the corresponding locations in the account page we've created for them. Adding a few more optional fields to the ProxyConnect page would be the simplest solution and I don't think it would overly clutter the page. Perhaps if they were in an box to show that they were optional?
having that analogy exists for when a user clicks "change my password/email" would be quite complementary to this.
Vanilla Forums COO [GitHub, Twitter, About.me]
I´m using embed vanilla + proxy connect.
I have imported all users and discussions from bbPress with some hacks (user table wp_users -> bb_users + assign roles to imported users) and everything rocks now(except logout problems). I use "Proxy" and the existing users have accounts in both WP and Vanilla(imported users). Is there some way to skip the step where Vanilla asks for link accounts? The members already have accounts and don't want to put in the password again + they get confused about the choice 'New account' or 'Link account'
I would like to thank the Vanilla team for a great piece of software and awesome WP integration.
/T
Vanilla Forums COO [GitHub, Twitter, About.me]
Does ProxyConnect work with Vanilla 2.0.1.7.10? I have been trying to setup it up but I get an error message when I click on Settings from the plugin list.
Your help is appreciated. Does this look like a permissions issue?
This is the ERROR MESSAGE:
FATAL ERROR IN: Gdn_PluginManager.xAvailablePluginFolders();
"The "Gdn_PluginManager" object does not have a "xAvailablePluginFolders" method." LOCATION: C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php > 163: // Make sure that $ActualMethodName exists before continuing: > 164: if (!method_exists($this, $ActualMethodName)) { > 165: // Make sure that a plugin is not handling the call > 166: if (!Gdn::PluginManager()->HasNewMethod($this->ClassName, $ReferenceMethodName)) >>> 167: trigger_error(ErrorMessage('The "' . $this->ClassName . '" object does not have a "' . $ActualMethodName . '" method.', $this->ClassName, $ActualMethodName), E_USER_ERROR); > 168: } > 169: > 170: // Make sure the arguments get passed in the same way whether firing a custom event or a magic one. > 171: $this->EventArguments = $Arguments; BACKTRACE: [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php] PHP::Gdn_ErrorHandler(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php 167] PHP::trigger_error(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluggable.php 167] Gdn_Pluggable->__call(); [C:\wwwroot\mydomain.com\SubDomains\forum\plugins\ProxyConnect\class.proxyconnect.plugin.php 58] Gdn_PluginManager->AvailablePluginFolders(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.pluginmanager.php 432] ProxyConnectPlugin->SettingsController_ProxyConnect_Create(); [C:\wwwroot\mydomain.com\SubDomains\forum\library\core\class.dispatcher.php 290] Gdn_PluginManager->CallNewMethod(); [C:\wwwroot\mydomain.com\SubDomains\forum\index.php 38] Gdn_Dispatcher->Dispatch();