SFC conflict with contact form

So, don’t use those plugins. Or fix them. Without more information on the details of the problem, I can’t really help you.

Yes, well, the bottom line is that those plugins that have this problem are doing-it-wrong.

Here’s some text on that second link you posted:

It looks to me that it is caused by the SFC plugins trying to scan the page content prior to WordPress showing it. This interferes with proper posting of the form. In my opinion, the author of SFC should either make it compatible or make a page exclusion feature so pages can be excluded from the SFC Like and SFC Share features.

Firstly, this is exactly correct, SFC does indeed scan the content of the page in the header, and then rewinds the query. This is what it is supposed to do. This is a correct operation.

What the author of that plugin is missing is that his plugin is making an invalid assumption. He’s assuming that the_content filter can only be called once per post per page-load. This is an invalid assumption. the_content is a *filter*. Filters are functions that just modify things. They cannot assume that they’re only going to be called one time per post or page-load.

So he has code somewhere that, after it produces the contact form, sets some flag so that it won’t produce that contact form again. This is invalid, his filter code needs to produce that contact form every single time.

If he simply removed this blocking code, then it would work properly.

My code is behaving properly, his code is not. And I’m not going to “fix” what isn’t broken. Frankly, I can’t. That code must process the content in order to produce the Facebook OpenGraph meta tags properly. I’m not going to add an exclusion feature either.

If your contact form isn’t showing, then your contact form plugin is doing it wrong, and you need to tell the author of that plugin so. Refer them to me. I’d be happy to explain how their plugin is broken to them.

Yes, well, in these specific cases, it is the other sides fault.

Here’s the problem: I’m not going to spend my time fixing the problems caused by other people’s plugins and other people’s incorrect code. If it does not work with SimplePress, then my advice is to tell the author of SimplePress to fix it, or stop using one or the other. Either way, I don’t care which.

If you want to point out a problem that actually exists in SFC, then I’m happy to fix it. But if you’re going to point out a problem with somebody else’s crap plugin that is doing things wrong, then I’m not going to fix other people’s issues.

If you don’t like this, then you’re perfectly free to just use something else.

No, the conflict existed before 1.0. The Like button and the Share button always had this same issue with the other plugin.

The difference now is that the code that generates the metadata has been moved into the base plugin, because it makes more sense to always generate the correct metadata for the entire site instead of having those two plugins do extra processing separately.

Thus, the plugin will now always conflict with other plugins that are doing it wrong.

STC doesn’t generate any metadata. Twitter doesn’t work the same way that Facebook does.

The conflict is that the other plugin has code in it specifically designed to not generate whatever it’s generating (like the contact form) more than one time per page-load. This won’t work because SFC needs to get that contact form, and anything else in the_content call, earlier than the normal page display.

Basically, on a normal site, your theme makes a call to the_content() to display, well, the content of the post or page or whatever. The SFC plugin also makes a call to the_content filter (three times, in fact, once to build an excerpt, once to get images, and once to get videos), in order to get the content that is going to be displayed on the page early. It has to do this, because it needs the final content of the post, images shown and shortcodes processed and oembeded video turned into HTML and everything else, in order to do the next bit.

Then SFC searches for images in and video in this post content as well as builds a 1000 character excerpt from it. It does this so that it can figure out what the images and video are, and so that it can create a “description” of it all. Then it inserts OpenGraph meta tags into the header. These tags get used by Facebook for building their posts. So if you post a YouTube video, then the video file thumbnail will show up on the resulting wall posts of people liking it and such.

Finally, after it’s done this, it builds meta tags and outputs them. Simple and easy.

The problem is that some plugins, such as the problem ones you’re finding, have code in them specifically to only do their bit of the processing of the_content *one time only*. This is a misguided and incorrect attempt to make it so that things like the contact form or a forum display (like SimplePress does) or things like a Gallery (like NextGen Gallery does), don’t actually display twice on the page. The problem is that they’re making an assumption that every call to the_content filter is actually going to be displayed on the page. In other words, they’re doing-it-wrong.

A filter is just a name tied to a function which can alter data in repeatable ways. When they make their filters not behave the same every time, then they’re making an assumption of what that filter is being used for. They’re assuming that any call to the_content filter is going to be output as visible information on the page. That is an incorrect assumption. So because of their incorrect assumption, SFC calling the_content in order to actually get the content (which is the purpose of the_content in the first place) is actually getting that contact form. But it doesn’t display it. And then in the *next* call to the_content, this time by the actual page itself, the contact form code doesn’t work properly and it doesn’t return the contact form again.

Filters should be *repeatable*. Always. If I pass in X, then I should get out Y. Every time. These other plugins are broken because I can pass in X and only get out Y the first time it’s done, but not any time after that.

In particular, the particular problem with the Fast Secure Contact Form plugin is that he’s taking non-repeatable actions inside a *shortcode* processing function, of all places. In particular, he uses a shortcode-attached function to check the result of the captcha, and he does it in a way that doesn’t work when you run it more than one time on a page.

Shortcodes are not supposed to do things like that. They’re just like filters, except that they take in the content of a shortcode only, and return the resulting text to replace it. They can’t be used to actually *do* things. And yes, they can be processed more than once per post or page.

Real actions should take place inside *action* hooks. They’re named differently for a reason. In WordPress, action hooks are used to specify places where things can be done. Filters are used to modify variables. And shortcodes are a specific type of filter, used only for string processing in posts.