Using getValue() with Date Fields in MODX

In a recent article, we looked at a very fast and efficient xPDO method for getting the value of a single field from a MODX object using the getValue method of the xPDO object. For example, this code will get the introtext field from a resource with the pagetitle “Products”:

[code language=”php”]
$query = $modx->newQuery(‘modResource’, array(
‘pagetitle’ => ‘Products’,
));
$query->select(‘introtext’);
$intro = $modx->getValue($query->prepare());
[/code]

In this article, we’ll look at using it with date fields like createdon, and publishedon.

MODX logo

A while back, I wrote an article on MODX date fields where I complained about the fact that the date is stored as a unix timestamp, but retrieving it converts it to a date string. To format the date string yourself, you have to convert it back to a timestamp, then back to a formatted string. That requires two completely unnecessary transformations, both of which take time to perform.

Using getValue(), as described in the last few articles, provides a really nice solution for this, since getValue() always gets the raw value of a field. Here’s an example that gets the date that a particular resource was published and displays it as a formatted string using PHP’s strftime() function.

[code language=”php”]
$query = $modx->newQuery(‘modResource’, array(
‘pagetitle’ => ‘Products’,
));
$query->select(‘publishedon’);
$date = $modx->getValue($query->prepare());

if ($date === false) {
/* resource not found */
} elseif (empty($date)) {
/* resource not published */
} else {
return strftime("%m, %d, %Y", $date);
}
[/code]

The code above will give you a very fast and efficient display of the date the resource was published. Note that even though the output is based on a field from a foreign resource (i.e., not the current resource), that resource is never retrieved by our code. The code gets only the value of the field we’re interested in.

Other Date Fields

The process is the same for any of the date fields for a resource. Just put the field name in the select() line. Here’s a list of them:

  • createdon
  • publishedon
  • editedon
  • publishedon
  • pub_date
  • unpub_date
  • deletedon

The main code of our method is the same as it was in earlier articles, but you need to be a little careful in detecting errors because if the field is empty, the method will return '0', and PHP needs a little help in distinguishing that from an error return (false). You also need to remember that the return value will always be a string, even though the value in the database is a Unix timestamp.

As we saw with boolean fields in the previous article, the trick is to use three equal signs (===) to detect the error condition. Here’s an example using the
editedon field that generates and returns output based on the state of that field:

[code language=”php”]
$query = $modx->newQuery(‘modResource’, array(
‘pagetitle’ => ‘Products’,
));
$query->select(‘editedon’);
$editedOn = $modx->getValue($query->prepare());

if ($editedOn === false) {
/* The query failed */
$output = ‘Resource Not found’;
} elseif (empty($editedOn)) {
$output = ‘Resource Not Published’;
} else {
$output = strftime(‘%m, %d, %Y’, $editedOn);
}
return $output;
[/code]

With the code above, the first if looks for a boolean value of false. That result will only happen if the getValue() call fails, so it can reliably be used to detect an error condition. The second if will detect any case where the field value is empty or zero, so it will execute in all cases where the resource has not been published yet. If the code reaches our third if statement, we can be sure that the query was successful and that some date is set.

You might be wondering why we didn’t initialize the $output variable in the code above. You could make a very good argument that it should be early in the code with something like this:

[code language=”php”]
$output = ”;
[/code]

This is a very good practice. It helps avoid errors that pop up when a user has E_NOTICE errors on and the variable is used before being initialized. In this case, it’s technically unnecessary. Because the three if conditions exhaust all the possibilities, the $output variable will always be set before it could be used. Notice also that in all three if sections, the $output variable is on the left, which means that we are setting its value rather than using it, so there’s no chance of PHP complaining about using an unknown variable.

All that said, it would still be a good idea to initialize the $output variable in case the code involving the variable changes somewhere down the road.


For more information on how to use MODX to create a web site, see my web site Bob’s Guides, or better yet, buy my book: MODX: The Official Guide.

Looking for quality MODX Web Hosting? Look no further than Arvixe Web Hosting!

Tags: , , , , , , , , | Posted under MODX, MODX | RSS 2.0

Author Spotlight

Bob Ray

Bob Ray is the author of MODX: The Official Guide and over 30 MODX add-on components. He hosts Bob's Guides, a source of valuable information for MODX users, and has been very active in the MODX Forums with over 19,000 posts.

Leave a Reply

Your email address will not be published. Required fields are marked *