7eb316b786
* 🛠 bookshelf tarball, bson-objectid
* 🎨 schema changes
- change increment type to string
- add a default fallback for string length 191 (to avoid adding this logic to every single column which uses an ID)
- remove uuid, because ID now represents a global resource identifier
- keep uuid for post, because we are using this as preview id
- keep uuid for clients for now - we are using this param for Ghost-Auth
* ✨ base model: generate ObjectId on creating event
- each new resource get's a auto generate ObjectId
- this logic won't work for attached models, this commit comes later
* 🎨 centralised attach method
When attaching models there are two things important two know
1. To be able to attach an ObjectId, we need to register the `onCreating` event the fetched model!This is caused by the Bookshelf design in general. On this target model we are attaching the new model.
2. We need to manually fetch the target model, because Bookshelf has a weird behaviour (which is known as a bug, see see https://github.com/tgriesser/bookshelf/issues/629). The most important property when attaching a model is `parentFk`, which is the foreign key. This can be null when fetching the model with the option `withRelated`. To ensure quality and consistency, the custom attach wrapper always fetches the target model manual. By fetching the target model (again) is a little performance decrease, but it also has advantages: we can register the event, and directly unregister the event again. So very clean code.
Important: please only use the custom attach wrapper in the future.
* 🎨 token model had overriden the onCreating function because of the created_at field
- we need to ensure that the base onCreating hook get's triggered for ALL models
- if not, they don't get an ObjectId assigned
- in this case: be smart and check if the target model has a created_at field
* 🎨 we don't have a uuid field anymore, remove the usages
- no default uuid creation in models
- i am pretty sure we have some more definitions in our tests (for example in the export json files), but that is too much work to delete them all
* 🎨 do not parse ID to Number
- we had various occurances of parsing all ID's to numbers
- we don't need this behaviour anymore
- ID is string
- i will adapt the ID validation in the next commit
* 🎨 change ID regex for validation
- we only allow: ID as ObjectId, ID as 1 and ID as me
- we need to keep ID 1, because our whole software relies on ID 1 (permissions etc)
* 🎨 owner fixture
- roles: [4] does not work anymore
- 4 means -> static id 4
- this worked in an auto increment system (not even in a system with distributed writes)
- with ObjectId we generate each ID automatically (for static and dynamic resources)
- it is possible to define all id's for static resources still, but that means we need to know which ID is already used and for consistency we have to define ObjectId's for these static resources
- so no static id's anymore, except of: id 1 for owner and id 0 for external usage (because this is required from our permission system)
- NOTE: please read through the comment in the user model
* 🎨 tests: DataGenerator and test utils
First of all: we need to ensure using ObjectId's in the tests. When don't, we can't ensure that ObjectId's work properly.
This commit brings lot's of dynamic into all the static defined id's.
In one of the next commits, i will adapt all the tests.
* 🚨 remove counter in Notification API
- no need to add a counter
- we simply generate ObjectId's (they are auto incremental as well)
- our id validator does only allow ObjectId as id,1 and me
* 🎨 extend contextUser in Base Model
- remove isNumber check, because id's are no longer numbers, except of id 0/1
- use existing isExternalUser
- support id 0/1 as string or number
* ✨ Ghost Owner has id 1
- ensure we define this id in the fixtures.json
- doesn't matter if number or string
* 🎨 functional tests adaptions
- use dynamic id's
* 🎨 fix unit tests
* 🎨 integration tests adaptions
* 🎨 change importer utils
- all our export examples (test/fixtures/exports) contain id's as numbers
- fact: but we ignore them anyway when inserting into the database, see https://github.com/TryGhost/Ghost/blob/master/core/server/data/import/utils.js#L249
- in
|
||
---|---|---|
.github | ||
content | ||
core | ||
.editorconfig | ||
.gitignore | ||
.gitmodules | ||
.jscsrc | ||
.jshintrc | ||
.knex-migrator | ||
.npmignore | ||
.travis.yml | ||
Gruntfile.js | ||
gulpfile.js | ||
index.js | ||
LICENSE | ||
package.json | ||
PRIVACY.md | ||
README.md | ||
SECURITY.md |
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.
Quick Start Install
First, you’ll need Node.js v4 LTS or a supported version.
- Download the latest release of Ghost
- Unzip, and fire up terminal
npm install --production
- Start Ghost!
- Local environment:
npm start
- On a server:
npm start --production
- Local environment:
http://localhost:2368/ghost
🎉
More install docs here in case you get stuck.
Developer Install
This is for if you want to hack on Ghost core. First, you’ll need Node.js v4 LTS or a supported version. Then:
git clone git://github.com/tryghost/ghost.git
cd ghost
Install grunt
npm install -g grunt-cli
Install knex-migrator
npm install -g knex-migrator
Install Ghost
npm install
Build the things!
grunt init
Start your engines
grunt dev
Congrats! You made it. BTW you can also just npm install ghost
if you're into that sort of thing. NPM aficionados can also read up on using Ghost as an NPM module. More general install docs here in case you got stuck.
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-2016 Ghost Foundation - Released under the MIT license.