Publish press release at a precise time

Question

My department is planning to move its website to a new platform in the next year. We are evaluating several options including Drupal and Liferay.

One of the critical requirements is that we need to publish press releases at 11:00 each day. This time has to be very precise; how precise was not specified, the specification just said at 11:00 exactly but I would interpret this as meaning within 5 seconds or less after 11:00. This precision is needed because some of the statistics we publish are "market-sensitive" and we don't want some people to get them sooner than others (the media receive them ahead of time under embargo, other people get to see them at 11:00 via other channels).

We were told that Drupal would be able to do this, but in the initial test rounds it did not work. Now we are told that Drupal does not have the capacity to do this, or at least not with the specific architecture which the central IT service has set up with the assistance of Acquia. To quote:

As it stands now, the proposed solutions by Acquia and the central IT department, which are based on existing modules, will not be able to publish 'by design' a press release at 11:00 'sharp'.

'By design' means that content in Drupal which is 'published' is identified with a simple 'flag' which is set by a 'cron job' that checks at regular intervals if the publish date for an item has passed.

This means that in Drupal content can only be published (better: flagged as published) after the publish date/time and not on the publish date/time.

It is said that this might result in press releases appearing 5-60 seconds after 11:00.

Does this information make sense? I would have assumed that quite a few organisations have this requirement and that it would not pose a problem for Drupal? I would like to think that a clean solution can be found, as Drupal meets all our other requirements.

Notes:

• Our present website uses Oracle Portal version 10.1.4. According to our website team, this platform has built-in timed publishing which works fine. That is, pages and portal items (files) are set up with a specific time to become visible, which is quite precise. We have had some cache-related issues, but none with the actual timing of the publishing.

• We normally publish only 1 press release per day, occasionally 2. The press releases themselves are PDF files (ca 150 kbytes) with a 1-line title published on the front page of the website. Therefore the operations which have to happen between 11:00:00 and 11:00:05 are something like (a) do something to make the PDF file accessible (b) write new version of front page (c) manipulate cache(s) so that users actually get the new version of the front page.

Answer 1

I'm not aware of any architecture that can guarantee publishing of N number of items exactly at some atomic time -- as the number of items N increases; you will always have more processing time given linear execution.

• It sounds like they used hook_cron and an interval check for publishing unpublished items.

Option 1 (get rid of interval cron and provide 1 specific cron task @ time)

They could easily change the architecture to use a specific cron task to check at a specific time via Cron and publish all unpublished items via a Drush task -- removing timeout errors.

This requires new, relatively easy code.

Option 2 (parrallelize option 1)

call option 1 with like ultimate_cron module and background task, with N tasks to publish approximately N content items; parallelize the publishing process to limit how long it takes.

This is new harder code, and harder to debug.

Option 3 (crazyiness here)

create an unreachable directory which can be scraped. Scrape the result of viewing the Drupal pages final result to static files; remove restricting .htaccess file or rule at 11pm based on a simple cron task. Eg, make all your dynamic content -- into static pages prior to release and make they public instantly. Your page content may not allow this approach -- but everything would be made public in an instant.

This is crazy and pretty much a rewrite of any approach and removes Drupal and largely the DB almost (but for a reason).

Whose fault is the problem

Well, no 1 party is at fault ... the requirements were vague on how many items (at most) would be published at X time and also how long a lag in publishing is allowed.