IFDB: how are embargoed entries on the same date posted?

You all may have noticed that @DeusIrae and @jjmcc have been posting their reviews for IFComp 2022 to IFDB. I sort of have, for the ones I wrote in t he author forum, but I got behind. I, like, blame society, and stuff.

But I also want to catch up. My initial reaction was, okay, I can post 2 a day to do so. Which got me wondering: it’d feel a bit odd if my 2 reviews popped up first on the page, sort of pushing the others to the back a bit. There’s a 1/12 chance it happens at random, but it’s enough.

So I was wondering: what is IFDB’s procedure for posting embargoed reviews on the same day? Which takes precedence? Is it by some internal list? Alphabetical order?

(My solution to negate this is to submit reviews on certain days 30 minutes before GMT Midnight, along with a daily embargoed review. There will be 12 of them. They will be almost exclusively shorter games, especially ones that got a lot of reviews during IFComp, so they may need less of a signal boost, and my reviews will add relatively less to what is already there.)

I hope others follow up with IFComp or EctoComp reviews as well. They’re good to see. It feels like IFDB has been a lot busier over the past year.


Hopefully folks who know what they’re talking about will jump in, but one data point I’ve noticed is that the order of embargoed reviews sometimes moves around for me on the home page – I dunno if it’s wholly random, but there does appear to be something that isn’t completely deterministic happening.


This isn’t directly connected (because I don’t know the answer), but a fun trick is that if you embargo a review and then un-embargo it, it goes back into the queue in its original position. If you wait long enough before un-embargoing, they never show up on the front page at all. I did that with a really big chunk of reviews in 2017 or so.


I’m not 100% sure I understand what’s being asked here, but the code for handling new items is here: ifdb/newitems.php at main · iftechfoundation/ifdb · GitHub

In particular, in getNewItems() there are a bunch of kinds of things we can put in the “New on IFDB” section:

  • Site news
  • Games
  • Recommended lists
  • Polls
  • Reviews
  • Competitions
  • Clubs
  • Game News (news added to a particular game listing)
  • Competition News
  • Club News

And the vast majority of those are sorted by their created date. The only exceptions are site news, which is sorted by posted, and reviews, which have the embargo system.

For reviews, the date used for sorting is:

        ifnull(reviews.embargodate, '0000-00-00')) as d,

You have to read this inside out. We’re comparing two dates, the createdate of the review, and the embargodate. We’ll sort by whichever is greatest (i.e. the latter of those two dates).

If the embargodate is null (i.e. if the review doesn’t have an embargo date), then we’ll pick the greatest date of either createdate or 0000-00-00. Since no review could possibly have a createdate that old, that means that we’ll use the createdate for unembargoed reviews.

(This is why if you unembargo a review, it will sort in its createdate order. If that’s weeks old, then the review will not appear on the home page.)

The sort order in the event of a tie is “undefined”

We’re ultimately sorting all of the items in PHP with usort. According to PHP’s documentation, If two members compare as equal, they retain their original order. Prior to PHP 8.0.0, their relative order in the sorted array was undefined.

We’re on PHP 7.4, which means that the sort order is “undefined,” which means that PHP can just do whatever it wants with the result. The effect will typically be stable for only as long as nothing gets added to the list of things to sort, but once something new gets added to the list, the items can seem to swap randomly.

(And even when we upgrade to PHP 8.0+, the sort order returned will be the “original” order, which means the order that our database returned them. SQL databases are allowed to return items in an arbitrary order when the ORDER BY clause is a tie, though I’ve heard a rumor that our database, MariaDB, returns rows in “insertion order” in case of a tie, i.e. createdate will effectively break the tie.)

For createdate, you’ll almost certainly never see a tie, because those dates are full timestamps, e.g. 2022-12-10 17:37:20. But embargo dates are dates timed at midnight; any two reviews embargoed for the same date will hit a tie, and so they’ll return in an “undefined” order, “moving around” non-deterministically, as Mike noticed.


Thanks for the detailed answer! I did have a question if the reviews were maybe sorted beneath the hood by embargo date and then by the date we embargoed them.

This may seem a bit silly to worry about, but if they were, my reviews would’ve gotten top billing each day because I embargoed them last, which seems slightly unfair.

So I’m glad the order is more or less random once IFDB sorts by embargo date. It seems like the right way to handle things.