prismic.io

json-responses

JSON responses

Although the API is very easy to experiment with, it is advised to use a kit for your technology, and to skip directly to our Developers' Manual; we guarantee that kits for your technology that appear on the prismic.io developers portal have been reviewed by our team, and are optimal to ensure compatibility with prismic.io's future features. If no library exists for your technology, you should read this to find out how easy it is to make one.

If you don't wish to use a kit, and wish to call your repository's API with curl for instance, do remember to set your "Accept" HTTP header to "application/json". This ensures that all the URLs in the API browser can be called that way.

But for now, let's focus on the API's parameters and naked JSON responses.

The /api endpoint

This is the document that needs to be called each time you want to make sure you're about to display content that is up-to-date.

It takes a single, optional parameter:

  • access_token: OAuth2-based token that will allow the user to access the limited information depending on his rights as set in prismic.io's writing room. If the API is private, you won't be able to get anything without this access_token; if the API is public, leaving this access_token out will simply make the /api endpoint give you access to the master ref only; if the API is open, you will be able to access both the master ref and the content releases without an access token.

The JSON response contains:

The refs object array lists the refs and releases that can be accessed by the current user (see the introduction of our API documentation to be reminded what refs and releases are for). This list changes depending on the access_token parameter. Each object in this array has at least three fields, and two optional ones:

  • id (a string) is the content release ID (which doesn't change when content changes),
  • ref (a string) is the content ref ID (which changes when content changes, and is the one that gets passed to API calls),
  • label (a string) is the ref's display name of the ref,
  • isMasterRef (optional) is a boolean set true if the ref is the master ref.
  • scheduledAt (optional) is the date the content release is scheduled to be pushed live, if it is.

A ref item object may look like this:

"refs": [
{
"id": "master",
"ref": "UlfoxUnM08QWYXdl",
"label": "Master",
"isMasterRef": true
},
{
"id" : "UlfoxUnM08QWYDvb",
"ref" : "UlfoxUnM08QWfGbB",
"label" : "Release of our new product",
"scheduledAt" : "2015-04-25T05:00:00+03:00"
}
]

The bookmarks object has as keys the existing bookmark IDs, and as values the matching document IDs. Bookmarks allow to give special "names" to certain particular documents that are unique in your repository. A bookmarks object may look like this:

"bookmarks":{
"about":"UjMvxsuvzT4ARdnq",
"jobs":"UjMuNrGIJ44BrirU",
"stores":"UjMwVbGIJ44BrirX"
}

The types object has as keys the document types' IDs, and as values the document types' display names. A types object may look like this:

"types":{
"blog-post":"Blog post",
"store":"Store",
"product":"Product"
}

The tags array contains all tags used on documents in the repository. A tags array may look like this:

"tags":[
"Macaron",
"Cupcake",
"Featured",
"Pie"
]

The forms objects array describe the operations than can be performed on your API, so you never have to forge any URL. If you're using one of our development kits, this is all transparent for you. Inside a form object, the fields are:

  • name: the display name of the form
  • method: the HTTP method to apply to the REST request (for instance: "GET")
  • rel: the type of result you'll get (for instance: "collection")
  • enctype: the encoding type to apply to the REST request
  • action: the URL of the REST request
  • fields: describing the fields that are allowed, their types and default values.

A form object may look like this:

"macarons":{
"name":"Macarons",
"method":"GET",
"rel":"collection",
"enctype":"application/x-www-form-urlencoded",
"action":"http://lesbonneschoses.prismic.io/api/documents/search",
"fields":{
"ref":{
"type":"String"
},
"q":{
"default":"[[:d = at(document.tags, [\"Macaron\"])][:d = any(document.type, [\"product\"])]]",
"type":"String"
}
}
}

Search form responses: global structure

Documents are retrieved as search form responses, including all the documents matching the given query. Search form responses are paginated and return 20 documents at a time by default.

Today, since the API only allows you to retrieve documents from the content repository, all the offered forms are search forms, and all return this kind of response. The parameters for search forms are described in the /api document, and they are:

  • ref (the only mandatory parameter) is the ID of the ref to apply the query on. A ref is a place on the repository's timeline that you may wish to query on, like: what is live right now (the master ref), or what will be live for that future content release, what was live in the past, etc.
  • q is the list of predicates defining the query, between square brackets (see our "Predicates' syntax" section)
  • orderings allows you to order your collection as you wish (see our "Orderings" section)
  • pageSize and page allows you to page your content, specifying the size of each page in your paging, and the number of the page you wish to be querying. Default values are pageSize=20, and page=1. Maximum pageSize value is pageSize=100 (higher pageSize values will be ignored).

The response JSON object has several simple fields, and a single array field (results, the list of documents). Those simple fields are:

  • page, results_per_page, results_size, total_results_size, total_pages are self-explanatory fields that relate to the pagination
  • next_page and prev_page are RESTful links to the search form resources; they may be null if the current page is the first or last one

Within the results array, documents are returned as object that have as fields:

  • id and type, which are self-explanatory!
  • uid is only present if a fragment of type "UID" is defined in the document mask. It's an identifier, unique within a type, editable by a writer.
  • href is the API URL to call to get the document itself (again, we don't want you to hardcode any API URL).
  • tags is a string array listing the document's tags.
  • slugs is a string array listing all the past slugs (since slugs change as the document's title changes); the current slug is the first element of the array.
  • linked_documents is an array summarizing documents that are being linked to in the current document (whether in Link fragments, or as hyperlinks in StructuredText fragments). It can be used to easily build a "read more" or "see also" feature on your front-end. Note that iy may not contain all linked documents if there exist a lot of links in your document.
  • data is an object containing the structured content itself. I contains a single field, whose key is the document's type, and whose value is an object that lists the document's fragments. Each fragment has as a key the fragment's ID, and contains an object that has two fields: the type string and the value object (the structure of latter depends on the type; all the possibilities for the value object are listed in the next paragraph).

More clearly, a typical document object may look like this:

{
"id" : "UkL0gMuvzYUANCpF",
"type" : "product",
"href" : "https://lesbonneschoses.prismic.io/api/documents/search?ref=UkL0hcuvzYUANCrm&q=%5B%5B%3Ad+%3D+at%28document.id%2C+%22UkL0gMuvzYUANCpF%22%29+%5D%5D",
"tags" : [ "Macaron" ],
"slugs" : [ "speculoos-macaron", "a-speculoos-macaron" ],
"linked_documents" : [
{
"id": "UotrJknM01Itg9Ul",
"tags": [ "macaron" ],
"type": "blog"
}
],
"data" : {
"product" : { /* This is the document's type */
"price" : {
"type" : "Number",
"value" : 3.5
},
"name" : {
"type" : "StructuredText",
"value" : [{ "type" : "heading1", "text" : "Speculoos Macaron", "spans" : [ ] }]
},
/* etc. other fragments */
}
}
}

Search form responses: the "value" field, per fragment type

For basic types, the value field contains the value directly, either as a number or a string.

"price" : {
"type" : "Number",
"value" : 2.5
}

For GeoPoint fragments, the value field contains two pretty self-explanatory sub-fields:

"location" : {
"type" : "GeoPoint",
"value" : {
"latitude" : 48.877108,
"longitude": 2.3338790
}
}

For Embed fragments, the value field contains a single field oembed, which is a regular oEmbed object, as described by the oEmbed spec.

"video" : {
"type" : "Embed",
"value" : {
"oembed" : {
"provider_url" : "http://www.youtube.com/",
"type" : "video",
"thumbnail_height" : 360,
"height" : 270,
"thumbnail_url" : "http://i1.ytimg.com/vi/baGfM6dBzs8/hqdefault.jpg",
"width" : 480,
"provider_name" : "YouTube",
"html" : "<iframe width=\"480\" height=\"270\" src=\"http://www.youtube.com/embed/baGfM6dBzs8?feature=oembed\" frameborder=\"0\" allowfullscreen></iframe>",
"author_name" : "Siobhan Wilson",
"version" : "1.0",
"author_url" : "http://www.youtube.com/user/siobhanwilsonsongs",
"thumbnail_width" : 480,
"title" : "Siobhan Wilson - All Dressed Up",
"embed_url" : "https://www.youtube.com/watch?v=baGfM6dBzs8"
}
}
}

For in-repository links ("Link.document" fragments), the value field is an object containing a isBroken boolean, and a document object describing the document (id, type, tags, slug). The slug is generated automatically from the first element of the page, usually the title.

"link" : {
"type" : "Link.document",
"value" : {
"document" : {
"id" : "Uo0X2gEAAJVG2ePz",
"type" : "article",
"tags" : [
"help"
],
"slug" : "first-document"
},
"isBroken" : false
}
}

For file links ("Link.file"), the value field is an object containing an file object, containing itself fields describing the image (name, kind, url, size). Images links are the same, except their object is called image, and they also contain height and width.

"link": {
"type" : "Link.file",
"value" : {
"file" : {
"name" : "Sponsor us.pdf",
"kind" : "document",
"url" : "https://prismic-io.s3.amazonaws.com/worldchanger%2Fe56fb9ce-20de-446c-b34b-cf0d731f23b8_sponsor+us.pdf",
"size" : "110972"
}
}
}

For web links ("Link.web"), the value field is an object containing a single url string field.

"link" : {
"type" : "Link.web",
"value" : {
"url" : "https:// prismic.io"
}
}

For Image fragments, the value field contains a main view, and an object of aternative views, which all together look like this:

{
"main":{
"url":"https://prismic-io.s3.amazonaws.com/lesbonneschoses/754c5929c6cc5907f5ef6c3ddad78d6f28c44b9d.jpg",
"alt":"",
"copyright": "",
"dimensions":{
"width":1500,
"height":500,
}
}
"views":{
"medium":{
"url":"https://prismic-io.s3.amazonaws.com/lesbonneschoses/fcc9921348bcccd2aa8dfe6fdf019fef5f952db9.jpg",
"alt":"",
"copyright":"",
"dimensions":{
"width":800,
"height":250,
}
}
"icon":{
"url":"https://prismic-io.s3.amazonaws.com/lesbonneschoses/5c2b5e5b2b3043846853a6f1f7e028f2577cd57c.jpg",
"alt":"",
"copyright":"",
"dimensions":{
"width":250,
"height":250
}
}
}

For StructuredText fragments, the value field is an array of sections, defined by their type ("heading1", "heading2", "paragraph", "image", "embed", ...). Depending on the section's type, the next fields in the object are the following:

  • if the type implies it is a text section ("heading1", "heading2", "paragraph", ...), then the other fields will be: text (the written content itself) and spans. The latter is an array of objects, to represent formatted spans of the section: each array contains the fields start, end and type. The latter has as possible values either "strong", "italic" or "hyperlink". If the value is "hyperlink", then the object will contain an additional field data, which is structured the same way as link fragments.
  • if the type is "embed", then the object will also contain an oembed field, that works the same way as in embed fragments.
  • if the type is "image", then the object will also contain the same fields as image fragments (url, alt, copyright, dimensions).

An example may look like this:

"content" : {
"type": "StructuredText",
"value" : [
{
"type": "heading1",
"text" : "This is a title",
"spans" : [
{
"start" : 8,
"end" : 9,
"type" : "em"
}
]
},
{
"type" : "paragraph",
"text" : "This is a paragraph that has a lot of formatting going on (even though this formatting could be on any prismic.io text block).",
"spans" : [
{
"start" : 38,
"end" : 48,
"type" : "strong"
},
{
"start" : 59,
"end" : 103,
"type" : "em"
},
{
"start" : 103,
"end" : 113,
"type" : "hyperlink",
"data": {
"type" : "Link.web",
"value" : {
"url": "https://prismic.io"
}
}
},
{
"start" : 103,
"end": 113,
"type" : "em"
},
{
"start" : 113,
"end" : 124,
"type" : "em"
}
]
},
{
"type" : "list-item",
"text" : "This is",
"spans" : [ ]
},
{
"type" : "list-item",
"text" : "a bulleted",
"spans" : [ ]
},
{
"type" : "list-item",
"text" : "list",
"spans" : [ ]
},
{
"type" : "image",
"url" : "https://prismic-io.s3.amazonaws.com/rudysandbox/abc59d245b772e06bd610d5ade73090e4765a971.jpg",
"alt" : "Sunset",
"copyright" : "",
"dimensions" : {
"width": 300,
"height": 225
}
}
]
}

For Group fragments, the value field is simply an array of sets of sub-fragments. For instance, in the example below, the first group of this fragment is composed of a "linktodoc" link sub-fragment and a "desc" structured text sub-fragment, while the second group of the same fragment is composed of a single "linktodoc" link sub-fragment:

"docs" : {
"type" : "Group",
"value" : [
{
"linktodoc" : {
"type" : "Link.document",
"value" : {
"document" : {
"id" : "UrDejAEAAFwMyrW9",
"type" : "doc",
"tags" : [ ],
"slug" : "installing-meta-micro"
},
"isBroken" : false
}
},
"desc" : {
"type" : "StructuredText",
"value" : [{
"type" : "paragraph",
"text" : "A detailed step by step point of view on how installing happens.",
"spans" : [ ]
}]
}
},
{
"linktodoc" : {
"type" : "Link.document",
"value" : {
"document" : {
"id" : "UrDmKgEAALwMyrXA",
"type" : "doc",
"tags": [ ],
"slug" : "using-meta-micro"
},
"isBroken" : false
}
}
}
]
}
orderings

Orderings

Predicates help you get the right set of content, but you might want the JSON presented in a specific order, so you can use it as is, in your project.

To order a collection by a given fragment, you simply need to tell which fragment, between brackets (see our "Writing your expressions" paragraph above):

[my.product.price]

If you want to order it from greatest to lowest, you can simply add "desc" next to the fragment's name:

[my.product.price desc]

Depending on your query, your collection may contain documents of several different types. If some returned documents do not contain this fragment, you can specify as many fragments as you want, in order to address all of the documents you are querying:

[my.product.price desc,my.blog-post.date desc,my.store.country]

This can also be useful if, on a given type, several documents have the same value for your ordered fragment; you can then tell them apart by setting secondary orderings, that easily:

[my.product.price desc,my.product.name,my.blog-post.date desc,my.store.country,my.store.city]

Be careful: since your fragments are typed, you do have to list them all even when they have the same name for different types. For instance:

[my.product.name,my.job-offer.name]

At the moment, it is possible to order by those fragment types:

  • Text
  • Date
  • Number
  • Range
  • Select
  • StructuredText (the order will be based on the first Text block found inside the fragment)
api-documentation

This section describes the REST API to access Prismic.io. It is useful to get an in-depth knowledge on how Prismic.io works, but most of the time you will be using a development kit; for that reason it is recommended to get familiar with the developer's manual before proceeding on this section.

API documentation

The API exposed by prismic.io is at the same time very powerful, allowing you to query and manipulate your content as you wish, and very easy to use, with concepts and tools that help you do things efficiently.

The main things that you need to know and remember:

  • /api is the single endpoint of your content repository, you can learn and browse everything else from there. In your code, you should never forge any API URL, as they're all described in /api as forms; this flexible RESTful way to expose our API's capabilities lets us free to add new forms later as we roll out new features
  • Forms are basically the ways the API can be used; you can compare a form to browsing a webpage, and getting data; then you request another form, and get some other data, etc. You can specify extra filters to apply on top of your form, using predicates (we'll get back to that!). Today, available forms through the prismic.io API are the one called "everything" (to query within all the repository, potentially filtering with additional predicates), plus one form per collection defined in the writing-room (to query within the collection, potentially filtering with additional predicates).
  • a content release is something writers create in your writing-room, and that symbolizes an event in the future that will impact your content (for instance, "Our new product goes public"). Writers can then make changes to your documents, and push those changes to the proper content release, to publish it all at once later. Through the API, you can wish to query either the master release (the documents that are live now), or any other upcoming release your writers have created. They all have a release ID, which doesn't change when new changes are pushed to the release.
  • at a given time, each content release has a content ref ID, which is the revision ID on which the content release is currently. If you change any content in the content release, its content ref ID changes, since this is a new revision of content. To keep our API calls immutable (which means the call itself has to be different if the result is expected to be different), the information that is passed in API calls is not the release ID, but the content ref ID. A table of correspondence between the two is in the /api endpoint.
  • since /api is the only way for you to know if your information about your content is up-to-date, you shouldn't cache your calls to /api (we've made it especially performant, and our development kits make sure you don't call it more than once every 5 seconds); but you may cache any other request virtually forever (and all of our development kits come with caching out-of-the-box).
an-overview-of-the-api-browser

An overview of the API browser

We'll see later what predicates are, but you'll see that the API browser is the most helpful friend to create them and use your repository's API: try a query, view the result, correct the query (making it more precise with more predicates, for instance), repeat until you're happy!

Once you're done, you just have to copy and paste your predicates into your code, and you're good to go!

To get to the API browser from your writing room, you will find it behind the "?" icon at the bottom right of every page.

The first time you visit the API Browser, before doing anything, you may want to start by hitting the "Search documents" button directly; this will return all documents in the repository, paginated by 20.

1- Select a ref

The selectbox will offer you to select any present or future release of which you have access.

If you're supposed to have access to future releases and you can't see them, you may have to log in (step 2).

2- Log in

By checking your credentials in the writing room, the API browser will display all the releases you have rights to access. The lock is closed when you're not logged in, and open when you're logged in.

3- Choose your form

The form by default is "Everything", which retrieves all your content in a paginated way, and allows you to query within them; the other available forms today allow you to do the same thing on the limited content set of each collection set in the writing-room.

4- Type in your predicates to query within your form

Press enter when you're done with one of them, double-click to modify one. To learn more about how to write the predicates, see our "Predicates' syntax" section below.

5- Type in your orderings

Here too, press enter when you're done with one of them, double-click to modify one. To learn more about how to write the orderings, see our "Orderings" section below.

6- There you go!

Launch your query, see what you're getting instantly. If you're not happy with it, reopen the form, and change your query, repeat!

7- HTML or JSON?

By default, the API browser will display its output as nicely-formatted HTML, optimized for developers to use the information as effectively as possible; but you can also choose to see the response in the same exact way it will be received by your application, in JSON. You can also make that choice before launching the query.

predicate-based-queries

Predicate-based queries

What are predicates?

Queries in prismic.io are based on predicates, which, if you've never queried data this way, is very easy to learn, and very powerful.

For instance, picture your content repository as an attic with many objects of many colors, shapes and sizes. All you need to do is describe facts (predicates) about the objects you want, and prismic.io will return all the objects that match. For instance, if you want blue objects, you'll just say:

d has the color set to "blue"

prismic.io will return every object that can be d.

You can also say much more sophisticated things, that would be very hard to write with non-predicate-based query languages. For instance:

d has the color blue
e has the color red
d is the same shape as e

prismic.io will then know to return every pair of objects d and e, that match what you described. It's not more complicated!

Do note that while predicate-based queries are known to allow this kind of sophisticated querying effortlessly, prismic.io only supports single-document queries for the moment. The documentation below will therefore all be about querying a single document for now.

Predicates' general syntax

A predicate is usually a comparison, making sure there is some kind of match between a fragment and a value. The way we're matching them is described by an operator. The syntax looks like this:

[:d = namespace.operator(<fragment>, <value>)]
  • the variable "d" is simply the variable name for a given found document; this is useful when there are several predicates.
  • the namespace brings some nice classification to operators; the most used is the "root" namespace, that doesn't need to be written. For instance, here is an example using the "at" (equality) operator of the "root" namespace: [:d = at(document.type, "product")]
  • the fragment expresses which piece of information stored in a prismic.io document we're working with. See the "Writing your fragment" paragraph below to learn more
  • values can be strings, numbers, etc. to compare the fragment with

Sometimes, you might have operators that take several values (for instance to check that a fragment is between two values); in which case, a predicate can also look like this:

[:d = namespace.operator(<fragment>, <value1>, <value2>, ...)]

Lists of predicates

When you'll be using predicates in your code, you'll have to present them as a list of predicates, between square brackets, like this:

[[:d = at(document.type, "product")][:d = any(document.tags, ["Macaron"])]]

This also means that if you're presenting a single query in your code, you have to write it as a single-item array; this makes it look like a single predicate with two square brackets, so don't be surprised!

[[:d = any(document.tags, ["Macaron"])]]

Writing your fragment

There are two types of fragments:

  • a non-type-dependent fragment start with "document.*", and there are only three: either "document.type", "document.tags" or "document.id" (the API browser's autocomplete will help you with that). You will see that some operators that are able to apply operations to the whole document may also use simply "document" as a fragment. Note that document.slug is not available to run queries. URLs should include a unique id, such as document.id.
  • a type-dependent fragment start with "my.*", and the complete syntax is: "my.documenttypename.fragmentname". For instance: "my.product.price", for the price of a product, or "my.product.uid" for the user id (the API browser's autocomplete will help you with that too).

Some nice use cases:

  • Querying over document link fragments: you can use a type-dependent fragment to query all documents that are linking to a given document through a given link fragment: [:d = at(my.documentType.fragmentName, "targetedDocumentId")]. This makes document links effectively queryable in both directions.
  • Querying over group fragments: you can also use a type-dependent fragment to query a sub-fragment inside a group fragment. This will match with every document that has one of their sub-fragments at the given value: [:d = at(my.documentType.groupFragmentName.subFragmentName, "value")].
predicate-operators

Predicate operators

The operator in a predicate is the part that defines how the fragment is matched to the value. For instance, in the predicate above that we just mentioned, the operator is "at", and the operator's namespace is "root" (which is the one that you don't have to write):

[:d = at(document.type, "product")]

The root namespace

Operators on the root namespace tend to be for basic tasks that work for all relevant fragment types.

The at operator is the equality operator, checking that the fragment matches the described value exactly. It takes as a value:

  • either an array of strings if you're applying it on tags, in which case it checks that ALL the listed tags are part of the document;
[:d = at(document.tags, ["Macaron", "Cupcake"])]
  • or a string for any other case (text fragment, document type, document id, ...).
[:d = at(document.type, "product")]

Warning: you shouldn't apply the "at" predicate to a structured text fragment, comparing its value to a full text string, as it won't match it. This is pretty logical: your structured text fragment contains so much more than just its full text value!

The any operator takes an array of strings as a value. It works exactly the same way as the at operator, but checks whether the fragment matches either one of the values in the array. You can use it with all fragment types; for instance, if you want to get the documents that are either a macaron or a cupcake:

[:d = any(document.tags, ["Macaron", "Cupcake"])]

The fulltext operator provides two capabilities: either you want to check if a certain string is anywhere inside a document (this is what you should use to make your project's search engine feature), or if the string is contained inside a specific document's structured text fragment. Checking whether a string is contained in the document would therefore look like this:

[:d = fulltext(document, "delight")]

And checking whether it is contained in a given structured text fragment would look like this:

[:d = fulltext(my.product.short_lede, "delight")]

The similar operator is especially smart, since it takes an ID of a document, and returns a list of documents whose contents are similar. This allows to build an automated content discovery feature (for instance, a "Related posts" block) at almost no cost. Also, remember that you can combine it with other predicates, and search for the "similar blog posts" for instance, of even the "similar blog posts that mention chocolate". The additional max parameter allows you to narrow the search in order to get more accurate results; it is especially interesting when you have a lot of documents talking about the same broad subject.

[:d = similar("idOfSomeDocument", 10)]

The number namespace

Operators that belong to the number namespace are meant to be applied on number fragments.

The gt operator tests whether a Number fragment is strictly greater than a numeric value:

[[:d = number.gt(my.product.price, 2)]]

The lt operator tests whether a Number fragment is strictly lower than a numeric value:

[[:d = number.lt(my.product.price, 4.2)]]

The inRange operator tests whether the Number fragment is between two numeric values; this is one of those operators that take more than just one value:

[[:d = number.inRange(my.product.price, 2, 4)]]

The date namespace

Operators that belong to the date namespace are meant to be applied on Date fragments. Values for dates are potentially:

  • dates following the ISO 8601 standard: "2013-09-25"
  • datetimes following the ISO 8601 standard: "2013-11-19T15:30:59z"
  • or a numerical timestamp: 1384872209277

All of these formats are allowed when this documentation uses the placeholder <date>.

The date.before and date.after operators test whether the Date fragment is before/after the specified date:

[
[:d = date.after(my.blog-post.publication-date, <date>)]
[:d = date.before(my.blog-post.publication-date, <date>)]
]

The date.between operator tests whether the Date fragment is between the specified two dates:

[:d = date.between(my.blog-post.publication-date, <date>, <date>)]

These three predicates are strict inequalities, in other words the date corresponding to the bounds is not returned in the results. If you need an inclusive query, you should offset the bound by one day.

The date.day-of-month operator tests whether the Date fragment matches the specified day of the month. The value must be between 1 and 31.

[:d = date.day-of-month(my.blog-post.publication-date, 10)]

The date.day-of-month-before and date.day-of-month-after operators operators test whether the day of month of the Date fragment is strictly lower/greater than the specified day of the month. The value must be between 1 and 31.

[
[:d = date.day-of-month-after(my.blog-post.publication-date, 10)]
[:d = date.day-of-month-before(my.blog-post.publication-date, 10)]
]

The date.day-of-week operator tests whether the Date fragment matches the specified day of the week. The value must either be between 1 and 7, or between "Monday" and "Sunday".

[
[:d = date.day-of-week(my.blog-post.publication-date, 2)]
[:d = date.day-of-week(my.blog-post.publication-date, "Tuesday")]
]

The date.day-of-week-before and date.day-of-week-after operators test whether the day of week of the Date fragment is strictly lower/greater than the specified day of the week. The value must either be between 1 and 7, or between "Monday" and "Sunday".

[
[:d = date.day-of-week-after(my.blog-post.publication-date, 4)]
[:d = date.day-of-week-before(my.blog-post.publication-date, "Friday")]
]

The date.month operator tests whether the Date fragment matches the specified month. The value must be either between 1 and 12, or between "January" and "December".

[
[:d = date.month(my.blog-post.publication-date, 2)]
[:d = date.month(my.blog-post.publication-date, "May")]
]

The date.month-before and date.month-after operator tests whether the month of the Date fragment is strictly lower/greater that the specified month. The value must be either between 1 and 12, or between "January" and "December".

[
[:d = date.month-after(my.blog-post.publication-date, 4)]
[:d = date.month-before(my.blog-post.publication-date, "December")]
]

The date.year function tests whether the Date fragment matches the specified year.

[
[:d = date.year(my.blog-post.publication-date, 2013)]
]

The date.year-before and date.year-after operators test whether the year of the Date fragment is strictly lower/greater that the specified year.

[
[:d = date.year-after(my.blog-post.publication-date, 2011)]
[:d = date.year-before(my.blog-post.publication-date, 2013)]
]

The date.hour operator tests whether the Date fragment matches the specified hour. The value must be between 0 and 23.

[
[:d = date.hour(my.blog-post.publication-date, 2)]
]

The date.hour-before and date.hour-after operators test whether the hour of the Date fragment is strictly lower/greater than the specified hour. The value must be between 0 and 23.

[
[:d = date.hour-after(my.blog-post.publication-date, 17)]
[:d = date.hour-before(my.blog-post.publication-date, 12)]
]