Ryan

Hi ebloss, terribly sorry about the slow reply — I didn’t receive a notification about your message.

“visibility: none;” shouldn’t do anything, as it’s not valid CSS. The honeypot element should already be wrapped in an element that contains “display: none;”, which would hide it. However, it’s possible that the space is because CF7 runs through wpautop(), which replaces line breaks with BR or P tags. The only way around this is to make sure there is no line break where you insert the honeypot shortcode. You can stick it snug up against one of the other form elements to assure this.

Hi ebloss, terribly sorry about the slow reply — I didn’t receive a notification about your message.

“visibility: none;” shouldn’t do anything, as it’s not valid CSS. The honeypot element should already be wrapped in an element that contains “display: none;”, which would hide it. However, it’s possible that the space is because CF7 runs through wpautop(), which replaces line breaks with BR or P tags. The only way around this is to make sure there is no line break where you insert the honeypot shortcode. You can stick it snug up against one of the other form elements to assure this.

square_eyes isn’t wrong, if you set the meta description tag explicitly on a post-by-post basis, the og:description tag shows up. However, if you’re relying on the plugin to generate your meta descriptions using excerpts (or auto-generated excerpts), then it seems the og:description tag fails to be generated.

Oddly, the Twitter (twitter:description) seems to load up just fine.

I tried birgire’s solution, but didn’t have any luck.

I ended up using the Custom Post Type Permalinks plugin. Makes it dead easy.

I agree, would be a nice feature.

I would. Definitely.

Right now output becomes a bit of an unpredictable mess when adjusting arguments and not including absolutely every variable. Having an associative array and managing arguments the same as with core WordPress functions seems like the best way to go.

-R

Cheers Jeff — just updated the plugin to reflect this.

Thanks petitnuage. Just switched to Hikari Category Permalink from sCategory — working perfectly.

Just to follow up on what I mentioned — I just realized it was my own stupidity. I didn’t have “share with all users on this site” checked. Works beautifully now. Again, fantastic plugin.

The answer didn’t, but I figured it out. It wasn’t publishing the link because I wasn’t the original author (even though I am the admin). I tried on a post I had written and it worked exactly as expected.

I’m guessing it’s a basic ACL check in the plugin, but it might be worth allowing admins to add links from old posts, even if the post wasn’t authored by the admin account.

Great plugin by the way.

See U09 here.

However, it doesn’t seem to be working for me.

The honeypot checks shouldn’t interfere with recaptcha at all. Please let me know if experience any trouble.

I don’t believe there’s any built in method to do this, so the only way would be to add a filter and modifying the output via a custom function by dropping something like the following in your theme’s functions.php file:

function custom_edit_post_link($output) {
    $output = str_replace('class="post-edit-link"', 'class="post-edit-link your-class', $output);
}
add_filter('edit_post_link', 'custom_edit_post_link');

Hope it helps.

Doh, found my problem (and yours as well). For setting the name=”” value of the radio we were both using:

$this->get_field_id(‘foobar’);

Instead of:

$this->get_field_name(‘foobar’);

It’s always something obvious and easy to miss, eh?

Hope this saves someone else the wasted time it cost me.

Hi duck__boy, did you ever figure out what the problem was? I’m faced with the same issue.