Premium WordPress Integration

clarkwinkelmann · Jul 29, 2020

benjaminschultz did you completely restart the extension installation after fixing the HTTPS issues?

I'd recommend following https://kilowhat.net/flarum/extensions/wordpress#the-installation-wizard-is-stuck to use the Wizard again and ensure a working API key is synced between Wordpress and Flarum.

If you are completely locked outside of Flarum, you'll need to go into your database with a tool like phpMyAdmin and delete the kilowhat-wordpress.wordpress_login_only entry in the settings table, or if you ended up with all user accounts connected to Wordpress, you can unlink them by setting kilowhat_wordpress_user_id to NULL in the users table for the corresponding user, which will allow the user to login with Flarum username/password again.

Another possible reason for the "csrf_token_mismatch" error could be that just like on Wordpress, the "Authorization" header is not forwarded to Flarum by the webserver, making Flarum think it's a web request instead of an API request. Maybe the same fix that worked for Wordpress will work for Flarum if both are using the same webserver.

I hope this helps!

benjaminschultz · Jul 29, 2020

Thank you, Clark. Last night I ran composer remove kilowhat/flarum-ext-wordpress and that let me back into my backend. (Though strangely, the "login with wordpress" option was still shown as a button on the flarum login, but at least I had my regular flarum login back - for everyone's future reference it is not advisable to enable the "only allow wordpress login" option until you are sure everything is working)

Today I reinstalled the extension and continued my troubleshooting. Looking into flarum's .htaccess, I discovered that flarum's "http:authorization" line was commented out. I uncommented that line but then wordpress was back to giving a 401! Turns out, wordpress rewrites .htaccess when you save its settings.

So now finally after adding the cloudlfare origin certificate to site ground along with an additional let's encrypt certificate for both the wordpress domain and the flarum subdomain, updating the wordpress .htaccess as below and uncommenting the http authorization line in flarum's .htaccess, it is finally working!

# PREVENT WP AUTO MODS
# @ https://m0n.co/08
<IfModule mod_ignore_wordpress.c>
# BEGIN WordPress
# The directives (lines) between BEGIN WordPress and END WordPress are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

</IfModule>

# CUSTOM WORDPRESS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

I now have one final problem: upon login from flarum, wordpress is not properly redirecting. The wordpress login window stays open and redirects (within that window) to "https://concept.app/flarum-auth" which is a 404. (But I am successfully logged into flarum if I reload the page)

I'm stoked to almost be through with this journey and I hope my struggles can help others who are trying to get this running on shared hosting. Thanks for your help, @clarkwinkelmann and @[deleted]

clarkwinkelmann · Jul 29, 2020

benjaminschultz I now have one final problem: upon login from flarum, wordpress is not properly redirecting. The wordpress login window stays open and redirects (within that window) to "https://concept.app/flarum-auth" which is a 404

This seems to happen when other Wordpress plugins try to handle the redirect after login. If you're able to share which Wordpress plugins you have installed that might do that I could take a look. I'll try to work on a better solution at some point (the problem is that I pass a special token instead of a URL and my plugin is supposed to build the URL on the Wordpress side but sometimes other plugins handle the token first)

benjaminschultz Though strangely, the "login with wordpress" option was still shown as a button on the flarum login

That's probably just for cache reasons. If you remove an extension without disabling it first, it won't re-compile the javascript/css. This can be fixed by clearing the cache or enabling/disabling any other extension.

benjaminschultz · Jul 29, 2020

clarkwinkelmann

That sounds reasonable so I deactivated every plugin except for Flarum Integration... unfortunately I am still getting the same behavior, just a redirect to "primarydomain.com/flarum-auth" within the popup window.

Is there any way I can hard-code a redirect for /flarum-auth that will perform the proper behavior? I thought about just redirecting that url to my flarum homepage, but then I suppose it would open within the login-popup window...

Edit: If I log in from wordpress on a different page, then go to an existing flarum tab and click "log in with wordpress", it pops up the wordpress login window for a second then immediately closes it and properly redirects. So it clearly is capable of redirecting properly, just not on login...

clarkwinkelmann · Jul 29, 2020

benjaminschultz have you enabled SSO in the settings on the Wordpress side? Those settings are currently not automatically synced.

benjaminschultz · Jul 29, 2020

clarkwinkelmann Yep, enabled in both places... I get a good health check in the flarum admin panel, but still no proper redirect in the wordpress login popup on flarum.

[deleted] · Jul 29, 2020

benjaminschultz just a redirect to "primarydomain.com/flarum-auth" within the popup window

I get exactly the same issue - it's the same as I reported to you on Discord @clarkwinkelmann

benjaminschultz · Jul 29, 2020

[deleted]

Well I figured it out... it wasn't a plugin, but rather my theme that was hijacking login redirection requests. I'm not sure what to do about it, but my next step is to figure out how I can modify the theme I'm using to re-enable that functionality.

add_filter('login_redirect', 'login_redirect_function', 10, 3); is how the plugin performs the redirect. This filter was completely unresponsive with my theme active. With the stock 2020 theme active, it works as expected.

benjaminschultz · Jul 29, 2020

HOORAY! After many days of fumbling this plugin is now working correctly. I searched my theme files to find where it is calling the same login_redirect filter and was able to overwrite it with my child theme's functions.php file. I am using the "buddyboss" theme which has a login_redirect filter that calls a function buddyboss_redirect_previous_page. The code below removes the filter after page initialization (necessary or else the theme re-adds the filter before the page loads) and then adds the filter again at a lower priority, allowing it to continue functioning but to be overridden by the flarum integration plugin as required.

// when the init hook fires
add_action( 'init', 'remove_bb_login_filter' );

function remove_bb_login_filter() {
    // remove the filter
	remove_filter( 'login_redirect', 'buddyboss_redirect_previous_page', 10, 3 );
	// re-add the filter at a lower priority of 9
	add_filter( 'login_redirect', 'buddyboss_redirect_previous_page', 9, 3 );
}

clarkwinkelmann · Jul 29, 2020

benjaminschultz would you be able to share with me the source code of those login_redirect hooks? (you can contact me on Discord or via email) I'm curious what that theme tries doing that isn't compatible with what I do. Or maybe I just need to change my hook priority to run before/after that.

[deleted] if you've got any idea which plugin/theme might be adding a login_redirect hook, I'm also happy to take a look into it. I remember we fixed it in the social login plugin in January, so I guess you've got another plugin causing it now

The difficulty with those issues is that I've been unsuccessful at reproducing them with free plugins so far, and then it's sometimes tricky to identify which paid plugin/theme is responsible and get a copy of it running on my local setup to reproduce.

benjaminschultz · Jul 29, 2020

clarkwinkelmann - I don't think it's that they're doing something incompatible, I think it's just that 10 is the highest priority and only one login_redirect can run. I could not get ANY login_redirect to work while that theme was active. Here is the source for what they're doing in their theme's "login.php", though:

add_filter( 'login_redirect', 'buddyboss_redirect_previous_page', 10, 3 );
function buddyboss_redirect_previous_page( $redirect_to, $request, $user ) {
	if ( buddyboss_theme()->buddypress_helper()->is_active() ) {

		$bp_pages = false;

		// Check if Platform plugin is active.
		if( function_exists('bp_get_option') ){
			$bp_pages = bp_get_option( 'bp-pages' );
		}

		$activate_page_id = !empty( $bp_pages ) && isset( $bp_pages[ 'activate' ] ) ? $bp_pages[ 'activate' ] : null;

		if ( (int) $activate_page_id <= 0 ) {
			return $redirect_to;
		}

		$activate_page = get_post( $activate_page_id );

		if ( empty( $activate_page ) || empty( $activate_page->post_name ) ) {
			return $redirect_to;
		}

		$activate_page_slug = $activate_page->post_name;

		if ( strpos( $request, '/' . $activate_page_slug ) !== false ) {
			$redirect_to = home_url();
		}
	}

	$request = wp_get_referer();

	if ( ! $request ) {
		return $redirect_to;
	}

	// redirect for native mobile app
	if ( ! is_user_logged_in() && wp_is_mobile() ) {
		$path = wp_parse_url( $request );

		if ( isset( $path['query'] ) && ! empty( $path['query'] ) ) {
			parse_str( $path['query'], $output );

			$redirect_to = ( isset( $output ) && isset( $output['redirect_to'] ) && '' !== $output['redirect_to'] ) ? $output['redirect_to'] : $redirect_to;
			return $redirect_to;
		}
	}

	$req_parts	      = explode( '/', $request );
	$req_part	      = array_pop( $req_parts );
    $url_arr          = [];
	$url_query_string = [];
	if ( substr( $req_part, 0, 3 ) == 'wp-' ) {
	    $url_query_string = wp_parse_url( $request );

	    if ( isset( $url_query_string['query'] ) && ! empty( $url_query_string['query'] ) ) {
		    parse_str( $url_query_string['query'], $url_arr );
		    $redirect_to = ( isset( $url_arr ) && isset( $url_arr['redirect_to'] ) && '' !== $url_arr['redirect_to'] ) ? $url_arr['redirect_to'] : $redirect_to;

		    return $redirect_to;
	    } else {
		    return $redirect_to;
        }
	}

	$request = str_replace( array( '?loggedout=true', '&loggedout=true' ), '', $request );

	return $request;
}

clarkwinkelmann · Aug 3, 2020

New updates! Also check out the updated compatibility list https://kilowhat.net/flarum/extensions/wordpress#compatibility . WP-Members is now mostly compatible. Ultimate Member is confirmed incompatible.

It's incredible how many plugins add their own login forms to Wordpress. It's hard to make them all compatible. Hopefully the changes in those releases should help a tiny bit.

The best global login experience is only experienced when using Wordpress native login ("wp-login.php"). WP-Member's custom login forms should now mostly work, but there are some situations where you might end up having to disconnect from Wordpress before being able to attempt global login again. Also the logout experience works but you end up on the homepage instead of the logout confirmation page.

Flarum changelog

Version 1.6.0 - August 3, 2020

Better error handling in case a Wordpress plugin interferes with the login redirect
Add Flarum modal login compatibility with WP-Members Wordpress plugin

You can update the Flarum extension via Composer.
Requires version 1.4 or greater of the Wordpress plugin.

Wordpress changelog

Version 1.4.0 - August 3, 2020

Enables the fixes released in the Flarum extension version 1.6.0
Fixes the post update date being updated each time the comment count changes

The plugin must be manually updated.
The new version can be downloaded via this link.
Works with any version of the Flarum extension.

[deleted] · Aug 3, 2020

clarkwinkelmann thanks very much for releasing this. You are an absolute legend.

[deleted] · Aug 8, 2020

@clarkwinkelmann one thing I have noticed is that the login session time between flarum and WordPress seems to be completely different. For example, I'm still logged in via WordPress, but flarum is logged out. To log back in to flarum, I have to logout of WordPress then back in again.

Doesn't it make more sense for flarum's session time to be governed by WordPress when using this extension ?

Thanks

clarkwinkelmann · Aug 8, 2020

[deleted] yes I'm aware of that. The problem is that the session time is currently not easily customized in Flarum, so I want to wait until the session refactor I'm working on in Flarum to implement the feature better in the Wordpress integration.

I might be able to implement a customizable session duration that's customizable in the extension settings though, and you could manually match that with Wordpress. But all of this will break with the planned changes in core so I will really try to get those changes in beta 14 first, then adapt the Wordpress extension.

[deleted] To log back in to flarum, I have to logout of WordPress then back in again

That's actually one of the few integration issues with WP-Members I couldn't fix. When using wp-login.php, if you're logged in Wordpress but logged out of Flarum, clicking login will open a modal that will immediately close and connect you with the current Wordpress account. Unfortunately I found no way of making that work with WP-Members so you end up in this situation where logging out is required in order to show the login form again.

[deleted] · Aug 8, 2020

clarkwinkelmann thanks. Any ideas what the session lifetime is in flarum currently ? I could fairly easily make WordPress match that as a workaround

clarkwinkelmann · Aug 8, 2020

[deleted] I'll need to do some research to find the actual values, but I know the issue is complex because there are multiple lifetimes:

There is the access token lifetime which currently only has an impact on remember_me sessions. The lifetime is 5 years. The Wordpress extension uses 5 year remember_me access tokens as well for the cross-site login
There's the remember_me cookie lifetime, which should automatically match the access token's lifetime
There's the flarum_session cookie lifetime for the active session, I'm not sure where it's configured
There's the PHP/Symfony's session lifetime, which has a value configured somewhere in the Laravel app's config array. I think it can be customized from config.php or extend.php but I can't find the thread where this was discussed. I think the cookie session also matches with that value

I think there's a consistency issue when logging in from Flarum to Wordpress vs Wordpress to Flarum because the remember_me cookie is not actually set when connecting from Flarum.

I'll try to get the behavior consistent and ideally, customizable.

I will try to get away from using the remember_me cookie and instead use my own cookie, that way I can avoid all Flarum sessions becoming remember_me sessions when connecting from Wordpress.

[deleted] · Aug 8, 2020

clarkwinkelmann thanks very much. Sounds promising. Not an immediate slow stopper but my forum is staying to gain serious traction with tens of new signups in the past few days alone, so I know it won't be long before someone mentions this

JJinJiaoHuan · Sep 9, 2020

After installing the plugin cannot post anything and shows POST api/discussions 500 error.

clarkwinkelmann · Sep 9, 2020

JinJiaoHuan please follow https://kilowhat.net/flarum/extensions/wordpress#troubleshooting and send me the full error message from the logs, preferably via the provided support email or Discord, or here if you don't mind posting your logs and forum info publicly.