Hmmm, yeah, I find dates confusing as well, but I hope this will clarify things a little:
The date validity check is carried out in the class definitions. For a news, blog or event item in the package, it’s in the
Resource class defined in
resource.class.inc.php. The routine in the functions file is there for compatibility with pkBlog, the forerunner to PubKit.
case 'date':
if ($features[1] == 'Req' && strlen($fields[$field]) < 1) {
$errors[] = $lang[$features[2]] . ': ' . $lang['err_blank'];
}
elseif (!empty($fields[$field])
AND strtotime($fields[$field]) === FALSE) {
$errors[] = $lang[$features[2]] . ': ' . $lang['err_dateFormat'];
}
break;
So, a date field that is specified as "required" in the item type’s "validate" array must not be blank, and must evaluate to something other than
False when fed to the PHP
strtotime() function. (This assumes PHP 5.1 or later; you’d need to check for
-1 as a bad format in earlier versions). In fact, you can input anything that the function sees as valid, regardless of the setting in your language file’s format string.
The string that comes back in the error message does need updating to the 4-digit year for my own preferred format - I just find it clearer now that we’ve gone beyond "09" for 2009. It should match whatever you have in the dateFormat string. I plumped for %d %b %Y as an unambiguous date format to prompt for.
When an error is detected, the date field just comes back as previously entered, as POST data. When the form is displayed for re-editing (returning from the preview, or from the management list), the format string from your language file is applied to it in the constructor function of the item type’s class file. The
&debug=`1` parameter is quite handy when you’re sorting this kind of thing out.
Re the confirm deletion template, this is actually an alternative form to the new/re-edit input form. The one in the package has only placeholders for title and headline fields. If you want to add a date, you’ll need to use a custom delete confirmation form. Have a look at
event.class.inc.php to see how that is handled.
pk.news.main.tpl and
pk.news.manage.tpl are pure Ditto tpl chunks - they know nothing of the settings in the PubKit files, hence the need to use PHx rules to convert the dates. I dare say you could include snippets at this point (maybe some custom PHx modifiers) to keep all the date formats in line, but it would add to the complexity (isn’t it complex enough already???). I also tend to build from the output backwards - that is, create items by hand and get them to display as I want, then add the PubKit input and management functions to make routine operation easier.
Hope this helps soothe your nerves
KP
KP
