Skip to main content
Developer Jahia 8.2

How do I retrieve all the published files of a site with GraphQL?

Question

How do I retrieve all the published files of a site with GraphQL?

Answer

Query the LIVE workspace. Everything in it is published by definition, so no filter on a publication property is needed - or wanted.

{
  jcr(workspace: LIVE) {
    nodeByPath(path: "/sites/mySite/files") {
      descendants(typesFilter: {types: ["jnt:file"]}) {
        nodes {
          path
          name
        }
      }
    }
  }
}

That is the whole answer. The published/unpublished distinction in Jahia is the EDIT/LIVE workspace split: an unpublished node simply does not exist in LIVE.

Do not add a filter on a published property

It is tempting to write something like fieldFilter: {filters: {evaluation: NOT_EMPTY, fieldName: "published.value"}}. Do not. That filter is accepted by the schema and returns an empty list, which reads as "this site has no published files" rather than as an error. It is a silent wrong answer, and it is harder to notice than a syntax error.

Measured on Jahia 8.2.3.2 against the Digitall demo site:

QueryResult
LIVE + fieldFilter on published.value0 files
LIVE, no field filter129 files
EDIT, no field filter130 files

That one-file difference is the point

The site has 130 file nodes in EDIT and 129 in LIVE. The missing one - /sites/digitall/files/bootstrap/fonts/glyphicons-halflings-regular.svg - is simply not published. Comparing the two workspaces is therefore also how you find unpublished files:

# run the same query twice, once with workspace: EDIT and once with LIVE,
# and diff the paths

Why filtering on j:published does not do what you expect

j:published does exist on nodes in LIVE - it is there alongside j:lastPublished, j:lastPublishedBy and j:originWS. But it is publication bookkeeping, not the thing that decides whether a node is in LIVE. By the time you are querying LIVE, the filtering has already happened: the workspace is the filter.

Filtering on it again can only remove rows that should have been returned, which is exactly what the measurement above shows.

Narrowing the result

/sites/mySite/files is the file repository. Query /sites/mySite instead to include files stored elsewhere under the site, at the cost of walking more of the tree. Add limit and offset on descendants for large sites rather than pulling everything in one request.


This article was drafted with AI assistance, then reviewed and curated by Jahia Customer Support engineers before publication.