Editorial workflow pull requests are rebased if the base has
changed to ensure that asset changes on the base branch are
reflected in the PR branch, but if an asset store is in use,
no rebasing is necessary because assets are stored outside
of the content repo.
When entries were loaded for the editorial workflow dashboard, they were
all assumed to be FrontMatter/MarkDown files. This PR allows them to be
any supported format.
* rebase editorial workflow pull requests when behind
* fix async/await transpilation
* add media library pagination
* switch media library to grid layout
* ensure that only cms branches can be force updated
Adds a `delete` flag to collections in `config.yml`; fixes
#593. Defaults to false. This is mostly for use with files to restrict
users from deleting settings files etc that available via the CMS.
* Clean up frontmatter formatter.
* Move `formatToExtension`.
* Use plain objects for file formatters.
* Use same parsers for files and frontmatter.
We want to use our file parsers for frontmatter, instead of the builtin
ones, as they process some formats (images, dates) properly.
* Cleanup YAML frontmatter parser code.
When clicking on a entry in the listing, a console error would be logged
by `history` (react-router): "Hash history cannot push state; it is
ignored". This was caused because using `bind` in the click handler
caused the return value to be passed to the `history.push` as the second
param. This was ignored in react-router v2, but gives a warning in v4.
Change suggested by @aquibm, thank you!
This is changed as of React 16:
When replacing `<A />` with `<B />`, `B.componentWillMount` now always
happens before `A.componentWillUnmount`. Previously,
`A.componentWillUnmount` could fire first in some cases.
If the backend was changed in the config, the user from the old backend
would be passed to the new backend, which could cause errors if the
format was different.
Before, if the CMS was loading user OAuth credentials from
`localStorage`, then user write access would not be checked again.
However, the `config.yml` repo could be changed, which would cause the
user to be still logged in even if they did not have write permissions.
Also, if the user had updated their metadata (avatar, etc.), the CMS
would not update that either.
