I am using Drupal 5.3 .... and not using the Polling Module at all.

I'm gonna test on another machine a clean, clean, clean install, add CCK, then add the link, imagefield, and date 1.6 module ... the 1.7 seems to have messed up the views. I started getting issues when I added the date CCK field ... but that's just speculation.

If no one from Drupal.org can tell me how to fix this ... there is NO WAY my employer is gonna use Drupal for an enterprise-wide stable CMS ....

Thanks! Tom

Robert C Corsaro wrote:

I am also seeing this problem sparadoicly when using the polling module. Ppl vote and get this error, but there vote IS counted. It doesn't always happen and I'm having trouble finding a pattern. I'm using 6. 0beta3. What version are you using Tom?

Tom Holmes Jr. wrote:

...

After adding a few modules, and after a submit most forms ... now I get the error: "Validation error, please try again. If this error persists, please contact the site administrator."

I AM the site administrator. After going to the Drupal site, and going on Google, I can't find out why this was caused. Where is this coming from? Why is it random? And MOST IMPORTANTLY how can I fix it?????????????

The very last thing I want to do is blow away my drupal dev environment, re-install it from scratch, add the CCK module, and the imagefield, link, and date modules ... and then ultimately come back to the same issue. I think the date CCK 1.7 module breaks the views .... but that's another issue.

Please, please, please .... tell me how I can get rid of this validation error!!!!!! Thanks!

                 Tom

Hi Casper ... thanks for the information ... it is much appreciated.

Because of the lack of support to his issue ... I've had to just blow away the database and the install and ............... start from scratch ..... The issue was just incredibly horrible and frustrating ... and it had to mean that something was really screwed-up under the covers.

I just started a fresh new install ... on two systems .... one is my local system, and the other is our shared server in the office.

On my local laptop ... everything is working wonderfully ... even after I added cck, imagefield, link, and the date-1.6 cck fields. So far, it is working great ....

However ... on my shared server .... the installation is broken ... the advanced options allows me to change the host for the database ... and the install script doesn't change it ... it ALWAYS remains 'localhost' no matter what I change the host to. I finally had to set the db_url setting manually in order to get the resin install to work.

So now ................ when I start going through all the form/submites ... the message in green to indicate if something was done .... that keeps growing, and growing, and growing, and growing ... and seldom resets ....

Maybe that is indicative of what is happening to me. If I can't get this fixed .... then we'll be looking for another CMS solution ....

Casper wrote:

Hi,

On Dec 3, 2007 7:51 PM, Tom Holmes Jr. tom@tomholmes.net wrote:

...

I am using Drupal 5.3 .... and not using the Polling Module at all.

I am not using the polling module either.

I have a Drupal 4.7 site that has been up for two years. During the past three weeks I am seeing this error. Clearing the cache table and repairing the tables gets rid of this error for about 12 to 36 hours before it is back.

The reason I repaired the tables was that the the watchdog table contains hundreds of lines containing this:

"Got error 28 from storage engine query: SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid = v.vid WHERE r.nid = 1955 ORDER BY v.weight, t.weight, t.name in /home/<my-htmldir-here>l/includes/database.mysql.inc on line 121."

Right now the site is offline in order to be upgraded from 4.7 to 5.3. I will report back once the upgrade has been done.

