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

    7 days later

    Does anyone else have bad results with posting times on Wordpress synced discussions?

    On regular Flarum discussions posting time is instant, but on WP synced discussions posting times wait are anywhere from 3-10 seconds.

      hrvoje_hr there is an extra behind the scene request to WordPress on each new post as well as post hide/restore (to update comment count)

      Those requests are made in queueable jobs. If you install the redis queue extension, those should start running on their own without slowing Flarum requests. This is still a bit experimental and not covered by the documentation because I've not had an opportunity to test that on a production forum myself yet.

          14 days later

          clarkwinkelmann I might be an idiot for even suggesting it,
          But maybe the comment sync should happen from the wordpress end? With the possibility to turn it on/off, and maybe tie into https://developer.wordpress.org/plugins/cron/scheduling-wp-cron-events/ with a configurable timer for those that want it to not happen on every post visit.

          If the comment sync have a API endpoint at the forum side, it would make it fairly easy for the end user to create a wp plugin to override sync?

          This might also make it easier if you ever decide to implement support for several wordpress sites. (I would use this plugin if that ever happens).

              andreherberth thanks for the suggestions!

              I have made the choice to delegate most of the logic on the Flarum side because it's the stack I'm most comfortable with and I have access to all the libraries from Packagist there to make the code easier to maintain.

              The plan regarding comment count synchronization is to make the queued sync an official feature (as described above, it already works but isn't documented). If some high traffic website requires it, I could also move this to a CRON job to reduce the number of API requests to Wordpress. But I would most likely make the CRON on Flarum side.

              Do you have an example of something the owner might want to change during the comment count synchronization?

              I also plan to make some changes to the API between Wordpress and Flarum, because the current solution has the side effect of editing the Wordpress post update time whenever the comment count change. This will go in a larger rewrite where I lock down the API between the two to prevent a compromised key to be able to perform other actions via the API.

              Regarding supporting multiple Wordpress websites, I haven't ruled that feature out. But I'm not sure there's enough demand at this time to justify adding the feature.

                8 days later

                Hey,

                I had a little problem if I want to use reCaptcha in wordpress when I want to login. This message appear :

                {"success":false,"data":[{"code":"http_request_failed","message":"Too many redirects"}]}

                Wordpress plugin in use to do this : Advanced noCaptcha & invisible Captcha
                And another to customize the login page : GS Custom Login Lite

                Maybe it can help. But without the Advanced noCaptch all work fine.

                sorry for my bad english :S

                  Amarok hi! Could you try temporarily disabling the single sign on of this extension by going to Wordpress settings > General > Enable SSO integration and turning it off?

                  Then you can try connecting again and see whether the error still happens. If it continues to happen, then it's likely not related to my extension. But if it only happens when "Enable SSO integration" is turned on, I'll investigate to see what might be causing the incompatibility.

                  Unfortunately Wordpress doesn't have a proper log file so I think we have no way to know which URL is being caught in a redirect loop unless looking at the webserver access logs if they exist.

                  Could you share links to the Wordpress plugins you are using? That way I can test with the exact same plugins on my test website.

                      clarkwinkelmann Hi.
                      It's appear it was an Edge Navigator problem... and coockies. Deleted all of them and all work perfectly with SSO turning on.

                      Sorry for the sorry for the inconvenience :S

                          Amarok no inconvenience, I'm here to help 🙂

                          That seemed an odd error to be caused by a specific browser since the error appears to be related to a background request made by the server itself. But glad to hear it's solved!

                            I am aware of an issue regarding cookies when my extension is used in a cross-origin context. Using the extension in such a context has so far been unsupported (see requirements in documentation), but it was mostly working.

                            Up until recently, only global login would be unavailable on cross-origin, but connecting and disconnecting from Flarum side would work.

                            Now with Chrome defaulting cookies to SameSite=Lax, cross-origin iframes can no longer access Flarum session cookies, which means the iframe comments has effectively become read-only and it's impossible to connect or interact with Flarum inside of it.

                            The upcoming Flarum beta 14 will also mark Flarum cookies explicitely as SameSite=Lax, which means this behavior will be experienced across all browsers.

                            As I said this should only affect users that were using my extension in an already unsupported manner. But if you are affected and have suggestions regarding the handling of cookies, feedback is welcome.

                            I could offer an option to force Flarum cookies to use SameSite=None, but that seems counter-productive for security. Especially since my extension still wouldn't fully support global login for such setups.

                            My recommendation continues to be to only use this extension for contexts where Wordpress and Flarum share a common origin.

                            9 days later

                            hrvoje_hr no, the extension is currently incompatible with Flarum beta 14. The constraints will prevent you from upgrading.

                            An update was prepared a few weeks ago I just need to test it against the final beta 14 release. It will be released within a week.

                              Is it able to import existing WordPress comments? I'm thinking about to migrate from existing comments to the plugin one.

                                codemotion not yet, but this might be coming in a future update.

                                In the meantime it's still possible to manually import them, but that does require a fair amount of manual work.

                                  8 days later

                                  Flarum extension versions 1.6.1 & 1.6.2 - November 3, 2020

                                  • Flarum beta 14 compatibility

                                  Version 1.6.1 contained a bug. 1.6.2 fixes it.

                                  This version can only be installed on Flarum beta 14.

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

                                    BigMinnie I still can't offer any timeline. There are other requested features that I will most likely implement first.

                                    Having studied other comment embed platforms, it seems most of them do use an iframe. They just load it with javascript and have a more polished design that makes it look like the iframe is part of the website. The fully no-iframe implementation will likely be a lot of work and also add some additional constraints on cookies and headers for the host.

                                    I'm still not sure how the current solution impacts your load time? The iframe shouldn't prevent the page from rendering. If there's an actual problem on that side I can add some way of delaying the rendering of the iframe in Wordpress.

                                        clarkwinkelmann They just load it with javascript and have a more polished design that makes it look like the iframe is part of the website.

                                        For the start this could probably work but when I tried the current iframe load times jumped + few seconds, it does not sound a lot but it didn't work for my website.