Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
// # Post Model
|
2018-10-09 16:31:09 +03:00
|
|
|
const _ = require('lodash');
|
|
|
|
const uuid = require('uuid');
|
|
|
|
const moment = require('moment');
|
|
|
|
const Promise = require('bluebird');
|
|
|
|
const sequence = require('../lib/promise/sequence');
|
|
|
|
const common = require('../lib/common');
|
|
|
|
const htmlToText = require('html-to-text');
|
|
|
|
const ghostBookshelf = require('./base');
|
|
|
|
const config = require('../config');
|
|
|
|
const converters = require('../lib/mobiledoc/converters');
|
|
|
|
const relations = require('./relations');
|
|
|
|
const MOBILEDOC_REVISIONS_COUNT = 10;
|
2018-11-15 17:53:24 +03:00
|
|
|
const ALL_STATUSES = ['published', 'draft', 'scheduled'];
|
2018-10-09 16:31:09 +03:00
|
|
|
|
|
|
|
let Post;
|
|
|
|
let Posts;
|
2013-06-25 15:43:15 +04:00
|
|
|
|
2013-09-23 02:20:08 +04:00
|
|
|
Post = ghostBookshelf.Model.extend({
|
2013-06-25 15:43:15 +04:00
|
|
|
|
|
|
|
tableName: 'posts',
|
|
|
|
|
2018-02-16 02:49:15 +03:00
|
|
|
/**
|
2018-06-26 17:00:54 +03:00
|
|
|
* @NOTE
|
|
|
|
*
|
2018-02-16 02:49:15 +03:00
|
|
|
* We define the defaults on the schema (db) and model level.
|
|
|
|
*
|
2018-06-26 17:00:54 +03:00
|
|
|
* Why?
|
|
|
|
* - when you insert a resource, Knex does only return the id of the created resource
|
|
|
|
* - see https://knexjs.org/#Builder-insert
|
|
|
|
* - that means `defaultTo` is a pure database configuration (!)
|
|
|
|
* - Bookshelf just returns the model values which you have asked Bookshelf to insert
|
|
|
|
* - it can't return the `defaultTo` value from the schema/db level
|
|
|
|
* - but the db defaults defined in the schema are saved in the database correctly
|
|
|
|
* - `models.Post.add` always does to operations:
|
|
|
|
* 1. add
|
|
|
|
* 2. fetch (this ensures we fetch the whole resource from the database)
|
|
|
|
* - that means we have to apply the defaults on the model layer to ensure a complete field set
|
|
|
|
* 1. any connected logic in our model hooks e.g. beforeSave
|
|
|
|
* 2. model events e.g. "post.published" are using the inserted resource, not the fetched resource
|
2018-02-16 02:49:15 +03:00
|
|
|
*/
|
|
|
|
defaults: function defaults() {
|
|
|
|
return {
|
|
|
|
uuid: uuid.v4(),
|
2018-06-26 17:00:54 +03:00
|
|
|
status: 'draft',
|
|
|
|
featured: false,
|
|
|
|
page: false,
|
|
|
|
visibility: 'public'
|
2018-02-16 02:49:15 +03:00
|
|
|
};
|
|
|
|
},
|
|
|
|
|
2018-10-09 16:31:09 +03:00
|
|
|
relationships: ['tags', 'authors', 'mobiledoc_revisions'],
|
2017-11-21 16:28:05 +03:00
|
|
|
|
2018-04-05 17:11:47 +03:00
|
|
|
// NOTE: look up object, not super nice, but was easy to implement
|
|
|
|
relationshipBelongsTo: {
|
|
|
|
tags: 'tags',
|
|
|
|
authors: 'users'
|
|
|
|
},
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
/**
|
|
|
|
* The base model keeps only the columns, which are defined in the schema.
|
|
|
|
* We have to add the relations on top, otherwise bookshelf-relations
|
|
|
|
* has no access to the nested relations, which should be updated.
|
|
|
|
*/
|
|
|
|
permittedAttributes: function permittedAttributes() {
|
|
|
|
let filteredKeys = ghostBookshelf.Model.prototype.permittedAttributes.apply(this, arguments);
|
|
|
|
|
|
|
|
this.relationships.forEach((key) => {
|
|
|
|
filteredKeys.push(key);
|
|
|
|
});
|
|
|
|
|
|
|
|
return filteredKeys;
|
|
|
|
},
|
|
|
|
|
2017-05-22 11:24:59 +03:00
|
|
|
emitChange: function emitChange(event, options) {
|
2018-04-06 19:19:45 +03:00
|
|
|
let eventToTrigger;
|
2017-05-22 11:24:59 +03:00
|
|
|
|
2015-03-24 23:23:23 +03:00
|
|
|
var resourceType = this.get('page') ? 'page' : 'post';
|
2017-05-22 11:24:59 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
if (options.useUpdatedAttribute) {
|
2015-03-24 23:23:23 +03:00
|
|
|
resourceType = this.updated('page') ? 'page' : 'post';
|
2018-04-06 19:19:45 +03:00
|
|
|
} else if (options.usePreviousAttribute) {
|
|
|
|
resourceType = this.previous('page') ? 'page' : 'post';
|
2015-03-24 23:23:23 +03:00
|
|
|
}
|
2017-01-25 16:47:49 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
eventToTrigger = resourceType + '.' + event;
|
|
|
|
|
|
|
|
ghostBookshelf.Model.prototype.emitChange.bind(this)(this, eventToTrigger, options);
|
2015-03-24 23:23:23 +03:00
|
|
|
},
|
|
|
|
|
2017-04-19 16:53:23 +03:00
|
|
|
/**
|
|
|
|
* We update the tags after the Post was inserted.
|
|
|
|
* We update the tags before the Post was updated, see `onSaving` event.
|
|
|
|
* `onCreated` is called before `onSaved`.
|
2018-03-19 18:27:06 +03:00
|
|
|
*
|
|
|
|
* `onSaved` is the last event in the line - triggered for updating or inserting data.
|
|
|
|
* bookshelf-relations listens on `created` + `updated`.
|
|
|
|
* We ensure that we are catching the event after bookshelf relations.
|
2017-04-19 16:53:23 +03:00
|
|
|
*/
|
2018-03-19 18:27:06 +03:00
|
|
|
onSaved: function onSaved(model, response, options) {
|
|
|
|
if (options.method !== 'insert') {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
var status = model.get('status');
|
2017-04-19 16:53:23 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('added', options);
|
2014-04-27 20:58:34 +04:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (['published', 'scheduled'].indexOf(status) !== -1) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange(status, options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2017-04-19 16:53:23 +03:00
|
|
|
},
|
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
onUpdated: function onUpdated(model, attrs, options) {
|
2016-10-14 15:37:01 +03:00
|
|
|
model.statusChanging = model.get('status') !== model.updated('status');
|
|
|
|
model.isPublished = model.get('status') === 'published';
|
|
|
|
model.isScheduled = model.get('status') === 'scheduled';
|
|
|
|
model.wasPublished = model.updated('status') === 'published';
|
|
|
|
model.wasScheduled = model.updated('status') === 'scheduled';
|
|
|
|
model.resourceTypeChanging = model.get('page') !== model.updated('page');
|
|
|
|
model.publishedAtHasChanged = model.hasDateChanged('published_at');
|
|
|
|
model.needsReschedule = model.publishedAtHasChanged && model.isScheduled;
|
|
|
|
|
|
|
|
// Handle added and deleted for post -> page or page -> post
|
|
|
|
if (model.resourceTypeChanging) {
|
|
|
|
if (model.wasPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unpublished', Object.assign({useUpdatedAttribute: true}, options));
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2016-04-14 14:22:38 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.wasScheduled) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unscheduled', Object.assign({useUpdatedAttribute: true}, options));
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('deleted', Object.assign({useUpdatedAttribute: true}, options));
|
|
|
|
model.emitChange('added', options);
|
2015-03-24 23:23:23 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('published', options);
|
2014-10-28 03:41:18 +03:00
|
|
|
}
|
2015-03-24 23:23:23 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.isScheduled) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('scheduled', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (model.statusChanging) {
|
|
|
|
// CASE: was published before and is now e.q. draft or scheduled
|
|
|
|
if (model.wasPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unpublished', options);
|
2016-04-14 14:22:38 +03:00
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// CASE: was draft or scheduled before and is now e.q. published
|
2015-03-24 23:23:23 +03:00
|
|
|
if (model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('published', options);
|
2015-03-24 23:23:23 +03:00
|
|
|
}
|
2016-04-14 14:22:38 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// CASE: was draft or published before and is now e.q. scheduled
|
2016-04-14 14:22:38 +03:00
|
|
|
if (model.isScheduled) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('scheduled', options);
|
2016-04-14 14:22:38 +03:00
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// CASE: from scheduled to something
|
|
|
|
if (model.wasScheduled && !model.isScheduled && !model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unscheduled', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('published.edited', options);
|
2015-03-24 23:23:23 +03:00
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.needsReschedule) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('rescheduled', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2014-10-28 03:41:18 +03:00
|
|
|
}
|
2015-03-24 23:23:23 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// Fire edited if this wasn't a change between resourceType
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('edited', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2019-01-08 12:48:53 +03:00
|
|
|
|
|
|
|
if (model.statusChanging && (model.isPublished || model.wasPublished)) {
|
|
|
|
this.handleStatusForAttachedModels(model, options);
|
|
|
|
}
|
2016-10-14 15:37:01 +03:00
|
|
|
},
|
2016-09-19 16:45:36 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
onDestroyed: function onDestroyed(model, options) {
|
2017-11-21 16:28:05 +03:00
|
|
|
if (model.previous('status') === 'published') {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unpublished', Object.assign({usePreviousAttribute: true}, options));
|
2017-11-21 16:28:05 +03:00
|
|
|
}
|
2016-10-14 15:37:01 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('deleted', Object.assign({usePreviousAttribute: true}, options));
|
2013-08-20 22:52:44 +04:00
|
|
|
},
|
|
|
|
|
2019-01-08 12:48:53 +03:00
|
|
|
onDestroying: function onDestroyed(model) {
|
|
|
|
this.handleAttachedModels(model);
|
|
|
|
},
|
|
|
|
|
|
|
|
handleAttachedModels: function handleAttachedModels(model) {
|
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
* Bookshelf only exposes the object that is being detached on `detaching`.
|
|
|
|
* For the reason above, `detached` handler is using the scope of `detaching`
|
|
|
|
* to access the models that are not present in `detached`.
|
|
|
|
*/
|
|
|
|
model.related('tags').once('detaching', function onDetached(collection, tag) {
|
|
|
|
model.related('tags').once('detached', function onDetached(detachedCollection, response, options) {
|
|
|
|
tag.emitChange('detached', options);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
model.related('tags').once('attaching', function onDetached(collection, tags) {
|
|
|
|
model.related('tags').once('attached', function onDetached(detachedCollection, response, options) {
|
|
|
|
tags.forEach(tag => tag.emitChange('attached', options));
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
model.related('authors').once('detaching', function onDetached(collection, author) {
|
|
|
|
model.related('authors').once('detached', function onDetached(detachedCollection, response, options) {
|
|
|
|
author.emitChange('detached', options);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
model.related('authors').once('attaching', function onDetached(collection, authors) {
|
|
|
|
model.related('authors').once('attached', function onDetached(detachedCollection, response, options) {
|
|
|
|
authors.forEach(author => author.emitChange('attached', options));
|
|
|
|
});
|
|
|
|
});
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
* when status is changed from or to 'published' all related authors and tags
|
|
|
|
* have to trigger recalculation in URL service because status is applied in filters for
|
|
|
|
* these models
|
|
|
|
*/
|
|
|
|
handleStatusForAttachedModels: function handleStatusForAttachedModels(model, options) {
|
|
|
|
model.related('tags').forEach((tag) => {
|
|
|
|
tag.emitChange('attached', options);
|
|
|
|
});
|
|
|
|
|
|
|
|
model.related('authors').forEach((author) => {
|
|
|
|
author.emitChange('attached', options);
|
|
|
|
});
|
|
|
|
},
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
onSaving: function onSaving(model, attr, options) {
|
2016-04-14 14:22:38 +03:00
|
|
|
options = options || {};
|
|
|
|
|
2014-03-24 22:08:06 +04:00
|
|
|
var self = this,
|
2015-10-27 14:15:09 +03:00
|
|
|
title,
|
2016-03-23 16:17:01 +03:00
|
|
|
i,
|
|
|
|
// Variables to make the slug checking more readable
|
2017-11-21 16:28:05 +03:00
|
|
|
newTitle = this.get('title'),
|
|
|
|
newStatus = this.get('status'),
|
2016-05-19 14:49:22 +03:00
|
|
|
olderStatus = this.previous('status'),
|
2018-04-10 23:45:31 +03:00
|
|
|
prevTitle = this.previous('title'),
|
|
|
|
prevSlug = this.previous('slug'),
|
2016-06-02 20:11:54 +03:00
|
|
|
publishedAt = this.get('published_at'),
|
2017-04-06 19:49:59 +03:00
|
|
|
publishedAtHasChanged = this.hasDateChanged('published_at', {beforeWrite: true}),
|
2018-04-10 23:45:31 +03:00
|
|
|
generatedFields = ['html', 'plaintext'],
|
2017-11-21 16:28:05 +03:00
|
|
|
tagsToSave,
|
|
|
|
ops = [];
|
2013-08-25 14:49:31 +04:00
|
|
|
|
2016-05-19 14:49:22 +03:00
|
|
|
// CASE: disallow published -> scheduled
|
|
|
|
// @TODO: remove when we have versioning based on updated_at
|
|
|
|
if (newStatus !== olderStatus && newStatus === 'scheduled' && olderStatus === 'published') {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.i18n.t('errors.models.post.isAlreadyPublished', {key: 'status'})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2016-05-19 14:49:22 +03:00
|
|
|
}
|
|
|
|
|
2018-07-19 12:35:55 +03:00
|
|
|
if (options.method === 'insert') {
|
|
|
|
if (!this.get('comment_id')) {
|
|
|
|
this.set('comment_id', this.id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-19 14:49:22 +03:00
|
|
|
// CASE: both page and post can get scheduled
|
2016-04-14 14:22:38 +03:00
|
|
|
if (newStatus === 'scheduled') {
|
|
|
|
if (!publishedAt) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.i18n.t('errors.models.post.valueCannotBeBlank', {key: 'published_at'})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2016-04-14 14:22:38 +03:00
|
|
|
} else if (!moment(publishedAt).isValid()) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.i18n.t('errors.models.post.valueCannotBeBlank', {key: 'published_at'})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2017-12-12 00:47:46 +03:00
|
|
|
// CASE: to schedule/reschedule a post, a minimum diff of x minutes is needed (default configured is 2minutes)
|
2017-05-12 15:56:40 +03:00
|
|
|
} else if (
|
|
|
|
publishedAtHasChanged &&
|
|
|
|
moment(publishedAt).isBefore(moment().add(config.get('times').cannotScheduleAPostBeforeInMinutes, 'minutes')) &&
|
2018-10-06 22:27:12 +03:00
|
|
|
!options.importing &&
|
|
|
|
(!options.context || !options.context.internal)
|
2017-05-12 15:56:40 +03:00
|
|
|
) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.i18n.t('errors.models.post.expectedPublishedAtInFuture', {
|
2016-09-13 18:41:14 +03:00
|
|
|
cannotScheduleAPostBeforeInMinutes: config.get('times').cannotScheduleAPostBeforeInMinutes
|
2016-05-19 14:49:22 +03:00
|
|
|
})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2016-04-14 14:22:38 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
// CASE: detect lowercase/uppercase tag slugs
|
|
|
|
if (!_.isUndefined(this.get('tags')) && !_.isNull(this.get('tags'))) {
|
|
|
|
tagsToSave = [];
|
|
|
|
|
2016-06-02 20:11:54 +03:00
|
|
|
// and deduplicate upper/lowercase tags
|
2017-11-21 16:28:05 +03:00
|
|
|
_.each(this.get('tags'), function each(item) {
|
|
|
|
for (i = 0; i < tagsToSave.length; i = i + 1) {
|
2018-01-28 20:58:37 +03:00
|
|
|
if (tagsToSave[i].name && item.name && tagsToSave[i].name.toLocaleLowerCase() === item.name.toLocaleLowerCase()) {
|
2016-06-02 20:11:54 +03:00
|
|
|
return;
|
|
|
|
}
|
2014-03-24 22:08:06 +04:00
|
|
|
}
|
2014-05-23 23:32:14 +04:00
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
tagsToSave.push(item);
|
2016-06-02 20:11:54 +03:00
|
|
|
});
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
this.set('tags', tagsToSave);
|
2016-06-02 20:11:54 +03:00
|
|
|
}
|
2014-02-19 17:57:26 +04:00
|
|
|
|
2019-01-08 12:48:53 +03:00
|
|
|
this.handleAttachedModels(model);
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
ghostBookshelf.Model.prototype.onSaving.call(this, model, attr, options);
|
2013-08-25 14:49:31 +04:00
|
|
|
|
2018-04-10 23:45:31 +03:00
|
|
|
// do not allow generated fields to be overridden via the API
|
2018-08-03 14:02:14 +03:00
|
|
|
if (!options.migrating) {
|
|
|
|
generatedFields.forEach((field) => {
|
|
|
|
if (this.hasChanged(field)) {
|
|
|
|
this.set(field, this.previous(field));
|
2018-05-04 16:59:39 +03:00
|
|
|
}
|
2018-08-03 14:02:14 +03:00
|
|
|
});
|
|
|
|
}
|
2018-05-04 16:59:39 +03:00
|
|
|
|
2018-08-03 14:02:14 +03:00
|
|
|
if (!this.get('mobiledoc')) {
|
|
|
|
this.set('mobiledoc', JSON.stringify(converters.mobiledocConverter.blankStructure()));
|
|
|
|
}
|
2018-05-04 16:59:39 +03:00
|
|
|
|
2018-08-03 14:02:14 +03:00
|
|
|
// render mobiledoc to HTML
|
|
|
|
if (this.hasChanged('mobiledoc') || !this.get('html')) {
|
|
|
|
this.set('html', converters.mobiledocConverter.render(JSON.parse(this.get('mobiledoc'))));
|
2016-09-26 16:23:49 +03:00
|
|
|
}
|
2017-04-11 11:55:36 +03:00
|
|
|
|
replace custom showdown fork with markdown-it (#8451)
refs https://github.com/TryGhost/Ghost-Admin/pull/690, closes #1501, closes #2093, closes #4592, closes #4627, closes #4659, closes #5039, closes #5237, closes #5587, closes #5625, closes #5632, closes #5822, closes #5939, closes #6840, closes #7183, closes #7536
- replace custom showdown fork with markdown-it
- swaps showdown for markdown-it when rendering markdown
- match existing header ID behaviour
- allow headers without a space after the #s
- add duplicate header ID handling
- remove legacy markdown spec
- move markdown-it setup into markdown-converter util
- update mobiledoc specs to match markdown-it newline behaviour
- update data-generator HTML to match markdown-it newline behaviour
- fix Post "converts html to plaintext" test
- update rss spec to match markdown-it newline behaviour
- close almost all related showdown bugs
2017-05-15 19:48:14 +03:00
|
|
|
if (this.hasChanged('html') || !this.get('plaintext')) {
|
2017-04-11 11:55:36 +03:00
|
|
|
this.set('plaintext', htmlToText.fromString(this.get('html'), {
|
|
|
|
wordwrap: 80,
|
|
|
|
ignoreImage: true,
|
|
|
|
hideLinkHrefIfSameAsText: true,
|
|
|
|
preserveNewlines: true,
|
|
|
|
returnDomByDefault: true,
|
|
|
|
uppercaseHeadings: false
|
|
|
|
}));
|
|
|
|
}
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2014-01-07 00:17:20 +04:00
|
|
|
// disabling sanitization until we can implement a better version
|
2017-05-23 19:18:13 +03:00
|
|
|
if (!options.importing) {
|
2017-12-12 00:47:46 +03:00
|
|
|
title = this.get('title') || common.i18n.t('errors.models.post.untitled');
|
2017-05-23 19:18:13 +03:00
|
|
|
this.set('title', _.toString(title).trim());
|
|
|
|
}
|
2013-08-30 08:18:55 +04:00
|
|
|
|
2015-09-25 19:11:22 +03:00
|
|
|
// ### Business logic for published_at and published_by
|
|
|
|
// If the current status is 'published' and published_at is not set, set it to now
|
2016-04-14 14:22:38 +03:00
|
|
|
if (newStatus === 'published' && !publishedAt) {
|
2015-09-25 19:11:22 +03:00
|
|
|
this.set('published_at', new Date());
|
|
|
|
}
|
2015-02-22 00:04:00 +03:00
|
|
|
|
2015-09-25 19:11:22 +03:00
|
|
|
// If the current status is 'published' and the status has just changed ensure published_by is set correctly
|
2016-04-14 14:22:38 +03:00
|
|
|
if (newStatus === 'published' && this.hasChanged('status')) {
|
2015-02-22 00:04:00 +03:00
|
|
|
// unless published_by is set and we're importing, set published_by to contextUser
|
|
|
|
if (!(this.get('published_by') && options.importing)) {
|
2014-08-09 23:16:54 +04:00
|
|
|
this.set('published_by', this.contextUser(options));
|
|
|
|
}
|
2015-09-25 19:11:22 +03:00
|
|
|
} else {
|
|
|
|
// In any other case (except import), `published_by` should not be changed
|
|
|
|
if (this.hasChanged('published_by') && !options.importing) {
|
2018-07-24 15:37:17 +03:00
|
|
|
this.set('published_by', this.previous('published_by') || null);
|
2015-09-25 19:11:22 +03:00
|
|
|
}
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
2013-06-15 20:11:15 +04:00
|
|
|
|
2016-03-23 16:17:01 +03:00
|
|
|
// If a title is set, not the same as the old title, a draft post, and has never been published
|
2016-04-14 14:22:38 +03:00
|
|
|
if (prevTitle !== undefined && newTitle !== prevTitle && newStatus === 'draft' && !publishedAt) {
|
2017-04-19 16:53:23 +03:00
|
|
|
ops.push(function updateSlug() {
|
|
|
|
// Pass the new slug through the generator to strip illegal characters, detect duplicates
|
|
|
|
return ghostBookshelf.Model.generateSlug(Post, self.get('title'),
|
2015-09-23 13:54:56 +03:00
|
|
|
{status: 'all', transacting: options.transacting, importing: options.importing})
|
2017-04-19 16:53:23 +03:00
|
|
|
.then(function then(slug) {
|
|
|
|
// After the new slug is found, do another generate for the old title to compare it to the old slug
|
|
|
|
return ghostBookshelf.Model.generateSlug(Post, prevTitle,
|
|
|
|
{status: 'all', transacting: options.transacting, importing: options.importing}
|
|
|
|
).then(function then(prevTitleSlug) {
|
|
|
|
// If the old slug is the same as the slug that was generated from the old title
|
|
|
|
// then set a new slug. If it is not the same, means was set by the user
|
|
|
|
if (prevTitleSlug === prevSlug) {
|
|
|
|
self.set({slug: slug});
|
|
|
|
}
|
|
|
|
});
|
2016-03-23 16:17:01 +03:00
|
|
|
});
|
2017-04-19 16:53:23 +03:00
|
|
|
});
|
2016-03-23 16:17:01 +03:00
|
|
|
} else {
|
2017-04-19 16:53:23 +03:00
|
|
|
ops.push(function updateSlug() {
|
|
|
|
// If any of the attributes above were false, set initial slug and check to see if slug was changed by the user
|
|
|
|
if (self.hasChanged('slug') || !self.get('slug')) {
|
|
|
|
// Pass the new slug through the generator to strip illegal characters, detect duplicates
|
|
|
|
return ghostBookshelf.Model.generateSlug(Post, self.get('slug') || self.get('title'),
|
2016-03-23 16:17:01 +03:00
|
|
|
{status: 'all', transacting: options.transacting, importing: options.importing})
|
2017-04-19 16:53:23 +03:00
|
|
|
.then(function then(slug) {
|
|
|
|
self.set({slug: slug});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return Promise.resolve();
|
|
|
|
});
|
2013-09-14 23:01:46 +04:00
|
|
|
}
|
2017-04-19 16:53:23 +03:00
|
|
|
|
2018-10-09 16:31:09 +03:00
|
|
|
// CASE: Handle mobiledoc backups/revisions. This is a pure database feature.
|
|
|
|
if (model.hasChanged('mobiledoc') && !options.importing && !options.migrating) {
|
|
|
|
ops.push(function updateRevisions() {
|
|
|
|
return ghostBookshelf.model('MobiledocRevision')
|
|
|
|
.findAll(Object.assign({
|
|
|
|
filter: `post_id:${model.id}`,
|
|
|
|
columns: ['id']
|
|
|
|
}, _.pick(options, 'transacting')))
|
|
|
|
.then((revisions) => {
|
|
|
|
/**
|
|
|
|
* Store prev + latest mobiledoc content, because we have decided against a migration, which
|
|
|
|
* iterates over all posts and creates a copy of the current mobiledoc content.
|
|
|
|
*
|
|
|
|
* Reasons:
|
|
|
|
* - usually migrations for the post table are slow and error-prone
|
|
|
|
* - there is no need to create a copy for all posts now, because we only want to ensure
|
|
|
|
* that posts, which you are currently working on, are getting a content backup
|
|
|
|
* - no need to create revisions for existing published posts
|
|
|
|
*
|
|
|
|
* The feature is very minimal in the beginning. As soon as you update to this Ghost version,
|
|
|
|
* you
|
|
|
|
*/
|
|
|
|
if (!revisions.length && options.method !== 'insert') {
|
|
|
|
model.set('mobiledoc_revisions', [{
|
|
|
|
post_id: model.id,
|
|
|
|
mobiledoc: model.previous('mobiledoc'),
|
|
|
|
created_at_ts: Date.now() - 1
|
|
|
|
}, {
|
|
|
|
post_id: model.id,
|
|
|
|
mobiledoc: model.get('mobiledoc'),
|
|
|
|
created_at_ts: Date.now()
|
|
|
|
}]);
|
|
|
|
} else {
|
|
|
|
const revisionsJSON = revisions.toJSON().slice(0, MOBILEDOC_REVISIONS_COUNT - 1);
|
|
|
|
|
|
|
|
model.set('mobiledoc_revisions', revisionsJSON.concat([{
|
|
|
|
post_id: model.id,
|
|
|
|
mobiledoc: model.get('mobiledoc'),
|
|
|
|
created_at_ts: Date.now()
|
|
|
|
}]));
|
|
|
|
}
|
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2017-04-19 16:53:23 +03:00
|
|
|
return sequence(ops);
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2018-03-05 11:10:27 +03:00
|
|
|
emptyStringProperties: function emptyStringProperties() {
|
|
|
|
// CASE: the client might send empty image properties with "" instead of setting them to null.
|
|
|
|
// This can cause GQL to fail. We therefore enforce 'null' for empty image properties.
|
|
|
|
// See https://github.com/TryGhost/GQL/issues/24
|
|
|
|
return ['feature_image', 'og_image', 'twitter_image'];
|
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
created_by: function createdBy() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.belongsTo('User', 'created_by');
|
2014-04-27 20:58:34 +04:00
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
updated_by: function updatedBy() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.belongsTo('User', 'updated_by');
|
2014-04-27 20:58:34 +04:00
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
published_by: function publishedBy() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.belongsTo('User', 'published_by');
|
2014-04-27 20:58:34 +04:00
|
|
|
},
|
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
authors: function authors() {
|
|
|
|
return this.belongsToMany('User', 'posts_authors', 'post_id', 'author_id')
|
|
|
|
.withPivot('sort_order')
|
|
|
|
.query('orderBy', 'sort_order', 'ASC');
|
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
tags: function tags() {
|
2018-02-20 10:49:00 +03:00
|
|
|
return this.belongsToMany('Tag', 'posts_tags', 'post_id', 'tag_id')
|
|
|
|
.withPivot('sort_order')
|
|
|
|
.query('orderBy', 'sort_order', 'ASC');
|
2014-02-25 00:28:18 +04:00
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
fields: function fields() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.morphMany('AppField', 'relatable');
|
2014-04-22 05:08:11 +04:00
|
|
|
},
|
2018-10-09 16:31:09 +03:00
|
|
|
|
|
|
|
mobiledoc_revisions() {
|
|
|
|
return this.hasMany('MobiledocRevision', 'post_id');
|
|
|
|
},
|
|
|
|
|
2018-04-06 14:32:10 +03:00
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
* If you are requesting models with `columns`, you try to only receive some fields of the model/s.
|
|
|
|
* But the model layer is complex and needs specific fields in specific situations.
|
|
|
|
*
|
2018-10-03 16:44:30 +03:00
|
|
|
* ### url generation was removed but default columns need to be checked before removal
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
* - @TODO: with dynamic routing, we no longer need default columns to fetch
|
|
|
|
* - because with static routing Ghost generated the url on runtime and needed the following attributes:
|
2018-04-06 14:32:10 +03:00
|
|
|
* - `slug`: /:slug/
|
|
|
|
* - `published_at`: /:year/:slug
|
|
|
|
* - `author_id`: /:author/:slug, /:primary_author/:slug
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
* - now, the UrlService pre-generates urls based on the resources
|
2018-04-25 20:37:39 +03:00
|
|
|
* - you can ask `urlService.getUrlByResourceId(post.id)`
|
2018-04-06 14:32:10 +03:00
|
|
|
*
|
|
|
|
* ### events
|
|
|
|
* - you call `findAll` with `columns: id`
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
* - then you trigger `post.save()` on the response
|
2018-04-06 14:32:10 +03:00
|
|
|
* - bookshelf events (`onSaving`) and model events (`emitChange`) are triggered
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
* - but you only fetched the id column, this will trouble (!), because the event hooks require more
|
|
|
|
* data than just the id
|
|
|
|
* - @TODO: we need to disallow this (!)
|
2018-04-06 14:32:10 +03:00
|
|
|
* - you should use `models.Post.edit(..)`
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
* - this disallows using the `columns` option
|
2018-04-06 14:32:10 +03:00
|
|
|
* - same for destroy - you should use `models.Post.destroy(...)`
|
|
|
|
*
|
|
|
|
* @IMPORTANT: This fn should **never** be used when updating models (models.Post.edit)!
|
|
|
|
* Because the events for updating a resource require most of the fields.
|
|
|
|
* This is protected by the fn `permittedOptions`.
|
|
|
|
*/
|
2016-07-18 23:21:47 +03:00
|
|
|
defaultColumnsToFetch: function defaultColumnsToFetch() {
|
|
|
|
return ['id', 'published_at', 'slug', 'author_id'];
|
|
|
|
},
|
2017-05-30 13:40:39 +03:00
|
|
|
/**
|
|
|
|
* If the `formats` option is not used, we return `html` be default.
|
|
|
|
* Otherwise we return what is requested e.g. `?formats=mobiledoc,plaintext`
|
|
|
|
*/
|
|
|
|
formatsToJSON: function formatsToJSON(attrs, options) {
|
|
|
|
var defaultFormats = ['html'],
|
|
|
|
formatsToKeep = options.formats || defaultFormats;
|
|
|
|
|
|
|
|
// Iterate over all known formats, and if they are not in the keep list, remove them
|
|
|
|
_.each(Post.allowedFormats, function (format) {
|
|
|
|
if (formatsToKeep.indexOf(format) === -1) {
|
|
|
|
delete attrs[format];
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
return attrs;
|
|
|
|
},
|
2016-07-18 23:21:47 +03:00
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
toJSON: function toJSON(unfilteredOptions) {
|
|
|
|
var options = Post.filterOptions(unfilteredOptions, 'toJSON'),
|
2018-07-19 12:35:55 +03:00
|
|
|
attrs = ghostBookshelf.Model.prototype.toJSON.call(this, options);
|
2014-04-22 05:08:11 +04:00
|
|
|
|
2017-05-30 13:40:39 +03:00
|
|
|
attrs = this.formatsToJSON(attrs, options);
|
|
|
|
|
2018-10-09 16:31:09 +03:00
|
|
|
// CASE: never expose the revisions
|
|
|
|
delete attrs.mobiledoc_revisions;
|
|
|
|
|
2017-07-31 12:00:03 +03:00
|
|
|
// If the current column settings allow it...
|
|
|
|
if (!options.columns || (options.columns && options.columns.indexOf('primary_tag') > -1)) {
|
2017-08-24 15:07:19 +03:00
|
|
|
// ... attach a computed property of primary_tag which is the first tag if it is public, else null
|
|
|
|
if (attrs.tags && attrs.tags.length > 0 && attrs.tags[0].visibility === 'public') {
|
|
|
|
attrs.primary_tag = attrs.tags[0];
|
|
|
|
} else {
|
|
|
|
attrs.primary_tag = null;
|
|
|
|
}
|
2017-07-31 12:00:03 +03:00
|
|
|
}
|
2015-07-04 21:27:23 +03:00
|
|
|
|
2014-04-22 05:08:11 +04:00
|
|
|
return attrs;
|
2015-11-11 20:52:44 +03:00
|
|
|
},
|
2018-01-25 19:54:28 +03:00
|
|
|
enforcedFilters: function enforcedFilters(options) {
|
|
|
|
return options.context && options.context.public ? 'status:published' : null;
|
2015-11-11 20:52:44 +03:00
|
|
|
},
|
2018-01-25 19:54:28 +03:00
|
|
|
defaultFilters: function defaultFilters(options) {
|
|
|
|
if (options.context && options.context.internal) {
|
2016-04-14 18:54:49 +03:00
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
2018-01-25 19:54:28 +03:00
|
|
|
return options.context && options.context.public ? 'page:false' : 'page:false+status:published';
|
2018-11-15 17:53:24 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* You can pass an extra `status=VALUES` or "staticPages" field.
|
|
|
|
* Long-Term: We should deprecate these short cuts and force users to use the filter param.
|
|
|
|
*/
|
|
|
|
extraFilters: function extraFilters(options) {
|
|
|
|
if (!options.staticPages && !options.status) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
let filter = null;
|
|
|
|
|
|
|
|
// CASE: "staticPages" is passed
|
|
|
|
if (options.staticPages && options.staticPages !== 'all') {
|
|
|
|
// CASE: convert string true/false to boolean
|
|
|
|
if (!_.isBoolean(options.staticPages)) {
|
|
|
|
options.staticPages = _.includes(['true', '1'], options.staticPages);
|
|
|
|
}
|
|
|
|
|
|
|
|
filter = `page:${options.staticPages}`;
|
|
|
|
} else if (options.staticPages === 'all') {
|
|
|
|
filter = 'page:[true, false]';
|
|
|
|
}
|
|
|
|
|
|
|
|
// CASE: "status" is passed, combine filters
|
|
|
|
if (options.status && options.status !== 'all') {
|
|
|
|
options.status = _.includes(ALL_STATUSES, options.status) ? options.status : 'published';
|
|
|
|
|
|
|
|
if (!filter) {
|
|
|
|
filter = `status:${options.status}`;
|
|
|
|
} else {
|
|
|
|
filter = `${filter}+status:${options.status}`;
|
|
|
|
}
|
|
|
|
} else if (options.status === 'all') {
|
|
|
|
if (!filter) {
|
|
|
|
filter = `status:[${ALL_STATUSES}]`;
|
|
|
|
} else {
|
|
|
|
filter = `${filter}+status:[${ALL_STATUSES}]`;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
delete options.status;
|
|
|
|
delete options.staticPages;
|
|
|
|
return filter;
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
|
|
|
}, {
|
2018-07-19 12:35:55 +03:00
|
|
|
allowedFormats: ['mobiledoc', 'html', 'plaintext'],
|
2017-05-30 13:40:39 +03:00
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
orderDefaultOptions: function orderDefaultOptions() {
|
|
|
|
return {
|
|
|
|
status: 'ASC',
|
|
|
|
published_at: 'DESC',
|
|
|
|
updated_at: 'DESC',
|
|
|
|
id: 'DESC'
|
|
|
|
};
|
|
|
|
},
|
|
|
|
|
2018-11-15 17:27:31 +03:00
|
|
|
orderDefaultRaw: function (options) {
|
|
|
|
let order = '' +
|
2016-07-15 13:04:10 +03:00
|
|
|
'CASE WHEN posts.status = \'scheduled\' THEN 1 ' +
|
|
|
|
'WHEN posts.status = \'draft\' THEN 2 ' +
|
|
|
|
'ELSE 3 END ASC,' +
|
2018-09-04 14:28:11 +03:00
|
|
|
'CASE WHEN posts.status != \'draft\' THEN posts.published_at END DESC,' +
|
2016-07-15 13:04:10 +03:00
|
|
|
'posts.updated_at DESC,' +
|
|
|
|
'posts.id DESC';
|
2018-11-15 17:27:31 +03:00
|
|
|
|
|
|
|
// CASE: if the filter contains an `IN` operator, we should return the posts first, which match both tags
|
|
|
|
if (options.filter && options.filter.match(/(tags|tag):\s?\[.*\]/)) {
|
🐛 Fixed all known filter limitations (#10159)
refs #10105, closes #10108, closes https://github.com/TryGhost/Ghost/issues/9950, refs https://github.com/TryGhost/Ghost/issues/9923, refs https://github.com/TryGhost/Ghost/issues/9916, refs https://github.com/TryGhost/Ghost/issues/9574, refs https://github.com/TryGhost/Ghost/issues/6345, refs https://github.com/TryGhost/Ghost/issues/6309, refs https://github.com/TryGhost/Ghost/issues/6158, refs https://github.com/TryGhost/GQL/issues/16
- removed GQL dependency
- replaced GQL with our brand new NQL implementation
- fixed all known filter limitations
- GQL suffered from some underlying filter bugs, which NQL tried to fix
- the bugs were mostly in how we query the database for relation filtering
- the underlying problem was caused by a too simple implementation of querying the relations
- mongo-knex has implemented a more robust and complex filtering mechanism for relations
- replaced logic in our bookshelf filter plugin
- we pass the custom, default and override filters from Ghost to NQL, which then are getting parsed and merged into a mongo JSON object. The mongo JSON is getting attached by mongo-knex.
NQL: https://github.com/NexesJS/NQL
mongo-knex: https://github.com/NexesJS/mongo-knex
2018-12-11 13:53:40 +03:00
|
|
|
order = `(SELECT count(*) FROM posts_tags WHERE post_id = posts.id) DESC, ${order}`;
|
2018-11-15 17:27:31 +03:00
|
|
|
}
|
|
|
|
|
2018-11-15 18:17:51 +03:00
|
|
|
// CASE: if the filter contains an `IN` operator, we should return the posts first, which match both authors
|
|
|
|
if (options.filter && options.filter.match(/(authors|author):\s?\[.*\]/)) {
|
🐛 Fixed all known filter limitations (#10159)
refs #10105, closes #10108, closes https://github.com/TryGhost/Ghost/issues/9950, refs https://github.com/TryGhost/Ghost/issues/9923, refs https://github.com/TryGhost/Ghost/issues/9916, refs https://github.com/TryGhost/Ghost/issues/9574, refs https://github.com/TryGhost/Ghost/issues/6345, refs https://github.com/TryGhost/Ghost/issues/6309, refs https://github.com/TryGhost/Ghost/issues/6158, refs https://github.com/TryGhost/GQL/issues/16
- removed GQL dependency
- replaced GQL with our brand new NQL implementation
- fixed all known filter limitations
- GQL suffered from some underlying filter bugs, which NQL tried to fix
- the bugs were mostly in how we query the database for relation filtering
- the underlying problem was caused by a too simple implementation of querying the relations
- mongo-knex has implemented a more robust and complex filtering mechanism for relations
- replaced logic in our bookshelf filter plugin
- we pass the custom, default and override filters from Ghost to NQL, which then are getting parsed and merged into a mongo JSON object. The mongo JSON is getting attached by mongo-knex.
NQL: https://github.com/NexesJS/NQL
mongo-knex: https://github.com/NexesJS/mongo-knex
2018-12-11 13:53:40 +03:00
|
|
|
order = `(SELECT count(*) FROM posts_authors WHERE post_id = posts.id) DESC, ${order}`;
|
2018-11-15 18:17:51 +03:00
|
|
|
}
|
|
|
|
|
2018-11-15 17:27:31 +03:00
|
|
|
return order;
|
2016-07-15 13:04:10 +03:00
|
|
|
},
|
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
/**
|
2017-12-12 00:47:46 +03:00
|
|
|
* Returns an array of keys permitted in a method's `options` hash, depending on the current method.
|
|
|
|
* @param {String} methodName The name of the method to check valid options for.
|
|
|
|
* @return {Array} Keys allowed in the `options` hash of the model's method.
|
|
|
|
*/
|
2015-06-14 18:58:49 +03:00
|
|
|
permittedOptions: function permittedOptions(methodName) {
|
2018-09-20 17:23:39 +03:00
|
|
|
var options = ghostBookshelf.Model.permittedOptions.call(this, methodName),
|
2014-05-06 05:45:08 +04:00
|
|
|
|
|
|
|
// whitelists for the `options` hash argument on methods, by method name.
|
|
|
|
// these are the only options that can be passed to Bookshelf / Knex.
|
|
|
|
validOptions = {
|
2017-11-14 02:18:59 +03:00
|
|
|
findOne: ['columns', 'importing', 'withRelated', 'require'],
|
2018-09-26 15:11:22 +03:00
|
|
|
findPage: ['page', 'limit', 'columns', 'filter', 'order', 'status', 'staticPages'],
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
findAll: ['columns', 'filter'],
|
|
|
|
destroy: ['destroyAll']
|
2014-05-06 05:45:08 +04:00
|
|
|
};
|
|
|
|
|
2017-05-30 13:40:39 +03:00
|
|
|
// The post model additionally supports having a formats option
|
|
|
|
options.push('formats');
|
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
if (validOptions[methodName]) {
|
|
|
|
options = options.concat(validOptions[methodName]);
|
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
},
|
|
|
|
|
2018-04-15 13:12:20 +03:00
|
|
|
/**
|
|
|
|
* We have to ensure consistency. If you listen on model events (e.g. `post.published`), you can expect that you always
|
|
|
|
* receive all fields including relations. Otherwise you can't rely on a consistent flow. And we want to avoid
|
|
|
|
* that event listeners have to re-fetch a resource. This function is used in the context of inserting
|
|
|
|
* and updating resources. We won't return the relations by default for now.
|
|
|
|
*/
|
|
|
|
defaultRelations: function defaultRelations(methodName, options) {
|
2019-01-08 12:48:53 +03:00
|
|
|
if (['edit', 'add', 'destroy'].indexOf(methodName) !== -1) {
|
2018-10-11 10:04:47 +03:00
|
|
|
options.withRelated = _.union(['authors', 'tags'], options.withRelated || []);
|
2018-04-15 13:12:20 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
},
|
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
/**
|
2017-04-19 11:59:09 +03:00
|
|
|
* Manually add 'tags' attribute since it's not in the schema and call parent.
|
|
|
|
*
|
2014-05-06 05:45:08 +04:00
|
|
|
* @param {Object} data Has keys representing the model's attributes/fields in the database.
|
|
|
|
* @return {Object} The filtered results of the passed in data, containing only what's allowed in the schema.
|
|
|
|
*/
|
2015-06-14 18:58:49 +03:00
|
|
|
filterData: function filterData(data) {
|
2017-04-19 11:59:09 +03:00
|
|
|
var filteredData = ghostBookshelf.Model.filterData.apply(this, arguments),
|
2017-11-21 16:28:05 +03:00
|
|
|
extraData = _.pick(data, this.prototype.relationships);
|
2014-05-06 05:45:08 +04:00
|
|
|
|
2017-04-19 11:59:09 +03:00
|
|
|
_.merge(filteredData, extraData);
|
2014-05-06 05:45:08 +04:00
|
|
|
return filteredData;
|
|
|
|
},
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
|
Refactor API arguments
closes #2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
2014-05-08 16:41:19 +04:00
|
|
|
// ## Model Data Functions
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Find One
|
|
|
|
* @extends ghostBookshelf.Model.findOne to handle post status
|
|
|
|
* **See:** [ghostBookshelf.Model.findOne](base.js.html#Find%20One)
|
|
|
|
*/
|
2015-06-14 18:58:49 +03:00
|
|
|
findOne: function findOne(data, options) {
|
2015-06-25 21:56:27 +03:00
|
|
|
data = _.defaults(data || {}, {
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
status: 'published'
|
2015-06-25 21:56:27 +03:00
|
|
|
});
|
2013-06-09 03:39:24 +04:00
|
|
|
|
Refactor API arguments
closes #2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
2014-05-08 16:41:19 +04:00
|
|
|
if (data.status === 'all') {
|
|
|
|
delete data.status;
|
2013-06-01 18:47:41 +04:00
|
|
|
}
|
|
|
|
|
2017-10-13 17:44:39 +03:00
|
|
|
return ghostBookshelf.Model.findOne.call(this, data, options);
|
2013-09-13 17:29:59 +04:00
|
|
|
},
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
|
Refactor API arguments
closes #2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
2014-05-08 16:41:19 +04:00
|
|
|
/**
|
|
|
|
* ### Edit
|
2017-04-19 16:53:23 +03:00
|
|
|
* Fetches and saves to Post. See model.Base.edit
|
|
|
|
*
|
Refactor API arguments
closes #2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
2014-05-08 16:41:19 +04:00
|
|
|
* @extends ghostBookshelf.Model.edit to handle returning the full object and manage _updatedAttributes
|
|
|
|
* **See:** [ghostBookshelf.Model.edit](base.js.html#edit)
|
|
|
|
*/
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
edit: function edit(data, unfilteredOptions) {
|
|
|
|
let options = this.filterOptions(unfilteredOptions, 'edit', {extraAllowedProperties: ['id']});
|
2017-11-21 16:28:05 +03:00
|
|
|
|
|
|
|
const editPost = () => {
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
options.forUpdate = true;
|
2017-04-19 16:53:23 +03:00
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
return ghostBookshelf.Model.edit.call(this, data, options)
|
2017-11-21 16:28:05 +03:00
|
|
|
.then((post) => {
|
2018-04-15 13:12:20 +03:00
|
|
|
return this.findOne({
|
|
|
|
status: 'all',
|
|
|
|
id: options.id
|
|
|
|
}, _.merge({transacting: options.transacting}, unfilteredOptions))
|
2017-11-21 16:28:05 +03:00
|
|
|
.then((found) => {
|
2017-04-19 16:53:23 +03:00
|
|
|
if (found) {
|
|
|
|
// Pass along the updated attributes for checking status changes
|
|
|
|
found._updatedAttributes = post._updatedAttributes;
|
|
|
|
return found;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
});
|
2017-11-21 16:28:05 +03:00
|
|
|
};
|
2014-02-19 17:57:26 +04:00
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
if (!options.transacting) {
|
2017-11-21 16:28:05 +03:00
|
|
|
return ghostBookshelf.transaction((transacting) => {
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
options.transacting = transacting;
|
2017-11-21 16:28:05 +03:00
|
|
|
return editPost();
|
|
|
|
});
|
2017-04-19 16:53:23 +03:00
|
|
|
}
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
return editPost();
|
2013-11-03 21:13:19 +04:00
|
|
|
},
|
Refactor API arguments
closes #2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
2014-05-08 16:41:19 +04:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Add
|
|
|
|
* @extends ghostBookshelf.Model.add to handle returning the full object
|
|
|
|
* **See:** [ghostBookshelf.Model.add](base.js.html#add)
|
|
|
|
*/
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
add: function add(data, unfilteredOptions) {
|
|
|
|
let options = this.filterOptions(unfilteredOptions, 'add', {extraAllowedProperties: ['id']});
|
Refactor API arguments
closes #2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
2014-05-08 16:41:19 +04:00
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
const addPost = (() => {
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
return ghostBookshelf.Model.add.call(this, data, options)
|
2017-11-21 16:28:05 +03:00
|
|
|
.then((post) => {
|
2018-04-15 13:12:20 +03:00
|
|
|
return this.findOne({
|
|
|
|
status: 'all',
|
|
|
|
id: post.id
|
|
|
|
}, _.merge({transacting: options.transacting}, unfilteredOptions));
|
2017-11-21 16:28:05 +03:00
|
|
|
});
|
2013-09-13 17:29:59 +04:00
|
|
|
});
|
2017-11-21 16:28:05 +03:00
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
if (!options.transacting) {
|
2017-11-21 16:28:05 +03:00
|
|
|
return ghostBookshelf.transaction((transacting) => {
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
options.transacting = transacting;
|
2017-11-21 16:28:05 +03:00
|
|
|
|
|
|
|
return addPost();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return addPost();
|
|
|
|
},
|
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
destroy: function destroy(unfilteredOptions) {
|
|
|
|
let options = this.filterOptions(unfilteredOptions, 'destroy', {extraAllowedProperties: ['id']});
|
2017-11-21 16:28:05 +03:00
|
|
|
|
|
|
|
const destroyPost = () => {
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
return ghostBookshelf.Model.destroy.call(this, options);
|
2017-11-21 16:28:05 +03:00
|
|
|
};
|
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
if (!options.transacting) {
|
2017-11-21 16:28:05 +03:00
|
|
|
return ghostBookshelf.transaction((transacting) => {
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
options.transacting = transacting;
|
2017-11-21 16:28:05 +03:00
|
|
|
return destroyPost();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return destroyPost();
|
2013-09-27 14:56:20 +04:00
|
|
|
},
|
2014-04-03 17:03:09 +04:00
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
// NOTE: the `authors` extension is the parent of the post model. It also has a permissible function.
|
2019-01-18 15:39:53 +03:00
|
|
|
permissible: function permissible(postModel, action, context, unsafeAttrs, loadedPermissions, hasUserPermission, hasAppPermission, hasApiKeyPermission) {
|
2018-03-27 17:16:15 +03:00
|
|
|
let isContributor, isEdit, isAdd, isDestroy;
|
2018-02-21 18:59:48 +03:00
|
|
|
|
2017-09-27 14:12:53 +03:00
|
|
|
function isChanging(attr) {
|
|
|
|
return unsafeAttrs[attr] && unsafeAttrs[attr] !== postModel.get(attr);
|
|
|
|
}
|
|
|
|
|
2018-02-07 12:46:22 +03:00
|
|
|
function isPublished() {
|
|
|
|
return unsafeAttrs.status && unsafeAttrs.status !== 'draft';
|
|
|
|
}
|
|
|
|
|
|
|
|
function isDraft() {
|
|
|
|
return postModel.get('status') === 'draft';
|
|
|
|
}
|
|
|
|
|
|
|
|
isContributor = loadedPermissions.user && _.some(loadedPermissions.user.roles, {name: 'Contributor'});
|
|
|
|
isEdit = (action === 'edit');
|
|
|
|
isAdd = (action === 'add');
|
|
|
|
isDestroy = (action === 'destroy');
|
|
|
|
|
|
|
|
if (isContributor && isEdit) {
|
2018-03-27 17:16:15 +03:00
|
|
|
// Only allow contributor edit if status is changing, and the post is a draft post
|
|
|
|
hasUserPermission = !isChanging('status') && isDraft();
|
2018-02-07 12:46:22 +03:00
|
|
|
} else if (isContributor && isAdd) {
|
|
|
|
// If adding, make sure it's a draft post and has the correct ownership
|
2018-03-27 17:16:15 +03:00
|
|
|
hasUserPermission = !isPublished();
|
2018-02-07 12:46:22 +03:00
|
|
|
} else if (isContributor && isDestroy) {
|
|
|
|
// If destroying, only allow contributor to destroy their own draft posts
|
2018-03-27 17:16:15 +03:00
|
|
|
hasUserPermission = isDraft();
|
2018-02-07 12:46:22 +03:00
|
|
|
}
|
|
|
|
|
2018-10-09 14:03:13 +03:00
|
|
|
const excludedAttrs = [];
|
2018-02-07 12:46:22 +03:00
|
|
|
if (isContributor) {
|
|
|
|
// Note: at the moment primary_tag is a computed field,
|
2018-03-27 17:16:15 +03:00
|
|
|
// meaning we don't add it to this list. However, if the primary_tag/primary_author
|
2018-02-07 12:46:22 +03:00
|
|
|
// ever becomes a db field rather than a computed field, add it to this list
|
2018-03-27 17:16:15 +03:00
|
|
|
// TODO: once contributors are able to edit existing tags, this can be removed
|
|
|
|
// @TODO: we need a concept for making a diff between incoming tags and existing tags
|
2018-10-09 14:03:13 +03:00
|
|
|
excludedAttrs.push('tags');
|
2014-05-14 05:49:07 +04:00
|
|
|
}
|
|
|
|
|
2019-01-18 15:39:53 +03:00
|
|
|
if (hasUserPermission && hasApiKeyPermission && hasAppPermission) {
|
2018-10-09 14:03:13 +03:00
|
|
|
return Promise.resolve({excludedAttrs});
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
}
|
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
return Promise.reject(new common.errors.NoPermissionError({
|
|
|
|
message: common.i18n.t('errors.models.post.notEnoughPermission')
|
|
|
|
}));
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
|
|
|
});
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2013-09-23 02:20:08 +04:00
|
|
|
Posts = ghostBookshelf.Collection.extend({
|
2015-12-02 13:06:44 +03:00
|
|
|
model: Post
|
2013-06-25 15:43:15 +04:00
|
|
|
});
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
// Extension for handling the logic for author + multiple authors
|
|
|
|
Post = relations.authors.extendModel(Post, Posts, ghostBookshelf);
|
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
module.exports = {
|
2014-07-13 15:17:18 +04:00
|
|
|
Post: ghostBookshelf.model('Post', Post),
|
|
|
|
Posts: ghostBookshelf.collection('Posts', Posts)
|
2014-02-25 14:18:33 +04:00
|
|
|
};
|