alextegelid

The debug page took about 3-4 minutes to load. Apparently we’ve logged just over 300.000 events in the past two weeks. I’ll have too look into what’s creating all those logs. Thanks for the speedy response!

I’ve been busy the last couple of weeks and haven’t had a chance to try out your tips. You seem to have solved it nicely in release 2.0.3. Thanks for that!

Thank you for the fast response and the pre-beta version. Unfortunately it didn’t solve the problem. I’ve been debugging a little and if my guess is correct the method filter_soft_attributes inside Email_Encoder_Validate should filter some emails with a lighter encryption (inside the placeholder attribute for example) before the heavy javascript based encryption is applied?

I had a look at the $content variable inside that method and it never contains the source code where my placeholder attribute appears. It seems to only contain a chunk of the source code.

Bear in mind that I might be completely wrong in my assumption.

The same goes for any other row action filters, like post_row_actions and {$taxonomy}_row_actions, where Nested Pages will redo the post list.

The sense morale is that Nested Pages shouldn’t hide theme or plugin specific functions.

Thank you! It seems that module isn’t installed on the server, and that’s clearly why it isn’t working. Maybe a check for that module would be appropriate? Something like this:

<IfModule mod_setenvif.c>
#SetEnvIF REMOTE_ADDR "^XX\.XXX\.XXX\.XX$" DenyAccess
#SetEnvIF X-FORWARDED-FOR "^XX\.XXX\.XXX\.XX$" DenyAccess
#SetEnvIF X-CLUSTER-CLIENT-IP "^XX\.XXX\.XXX\.XX$" DenyAccess
</IfModule mod_setenvif.c>

Thanks, I’ll look into this. Come to think of it it just might be the same web server that’s causing the problems, though for several of my sites. Thanks for pointing that out, I’ll try to get back to this thread with an answer.

I have the same problem. I all my cases it seems to be the directive SetEnvIF that’s causing the server error. The directive doesn’t seem to be valid on any of the webservers that i encountered this on…

Commenting these lines out seems to solve the problem, and still block the users with the row “deny from XXX.XXX.XXX.XXX”.

This is just a manual way of fixing this every time it happens. I think the developers need to find a permanent fix for this.