Template specific fields dont work for me, the additional fields dont appear when selecting the template. I tried restarting nginx, checking the database and clearing the cache, but that didn't work.
config.yml (indentation changed when copy-pasting):
templatefields:
tochten.twig:
section_1_heading:
type: text
section_1_body:
type: html
section_2_heading:
type: text
section_2_body:
type: html
And this is the contenttype I am using with the template specific fields (indentation, changed when copy-pasting):
paginas:
name: Paginas
singular_name: Pagina
fields:
title:
type: text
class: large
heading:
type: text
class: large
slug:
type: slug
uses: title
image:
type: image
upload: paginas
extensions: [ jpg ]
body:
type: html
template:
type: templateselect
filter: '*.twig'
default_status: publish
sort: -datepublish
Edit: BoltCMS version 2.2.1
Do you have the latest version of Bolt? It's only supported on 2.2 onward.
Related
I am creating an OpenAPI 3 spec for an api which has object for which some property are required and for some they are anyof. When i create the spec as below it throws an error, which i am unable to fix.
EnrollementRequest:
type: object
properties:
consent:
$ref: "#/components/schemas/ConsentEnum"
cid:
$ref: '#/components/schemas/CID'
card:
$ref: '#/components/schemas/Card'
enrollmentDateTime :
description: The date and time of enrollment with respective timezone
format: date-time
example: 2018-11-13T20:20:39+00:00
campaign_code:
description: the campaign-code for which customer wants to enroll
type: string
offer_code:
description: the offer-code for which customer wants to enroll
type: string
channelInfo:
$ref: '#/components/schemas/Channel'
required:
- consent
- cid
- enrollmentDateTime
- channelInfo
anyOf:
- campaign_code
- offer_code
Swagger editor gives an error as below -
Errors
Structural error at components.schemas.EnrollementRequest.anyOf.0
should be object
Jump to line ...
Structural error at components.schemas.EnrollementRequest.anyOf.1
should be object
Jump to line ...
Upon using the suggestion as below
anyOf:
- required: [campaign_code]
- required: [offer_code]
the validation error went away but the swagger editor schema / model view is not showing any content as below -
Right, anyOf must be a list of objects. Try this:
anyOf:
- required: [campaign_code]
- required: [offer_code]
Alternativelly, to make it look better in the Swagger editor:
EnrollementRequest:
type: object
properties:
consent:
$ref: "#/components/schemas/ConsentEnum"
cid:
$ref: '#/components/schemas/CID'
card:
$ref: '#/components/schemas/Card'
enrollmentDateTime :
description: The date and time of enrollment with respective timezone
format: date-time
example: 2018-11-13T20:20:39+00:00
channelInfo:
$ref: '#/components/schemas/Channel'
required:
- consent
- cid
- enrollmentDateTime
- channelInfo
anyOf:
- properties:
campaign_code:
description: the campaign-code for which customer wants to enroll
type: string
required: [campaign_code]
- properties:
offer_code:
description: the offer-code for which customer wants to enroll
type: string
required: [offer_code]
I'm seeking the best way for documenting my rest API response according to JSON API and also how to describe it in Swagger YAML documentation.
My API receives a word and a list of URLs and returns how many times the given word appears in each website provided. My first take for the successful response was:
{
"data": {
"foo": {
"http://www.foobar.com": 12,
"http://www.bar.com": 0
}
}
}
Using the word and the URLs as property names.
I'd like to know if it is a good practice according to JSON API and if yes, how to document it in Swagger YAML:
swagger: '2.0'
info:
description: How many times a given word appears in each site provided? This API answer it
version: 1.0.0
title: WordApp
contact:
email: foo#bar.com
license:
name: Apache 2.0
url: http://www.apache.org/licenses/LICENSE-2.0.html
paths:
/:
get:
summary: returns how many times a given word appears in each provided URL
description: |
By passing in the appropriate options, you can search for
the number of occurrences of a given word in each URL provided
produces:
- application/json
parameters:
- in: query
name: word
description: pass a word for looking up its occurrences in each site
required: true
type: string
- in: query
name: url
description: a list of valid URLs
type: string
required: true
responses:
200:
description: search results matching criteria
schema:
type: array
items:
$ref: '#/definitions/Data'
500:
description: Internal Server Error
definitions:
Data:
type: object
required:
- word
- url
- value
properties:
word:
type: string
example: Brazil
url:
type: string
example: 'https://www.nytimes.com/'
value:
type: integer
example: 12
If it is not the best practice, what would be a better way of modeling my response?
I'm having some difficulty with Swagger 2.0 insiting that fields are required when they are not in fact defined to be required.
Here's a snipped version of my Swagger YML file.
definitions:
category:
type: object
required:
- name
- code
properties:
name:
type: string
description: Category name
code:
type: string
description: Category code
_links:
$ref: '#/definitions/categoryLinks'
children:
type: array
items:
$ref: '#/definitions/category'
categoryLinks:
required:
- self
- parent
- children
properties:
self:
description: Canonical link to this category
$ref: '#/definitions/genericLink'
parent:
description: Link to the parent category
$ref: '#/definitions/genericLink'
children:
description: Link to the child categories
$ref: '#/definitions/genericLink'
genericLink:
properties:
href:
type: string
description: The absolute URL being linked to.
paths:
'/categories/{category_code}':
get:
summary: Get a specific category
description: Returns information about a specific category.
parameters:
- name: category_code
description: Code of category to get
type: string
in: path
required: true
responses:
200:
description: Information about requested category.
schema:
$ref: '#/definitions/category'
The response from get '/categories/awesome-cat' looks like:
{
"name" => "My awesome Category",
"code" => "awesome-cat",
"_links" => {
"self" => {
"href" => "https://api.test.testing/categories/awesome-cat.json"
},
"parent"=> {},
"children" => {}
}
}
Which is as expected, and which conforms to my definiton of a category above.
I'm using the swagger rspec matcher called conform_to_the_documented_model_for provided by the Apivore project to validate the output from all my API endpoints:
matcher :conform_to_the_documented_model_for do |swagger, fragment|
match do |body|
body = JSON.parse(body)
#errors = JSON::Validator.fully_validate(swagger, body, fragment: fragment)
#errors.empty?
end
failure_message do |body|
#errors.map { |e| e.sub("'#", "'#{path}#").gsub(/^The property|in schema.*$/,'') }.join("\n")
end
end
Alas my test is failing.
3) the V1 API path /categories/{category_code} method get response 200 responds with the specified models
Failure/Error: expect(response.body).to conform_to_the_documented_model_for(swagger, fragment)
'#/_links/parent' did not contain a required property of 'href'
'#/_links/children' did not contain a required property of 'href'
'#' did not contain a required property of 'children'
For some reason the JSON validator is not regarding the href property of the link as optional, nor is it regarding rhe children property of category as optional.
It was my understanding that properties not listed under the required section are optional. Why is the JSON::Validator.fully_validate regarding them as non-optional?
Dave, just answering here too for completeness. The latest version of the Apivore gem, 0.0.2, no longer uses the :strict mode of the JSON Validator gem json-schema, which makes the assumption that all fields are required. This is a recent change I made after we sorted out the misunderstandings around additionalProperties. I am now of the opinion that the :strict mode of the validator isn't very helpful. The default JSON schema validation is correct, there is no reason to be any 'stricter'.
Making sure you have the latest version of the Apivore gem (0.0.2, or greater) should solve your problem.
I have a RESTful API that I have created recently and I won't remember how to use it in a few months. I decided to document my API using Swagger, however I'm going crazy.
I used http://editor.swagger.io/ to create the YAML file that I then convert into a JSON file Swagger can use. When I put file into Swagger UI it just gets stuck at fetching resource list: localhost/swagger.json and the console says Uncaught TypeError: Cannot read property '$ref' of undefined .
I'm using version 2.1.0-alpha.5 of Swagger UI.
Here is my spec file:
swagger: '2.0'
info:
title: TITLE
description: BLAH, BLAH, BLAH, ETC
version: "1.0b"
host: api.example.com
schemes:
- http
basePath: /v1
produces:
- application/json
paths:
/match.json:
get:
#summary: Match Data
description: Used for getting data about a match
parameters:
- name: id
in: query
description: The match ID of from a game
required: true
type: integer
format: int32
- name: key
in: query
description: API key used for authentication.
required: true
type: string
responses:
200:
description: Returns match data
schema:
type: array
items:
$ref: '#/definitions/MatchData'
default:
description: Unexpected error
schema:
$ref: '#/definitions/Error'
definitions:
MatchData:
properties:
info:
type: integer
format: int64
description: General information about the match
time:
type: integer
format: int64
description: Information about the start/end time
stats:
type: array
format: int64
description: Stats about the match
Error:
required:
- errorID
- message
properties:
errorID:
type: string
description: Error ID.
message:
type: string
description: Information about the error.
I've tested your spec, and while I'm not getting the same error you do, the spec is indeed invalid.
If you look at #/definitions/MatchData/properties/stats, you'll see that you define the type: array but you don't provide an 'items' property next to it to say which array it is (and that's mandatory). You may have intended to use type: integer like the properties above it, which goes along with the format: int64.
Since I don't know what you intended to provide, it's difficult to give an accurate solution, but if you add a comment with what you intended to do, I could provide a more detailed answer.
Upon some additional testing, I discovered that there's a bug in the UI. After you make that modification and the spec loads, the operation itself will not expand unless you click on the Expand Operations link. I've opened an issue about it, feel free to follow it there.
This problem can be due to some indentation errors in the yaml file which actually did not show up in the Swagger editor. Check all your definitions and whether they are getting displayed as expected in the preview that you can see in Swagger editor (especially check MatchData).
You can also try giving:
responses:
200:
description: Returns match data
schema:
type: array
items:
schema:
$ref: '#/definitions/MatchData'
For our case, we used Swagger-php and we have:
* #SWG\Response(
* response=200,
* description="app response"
* #SWG\Schema(
* type="array"
* )
* ),
but we missed " * #SWG\Items(ref="#/definitions/pet")". After removing "#SWG\Schema(", it works e.g.
* #SWG\Response(
* response=200,
* description="app response"
* ),
In what I can find about using JSON schema, there seems to be a confusing conflation of (or at least a lack of distinction among) the tasks of describing valid data, validating stored data, and validating input data.
A typical example looks like:
var schema = {
type: 'object',
properties: {
id: { type: 'integer', required: true },
name: { type: 'string', required: true },
description: { type: 'string', required: false }
}
};
This works well for describing what valid data in a data store should look like, and therefore for validating it (the latter isn't terribly useful—if it's in a store it should be valid already):
var storedData = {
id: 123,
name: 'orange',
description: 'delicious'
};
It doesn't work that well for validating input. id is most likely left for the application to generate and not for the user to provide as part of the input. The following input fails validation because it lacks the id which the schema declares to be required:
var inputData = {
name: 'orange',
description: 'delicious'
};
Fine, one might say, the schema isn't meant to validate direct input, validation should only occur after the application added an id and the data is what is meant to be stored.
If the schema isn't meant to validate direct input, however, what is 1) the point of JavaScript validators running in the browser, presumably being fed direct input and 2) the point of the obviously input-oriented readonly schema feature in the spec?
Ground gets shakier when thinking of properties that can be set once but not updated (like a username), as well as different access levels (e.g. the admin and the owner of the orange should be able to change the description, while for other users it should stay readonly).
What is the best (or at least working) practice to deal with this? A different schema for each use case, like below?
var baseSchema = {
type: 'object',
properties: {
id: { type: 'integer', required: true },
name: { type: 'string', required: true },
description: { type: 'string', required: false }
}
};
var ownerUpdateSchema = {
type: 'object',
properties: {
id: { type: 'integer', required: false, readonly: true },
name: { type: 'string', required: true },
description: { type: 'string', required: false }
}
};
var userUpdateSchema = {
type: 'object',
properties: {
id: { type: 'integer', required: false, readonly: true },
name: { type: 'string', required: false, readonly: true },
description: { type: 'string', required: false, readonly: true }
}
};
Or something else?
Side-note: "required" is now an array in the parent element in v4, and "readOnly" is capitalised differently - I'll be using that form for my examples
I agree that validating the stored data is pretty rare. And if you're just describing the data, then you don't need to specify that "id" is required.
Another thing to say is that these schemas should all have URIs at which they can be referenced (e.g. /schemas/baseSchema). At that point, you can extend the schemas to make "id" required in some of them:
var ownerInputSchema = {
type: 'object',
properties: {
id: {type: 'integer', readOnly: true},
name: {type: 'string'},
description: {type: 'string'}
},
required: ['name']
};
var userInputSchema = {
allOf: [{"$ref": "/schemas/inputSchema"}],
properties: {
name: {readOnly: true}
}
};
var storedSchema = {
allOf: [{"$ref": "/schemas/inputSchema"}],
required: ["id"]
}
Although, as I said above, I'm not sure storedSchema should be necessary. What you end up with is one "owner" schema that describes the data format (as served, and as editable by the data owner), and you have a secondary schema that extends that to declare readOnly on an additional property.
Well, I think the purpose of Json-Schema is more clearly defined in v4. The goal is assist you in a data structure validation (whether it is going to be stored, it has been sent to you across the wire, or you are creating in an interactive fashion).
readOnly is not a Json-Schema validation property because it has not validation constraints. In Json-Schema v4 readOnly is part of the hyper-schema definition. It can be used to express that you can not change this property in a POST request.
Json-schema does not define how you should implement the interaction with the user, if you allow for transitory "bad" data, or if any error has to be corrected before you can add more data to the system. This is up to you.