FWITW according to what I read on Drupal.org this could very be the result of removing an "access module" without properly uninstalling first. This reference ( http://drupal.org/node/64114 ) is relevant as is this ( http://drupal.org/node/162148 ).

Casper

---

Casper Labuschagne +27827054416 ; Skype=krooninfo ; Struggling with computer errors, virusses and spyware? Are you forced to upgrade all your hardware and software? There is an alternative to the Windows madness! Visit http://www.ubuntu.com and install Ubuntu Linux!

Thanks for the help! How do you turn off the caching? You mean in the database, resin, or in drupal?

Skip Taylor wrote:

I'm not even sure this is related, but it can't hurt to try it.

I had something similar happening (the error was that everyone was being logged out sporadically) and no one could help me either. Then it dawned on me that pages were coming from a cache that were giving the errors.

I turned off cacheing and the problem went away. It may cost a bit in CPU time, but I don't have any hassles.

This is on a site that was upgraded from 4.7.7 directly to 5.3.

Maybe this might help or it may just be a shot in the dark!

Skip On Dec 3, 2007 9:51 AM, Tom Holmes Jr. <tom@tomholmes.net mailto:tom@tomholmes.net> wrote:

I am using Drupal 5.3 .... and not using the Polling Module at all.

I'm gonna test on another machine a clean, clean, clean install, add
CCK, then add the link, imagefield, and date 1.6 module ... the 1.7
seems to have messed up the views.
I started getting issues when I added the date CCK field ... but
that's
just speculation.

If no one from Drupal.org <http://drupal.org/> can tell me how to
fix this ... there is NO
WAY my employer is gonna use Drupal for an enterprise-wide stable
CMS ....

Thanks!
                           Tom

Robert C Corsaro wrote:
> I am also seeing this problem sparadoicly when using the polling
module.
>   Ppl vote and get this error, but there vote IS counted.  It
doesn't
> always happen and I'm having trouble finding a pattern.  I'm
using 6.
> 0beta3. What version are you using Tom?
>
> Tom Holmes Jr. wrote:
>
>> After adding a few modules, and after a submit most forms ...
now I get
>> the error:
>> "Validation error, please try again. If this error persists,
please
>> contact the site administrator."
>>
>> I AM the site administrator.   After going to the Drupal site,
and going
>> on Google, I can't find out why this was caused.
>> Where is this coming from? Why is it random? And MOST
IMPORTANTLY how
>> can I fix it?????????????
>>
>> The very last thing I want to do is blow away my drupal dev
environment,
>> re-install it from scratch, add the CCK module, and
>> the imagefield, link, and date modules ... and then ultimately
come back
>> to the same issue.
>> I think the date CCK 1.7 module breaks the views .... but
that's another
>> issue.
>>
>> Please, please, please .... tell me how I can get rid of this
validation
>> error!!!!!!    Thanks!
>>
>>                      Tom
>>
>>
>
>

--
[ Drupal support list | http://lists.drupal.org/
<http://lists.drupal.org/> ]

-- Half of being smart is knowing what you're dumb at. -- David Gerrold

---

NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

---

No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.13/1164 - Release Date: 12/2/2007 11:30 AM

Skip Taylor wrote:

In Drupal. Go to Administer/Site Configuration/Performance. The page cache is what was giving me grief.

This sounds plausible. I think the only place in core that this error's wording can come from is a mismatch of form tokens.

Each visitor, during their session on the site, has unique tokens generated from their session data for each form submission. I think it prevents forms being maliciously submitted by bots e.g:

http://drupal.org/node/28420

The submission handling checks the token is valid, but if a URL in a module claims to be cache-friendly, yet it actually contains such a token, then one visitor could end up with a cached version generated with another user's token. Hence a token mismatch arises and generates the error message as per includes/form.inc:395

I don't know enough to fix it, but if it can be replicated outside the Resin environment then you might be able to track it down, using two or three separate browsers simultaneously, to a particular form created by a particular module, and then alert the module's owner.

J-P

Hi Anton,

There are a lot of reasons why enterprise level companies might choose resin to host their app. One reason I could think of right off is the necessity to run legacy apps written in java. But the main reason is speed. Resin kicks all other servers right off the page when it comes to performance. And yes, that includes apache. I used resin to host my java apps for years and never had an issue, but haven't ran it with php so I can't comment on it's implementation.

For what it's worth, if the issue is with resin's php implementation and the client wants to use resin for java, resin can run as an apache module so it's possible to use apache for static files, resin for java and the standard apache php module for php (and therefore drupal).

It would be worth figuring out with resin though, especially with all the performance problems drupal currently has.

Anton wrote:

On 04/12/2007, Tom Holmes Jr. tom@tomholmes.net wrote:

...

If no one from Drupal.org can tell me how to fix this ... there is NO WAY my employer is gonna use Drupal for an enterprise-wide stable CMS ....

Forgive me for bringing this up, but I noticed you were using Resin as a web server. Do these problems still happen on Apache with mod_php?

I seems a little 'un-enterprise' to run a complex app like Drupal on a platform that has received practically no real testing from the Drupal community and isn't listed on the system requirements http://drupal.org/requirements. Let alone testing of your chosen contrib modules on Resins PHP implementation. My experience on enterprise app deployment is that they are extremely conservative and won't go anywhere near situations like that.

Resin apparently involves all sorts of (to use PHP language) opcode caches, differing threading models, and JIT compilation etc. In their early days PHP opcode caches also caused (and still do to some extent) weird issues in complex apps that took time to shake out. Just like fast_cgi also produced some weirdness early on.

Unless these problems also appear on Apache (as the most mature way of running PHP), these could just be symptoms of a platform combination that still has some maturing to do - a process all the other platform combinations are in various stages of going through.

I certainly wouldn't be try running a standard Python or Ruby app on Jython or JRuby without expecting there might be issues. Not sure why a Java implementation of PHP would be any different.

Absolutely 100% agreed on all points, especially the one below.

Anyway, I suspect the ability or inability to replicate this issue on Apache (or other platform) will at least partially help in isolating the actual problem.