c93f03b87e
closes #5599 If two users edit the same post, it can happen that they override each others content or post settings. With this change this won't happen anymore. ✨ Update collision for posts - add a new bookshelf plugin to detect these changes - use the `changed` object of bookshelf -> we don't have to create our own diff - compare client and server updated_at field - run editing posts in a transaction (see comments in code base) 🙀 update collision for tags - `updateTags` for adding posts on `onCreated` - happens after the post was inserted --> it's "okay" to attach the tags afterwards on insert --> there is no need to add collision for inserting data --> it's very hard to move the updateTags call to `onCreating`, because the `updateTags` function queries the database to look up the affected post - `updateTags` while editing posts on `onSaving` - all operations run in a transactions and are rolled back if something get's rejected - Post model edit: if we push a transaction from outside, take this one ✨ introduce options.forUpdate - if two queries happening in a transaction we have to signalise knex/mysql that we select for an update - otherwise the following case happens: >> you fetch posts for an update >> a user requests comes in and updates the post (e.g. sets title to "X") >> you update the fetched posts, title would get overriden to the old one use options.forUpdate and protect internal post updates: model listeners - use a transaction for listener updates - signalise forUpdate - write a complex test use options.forUpdate and protect internal post updates: scheduling - publish endpoint runs in a transaction - add complex test - @TODO: right now scheduling api uses posts api, therefor we had to extend the options for api's >> allowed to pass transactions through it >> but these are only allowed if defined from outside {opts: [...]} >> so i think this is fine and not dirty >> will wait for opinions >> alternatively we have to re-write the scheduling endpoint to use the models directly |
||
|---|---|---|
| .github | ||
| content | ||
| core | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| .jscsrc | ||
| .jshintrc | ||
| .npmignore | ||
| .travis.yml | ||
| Gruntfile.js | ||
| index.js | ||
| LICENSE | ||
| MigratorConfig.js | ||
| package.json | ||
| PRIVACY.md | ||
| README.md | ||
| SECURITY.md | ||
| yarn.lock | ||
The project is maintained by a non-profit organisation called the Ghost Foundation, along with an amazing group of independent contributors. We're trying to make publishing software that changes the shape of online journalism.
NOTE: If you’re stuck, can’t get something working or need some help, please head on over and join our Slack community rather than opening an issue.
Ghost 1.0-alpha Developer Install
Please note: These are the install instructions for Ghost 1.0-alpha, which is not stable. If you're looking for the latest release of Ghost, check out the stable branch or the latest release. If you get stuck, come say hi over on slack!
Important: Ghost uses yarn rather than npm to manage it's dependencies. Ensure that you have it installed and you have configured your PATH environment variable for it to work correctly. We recommend the "Installation Script" instructions because it works better with nvm but choose the best option for your development setup.
Install and run Ghost.
git clone git@github.com:TryGhost/Ghost.git ghost
Download the Ghost code base
npm run init
Short command for: yarn global add knex-migrator ember-cli grunt-cli && yarn install && grunt symlink && grunt init
knex-migrator init
Creates and initialises your database
grunt dev
Starts the express server and ember build
Run server tests
grunt test-all
Run client tests
cd core/client
ember test
Read more about the development workflows.
Deploying Ghost
The easiest way to deploy Ghost is with our official Ghost(Pro) managed service. You can have a fresh instance up and running in a couple of clicks with a worldwide CDN, backups, security and maintenance all done for you.
Not only will it save you many hours per month, but all revenue goes to the Ghost Foundation, which funds the maintenance and further development of Ghost itself. So you’ll be supporting open source software and getting a great service at the same time! Talk about win/win. 🏆
Other options are also available if you prefer playing around with servers by yourself, of course. The freedom of choice is in your hands.
Staying Up to Date
When a new version of Ghost comes out, you'll want to look over these upgrade instructions for what to do next.
You can talk to other Ghost users and developers in our public Slack team (it's pretty awesome). We have a public meeting every Tuesday at 5:30pm UK time.
New releases are announced on the dev blog. You can subscribe by email or follow @TryGhost_Dev on Twitter, if you prefer your updates bite-sized and facetious. 🎷🐢
Copyright & License
Copyright (c) 2013-2017 Ghost Foundation - Released under the MIT license.