marjoleink

That was not a complete solution… The link inside the login form has id pop_signup, while the link on the widget has id show_register. The jQuery looks for respectively (#pop_login, #pop_signup) and (#show_login, #show_signup).

So, if we change the id in the function that generates the link to show_signup, it starts working:

function simple_ajax_auth_register_link( $before = '', $after = '' ) {
        $setup = get_option('simpleajaxauth');
        return ( ! is_user_logged_in() && get_option( 'users_can_register' )) ? ( $before . '<a id="show_signup">' . ( isEmpty($setup['register_text']) ? 'Register' : $setup['login_text'] ) . '<a/>' . $after ) : '';
}

That’s more consistent, too.

You can mark this as resolved. ??

Looking through the code, I already found the problem, I think:

In the file plugin.php, function simple_ajax_auth_register_link() is missing a closing <a/> tag; it should be (line 160 etc.):

function simple_ajax_auth_register_link( $before = '', $after = '' ) {
        $setup = get_option('simpleajaxauth');
        return ( ! is_user_logged_in() && get_option( 'users_can_register' )) ? ( $before . '<a id="show_register">' . ( isEmpty($setup['register_text']) ? 'Register' : $setup['login_text'] ) . '<a/>' . $after ) : '';
}

Untested, but I think the missing end tag is preventing jQuery from recognizing the link.

It looks like the (web!) editor is simply droppping everything in tags, like <svg....>...</svg>

Try hand-editing the css (like with a local text or programmer editor); something simple like notepad or mousepad would do.

I was away for a few days, with an internet dongle that refused to work…

@mra13 I’m happy to read on my return that this has been resolved – thank you! But I’m curious to know what, exactly, was the problem: any clues?

@bcwlaw thanks for the captcha plugin reference; that’s very useful.

@bcwlaw my apologies about ‘talking code’ – with my background I just naturally approach problems like this from the code end.

That said, while I admit that @mbrsolution was correct in my case that the problem was with the theme, it’s also evident to me that we’re seeing different problems here, and not everyone’s problems in this thread are actually the same.

If a plugin works with your (chosen) theme but doesn’t after an update, logic tells me it cannot be just the theme, or it would not have worked before the update either. That suggests some “contextual” problem – and those are the hardest to track down and solve. But clearly there is a problem and it should be solved. I hate to say that, because on the whole I’m actually very happy with AIOWP (which I use in combination with two other security plugins as well as some setup changes I made “manually”. It all works together very well).

@bcwlaw you could of course try to “downgrade” to version 3.6 again. But could you tell me which alternative captcha plugin you’re using? I am very uneasy leaving my comment form unsecured while I can only work on a solution on and off for the near future… Knowing what works as an intermediate solution would save me a lot of time!

OK, I think I found it! ??

Yet another search pulled up comment-form.php inside wp-includes. I found a function that creates a comment form and – more importantly – contains the action hooks you are referring to.

And then it dawned on me that while adapting the fields of my theme’s comment form, I never saw any hooks like that.

As a quick test, I inserted both hooks in my template. Sure enough, the captcha now appears. Except when a user is logged in, it appears twice. ?? Never mind. Functionality added. (I cannot call it “restored” since it clearly never existed in my theme’s comment form.

Now I just have to decide whether to replace the form with the wp-includes one, and style that to match my overall forms layout and styling, or just backport all the missing hooks to my theme’s comment form (all – since I don’t know what else I might be missing at a later time!).

So, thanks for the help @wpsolutions! The mention of the two hooks you’re using did put me the right track. ??

@wpsolutions I meant “just” literally: just before posting my latest reply here.

I changed the design only: adding label elements, and replacing ugly JavaScript by actual placeholder attributes. All while, like I said, without touching field names or field IDs. I most certainly did not touch, let alone “break” any functionality in the process.

My point was that it simply did not make any difference (I was hoping that removing the inline JavaScript might somehow help). The captcha still does not appear.

Did you actually look at my form?

The comment_form_after_fields parameter in the add_action() you mention suggests you’re looking for a particular field, probably by ID, in order to decide where to add the captcha field.

• If so, what are you looking for?
• If not, how else does this process decide where, exactly to insert its field?

I’m trying to find out what this functionality is that I didn’t break, and thus must have been broken already. I had already found
comment_form_after_fields and comment_form_logged_in_after (and more such for other fields) as well as the insert_captcha_question_form function (I searched for these specific strings just now – just before typing this – and landed on already-bookmarked lines. ?? ).
So I can see what is supposed to be inserted, but not how it decides where to insert it.

Can you explain this please?
(I’m relatively new to WP, but learning fast after about 40 years in IT ;))

Until I know this I cannot repair the functionality that I didn’t break… (yes, it’s possible that the theme I’m using broke it – but I need to know more to be able to fix whatever is broken). If it actually is the theme: changing to another theme is out of the question. I’m quite prepared to fix what’s broken – if anything – though. But I need to know what to look for.

@wpsolutions Actually caching was the first I thought of, and I cleared the cache, repeatedly. It didn’t make any difference.

My site is hosted @ SiteGround who have specialized WP hosting, including multi-level caching. This also comes with a plugin, which I have activated, but with Dynamic cache turned off in its settings – it was interfering too much with my current development work on the site, in spite of the fact that it’s supposed to detect changes (maybe not in templates and such files?).

I have just redesigned my theme’s comment form template (in my child theme) because I didn’t like the layout – being very careful to NOT change any field names or IDs. I turned the captcha back on now (and cleared the cache) – curiously no captcha appears but when I try to submit (not being logged in – and with all valid input) I am not sent to 127.0.0.1 now but get an error message:
“Duplicate comment detected; it looks as though you’ve already said that!” – on a separate page (wp-comments-post.php).

Never mind how much I vary user name, email address or comment content, the same message still appears…

You can have a look here: https://photos.marjoleinkatsma.com/2014/03/lets-see-happens/

BTW, I do get the captcha in the admin login form – on and off. Sometimes it disappears when reloading the page, and for a while it had gone completely – basically that’s why I thought the cache was involved, but clearing it doesn’t seem to have any influence either.

It would help me if I knew how the captcha functionality finds the location to insert a field… then I could look better for a cause myself.

@mbrsolution thanks for the fast reaction! But it can’t be just the theme as version 3.6 worked just fine with it. And it’s this plugin that changed.

I am investigating, but I have really little time (preparing for a trip) and there’s a lot of places to look. If I run out of time I can always restore version 3.6 – the protection of the comment form is more important to me than the new features…

I just upgraded, too, and was told by someone he tried to comment and the connection was reset. When I went to investigate I also found the captcha didn’t appear.

It looks as though the plugin assumes the captcha is there, doesn’t get a value for it, and thus blocks the comment.

Running WP 3.8.1 with a custom theme (360 degrees).

All i can say is the 2 ips are comment bots

A quick WHOIS lookup showed that both these IP addresses actually belong to Google. ‘Comment spammer’ must thus be a false positive – better leave a comment at Project Honeypot so they can whitelist these IPs. ??