* website: initial conversion to gatsby v2
* fix unexpected history use warning
* use commonjs only to fix gatsby error
* fix gatsby import error with sidecar
* remove unused postcss-colour-functions
* remove unused prop
* lowercase layout filename import to match actual file
* chore(lint): format code
<!--
Thanks for submitting a pull request!
Please make sure you've read and understood our contributing guidelines;
https://github.com/netlify/netlify-cms/blob/master/CONTRIBUTING.md
If this is a bug fix, make sure your description includes "fixes #xxxx", or
"closes #xxxx", where #xxxx is the issue number.
Please provide enough information so that others can review your pull request.
The first three fields are mandatory:
-->
**- Summary**
<!--
Explain the **motivation** for making this change.
What existing problem does the pull request solve?
-->
Was going through the quick-start and noticed 404 to links
**- Test plan**
<!--
Demonstrate the code is solid.
Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
-->
Just simple link changes.
**- Description for the changelog**
<!--
Write a short (one line) summary that describes the changes in this
pull request for inclusion in the changelog:
-->
e.g Changed (https://netlifycms.org/docs/hello) to (/docs/hello)
**- A picture of a cute animal (not mandatory but encouraged)**
![Cute cat](https://i.imgur.com/xkKw5r8.jpg "Logo Title Text 1")
* Add hint to example admin config
* Add hint and hint position boolean above/below widget
* Style hint for both above and below widget
* Add hint and hint_above options to docs
* Remove hint above and make hint plaintext
Prettier formatting our markdown files is causing bugs because of the
differences between Gatsby's parser and Prettier's. Also, Prettier
formats the inline code-blocks containing example CMS configs, but the
formatting it uses doesn't really make much sense or match the suggested
CMS config style.
It doesn't actually make much sense to format the docs anyway, since we
use the CMS itself to edit/generate them.
* docs(add-to-your-site): include verbose document links
- add extra references to config.yml
* docs(collection-types): provide consistent examples
- include link to configuration doc
- describe admin UI behaviour when accessing files
* docs(add-to-your-site): make authentication phrasing less biased
- add note regarding core behaviour fetching remote files
* docs(collection-types): add note about configurable branches
* docs(website): add more descriptive language to configuration notes
- include deep links to documentation where applicable
* docs(website): change link titles to match their target content
When loading Netlify CMS via script tag from a CDN, the file was named
`cms.js` until 2.0, when it was renamed to `netlify-cms.js` in alignment
with all packages outputting files that match the package name. To avoid
a lot of broken sites and confusion, this commit outputs both filenames
and prints a deprecation warning to the console in `cms.js` only.
The example URI for creating an application in GitLab does not contain a trailing `/` but the Netlify CMS admin oauth implicit grant request to GitLab does include a trailing `/`. This results in a failure with GitLab not matching the URI and returning an error.
Following the example explicitly as most will do with copy-paste, `https://example.com/app/admin` will be entered. Then the Netlify admin login will send `https://example.com/app/admin` and the URI will not match and GitLab will show an error indicating the URI is invalid.
The easy fix for the user is just to put the trailing `/` ... `https://example.com/app/admin/`.
I updated that example string in the hopes that users will not have to figure this out on their own in the future.
* return date object from date/datetime widgets if no format set
BREAKING CHANGE
As of 1.0, the documented behavior for the date and datetime widgets was
to always return a string value, but they were instead returning a date
object if the default date was not manually changed by the user. This
was addressed in #1143, but it became clear afterward that static site
generators were depending on the raw date objects that Netlify CMS was
unintentionally producing. Remaining as is or addressing the bug were
both "breaking" states, so this commit reverts to producing raw date
objects when no format is explicitly set.
It is now considered an edge case to require string dates, as most
static site generators expect to parse a raw date against formatting in
a site's templates.
Also note that this commit improves the original behavior by always
providing a date object when no format is provided, even if the user
manually changes the value.
* produce raw date when no format is provided