In short, no, that method won’t work. By the time the normal content filters run, it’s too late to add stuff to the head of the page. OpenGraph content must be in the head of the page for FB to see it, and content filters normally only run when producing the content lower down in the page.
The long version of my response to this you can find here: http://ottopress.com/2011/actions-and-filters-are-not-the-same-thing/
Summary: Other plugins should not use filters (or shortcodes) to take actions like sending email or performing other non-repeatable transactions. Any plugin that is doing such a thing is doing-it-wrong and needs to be fixed.
This is not an uncommon problem though, I’ve had to point out issues in plugins like this even to core developers when their plugins did it. It’s a relatively easy mistake to make. The easy fix is usually to pull whatever code is performing the action in question out of the filter function, and to put it in a function being called by the proper action hook (usually “init”) instead.
Hey Otto,
Thanks for the quick reply. I can see what you’re saying, but it also seems inefficient to generate the content and run all the filters twice. Seems like a chick-and-egg problem. I was surprised when I first dove into the SFC code and saw all the content processing it was duplicating.
Would it be possible to add an option to en/disable Open Graph tag generation to work around problems like this? The only feature I use in SFC is Publish and I have little control over other plugin authors. 🙁
Thanks,
Graham
The “inefficiency” is minor, at best. Most all filters and shortcodes do nothing more than simple string processing. The benefits and ease-of-use outweigh the downside.
And while you have little control over plugin authors, you do have the ability to tell them that their plugins are broken, and the ability to not use broken plugins. I suggest exercising that ability.
BTW, SFC-Publish needs the meta to be there too. The manual publish triggers FB to crawl your site for it.
I will not add an option to disable the meta generation, since most people don’t need it. Options are counterproductive when the vast majority of people don’t need to use them. “Decisions, not options.”
If you want to disable it yourself (breaking a lot of functionality in the process), then you can add a remove_action call somewhere to remove the sfc_base_meta function from the wp_head hook.
I understand your reasoning; I don’t like having zillions of options either. I just want things to work. But sometimes it helps users to be able to disable certain functionality when there is a plugin conflict or duplicated functionality. I have two other plugins installed that also generate OpenGraph tags.
Thanks for the tip. I’m not a fan of plugin-hacking, since the hack gets deleted in the next upgrade. I may have to resort to that; I’ve been playing with FacePress II for my wall updates, but it’s just not as clean as SFC Publish. 🙁
Cheers,
Graham
I have two other plugins installed that also generate OpenGraph tags.
Betcha mine does it better. 🙂
Just added audio support into 1.2. Video handling improvements are next, although I may have to write a whole frickin’ library to make that one work.
