refs #6621, #6622
- remove unneeded `return new Promise.resolve()` lines
- reduce code in tests
- improve quality of tests checking that all task functions are executed
- add missing test coverage
refs #6623
- automatically set useNullAsDefault to false for sqlite3 so that we don't get a warning
- we should *not* be relying on the behaviour of interpretting undefined anywhere, so it is correct that an error should be output if this happens so that we can fix the bad behaviour
- Simplify the `init` method in `models/index.js` so that it no longer
returns a promise. Easier to use.
- Eliminates the `deleteAllContent` method from `models/index.js` as it
can all be handled at the API layer in a single spot.
- Optimize `destroyAllContent` in `api/db.js`. Eliminates
double-fetching every post from the database and converting it to
JSON. Also only fetches ids from the database instead of the entire
model.
- Eliminates the custom static method `destroy` in the Post model in
favor of handling detaching tag relations in a single place (the
`destroying` event). This also eliminates a big source of unneeded
database round trips--needing to get post ids to feed into
`Post.destroy()` which then re-fetches the post again.
Closes#6440
* Removed the `.fake-placeholder`class from the input, test, and css
* On adding a nav item, if the url value has not been set by the user,
then set it to the base url as shown in the input
* If url has been set by the user, just do what it has always done
refs #6301
- fix messages that joined with comma and therefore missed outputting version no
- change `logInfo` to `logger` that has both an info and a warn method
- add new warn method to errors
- add a warn message everytime a migration (data or fixture) gets skipped over
- update logger everywhere, including tests
- update tests to check logger.warn gets called
refs #6301
- Make sure that every fixture operation has a check to ensure that it hasn't already run
- E.g. The update of sort_order on posts_tags should only happen if there are no values which aren't a zero
- This makes sure that we don't accidentally overwrite data on FORCE_MIGRATE
- No need to try to set settings types if they are already correct
- Only update the admin client if it needs it, else we're regenerating secrets each time
refs #5091, #6612
- fixes meta data so it won't output 'null' as a JSON-LD schema
- added test coverage for this if/else
- this case cannot happen within the existing system, it only happens with custom channels after #6612
refs #5091, #6612
- unify getNextUrl & getPrevUrl into getPaginatedUrl
- ensure that it can generate a prev, next or exact page no url
- ensure that it can figure out the base url
- use the same code from the page_url helper
- refactor the tests to ensure there's 100% coverage
Following on from #6612, this ensures that pagination always works regardless of whether the channel is default or custom
refs #5091
- makes post context explicit - data.post must be set, rather than post being the default
- uses channelConfig to determine the context for a channel (the channel name) rather than basing it off of the URL
- updates tests to setup the contexts more clearly, the outcome has not changed
Since #6469 req has channelConfig attached to it.
We can use req.channelConfig to determine what the context should be for a channel (the channel name)
This allows us to remove the hardcoded URLs, and means that custom channels will automatically get their own context.
Coupled with removing 'post' from being a default/fallthrough, to being explicitly set, this will reduce
potential context errors, as we start to extend the frontend capabilities
closes#6604
* Default for `to` was always `(from-1) + limit`. This caused a problem
where the `to` value could be higher than the length of the number of
blog posts, causing `@last` to never be called/reached
* Now sets `to` to have a default of `length` and if a limit was sent
through and not higher than `length`, to then set `to` to that value
* Added some extra tests for `@last` and `@first` use cases
* Added some inline commenting
refs #6301
- Replace builder & automated database upgrade with a set of explicit tasks
- Ensure the tasks can only happen if they need to
- Remove some duplicate code between fixture & db upgrades (more to do)
- Add tests
closes#6605
- ensure that roles are being output in order of their ID before asserting
- the asserting checks both the content and order of the array - this could be done differently as order doesn't really matter here, but will let us know if there are changes in DB behaviour
refs #6301
- changes createTable to use createTableIfNotExists, this is consistent with deletion
- splits out backup, reset, update and populate functions from migration/index into their own files
- moves the wrapped function for populatingDefaultSettings to fixtures.ensureDefaultSettings
- moves `modelOptions` down to the fixture files that actually use it
- adds test coverage for backup, reset and populate, but not for update as that needs refactoring
refs #6301
- `currentVersion` was leftover from before the first public release of Ghost!
- simplified the code for `getDatabaseVersion`
- improved & made consistent how errors are handled in `getDatabaseVersion`
- migration error handling updated to reflect the changes in `getDatabaseVersion`
- added tests for both `getDatabaseVersion` and `setDatabaseVersion`
no issue
- removes should-sinon dependency from package.json
- rewrites all usages of should-sinon to use normal should assertions
Unfortunately, should-sinon has very minimal documentation and therefore it is hard to discern what is considered a correctly-written assertion:
- in some cases, refactoring to use should-sinon causes false positives
- in other cases, assertions that work written in the normal way fail when written using should-sinon (e.g. getters, combos with rewire)
The additional overhead created by these issues outweigh any benefit from the easier-to-read assertions
refs #6354, #6495 & #6599
- don't allow config.database to be merged, instead, override it always
- make sure that route tests call done even when they error
refs #6301
- change knex getter def to be configurable, else it is not testable
- remove exportPath and lang from config - neither are used
- add client_trusted_domains to tables which shouldn't be exported as there are no clients in the export
- change export signature to be an object with `doExport` function consistent with import & easier to test
- cleanup export code so it is clearer, easier to read & to test:
- use mapSeries instead of sequence
- use Promise.props instead of Promise.join
- split functionality into smaller functions
- add test coverage
refs #6301
Fixtures:
- Removed all the old (and now broken) 003 fixture upgrades
- Split the 004 fixture upgrade tasks out, each into their own file
- Improved the versioning code that figured out which upgrades we should do
- Added lots of test coverage to make sure all the fixtures are still being run correctly.
Permissions fixtures:
- Changed the code that was populating permissions fixtures to be more automated & based only on what is in the permissions.json file.
- Added lots of test coverage to make sure all the permissions are still being created correctly.
Merging the two things:
- Merged the content of permissions.json and fixtures.json into fixtures.json, but using the new structure from permissions.json.
- Changed to use the new automated model & relation creation for all fixtures, not just permissions.
- The only thing that can't be auto-populated just now is the owner creation, I think that's important enough to do separately.
- There were (so far) never any permission updates, so code for updating fixtures stays the same through the merge.
- This results in two clear code paths: populate (fill out a brand new DB) and update (make any changes since the last version)
Test coverage is now 100% across both updates and populations.
