I have code like:
$mform->addGroupRule('aftergroup', array('afterdate' => array(array('Invalid date format', 'regex', '^\d{1,2}/\d{1,2}/\d{1,4}^', 'server'))));
This seems to let expressions like 1234/12/1234 through. While ^\d+/\d+/\d+^' correctly makes sure that only digits are entered I cannot seem to find a regular expression that Moodle will restrict the number of digits. Ideas?
The curly braces notation for repetition should not be allowing 1234/12/1234 in that case, though I am admittedly unfamiliar with how Moodle handles regex patterns handed to it.
As you have it, the following inputs would also be valid:
1/1/4
1/2/14
1/3/014
1/4/2014
99/99/9999
That is what I thought. But it is not working like this. That is the question why doesn't the regular expression work?
As you're using server-side validation anyway, why not put in a restriction in the 'validation' function in the form definition that will properly parse the date and check that it is valid (which would also allow you to exclude the 31st Feb and other non-existent dates), rather than the partial solution which you're attempting here.
Alternatively, why not just use the Moodle built-in 'date selector' form element? ( http://docs.moodle.org/dev/lib/formslib.php_Form_Definition#date_selector )
Isn't the add rule a validation function? It is using regular expressions to validate the input? Ar you saying that the regular expressions "rule" in this case does not work?
The 'date_selector' works fine but I am not able to have a fine grain control over the range of dates allowed. I can only specify the minimum year and maximum year. So there would be no way to specify something like year to date or the 3 months before and after now. That is way I opted to go with the YUI Calendar.
What I am suggesting is that whilst regular expressions are one way of validating the date, they are a) quite hard to get right and b) an incomplete solution to the validation of dates (as they won't check for whether or not the date actually exists).
I'm suggesting that a far better approach, in this case, would be to add a function to your form definition called 'validation' ( http://docs.moodle.org/dev/lib/formslib.php_Validation - scroll down to the second section), which then allows you to use the full range of PHP date functions to not only check that there are the expected number of digits in the input, but also the date is a real date (from the user's perspective, they won't be able to tell the difference between validation done by a server-side 'addRule' and the server-side 'validation' function).
Thank you. I was unaware of this option. This helps.
But using this with the input of '1234/12/12' which is not a date if the format is m/d/y. The PHP function date_parse tries to parse this and comes up with the year as 'false' the month of 3 and a day of 12. Even here I need to apply a regular expression to make sure the date is at least close. Once I have verified that it is close then I could use date_parse to check for outlier cases like 'Feb. 31st'.
Also, if I return a string in the $errors array I get back to the original form (the input was rejected) but I don't see any indication of the error on the form like I would on addRule or addGroupRule. This seems to be a problem with using the validation in the Moodle form.
When I use DateTime::createFromFormat('m/d/Y', '2/31/2014') I get no exception but it formed a date 3/3/2014. So it seems rather than flagging it as an error it just adds the 3 invalid days to form the date. I would call this a PHP bug. But I am not going there.
So there doesn't seem to be a 'simple' validation answer. You?
Also if you have any input the first example for validation online is wrong. It shows a single argument of $data where two arguments ($data and $files) are expected.
Yes - the last version (or two?) of Moodle has introduced the new '$files' parameter and it looks like the docs have not been updated - as the docs are a wiki, feel free to make corrections when you spot any mistakes like that.
Could you be so kind as to walk me thru how I might change the docs? I have not done this kind of thing before. Thank you.
On the docs page, click 'Log in' in the top-right corner of the screen.
Next click 'Edit' at the top of the page (or beside the heading for the section you want to edit).
There are instructions on that page about how to edit the docs.
If I override the validation method and return an associative array I can see that $mform->setElementError() is called. It seems that this function does not work for an element in a group. How do I get a display of an error message?
I was curious about this one, so I've put together a quick test script to find out how to make it work.
It looks like you have to attach the error to the whole group, not to the individual elements within the group. See the attached file for an example of this working (I called the file formtest2.php, as I already had a formtest.php sitting in that directory). To try it out, drop the file into the root directory of your (dev) Moodle site then visit [site]/formtest2.php - try submitting the form with either of the text fields filled in (or both empty) to see an error message.
Thank you for the work. But is not working is the addGroupRule with a type of 'regexp' is not working when the regular expression limits the count as well as the type of input. Like \d{1,2}/\d{1,2}/\d{1,4}. I would imaging the regular expression rule would work the same with single elements as well as elements in a group. I just so happened to have elements in a group. The initial post was because I could not get the rule to work right. It was suggested later to use the validation override which seems like a good solution. But the problem with the regular expression rule still remains.
