Version 2.0.0 - May 9, 2024
This is a major release. Please read this announcement and execute the migration commands listed below.
Thanks to everyone who sent feedback in these last few months, I hope this update addresses most of your needs!
Video showing the new features
Upgrade instructions
This update requires a few additional steps. The extension will not work as intended if you skip them.
If you have some sort of maintenance mode, I suggest enabling it so no user tries to login or post during the update. But it should only take a few minutes and most features of WordPress and Flarum should continue to work even if you haven't finished to update both sides yet.
Update the WordPress plugin. The download link is available under the WordPress changelog.
First update the package (require will make sure you bump the major version):
composer require kilowhat/flarum-ext-wordpress
Then open the Flarum admin panel, and enable the "Backoffice" extension which will have been automatically installed.
Enabling this new extension should have automatically run the migrations and cleared the cache, but you can run them again to be sure:
php flarum migrate
php flarum cache:clear
And finally, after having updated both the WordPress plugin and Flarum extension, run the following command on the Flarum server to migrate the settings to their new names and invalidate the old API Key:
php flarum kilowhat-wordpress:migrate:v2
The command will list the actions that are about to be performed and ask you to accept. Press Enter to continue, or use the --no-interaction CLI flag when calling the command to skip confirmation. The command can be run again without any danger.
That should be it! You can then check out the settings in the Flarum admin panel if you wish to enable the new features.
If you encounter any error during the update process, please reach out.
Improved security
I have completely rewritten the way Flarum and WordPress communicate together.
Previously, a Flarum API Key was used and also behaved like an API Key on the WordPress side, meaning a compromised key would allow performing any admin action on both Flarum and WordPress, resulting in a complete compromise of both sites.
The new implementation uses a shared key that only authenticates synchronisation requests.
If that key were to be compromised, it would at worst allow an attacker to create bogus discussions under the tags configured for WordPress comment threads. Or when the SSO feature is used, it would allow creating bogus user accounts but won't be able to give them arbitrary groups (but if you use role to group synchronisation, they could assign any of those groups).
This change was made to follow best practices, I don't have any report of the old system being abused.
For the key to be stolen in the first place, one of WordPress or Flarum (or their respective backups) would probably have to be compromised. The new system ensures my extension cannot be used as a vector to compromise the other website in case one is compromised.
New global login methods
In addition to the cookie-based global login previously used by the SSO module, 2 new methods have been added.
These new methods remove the requirement to host WordPress and Flarum on a common top level domain.
Redirect uses a redirect after the first login from WordPress to connect Flarum.
Iframe uses a hidden iframe and the PostMessage web API to enable cross-origin communication between Flarum and WordPress and offer a one-click login, or optionally login through an automatic client-side page refresh.
See the documentation for the pro and cons of each method.
Improved cross-origin support, but...
I have performed many tests for cross-origin support. I added more built-in headers that you don't have to setup manually and created a section in the documentation about what must be done manually.
Unfortunately, the main conclusion of these many tests is that the setup will be infinitely easier if you stick to a common top-level domain.
Despite the improvements, global login and interacting with the comments in the iframe probably won't work in private browsing or privacy-enhanced mode in most browsers.
Role to group synchronisation
As part of the SSO feature, you can now automatically assign groups to Flarum users based on their WordPress role.
Forced Synchronisation commands
You can now manually force a synchronisation of all posts or users. Useful if you have a lot of data already in WordPress before enabling the integration.
Check out the help page for the commands and the online documentation.
php flarum help kilowhat-wordpress:sync:posts
php flarum help kilowhat-wordpress:sync:users
Feature toggles kept in sync
Previously, the SSO and Comments features had to be toggled on both Flarum and WordPress side.
In this new version, toggling a feature from the Flarum admin panel will automatically toggle it on WordPress side as well.
Other changes
- Added: Option to send Guzzle exceptions to the Flarum reporter instead of silencing them, useful with Sentry for example.
- Changed: Moved settings to the "Backoffice" admin area in order to use some of the reusable components provided by that extension.
- Fixed: The "last updated" date of a WordPress post is no longer bumped anytime a comment is written.
