As I understand it, embargoexpiry applies a decorator to SiteTree, so the functionality is added to all page types. I'm not sure if it allows further customisation per page type.

Mark

Almost there. Almost there...

The embargoexpiry module installs nicely and gives me exactly what I want! There is one small problem with it. Here's my example:

If I embargo a page (eg. a page of type ArticlePage), it does not appear in the sidebar menu (good) and it does not appear on the ArticleHolder listing page (also good).

However, I am calling the top 5 articles onto my homepage with a function that looks like this:

function LatestNews($num=5) {
$news = DataObject::get_one("ArticleHolder");
return ($news) ? DataObject::get("ArticlePage", "ParentID = ".$this->LatestNewsID(), "Date DESC", "", $num) : false;
}

Unfortunately, the embargoed article still shows up in this list.

The article is in fact still embargoed - we can tell because if you click on it's "more..." link you get re-directed to the admin log-in screen. So everything is working well in the background. I just need to be able to suppress embargoed articles from that top 5 list.

Anyone know how to do this?

jf/

Should that function be:

function LatestNews($num=5) {
$news = DataObject::get_one("ArticleHolder");
return ($news) ? DataObject::get("ArticlePage", "ParentID = ".$news->ID, "Date DESC", "", $num) : false;
}

Hi Mark

Nope. I have lots of sections in the site that use ArticleHolders/Articles. I use a custom function to return me the ID of the parent ArticleHolder I am interested in so that I only list *its* children on my homepage.

jf/

... and even when using $news->ID to drive the function, the embargoed article still shows up in the Top 5 list (I checked).

Does embargoexpiry module need to be adapted to be able to do what I need, or have I missed something?

jf/

I'm not really familiar with the details of embargoexpiry. It is supported by a community member.

I know that cmsworkflow's embargo function has a scheduled job that publishes/unpublishes by the times given, so when something is embargoed it really isn't published until that date.

So two main possibilities I can see: the embargoed page is being published too early (you can check this by seeing if Page_Live is populated before the embargo is reached), or there is something wrong with the query that grabs the top five (e.g if it is hard-coded SQL, you need to select out of Page_Live (published) instead of Page (unpublished). If queried via the ORM, check that it's querying out of live (using ?showqueries=1 to see what is being executed)

Mark

Looking directly at the SiteTree_Live table, there is a new column on the end called Embargo, which is populated by a date. I think therefore that the SQL doesn't have to differentiate between the SiteTree and SiteTree_Live tables to get the right data, it has to take that new column into account.

Now, we know that it does do that for the Menu and the listings on the ArticleHolder page. But we don't know why it doesn't do so when using the LatestNews() function.

Can you tell me where in the file structure I would expect to find the SQL for these queries? Both the ones that drive the menu system and the one that is called by the LatestNews() function? I've been trawling through Sapphire but I can't find anything that looks remotely close...

jf/

I've had a look at the embargoexpiry source. When you set an embargo date and "save and publish", it publishes the page immediately. It looks like it uses canView() to to control the visibility, returning false if the date is outside the embargo/expiry range. This will work where logic explicitly executes canView() on items in a return set (e.g. menus), but if you write an arbitrary function to return Pages, unless you code for it, it will be displayed regardless of the embargo or expiry dates.

This differs from the approach taken in cmsworkflow, which literally doesn't even publish the page if it has an embargo date, and relies on a separate process to run periodically, which does the publish/unpublish according to the dates.

The solution in your case is either to call CanView, or to add a condition to the filter where you get the records to exclude records outside of the date range. The latter is better if the query has a limit. If you ask for 5, you'll get 5. If you rely on canView(), the DB might limit you to 5, but canView() might exclude some of those leaving you with less than you asked for.

Mark