Just a heads-up, the premium Wordpress integration is incompatible with Flarum Help Tags. If you enable Help Tags, then a logged in user will always see the oldest discussion they authored in the iframe instead of the intended comment thread.

Most likely @askvortsov will be able to fix it. I opened an issue here with the details if anyone is curious askvortsov1/flarum-help-tags1

This is the issue that was affecting danielunited

Hi all. I've installed the plugins on each of Wordpress and Flarum, using the new Extiverse private repo method. I'm having trouble with the health check (and the install wizard), but there are no errors being written to the log file.

The wizard is reporting different errors. If I include the site URL on its own it says, "We could not authenticate with the given credentials. Double-check the URL, username and password.", but they're definitely correct.

If I include wp-login.php to ensure it's specifically trying to login via the right point, it says, "Error while performing a GET request to Wordpress settings ({exception})".

If I manually enter all the settings and API keys each on Wordpress and Flarum without the wizard and perform a health check, I also get different errors:

With wp-login.php defined: "Trying to access the Wordpress API resulted in an error: json_decode error: Syntax error"
Without wp-login.php defined: "Trying to access the Wordpress API resulted in a 401 error. Double-check the "Wordpress admin username" in Flarum and the "Flarum API Key" in Wordpress"

Am I correct in thinking that by defining wp-login.php Flarum is at least authenticating correctly with WP?

