woolgatherer

We did not resolve the issue but, annoyingly perhaps, it has gone away.

Thanks. I wish the answer had been otherwise ??

Did you ever get help with this? I’m wanting to do the same. Koken has become unusable.

This problem has just been notified to me by a customer. I too have the “Allow registration on the checkout page” option disabled. I do not require customers to register and in fact prefer that they do not as it provides too many backdoors. If they do wish to create an account, I want to enforce strong passwords.

I note this issue was reported EIGHT MONTHS ago, but no response. I deduce crap software and support and will therefore be removing the plugin.

It is indeed broken with version 3.0.

The plugin works fine on the single post page but is broken on the front page.

It is not a plugin conflict (this is a new installation and still very fresh) and the same behaviour was observed in a number of themes tested, including the default – so it is not theme-specific either.

From what we can tell from the code there is an exclusion in the code to prevent the gallery showing on the front page (OK – that makes sense to me) – however, it still displays non-functioning thumbnails on the front page.

We roughly hacked it so that the behaviour is the same on the front page as in the single post page. Example can be seen here:
https://www.poultry.sanday.org.uk/
https://www.poultry.sanday.org.uk/2010/07/is-a-very-very-fine-house/

Hi imiger

It is pretty clear (to me at least) that this problem affects some users, based on their firewall and security software. It is definitely caused by the Dreamhost hack of the WordPress files. Commenting the hack out cures the problem.

I think the fact that WordPress installations on other hosts also exhibit the same problem might be down to them deploying a similar tactic. Of course, there can be no level of certainty about this.

Whatever – if you comment out the code in your comments and comments pop up files, the problem does go away. It comes back when using the Dreamhost 1-click upgrade though ??

To be clear – it is only these lines that need removing or commenting out:

if (!$_SERVER[‘HTTP_REFERER’] == dirname(__FILE__) . ‘/wp-comments.php’)
{
die (‘Error: This file cannot be used on its own.’);
}

(my comments pop up file consisted of only this code, and nothing else)

The files in question are in the root of the installation, not in any of the theme directories.

The usual caveats apply – but it worked for me and for those of my readers who were affected. Hope this helps.

Thanks, V – I shan’t have a go at my hosts about it then.

May I clarify something? This problem arose with my blog today, for the first time after several years of using WordPress.

My host (Moose Internet Services) went belly up last week and I have had to move hosting to Dreamhost. My newly-installed WordPress is 2.0.4, I was running 2.0.3 previously, with no problems at The Moose.

Dreamhost say this, in their wiki:

“Finally, we have put a tiny little hack of our own in the wp-comments-post.php and wp-comments-popup.php files to try and prevent automated comment spam a bit. If you end up never getting any comment spam, it may be that that little hack was enough!”

Now… I looked at my WP code, and I found the section indicated in this thread. I had a wp-comments-post file with the code at the head (before the requires statement) and a popup file, which had only this piece of code in it.

Alarm bells rang.

We looked at the WordPress official download for 2.0.4 and this code does not appear

What I want to know is – was this code at some time in the official WP release? or was it NEVER there and are all the people who have reported the problem in fact hosted at Dreamhost?

I’ve commented the code out for now but I need to work out what to do if this is a Dreamhost hack (the code was uncommented!!) and they are likely to reintroduce it with any automatic upgrade processes.

I’d appreciate comments on my thoughts

Thanks you

As far as I can tell, it fails to work. I’m here looking for help with the problem.
Anybody?

Thank you. I wouldn’t worry if it were just my own blog but it is a group resource and I am dealing with very computer-illiterate users who find such things worrisome.
As I got rid of the error by deactivating the plugin and the plugin continues to work regardless – I guess I have the best of all possible worlds, don’t I? ??

Ah. I set it to 0 days and got 0+1=1.
Great
Until I made another post and then got no posts at all.
Interestingly th eproblem seems to have fixed itself with the later posting and am now working on the principle that the previous last posting caused some kind of blip.
I am worried though that I have a database error or a plug in conflict as there was some kind of interplay between the page post listings and another plugin – the Page Navigation 1.2 GaMerZ plugin.
Oddly, when I set days to more than 1 (when the listings were broken) the Page Navigation links vanished. They worked OK when I set it to 1 days (but was getting 2 days posts)
I think the technical term for what we have here is a “b*ll*king mess”
I dislike unexplained problems that go away on their own ….

I have been running this plug in and have been very happy with it. However, a mysterious SQL syntax error has been appearing in my Post Preview. To try to track this down I deactivate the plug ins one by one. It was this plug in causing the problem.
What I would liek to know is – is it a real problem or a spurious error that I and my users can live with, seeing this error every time they preview a post? Or am I causing an underlying database error by rnning this plug in?
And …. although the plug in is deactivated the code is still working although the SQL syntax error has departed!
Advice please?