Specifying resources overrides other query settings, like showUnpublished

[mgraham]

[[getResources? &resources=5 &showUnpublished=0 &showDeleted=0]]

Even if resource #5 is unpublished or deleted, getResources will still include it in the results.

The expected behavior is that getResources would hide the resource from the results.

Why is this an issue?

You might think that it is illogical to ask for specific resources, knowing that they are unpublished.

However, we routinely wrap getResources inside other snippets. Our snippet might calculate a list of resources, and then pass on this list to getResources for formatting. This has many benefits:

• allows us to avoid having to re-implement wheels (e.g. getResources' templating system)
• allows us to present a consistent interface

Currently we have a snippet that does a resource lookup based on some complicated template variable calculations. When the snippet has built a list of resources, it calls getResources. For instance:

$scriptProperties['resources'] = "5,10,32,86"; // in reality, this would be computed somehow
$scriptProperties['showUnpublished'] = false;
$scriptProperties['showDeleted'] = false;
return $modx->runSnippet('getResources', $scriptProperties);

The problem is that getResources displays all documents in the list, even the unpublished and deleted ones.

[opengeek]

It sure seems it would be better for your computations to not return the Resource ID to be used in the getResources call if the Resource is not published or deleted. Otherwise, we would have to create a whole new set of conditions for applying to the resources property, since it is expected behavior that it ignores the conditions used to select from the specified parents property.

I'll think some more on how we might approach this from a different perspective...

[mgraham]

Hi Jason,

Thanks for responding!

For my current project, I've done as you suggest: I changed my snippet to filter out unpublished and deleted resources before passing on the list to getResources.

In the general case, I'm not sure this is the best way to go because it makes it harder for snippets to wrap getResources.

I can definitely see your point: "why would I ask for resources that are unpublished or deleted if I didn't want them included?".

But the issue is a little more subtle: I want my snippet to be able to be used like getResources. I want it to have the same parameters and behavior of getResources. If the user of my snippet wants to include unpublished resources, they should be allowed to do so (by setting showUnpublished to true).

Keeping the interface the same as getResources means less documentation for my users, fewer bugs in my snippets, and more consistency amongst snippets. I got this idea from getPage, which does the same thing.

Maybe I can illustrate with an example. Here's an extract from my code:

// validate categoryId and make sure it does not contain any non-digits
preg_match("/\D/", $categoryId, $matches);
if ($matches) {
    return "invalid query";
}

$tmplVarResourceTable= $modx->getTableName('modTemplateVarResource');

$sql= "SELECT * FROM {$tmplVarResourceTable} WHERE 
     (`tmplvarid` = :tmplvarid) 
     AND
     (
       `value` = '{$categoryId}'
       OR
       `value` LIKE  '{$categoryId}||%'
       OR
       `value` LIKE  '%||{$categoryId}||%'
       OR
       `value` LIKE  '%||{$categoryId}'
     )
";

$bindings= array(
     ':tmplvarid' => $templateVarId,
);

$criteria= new xPDOCriteria($modx, $sql, $bindings);
$tmplVarMatches = $modx->getCollection('modTemplateVarResource',$criteria);

$resourceIds = array();

foreach ($tmplVarMatches as $match ) {
    $resourceIds[]= $match->get('contentid');
}

$scriptProperties['resources']   = implode(',', $resourceIds);

return $modx->runSnippet('getResources', $scriptProperties);

In order to filter out the deleted, hidden and unpublished resources, while keeping the same interface as getResources, I have to process the showDeleted, showHidden and showUnpublished parameters and include them in the above query (using an SQL JOIN with the resources table), or include them in a second query that filters the results from the first.

It makes my snippet more complicated and prone to error.

So I think that getResources should (at least optionally) allow the resources list to be subject to the same query params as parent is.

But if you decide not to go this way, I'd like to request that the documentation be updated to clear up the ambiguity.