Premium WordPress Integration

Flab I don't remember 100% and I'll need to check the code again but it's possible that the thumbnail settings only apply to new and updated WP posts.

Once I implement the import tool, it will also solve this issue as it will allow re-syncing all post previews in addition to the comment threads.

Flab I still have the login problem when I want to login from the comment section at the wordpress site. Does this log file from storage/log help?

It seems unlikely that those errors are related to login. The 3 WP logs are just information and not errors. The 2 instances of the same error must have happened during the deletion of a post.

The post deletion error is curious because I haven't seen it before. I'm not sure if it could be caused by my extension. It's probably caused by either discussion_user.last_read_post_number or discussions.last_post_number being NULL. This could be caused by malformed data after migrating from another software, or is related to posts/discussions that have been manually created by an extension, possibly my WP extension. I would need to test on my development server to see if I observe this issue.

Can you share your php flarum info and confirm whether you migrated data from another platform? Also if you remember deleting Flarum posts, do you remember if it was inside a WP comment thread or unrelated?

Flab that's correct. If your users don't need a WP account for any WP features, it's better to leave the SSO feature off and simply let users connect using native Flarum login and/or Flarum social login extensions.

You should be able to connect and reply directly from the iframe on the WP side. If it doesn't work, maybe the Flarum hosting needs some additional headers to allow the cross-domain embedding of the iframe. My extension doesn't add such headers, as they depend on the exact situation and are easy to add using Apache or Nginx rules.

I'd really like to add a section about headers to my documentation but I have a hard time figuring out all the use cases I should cover. And it seems like every time I finally have some instructions written, browsers update their security requirements and I have to research everything again

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.

Anomalien I am aware there might be a problem with subfolder installation. I have not been able to test yet. There is unfortunately no workaround. Either rollback to 1.x if you haven't run the migrate command yet, or manually change the settings by editing the database. If you ran the migrate command, everything should continue to work as before even if you can't access the settings.