I've just completed an upgrade from 2.5.3 to 2.7.0 (never want to do THAT again ;) ) and have run into an issue that seems to be coming from some changed security restrictions.

I have several simple pages that (in a nutshell)

  • read the contents of a web page into a variable
  • allow the selection (via radio button) of an e-mail address value for another variable
  • mails the html content to the provided e-mail address

This has been done for the last year or so, no problems at all. Two lines of php have capture the content and another line sends the mail with the native mail() function. The page has used a form to post the html payload and email address selection back to itself (action="") and then based on the value of a couple hidden variable has either executed the mail() command or recycled the page with alternate html to be delivered as payload.

Since upgrading to 2.7 these form submission have stopped working, and I am confronted with that ugly grey box stating

The following errors were encountered

- The action you have requested is invalid.

Return to Previous Page

A "wonderful" generic message, which says absolutely nothing at all. (sigh)

I bit of time with google had me thinking this was being caused by a now mandatory CSRF token, but looking at my config I saw that CSRF protection was not even enabled.

I can't find a hint of anything in any log file anywhere, nor does anything appear on screen for a superuser. Also, the action does not complete, the mail is not sent.

I whittled one of the pages down to the following contents as a test:

<form action="" method="post">
   <input type="hidden" name="toAddy" value="[email protected]" />
   <input type="submit" name="submit" value="mail" />

And this also generated the error page.

Looking at a web console in FF, nothing is generated at all. I simply cannot find any specific error information anywhere which can lead me to a next step.

Has anybody seen this, or does anybody have an suggestions?

Any help is very much appreciated.


1 Answer 1


It seems that for whatever reason my 2.5.3 was permitting these forms to function even though "Process form data in Secure Mode?" was set to YES. After the upgrade to 2.7 this restriction began to be enforced on my admin forms as well. The solution comes in two parts:

  1. Add a hidden input field to carry the XID token

  2. Find and use a suitable value to assign to XID. This turned out to be available through a global variable that had fallen out of the documentation, for whatever reason. The token is {XID_HASH} and will deliver and valid XID at any time.

So, your hidden input field will look like this:

<input type="hidden" name="XID" value="{XID_HASH}" />

and when part of your hand-coded forms, will successfully pass through the Secure Mode restrictions.

Here is some reading on the subject.

  • 1
    It's totally OK (encouraged, even) to answer your own question!
    – Alex Kendrick
    Sep 27, 2013 at 14:50
  • Thank you, Adrian, that's a lovely bit of intel to have. Much appreciated! (Hm, that reads funny in context :) I meant the "reading on the subject" bit. But yes, thank for the other tip as well. That takes a litte of the trepidation away.
    – Andy
    Sep 30, 2013 at 14:19
  • I was getting this problem with Solspace [freeform] if I submitted a search, then hit the back button the browser and tried to submit again. Secure Forms don't like reusing the XID, apparently.
    – 4midori
    Nov 7, 2013 at 0:16
  • I was having the same issue and adding the hidden field worked for me also. Thanks for sharing and for the reminder of why this is happening. Dec 27, 2013 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.