troymccann I'm sorry to see you go, but I understand.

If you are able to give me information to reproduce, or give me access to a hosting where the issue reliably happens, I could try to look into it.

Right now I don't know about anything that might cause it, and haven't seen that issue with any other customer.

If you wanted to give it a go again, I'd suggest first updating to Flarum beta 14 to see if the issue also happens with that version. I will also release the beta 15 version shortly.

Thanks Clark. I will one day, but I need to find the time to make sure everything is working just fine.

I did try to update to beta 14. It looks like it installs just fine, but the version indicator does not increment to reflect the change. I haven't found time to try and diagnose that problem, either.

4 days later

Hi @clarkwinkelmann. Finding some time to try and get this running properly. I'm on beta 14 now (although, might need to go to beta 15 for the Formulaire addon over this one). I'm on 1.4 of your Wordpress plugin and 1.6.2 of the Flarum extension.

I have a problem where the style for the embedded Flarum comments in Wordpress is bare when FoF/night-mode is enabled. Do you know of an easy way for me to tell your plugin to default to the day mode CSS when this addon is being used?

Here's an example.

    troymccann after taking a quick look, I'm unsure whether there's any solution to the problem. The extensions just cannot work together at the moment.

    This is due to Nightmode not being designed to handle multiple frontend groups, which is a very obscure feature only used by Flarum Embed extension and my own WP Embed. This means there are two different CSS files, but the code from Nightmode assumes there can be only one, and it replaces multiple style tags with the same target URL, which ends up being the file that contains just the WP CSS.

    I will try to take a deeper look and will probably open an issue to discuss this on FoF Nightmode. I hope there's some way to disable Nightmode on custom frontends, but that's not looking good.

    Flarum extension version 1.6.3 - December 28, 2020

    • Flarum beta 15 compatibility

    This version can only be installed on Flarum beta 15.

    The new version will automatically be installed when you migrate to Flarum beta 15 with Flarum's official instructions.
    Requires version 1.4 or greater of the Wordpress plugin.

      Amarok can you share the output of your php flarum info ?

      Do you have FoF Nightmode installed? It's known to cause that exact issue.

        Regarding the Nightmode extension, would it be possible to export some CSS from Flarum that could easily be embedded into Wordpress as custom CSS, such that it will override the CSS for the Flarum iframe?

        It wouldn't be automatic, but it would be good to also be able to change the style of the iframe to match the Wordpress site in case the site doesn't quite match the style of the Flarum site.

          troymccann in the Wordpress extension, there is an additional button on the Appearance page that allows to add CSS just for the iframe.

          However Nightmode compatibility is a nightmare. The way Flarum assets management work is so obscure I'm not even sure where to look.

          The only remotely possible solution I see would be for the Wordpress extension to not use a second CSS file, and instead push everything into the main CSS file of Flarum. But that's not an ideal solution for flexibility, and it also increases the size of the base Flarum assets on all pages when it's only used in the iframe...

          5 days later

          I've resubscribed because I've got this all up to date now and it's all working nicely. Let me know when the Formulaire extension is ready for beta 15, because I'd love to use that in the next couple of days if it will be ready!

          Thanks for the info re. CSS. At the moment night mode is a luxury, so easier to turn it off with this extension running.

            troymccann thanks. Yeah, since I'm not seeing any easy solution for Night mode, it's probably best that way.

            Formulaire update should be ready in 1-2 days.

            7 days later

            Hi @clarkwinkelmann . Do you think it would be possible to replace Gravatar on WP with avatars loaded from the Flarum database instead?

            In fact, is it possible to sync more data between the user profiles on Wordpress and Flarum? I'd love to see the two merged together, to minimise the confusion for users who don't understand why therer's two different profile settings locations.

              troymccann technically, yes.

              However it's more supposed to be the opposite. When the extension is active and a user exists on both sides, Wordpress becomes the authoritative source of information (it's where you change the email and password). So if I were to implement this I'd probably sync avatar from Wordpress to Flarum.

              But from a user experience standpoint I could see why we would want to keep the Flarum experience instead of the Wordpress experience... I would have to look into that. I don't want to mix the master/slave relationship between the two platforms because it makes things a lot harder to manage. Switching everything to Flarum as master requires re-writing almost everything since then you would want a login-with-Flarum in Wordpress instead of the current way.

              Ok, fair enough. I prefer to think of Wordpress as just the blog and website, with Flarum as the core infrastructure. Flarum is a much nicer experience for our members - great work, Flarum team!

              I'd like to do away with as much of WordPress as possible (especially direct interaction with the admin pages as members find them confusing and unfriendly) and just leave it as nothing more than our public-facing site and a blog with most of the time spent in Flarum.

              2 months later

              I'm using this on a site that we are running and it's working really nicely.

              We only use it for comment integration, not really interested in SSO, as we don't have multiple WP authors who would also be using the forum.

              There are a few things that I don't quite get though, and one of the must urgent and strange is the difference in the number of comments on WP and in Flarum. I'm not sure if it's something with my implementation (but I'm fairly sure not) or a bug, or by design for some reason, but seems wrong whichever case it is.

              See attached images below for an example post - the number shows up correctly in WP, but is always one less than the actual comment count in Flarum.

              In Flarum:

              In WordPress:

                JohnP thanks for the feedback!

                Can you confirm which version of the Wordpress plugin and extension version you are running?

                An instance of this issue was fixed in version 1.2.1 of the Flarum extension one year ago. But maybe there has been a regression.

                It might also happen if an extension adds some new post content. Are all discussions impacted, or only some with particular content (a custom post type from another extension, soft deleted posts, ...)?

                  clarkwinkelmann

                  WP plugin 1.4.0
                  Flarum ext 1.6.3

                  It's the same on all discussions.

                  It's as if it simply doesn't count the first reply after the plugin creates the post.

                  It also doesn't list the user or time of the first reply under the discussion on the forum index page, it only displays them from the second reply. The reply is there in the discussion thread but not counted somehow.

                    JohnP in Flarum it's sometimes a bit confusing because the first post is treated differently.

                    The number shown on the Flarum discussion list is the number of replies, which is the number of comment minus 1 for the first post.

                    Things start to get complicated with custom post types, because custom post types aren't comments, and as such aren't counted. The Wordpress extension is the only extension in the Flarum ecosystem right now that uses a custom post type as the first post of a discussion, and this leads to various issues, most of which have been patched in previous updates. But maybe there's still something wrong with Flarum trying to subtract one from the number of comments that doesn't include the first post.

                    Can you clarify how many replies you actually see in the discussion, without counting the Wordpress summary? Are there 2 or 3 user comments in reality?

                    JohnP It also doesn't list the user or time of the first reply under the discussion on the forum index page, it only displays them from the second reply

                    If you mean the author/date of the Wordpress summary post (first "post" in the Flarum discussion) isn't shown in the discussion list, there's actually a setting for that https://kilowhat.net/flarum/extensions/wordpress#set-the-summary-post-as-the-last-post-of-new-discussions If you meant something different, can you clarify? It would be odd if the first user comment was causing an issue.

                      clarkwinkelmann

                      I'm going to include a couple of screengrabs below for a post that was created by the plugin and has just one reply, which makes it easier to see the issue.

                      • The number of replies in a discussion is the number shown as the comment count in WordPress.
                      • The WP summary post (autocreated first post) is not counting in the number of replies in Flarum, which is as it should be.
                      • The number of posts (original post and replies) is correct in the scrubber, etc. when viewing the post.
                      • On the forum index page it is not showing the author and date for the first comment, i.e. 'XX replied XX hours ago' and the replies count has not increased to 1 but remains at 0.

                      Once a post receives a second reply, then the index page shows the commenter name and date for the second reply as it should, but the replies count stays one lower than it should be.