Did you ever wonder how MODX automatically publishes and unpublishes Resources on a particular date? A MODX user asked about this on the Forums and I realized that I had a general idea, but no clue on the details. A little digging in the MODX core code helped me understand how it’s done. In this article, I’ll discuss the process.
Limitations
The first thing to understand is that when no one is visiting the site, MODX is not on the job. The MODX code only executes when someone visits the site and requests a page. That’s why if you set a publication date in the future, and your site has low traffic, the Resource may not actually be published until several days after the specified publication date. In other words, it will be published at the time of the first visit to the site after the publication date.
Short of creating a cron job that runs every few minutes and checks publication dates, there’s really nothing you can do about this. Clients may sometimes complain if they notice the published on date doesn’t match the one they set, but the fact is, there’s really no value in having a Resource published when no one is visiting the site. And, if the client checks the site on the publication day, they’ll see the published Resource as long as they check after the publication time (which is often the previous midnight).
A Bad Strategy
My first assumption about publication was that MODX checked the pub_date and unpub_date fields of every Resource on the site on every page load. This would be horribly inefficient and would slow down page loads considerably, especially since it would be completely unnecessary on most requests. Worse yet, on some sites those fields are never set, so every check would be unnecessary.
A Good Strategy
I should have known that the process MODX uses is more efficient. In the MODX core/cache/ directory, there is a folder called auto_publish, and inside it, a file called auto_publish.cache.php. If you look at that file in a text editor, you’ll see that it’s very short. On my local machine, it looks like this:
<?php
return 0;It’s returning 0 because there are no Resources with their pub_date or unpub_date fields set. If there were, the file’s content would look something like this:
<?php
return '1393536872';The number returned from the file is a Unix timestamp. It represents a number of seconds since Jan 01, 1970. In this case, it also represents the time the very next Resource due for a change in publication status. On every page request, MODX checks the number in the file against the current time (the code is in the modRequest class). If the number in the file is less than the current time number, something is due to be published or unpublished. If not, there’s nothing to do and MODX goes on with handling the request.
If the number indicates that some Resource is due for a change in publication status, MODX leaps into action. It calls cacheManager->refresh(), which in turn calls the autoPublish() method. That method first finds all the Resources due to be published or unpublished. It resets their published status, and for Resources being published, their publishedon date. It clears the pub_date or unpub_date field, whichever is appropriate. That code looks like this:
$publishingResults['published']= $this->modx->exec("UPDATE {$tblResource} SET published=1,
publishedon=pub_date, pub_date=0 WHERE pub_date IS NOT NULL AND pub_date < {$timeNow} AND pub_date > 0");
$publishingResults['unpublished']= $this->modx->exec("UPDATE $tblResource SET published=0, publishedon=0,
pub_date=0, unpub_date=0 WHERE unpub_date IS NOT NULL AND unpub_date < {$timeNow} AND unpub_date > 0");Next, the code queries the database asking for the Resources with the minimum value in the pub_date and unpub_date, using two queries like this:
$sql= "SELECT MIN(pub_date) FROM {$tblResource} WHERE published = 0 AND pub_date > ?";
$sql = "SELECT MIN(unpub_date) FROM {$tblResource} WHERE published = 1 AND unpub_date > ?"The lower of the two date numbers goes into the auto_publish.cache.php file as a timestamp. It’s the next time any Resource is due to change publication status. This check is done after the modifications listed above that cleared the dates for articles it just published or unpublished, so these new date numbers always represent the very next Resource due to have a publication status change in the future.
How Does the Number Get Set in the First Place
We’ve just seen how the number in the auto_publish.cache.php file number gets updated when a Resource is due for a publication status change, but how does the number initially go from 0 to a real date? As you might guess, it happens when a Resource is saved with the pub_date or unpub_date field set. If either one is set, MODX checks its publish or unpublish timestamp against the time in the auto_publish.cache.php file. If it’s lower, or if the time in the file is 0, the Resource’s publish or unpublish date (whichever is lower) is converted to a Unix timestamp, and written to the auto_publish.cache.php file.
The odds of you needing to know how this process works are quite small, but I’m always impressed by the efficiency and elegance of the MODX core code, and the skill of the coders who created it.
Bob Ray is the author of the MODX: The Official Guide and dozens of MODX Extras including QuickEmail, NewsPublisher, SiteCheck, GoRevo, Personalize, EZfaq, MyComponent and many more. His website is Bob’s Guides. It not only includes a plethora of MODX tutorials but there are some really great bread recipes there, as well.