I’ve been playing with Redwood for the past few days and have to say that Iit.
Here is my HOW TO on connecting Netlify CMS and RedwoodJS. They have docs, but it’s not clear with Redwood’s file structure where to put everything.
In web/public make a new file called ‘admin’.
Add two files to web/public/admin → 'config.yml and index.html
in index.html add the following HTML:
<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
<title>Content Manager</title>
</head>
<body>
<!-- Include the script that builds the page and powers Netlify CMS -->
<script src="https://unpkg.com/netlify-cms@^2.0.0/dist/netlify-cms.js"></script>
</body>
</html>
In your terminal (make sure you are in the RedwoodJS root folder):
yarn workspace web add netlify-cms --save
Configure your config.yml file in the web/public/admin folder:
backend:
name: git-gateway
branch: master # Branch to update (optional; defaults to master)
publish_mode: editorial_workflow
media_folder: "web/src/assets/uploads" # Media files will be stored in the repo under web/src/assets/uploads
public_folder: "uploads" # The src attribute for uploaded media will begin with /uploads
collections:
- name: "post"
label: "Blog Post"
folder: "content/posts"
create: true
slug: "{{slug}}"
fields:
// etc.
Warning
Make sure that your media_folder points to where your assets or media live. I added an additional uploads folder. I named my public_folder ‘uploads’
Add to github if you haven’t already
Deploy on Netlify
Go into your control panel and and under Identity scroll to the bottom and enable Git Gateway:
Hi @Jamie! This is fantastic – huge thank you for taking the time to post. I’m also going to pass this along to our friends at Netlify to see if they’ll help spread the word. 'Cause synergy, right?
I it.
^^ ok, we need to figure out a way to make this a thing. Just great🚀
I wonder if there’s potential here to just create a NetlifyCMS DB driver that looks at the specified db file much like a SQLite instance. That way, we really don’t need to use slugs or manage the markdown. We talk to the data like we would any other DS in Redwood.
Yeah, that would be rad. I feel like the first headless CMS service that finds a way to plug 'n play with Prisma is going to win this game. If I could setup content types on Contentful, then introspect with Prisma, then generate… Well, it would be
Is this a hint on what’s to come? RedwoodJS is probably the piece of underlying software that is best suited to help build that dream headless CMS.
I was vetting a bunch of headless CMS solutions for a client and in the end, I was a bit unhappy with all of them and was tempted to write the CMS experience in a separate app using RedwoodJS-- since the CMS would just be a another client that talks to the same DB/schema as the actual app but w/ a separate set of permissions.
The two main blockers for me in doing that were:
Time
The current inflexibility of RedwoodJS folder structure (I wanted to make a monorepo with all the RedwoodJS /web apps in it sharing the same /api).
There were options such as Git Submodules to share the contents of /api prime. But I just figured this kind of stuff is in the works and given the project cadence, I would not be surprised if the contributors got to this a month or two from now.
I imagine that /api sharing abstraction will eventually turn into the SDK that you distribute to tenants if you were to build this thing in RedwoodJS.
^^ not that I am aware of. But I’m wishing + planting seeds
The current inflexibility of RedwoodJS folder structure (I wanted to make a monorepo with all the RedwoodJS /web apps in it sharing the same /api).
^^ Hmm, did you know that a given Redwood Project (i.e. App) can be either a Web side or API side, and doesn’t even require a DB? So one thing you could do is create a project that’s only the API. Then spin it up with yarn rw dev api (note other CLI commands would work similarly like yarn rw build api. Then you could create additional projects that are only the Web side. You’d lose the mono-repo, but gain a singular API. There’d be things to figure out about deployment, but I think it is all possible as is. fwiw
Oh man, there’s something here. This feels like it could open up a whole new world for Redwood.
Contentful now supports GraphQL out of the box even on free plans.
^^ very cool!
If RW could:
store the Contentful API content delivery key in an env
translate or hand-off queries to another gql server
take gql schema and back into a sdl and make services
^^ I didn’t look at Contentful GQL, but would we even need a Redwood API… wouldn’t this make it possible to handle on the front-end using Apollo Client? Any React app could do this, then. I guess I’m just wondering if they are. I still like the concept of having the SDL + Services, but maybe that’s not the next step.
Lastly, have you tried any other CMS option, e.g. Sanity or Prismic? I’ve only dabbled in Contentful but I’m seeing the others pop up quite a bit.
Wanted to add what I’ve been experiencing w/ my recent spikes through various headless CMS + RedwoodJS. I’ve been vetting Contentful vs Prismic vs Sanity.
In all three spikes, I just make the headless CMS a service in the /api side much like Prisma DB. I chose not to call the client directly in /web because I like SDL + Services too and that abstraction will eventually allow me to distribute the Headless CMS service wrapper to other targets/clients.
Sanity: I didn’t want to serve my own headless CMS but seems to be most flexible
Prismic: IMO better GraphQL API if you’re gonna use it directly
Contentful: Not so bad if you use the REST API and stitch it into RedwoodJS
IMO both Prismic and Contentful kind of miss the mark in their GraphQL implementations. I think it’s because there is possibly less consideration right now for easy stitching as opposed to just straight consumption. There is a bit of complexity weaving their schema into Redwood. It just seems easier in general to use their REST API and stitch that into Redwood GraphQL instead. But that’s just my opinion and I might just need to learn more about GraphQL.
It’s best to have a monorepo for this because you can have unified tests for your deployments much more easily. If the schema changes in /api happen to break anything in other packages/targets, you’d know right away. The tests will be synchronous to the dependency changes which is actually ideal for not shooting yourself in the foot.
For the package that contains the main /api, it’s probably best to build a UI around it as a control plane (so it would just be a full rw project). This repo/package would act much like a headless CMS.
If I go the multi-repo route for now, I think the best option to share /api would be submodules. I’d also need to trigger tests in all repos against the main /api change.
But the current workspace config gets in the way. It would be amazing, if I was using multiple redwoodjs /web projects in the monorepo and was able to select which project to generate in be like yarn rw user-facing-client g scaffold Resource.
Right now, RedwoodJS’s value for me, by far are the generators and GraphQL/Prisma abstractions. We have to build so little by hand because of those and it just works.
Woah! Nice work and thank you for passing along the lessons learned. Especially the evaluations of the CMS providers.
I ideally wanted something like this:
^^ someday we’ll have full support for the concept of Redwood Sides, which means each Yarn Workspace will be a standalone unit that works with CLI and as a monorepo. There’s a POC of a React Native Side, for example. But the tools/config to make Sides possible should allow for what you’re trying to do here.
Wait, whaaatttt? I want to see this thing in action.
Also, this really feels like we’re all noodling on something that would be very helpful to a lot of people, including these CMS providers. Gonna on it. And not sure the Prisma approach is correct, but I might get their eyes on this as well for some reactions.
import CMS from 'netlify-cms-app'
// Initialize the CMS object
CMS.init()
// Now the registry is available via the CMS object.
CMS.registerPreviewTemplate('my-template', MyTemplate)
This thread has been dormant for a while but where did you put this code snippet within the Redwood codebase?
Looks like NetlifyCMS is getting some love now that Netlify acquired GatsbyJS. The name changed and there seems to be a new team dedicated to sprucing the CMS up and making it a major contender in the CMS space… Kinda cool
it.
Netlify CMS and RedwoodJS. They have docs, but it’s not clear with Redwood’s file structure where to put everything.
Warning 
currently is 
from 
Ha! That one is legend. Good find. Oh, the good ol’ days.