EDIT: Also, if one of my Flarum users signs on and they don't yet have an account on the Wordpress server, will it automatically be created and synchronised that way also?

    troymccann the "Wordpress URL" must be the path to the root of the Wordpress install. It must not contain index.php or wp-login. See examples at https://kilowhat.net/flarum/extensions/wordpress#wordpress-url . /wp-login is automatically appended to the given url and can be customized via the "Wordpress login path" setting.

    The Wizard only works if none of the settings in Wordpress have been filled yet.

    I notice there is an issue in the error message. {exception} is supposed to be replaced by an actual message. I have just released version 1.3.3 to fix that. I have also made the JSON errors a bit more verbose so that we can hopefully know what is received. Can you try updating to 1.3.3 and copy the new error messages ?

    Another hint in the meantime, are the Wordpress and Flarum websites on the same server ? They need to be able to make requests to each other via their public domain. You could check if that works by making a curl request from the server command line to the full URL of the website with HTTPS and see if that works.

    troymccann Also, if one of my Flarum users signs on and they don't yet have an account on the Wordpress server, will it automatically be created and synchronised that way also?

    No. Synchronisation is only from WP to Flarum. But if you make login WP-only, the user will have to create a WP account, and that new WP account will automatically be connected to the existing Flarum account with the same email. The WP SSO integration only applies to logins made from the WP login form. If you keep normal Flarum login or social login enabled, then those Flarum accounts will continue to work separately from Wordpress, until a Wordpress account is created with the same email.

      clarkwinkelmann Thanks for the reply.

      I followed the instructions in the examples, but they didn't work for me. I also tried the wizard before anything was entered in Wordpress, but the same errors happened (which is why I tried to enter them manually).

      I just updated to 1.3.3 and removed the settings on both WP and Flarum before trying the wizard, and get the We could not authenticate with the given credentials. Double-check the URL, username and password. Check the documentation for more troubleshooting steps. message still. Unfortunately with no errors being recorded in the logs I'm not sure how else to diagnose the problem. Yes, I've checked and the servers can communicate via HTTPS, confirmed using cURL.

        troymccann I'm really not sure what it could be. Make sure the Wordpress username is used, and not nickname or email.

        Maybe the 401 is triggered by a proxy or firewall and not Wordpress. Once you manually configure the Wordpress side you could try running curl -u admin:token https://example.com/index.php?rest_route=/wp/v2/settings from the Flarum server command line to see the full error message. Replace admin with the Wordpress username you entered in Flarum, token with the "Flarum API Key" and example.com with your Wordpress URL.

        It's also possible a Wordpress plugin is interfering. Could you share a list of the plugins, in particular if you have any that relates to security ?

        Yep, using the wordpress username of the admin, and I've copied the password from my password manager to be sure it's exactly correct. There's no proxy, and the firewall is open for HTTP and HTTPS on both servers. I tried temporarily disabling all plugins except yours to be sure, and the same error occurs.

        I can cURL or use Postman to access any other route fine, but I get this with /wp/v2/settings:
        {"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}

        Using Postman, I've tried both basic auth and using the Flarum API key as the bearer token (with and without the token pasted in the WP settings, since I'm not sure if that's what the token is being matched to), and I still can't seem to access /wp/v2/settings. 🤔

        EDIT: As an aside, I can't believe how much data leakage WP let's through the REST API! Once I've sorted this auth issue out I'll definitely be restricting access to https://example.com/index.php?rest_route=/wp/v2/users, that should not be available by default without any authentication. 😐

        EDIT 2: I'm at a loss. I can't seem to access the settings endpoint using admin accounts on any wordpress site I have control of. I've checked to confirm that the admin roles have the manage_options permission, and still, I can't get them to authenticate on that endpoint. Always returns a 401. Is anyone else on Wordpress 5.4 having this problem?

          A quick update for reference, it seems to be an issue with my Bitnami EC2 instance. That said, while others have managed to fix the same issue, I still can't after hours of trying.

          Will have to leave this for now and come back another time. I think the solution is going to be migrating to a new server without the Bitnami bloat.

          https://community.bitnami.com/t/setting-up-api-access-to-wordpress-on-aws-ec2-instance/60589/7

            troymccann my extension does something very similar to https://github.com/WP-API/Basic-Auth during the initial configuration, so if there are issues with Basic Auth, there will most likely be issues with my extension.

            Right now the provided Wordpress user must be able to read and write options via the API for the wizard and health check to work. It's however not required for the integrations to work.

            For SSO integration, the Wordpress admin username is actually not required, it's never used. Flarum never makes API requests to Wordpress for SSO.

            For the comments integration, the admin username must be able to edit WP posts via the API.

            I plan to rewrite that in a future release to add custom Wordpress API endpoints for this extension that won't require authenticating as a WP user at all.

            8 days later

            I have just published a video introduction to the extension features.

            My website has also been updated to offer the new install instructions and links for Extiverse (which replaces flagrow.io) https://kilowhat.net/flarum/extensions/wordpress

            The price stay the same, though any tax/VAT is now included in the $5/month, so it might be a tiny bit cheaper if you cancel your flagrow.io subscription and move to Extiverse.

            Thanks, @clarkwinkelmann . I took the time yesterday to rebuild a new server, avoiding Bitnami, and migrated WP across. Your plugin worked instantly using the new server setup and I can authenticate with REST without any mods needed on the server.

            As an aside, the Bitnami setup is terrible to work with given everything is installed in unexpected locations in strange ways. One example, after a day of trying I discovered that there's really no way to do something as simple as update PHP. They expect you to create a new container with the updated packages, if it exists, and migrate everything across. Anyway, all fixed now!

            I really like this extension. Thanks mate.

              As someone who's considering making the jump to Flarum, but only if I can integrate with existing WP content and users, this video makes an excellent case.

              @clarkwinkelmann I'm about to dive into trying to restrict the WP user roles that have permission to log in to Flarum. e.g. You can only login to Flarum if you're an Editor or Admin on Wordpress. Do you have any suggestions before I try this?

                Before I tackle that one, I've got a strange bug happening when I toggle to only allow WP login.

                If I'm logged out of WP and FL, and log into WP, then the cookie settings mean that when I load FL I'm logged in already. That's all great.

                If I'm logged out of WP and FL, and I go to log in via Fl, I get a popup from WP to login. I enter my details and click to login. Nothin happens for about 10 seconds, and then the window loads wp-admin for that user. I assume it should close and refresh the FL page using the active cookie? If I close the wp-admin box left, and refresh FL expecting it to be logged in since WP is logged in, it doesn't work and remains logged out. If I clik the 'login' link again, the window pops up trying to load wordpress.site/flarum_auth and returns a 404.

                To fix this issue of being locked out of FL, I can go back to WP, log out, log back in, and then FL is happily logged in using the cookie.

                I have been tinkering a lot on my WP server, so I'm not sure if this is something I've done or is reproducible in the plugin. Any thoughts would be appreciated!

                  • [deleted]

                  troymccann If I clik the 'login' link again, the window pops up trying to load wordpress.site/flarum_auth and returns a 404.

                  I can also confirm this behaviour. It's been reported to me several times.

                    • [deleted]

                    • Edited

                    troymccann To fix this issue of being locked out of FL, I can go back to WP, log out, log back in, and then FL is happily logged in using the cookie.

                    And that's also my workaround...I also have the additional issue of WordPress remaining logged in, and Flarum being logged out.

                    [deleted] Ah, my bad. I had read the whole thread, but before I was looking out for this bug. Thanks.

                    Looking at the documentation, I'm guessing this part of the process is where the bug is:
                    Wordpress returns the remember token directly to Flarum without setting any cookie

                    Is there an explanation on why we don't let WP set the Flarum remember cookie on the cookie domain like in process when logging in from WP?

                    troymccann e.g. You can only login to Flarum if you're an Editor or Admin on Wordpress

                    There is no such feature implemented at this time. You'd have to manually assign admin/editor groups inside Flarum and use the Flarum permissions to restrict access based on those groups. Anyone would still be able to login into Flarum with a Wordpress account, their access would just be limited by permissions.

                    troymccann I enter my details and click to login. Nothin happens for about 10 seconds, and then the window loads wp-admin for that user.

                    This sounds like a WP plugin might be interfering with the login flow. Could you check if you have any security or login related plugins installed ? If a plugin tries to redirect the user to a specific page after login, it might prevent the Flarum login from working.

                    When logging in from Flarum, the cookie isn't used. It's done like that for multiple reasons, but mostly because it's the most secure one.

                    troymccann If I clik the 'login' link again, the window pops up trying to load wordpress.site/flarum_auth and returns a 404

                    You mean when you are logged into Wordpress but logged out of Flarum, clicking the log in button in Flarum opens that page in the popup ? That's something I will try to fix.

                      Thanks @clarkwinkelmann. I've just found the issue this morning. It was one of my plugins that I wasn't aware was doing any redirects on login, and was also unnecessarily redirecting the admin account to wp-admin unconditionally.

                      Looking at their code, it seems to be unintentional. They're using a string of if statements to decide where to direct various types of users and various redirects, but seem to have mixed up the necessary order of some statements and have included others that don't need to be handled at all if they had the correct order.

                      I've disabled the offending code in that plugin and everything is good now, and I've let them know so they can hopefully clean up their code.

                      clarkwinkelmann You mean when you are logged into Wordpress but logged out of Flarum, clicking the log in button in Flarum opens that page in the popup ? That's something I will try to fix.

                      That's right, but with the other plugin fixed this isn't an issue anymore. I assume you want it to be if you manually visit wp.server/flarum-auth when already logged in it won't send a new token to the flarum server?

                      EDITED