Adding NetlifyCMS to Your VuePress Website(blog.michaelbrooks.dev)
blog.michaelbrooks.dev
Adding NetlifyCMS to Your VuePress Website
https://blog.michaelbrooks.dev/adding-netlifycms/
21 comments
If you're looking for mobile support, we (Forestry.io) support it https://forestry.io.
That is really disappointing and I wonder what's taking them so long, I hope they fix it soon.
[deleted]
I believe it's mostly Slate that's holding things up, but partial Android support (8 & 9) arrived in June [0], so things are slowly progressing.
[0] https://github.com/ianstormtaylor/slate/pull/2853
[0] https://github.com/ianstormtaylor/slate/pull/2853
NetlifyCMS is great for blogs. Anything more complex, I wouldn't recommend.
Even for blogs it is not ideal. I’ve set it up on my wifes website and blog and after some time I switched it to Contentful which has good enough free tier and is much better, especcially for bon tech users imho.
What problems do you find with it? It might be limited in features but I'd rather not have to maintain e.g. a WordPress server for more if I can avoid it.
As someone who really enjoys Netlify, I suspect that the CMS project is just under-staffed. I’ve been building out a fairly complex Gatsby project with it recently. While doing so, I spent a lot of time reviewing issues and finding workarounds for various problems on Github. As far as I can tell, there isn’t more than a couple people dedicated to working on it internally, and although a lot of people seem interested in the project, it doesn’t seem like very many of them are prepared to contribute. One need only briefly peruse the issues to find a half dozen (solid) issues with replies from the team lead along the lines of, “This is a good point. Willing to accept PRs” This is troubling, and it makes me wonder if Netlify’s choice to open source this was their way of acknowledging the need for the project without demonstrating an actual willingness to dedicate the resources writing a decent CMS actually requires. So they thought, “maybe if we throw it out there, people will help”
Politics aside, the largest problems I’ve had it with it revolve around the tension of organizing things in the CMS for the user vs configuring things for easy digestion in the SSG. If you set up the CMS how your, for example, non-tech savvy friend might expect it to look and then go build the front-end, you are almost certainty going to have a very bad time. This is because Netlify CMS’ widgets nest everything in deeply complex frontmatter by default, which makes sourcing and transforming it feel like a cumbersome chore. In my discussions with other people about it, more than one person has said, “So it sounds like the biggest benefit is just that it’s free. Thanks, but I’ll pass. My company pays for the base tier of X”
EDIT: I’d just like to point out that I think I would/will use it again. The next time around, I’ll probably use almost exclusively folder collections. This breaks out the markdown into oddly organized bits in the CMS, but it makes it much easier to consume and combine in the build step.
Politics aside, the largest problems I’ve had it with it revolve around the tension of organizing things in the CMS for the user vs configuring things for easy digestion in the SSG. If you set up the CMS how your, for example, non-tech savvy friend might expect it to look and then go build the front-end, you are almost certainty going to have a very bad time. This is because Netlify CMS’ widgets nest everything in deeply complex frontmatter by default, which makes sourcing and transforming it feel like a cumbersome chore. In my discussions with other people about it, more than one person has said, “So it sounds like the biggest benefit is just that it’s free. Thanks, but I’ll pass. My company pays for the base tier of X”
EDIT: I’d just like to point out that I think I would/will use it again. The next time around, I’ll probably use almost exclusively folder collections. This breaks out the markdown into oddly organized bits in the CMS, but it makes it much easier to consume and combine in the build step.
What kind of sites are you using it for? Does it work well for basic sites with e.g. some blog posts, some articles and FAQ questions? I curious at what point you think it starts to break down.
These are small brochure/marketing sites with complex configuration on each page and a handful of collections i.e. a blog or some services pages. Ironically, the blog posts are the easy part. After all, there are usually only a couple fields required for a blog post. Obvious examples would be an author field, a posting date, a title and the body. Out of the box Netlify CMS works very well with Gatsby for this. In the CMS config you just need to set up a "folder collection", which just means you define some fields and each time you make a new one or update it in the admin, a new markdown file is created or updated, respectively. Using just a couple plugins and a graphQL query, you can source them into your blog template and reference them as properties on an object. As for the body of the post, that's actually saved as the body of the markdown document itself. This is easily picked up and transformed to html that you can also request be added to your data object. You can then just use dangerouslySetInnerHTML to stick the html string right into your template (don't worry, remark.js is used by gatsby-transformer-remark[1] to sanitize it). Along the way, you'll have to deal with a couple of nested values like data.markdownRemark.title. Bam! You've got a working, re-useable blog post template. In the CMS admin, you can log in, click the blog collection on the left, then pound the "new blog" button and save them all day. The only other caveat I forgot to mention is that you have to do a bit of work in gatsby-node.js to programmatically create pages, but that only requires an hour tops with the docs and an example to reference to get it working really well.
Now, here's where the fun starts. Nowadays, most clients would like a level of configuration that goes a little bit further than a plain text box, right? That's really where things start to get sticky. Since you mentioned it, I'll use an FAQ as an example. With Netlify CMS + Gatsby, the best way to do this is probably to create a folder collection like I mentioned before with blog posts. That way, we can query all of them together and use them in any component we like. Here's where we hit a bit of a catch-22. What if I want to configure a heading and overview text for my FAQ? I can't add meta fields to collections themselves, so I have to put them somewhere else, presumably in a specific file in a file collection. This is a confusing experience for a non-tech savvy user, not to mention that it makes writing previews in the CMS more difficult. Now, some people might disagree with this approach altogether and opt to use a combination of list[2] and object[3] widgets in one file collection. That way, they can have their FAQ list right next to their FAQ "heading" and "subheading" fields. But if you do that, querying this information now becomes painful. You'll probably have to query by absolute file path to get the markdown node itself, then you'll have to de-structure content from one extra level deep in your data object, then once you've finally got your array, you'll have to map over it, then set the markdown body into the corresponding FAQ section. "Whatever, that's not that bad", you may be thinking, but here's the problem with that: nested markdown fields in frontmatter aren't transformed into HTML by gatsby-transformer-remark. You now have to manually go through and transform markdown to html yourself on a case-by-case basis in gatsby-node.js every time you want to use long-form text that requires formatting.
There are many other, smaller issues, but I think this is the most glaring. Granted, there are ways to work around this in Gatsby e.g. fragments or schema customization, but they all require intermediate to advanced knowledge of graphQL and Gatsby. Even as that knowledge becomes more commonplace, it's still just unnecessary extra labor. One could also argue that this is a problem with the netlify-cms source plugin or gatsby-transformer-remark, but I would suggest that regardless of how things are sourced, the presentation of content in the CMS itself is what's really broken here.
I hope this helps!
[0] https://remark.js.org [1] https://www.gatsbyjs.org/packages/gatsby-transformer-remark/ [2] https://www.netlifycms.org/docs/widgets/#list [3] https://www.netlifycms.org/docs/widgets/#object
Now, here's where the fun starts. Nowadays, most clients would like a level of configuration that goes a little bit further than a plain text box, right? That's really where things start to get sticky. Since you mentioned it, I'll use an FAQ as an example. With Netlify CMS + Gatsby, the best way to do this is probably to create a folder collection like I mentioned before with blog posts. That way, we can query all of them together and use them in any component we like. Here's where we hit a bit of a catch-22. What if I want to configure a heading and overview text for my FAQ? I can't add meta fields to collections themselves, so I have to put them somewhere else, presumably in a specific file in a file collection. This is a confusing experience for a non-tech savvy user, not to mention that it makes writing previews in the CMS more difficult. Now, some people might disagree with this approach altogether and opt to use a combination of list[2] and object[3] widgets in one file collection. That way, they can have their FAQ list right next to their FAQ "heading" and "subheading" fields. But if you do that, querying this information now becomes painful. You'll probably have to query by absolute file path to get the markdown node itself, then you'll have to de-structure content from one extra level deep in your data object, then once you've finally got your array, you'll have to map over it, then set the markdown body into the corresponding FAQ section. "Whatever, that's not that bad", you may be thinking, but here's the problem with that: nested markdown fields in frontmatter aren't transformed into HTML by gatsby-transformer-remark. You now have to manually go through and transform markdown to html yourself on a case-by-case basis in gatsby-node.js every time you want to use long-form text that requires formatting.
There are many other, smaller issues, but I think this is the most glaring. Granted, there are ways to work around this in Gatsby e.g. fragments or schema customization, but they all require intermediate to advanced knowledge of graphQL and Gatsby. Even as that knowledge becomes more commonplace, it's still just unnecessary extra labor. One could also argue that this is a problem with the netlify-cms source plugin or gatsby-transformer-remark, but I would suggest that regardless of how things are sourced, the presentation of content in the CMS itself is what's really broken here.
I hope this helps!
[0] https://remark.js.org [1] https://www.gatsbyjs.org/packages/gatsby-transformer-remark/ [2] https://www.netlifycms.org/docs/widgets/#list [3] https://www.netlifycms.org/docs/widgets/#object
I was trying to build a static site for a non-developer user that is essentially a catalog of products. Each "Product" has a list of variations, which has 2 fields: name and price. The relation widget in "Product" could only store name or price, not both, making it harder to build the select I wanted.
Also, I've run into trouble with simple things like setting an unique ID for each "Product" without typing it manually, like an incremental id. Datetime field with UNIX formater was the closest I found, but it was not foolproof enough.
Also, I've run into trouble with simple things like setting an unique ID for each "Product" without typing it manually, like an incremental id. Datetime field with UNIX formater was the closest I found, but it was not foolproof enough.
I'm curious. What would you recommend for more complex stuff?
For static sites Forestry.io is good. The editor experience is great and you can do clever stuff with front matter - including adding a component based layout builder.
https://forestry.io/blog/blocks-give-your-editors-the-power-...
https://forestry.io/blog/blocks-give-your-editors-the-power-...
Co-creator here. We just launched some starters if you want to kick the tires. https://forestry.io/starters/
The UI for these starters doesn't show off advanced stuff, but click on "Front Matter" and add complex fields/groups/blocks to get a feel for the UI.
The UI for these starters doesn't show off advanced stuff, but click on "Front Matter" and add complex fields/groups/blocks to get a feel for the UI.
Craft or Directus probably if I had more time.
My requirements at the time were:
- Can be integrated in a Vue static site generator
- Has a free plan (single user)
- Could be hosted for free at least during development
- Could have relations ("Post" can have a "Category" field that list its content as options)
- Has a admin UI that a non-developer could figure out
My requirements at the time were:
- Can be integrated in a Vue static site generator
- Has a free plan (single user)
- Could be hosted for free at least during development
- Could have relations ("Post" can have a "Category" field that list its content as options)
- Has a admin UI that a non-developer could figure out
Craft CMS
I bet with a bit of engineering it could be pretty flexible. You could have a folder containing modules and then folders in there for submodules. You could then get JS to pick out specific modules and submodules on specific pages.
There would be a lot involved and probably wouldn't be worth the effort when more dynamic solutions are already out there, but I think it would be doable.
There would be a lot involved and probably wouldn't be worth the effort when more dynamic solutions are already out there, but I think it would be doable.
Curious as well. Currently trying to integrate ut for a client with a Gatsby template. Has been very smooth sailing so far.
https://github.com/netlify/netlify-cms/issues/441#issuecomme...