Iron Dragon

YAY!!! I just updated to 1.2.1. HTML code is no longer displayed on the frontend, which is great!

Thanks so much for finally getting this fixed. ?

It’s very annoying that this issue hasn’t been fixed yet. The galleries look so unprofessional now.

Since this problem didn’t exist until the 1.2.0 update, it should have been an easy fix… All that needed to be done was roll back whatever change was made to code rendering.

@visi19 When I use your code in the description, your plugin automatically converts <br> back to <br /> after saving.

The raw HTML still displays in the frontend.

• This reply was modified 4 years, 3 months ago by Iron Dragon.

@visi19 Since the HTML is still visible on the frontend I’m not sure what use there is in me providing you with an example, because it will be exactly the same as what you can already see if you view the gallery. But okay…

This is from the first displayed image in the linked gallery:

08.May.2009<br />I was a pretty big fan of <i>Sailor Moon</i>. This was my fan character, Sailor Starfury.<br />I used layers set to Multiply to achieve the shadows. I also used a slightly different blending technique with the Smudge tool.<br />The pose is taken directly from <i>Sailor Moon</i>.<br />This is the last image I ever drew of this character, as shortly afterward I abandoned my attempts to revive the story and left the <i>Sailor Moon</i> fandom behind in favor of other projects.

Hi @visi19

Thanks for looking into this and getting back to me. I’m not sure what you mean by “put the HTML elements well”??

I tried removing a description, saving it, then putting the original description (with HTML) back, but the problem remains.

Hi Matt,

In the log, my customer’s IP address is listed seven times as trying to access the URL that 404’d. Only five of those instances is associated with the customer’s user account. The other two instances are blank in the user field.

Since iThemes was set to lockout after five attempts I don’t understand why the log shows seven hits. Surely that can’t be possible if the plugin is respecting the settings properly.

I’ve asked my customer again to confirm she only tried the URL once and that she didn’t do anything else like refreshing. She says she definitely did not try to access it that many times.

She did mention that after I whitelisted her and she tried to get back to what we were doing, she had to log in again, ie, the lockout either logged her out automatically or it wiped the login cookie from her browser. Is that intended behavior too?

Thanks!

Given all the other problems people have been having with v3, and all the spam that has been getting through since changing to v3 that never got through on v2, I installed the Contact Form 7 – reCaptcha addon so I could go back to the v2 api. Nice bonus is that it gets rid of the ugly floating reCAPTCHA button appearing on every. single. page. without having to add more CSS to my site hide it.

Good luck!

Just tested my contact form to see if it was working since swapping to v3 and it turns out I have this issue too, though it’s intermittent. Testing my form myself resulted in failures; someone else testing it for me did not.

Welp, since nobody did much to help me with this, just wanted to post an update to say that I deleted the Wordfence plugin from all three of my websites and so far the problem seems to have gone away.

Unless I get blocked by my host again, I won’t be returning to Wordfence in the future. Too bad.

• This reply was modified 8 years ago by Iron Dragon.

They weren’t specific except to say their firewall isn’t triggered until there are hundreds of open connections that have “no expire”. I’m really very baffled by it all.

Does anyone have any thoughts on this?

Since posting I have deliberately avoided loading any of the Wordfence admin pages in my browser and so far I have not been blocked by my host again. This isn’t really the kind of “confirmation” I’m looking for on this issue though…

I also have users who have problems posting comments to my site because wp-comments-post.php returns a 404.

In my case it only happens to them if they’re using Chrome. If the same user changes to Firefox or Safari they can post just fine.

I am also baffled; I have replaced wp-comments-post.php from a fresh download of WP 4.6.1 to ensure the file isn’t corrupt, checked .htaccess, etc. Why would it be picky about just one browser?

To my host, since they are the ones blocking me for “too many connections”.

Major thanks! I am not sure why I didn’t come across the special mail tags page before. I was searching all over the site for that information. Maybe I just missed it because I was upset. ??

Thank you also Gnomag for your suggestion! I will look into that too.

I changed the settings to Dark and it appears to be working now.

Thanks for the note about the spamshield error; I will pass that on to that plugin author. I didn’t disable the plugin so there doesn’t seem to be a conflict there.

Thank you for your help!