bswb97

Great, thank you for the quick feedback. So a few other relevant points:

1) There are no caching plugins active on this site. My host (Bluehost) was having some technical issues with W3 Total Cache and requested we turn it off, which we did.

2) This issue has been detected across users. The other operator said users brought it to her attention and sent her a screencap. She replicated the problem and sent me a specific post as an example. I saw it there for about ten minutes and then it disappeared, but I did find it on other URLs.

3) It seems to be reverting back to a specific subset of commenters for auto-fill. Contest entries typically get 15-20 unique comments, but I keep seeing the pre-fill be the same 3-4 people even if they have not commented on a post (but have definitely commented elsewhere).

Does that help clarify anything?

I tried that and it’s not changing the issue at all.

Could this be a caching issue on the host’s end?

@juggledad — if Atahualpa is not “dead”, will there still be bug fixes/updates available, even if off of the WordPress directory?

@jamessnell — have you found an alternative? I love Atahualpa’s structure and flexibility and haven’t found anything close to it.

Please note that I had very similar issues. I had NOT used the return path on my sites hosted via Bluehost and everything worked fine. I had not received a form request in a few weeks and figured it was simply the summer lull. But troubleshooting showed that it was not getting through DESPITE the fact that the test emails were (sent to a wide range of addresses)

The configured settings that worked:

-Return path: enabled, both fields filled out. This had to be a same-domain email.
-Footer info: disabled.

Confirmed across three sites and five forms on Bluehost.

Follow up on the two issues:

Confirmation email generation: I used an email logger and saw that no transactions were being logged. I tried the technique with the same domain name and that still didn’t generate any transactions.

Redirect: I wrote a 404 redirect and it handled that issue. No big deal.

Duh. All that time looking at PHP code and it’s the simplest fix of checking for tag usage. Thanks!

I actually submitted a support ticket with my host (Bluehost). They took a look at my php.ini and told me that even though I had MAX_INPUT_VARS in there, it was commented out! So, stupid me, I made it active and it worked.

Hopefully your issue is as simple as that!

This works! Thanks!

Turns out it was a PHP issue after all. A few clicks on the back end and it works. Thanks for your prompt responses.

Running 5.4 set to use a single php.ini

Thanks! Just sent you a private message.

The plugin worked. Thanks!

I found a workaround for this but it still affects the image quality. I created a DIV around the image and then forced the proper size. This achieved the image size but it wound up blowing up the 640px, so there’s some loss of resolution. I’d still like a solution to the original problem.

I’ve done the less-nuclear path of deleting and clean installing the WP files in the root directory, wp-includes folder, and wp-admin folder. It’s still showing up (made sure I used a cache-less browser).

In this case, I didn’t touch the wp-content folder. However, prior to this, I did deactivate all plugins and switch themes and it still showed up. Where else could this possibly be? Is it possible the MySQL database is corrupted? And if so, would an XML export of page/post content still contain this?

This is a shared GoDaddy account with another non-WP user. Is it possible that the malicious script was put in that way?

Thanks! Talk about frustrating!

Did you get any answer to this? GalleryView has thumbnail and filmstrip capabilities that I like but the quirks are definitely frustrating.