Support for this plugin is here:
I know. This was just obligatory to the “report broken” form.
On the documentation page linked above, there’s a workaround posted for this (FAQ29). Also, the premium addon uses the new API which IE9 doesn’t complain about 🙂
Yes, I am using this workaround since the first day plugin stopped working. Quite obvious one. However, it is just a temporary solution, which can not stay forever.
As much as I admire your work on this plugin (really!), I still think that the decision of leaving the free version invalid is a little uncool.
BTW – Microsoft is using the same method to keep the backoffice pages of MOSS 2010 working on IE9 🙂 (although the reason they do not work without it is quite different).
I can understand that. Try to see it from my perspective though: I’m using the Facebook API exactly as documented, and it doesn’t work properly on just one browser, thus it really seems it’s more of an issue for MS-FB to work out. I don’t think it’s quite fair to say I’m leaving it invalid as it’s always worked on every browser, until MS went ahead and released yet another “broken” one.
Also, it did take a considerable number of hours to implement the new API, all of which meant turning down other paid work. To be honest I don’t make even half as much even from premium sales as paid hours would’ve generated, so it’s just a way to try and partially cut my losses while still providing something that people obviously find useful. If it were just me and my site, I would’ve without question left it as it was. There are only so many hours in a day that one can put into doing things for free…
I know what you mean. I am developing a free software that is used by big companies to design websites and it did not bring me a penny yet, just hosting costs and satisfaction :).
However, the free plugin sells the premium one for you. It will not be more successful because it is broken. In my opinion, it will not be long until someone develops a new plugin, to fill the empty space given up by you.
On the other hand – you will then be free of the burden ;).
Well, IE9 was just released last month. My hope is that MS will pull their heads out of their butts and fix it, but if not, and if such a time comes that it becomes too much of a problem, then I suppose I’ll have little choice.
In any case, keep in mind that even when I wrote the FIRST version of the free plugin – just for personal use, without any intention of continuing development and certainly not of selling it – there were already 4 other Facebook Connect plugins out there. It just so happened that my design appealed to some people more than others. I do hope people continue to find it useful, but whatever the case, developing something for yourself and sharing it openly with others is one thing; coding solely to satisfy the needs of others is something different entirely. One is a hobby, the other is a job 😛
Actually, I do not know of any other fc plugin, that works so seamlessly for the user. Kudos for that BTW.
Thanks 🙂 That was pretty much THE reason I wrote version 1 – The way I saw it, “Facebook-connected” or not, if it’s a hassle for users to login they often just won’t bother to. So I tried to make it as “invisible” as I possibly could: just click a button and you’re in 🙂
Incidentally, regarding this IE9 issue: I did try to figure out a way to automatically insert the <meta http-equiv=”X-UA-Compatible” content=”IE=8″ /> tag so it’d work with IE9 out of the box, but unfortunately that needs to be the FIRST tag after <head> – and there’s no guarantee of when a theme will actually call wp_head(). Any thoughts…?
Ultimately, you could hook an output buffer (ob_start()) on the ‘init’ action, and output it after modifying on the ‘head’ action.
However, this is a very dirty solution, and I would not recommend it to anyone, unless he is completely aware of what is happening – and you can not be sure that your users are.
In general, instead of implicitly modifying someone else’s blog header, I would rather add a proper alert for IE9, that your plugin does not work properly and what is the temporary workaround.
Great news, but please don’t tell me, that you are injecting the meta compatibility tag 🙂
Haha, that’s exactly what I did 😛 I capture output from get_header to wp_head, and did add an option to disable this. While I am aware that it isn’t a “clean” solution per se, the way I see it, it’ll make the plugin work on all browsers without people needing to intervene – and if it causes any problems they can always turn it off, or I can always get rid of it if it becomes really problematic (though I don’t see how it would). This is actually exactly how the major cacheing plugins insert minification includes anyway – and will enable things to “just work” out of the box, far better than hassling people with warnings and instructing them to fix them on their own IMO.
Firefox 4.0 to 4.01 update also broke 1.9.2 version of this plugin. 🙁
(For example Chrome is still working fine on my site.)
I know this is not the support site, but couldn’t find http://www.justin-klein.com/projects/wp-fb-autoconnect anyplace to post this..
>>I know this is not the support site, but couldn’t find http://www.justin-klein.com/projects/wp-fb-autoconnect anyplace to post this..
…Did you really read the page? There’s a link to “Feedback & Support” right at the top, as well as an entire section at the bottom. 1,573 messages so far, it couldn’t be *that* hidden…
>>Firefox 4.0 to 4.01 update also broke 1.9.2 version of this plugin. 🙁
Even if you couldn’t find the support page, this thread is “Does not work in IE9” (FF 4.01 is not IE9, please stay on topic).
…But in any case, I’m currently using FF 4.0.1 and it works fine. Please try it on another computer.
- The topic ‘[Plugin: WP-FB-AutoConnect] Does not work in IE9’ is closed to new replies.