Easy Content Publication with Hugo, Decap CMS and Cloudinary

Are you looking for a simple and scalable way to launch a website? Does it need optimized image and video delivery? How about a flexible content management system?

Look no further! ⁠Martin Jagodic⁠, who is a senior web developer for ⁠PM⁠, has created an excellent solution. It includes static site generator ⁠Hugo⁠, as well as ⁠Decap CMS⁠ for content authoring. And the project uses ⁠Cloudinary’s rich transformations for optimization and aesthetics too⁠.

Martin walks through his project in this Cloudinary DevJams live stream and episode. In it, he shows developers how to use it for their next website launch. He also showcases ⁠Maistra⁠, one of the largest hospitality groups in Europe, and how they use this solution to power their web properties.

Sam Brace: [00:00:00] Welcome to DevJams. This is where we talk with developers who are doing interesting, innovative, inspiring projects. Normally when it comes to delivering or managing images and videos inside of those projects. And because I work for Cloudinary and this episode and this overall show is produced by Cloudinary, they are probably using Cloudinary in those projects.

My name is Sam Brace. I am the Senior Director of Customer Education and Community at Cloudinary, and we are so excited to be bringing you this episode where we’re gonna be talking about content publishing using a few different pieces of technology, static site generators like Hugo, as well as a Decap content management system, formerly known as Netlify CMS.

And of course, Cloudinary to be able to make it easy for you to be able to easily publish your files and create really [00:01:00] exciting web presences with the overall mix that happened to be there. Thanks to the development work of Martin, who is a senior web developer at PM, which is a content marketing and creation company that is based out of Slovenia.

So great work that’s being done by him, as well as being used for some of their amazing clients worldwide. Joined with me for every single one of these episodes is Jen Brissman. She’s a Technical Curriculum Engineer over here at Cloudinary, and I’m so happy to have her here for this episode. Jen, welcome to the program.

Jen Brissman: Hey, how’s it going?

Sam Brace: Good. Good. And I am so happy to have you here, and I’m so happy to be talking to Martin here in a little bit. But tell me a little bit, why are you excited to bring Martin onto this program?

Jen Brissman: Yeah. So as far as static site generators go, we’ve had people on the show that have talked about Eleventy, but we’ve never had anybody talk about Hugo before.

And I’ve heard that it’s really easy to use even if you’re not familiar [00:02:00] with Go. So I’m excited to hopefully inspire our listeners to maybe give Hugo a try. So…

Sam Brace: You’re absolutely right. This is the first time we are talking about Hugo, which is great. And as you also said, we have talked about different types of statics site generators in the past when it comes to this.

And so it’s not necessarily a new topic. You have all the way from NextJS to Jekyll to Gatsby, all these different things that are out there when it comes to being able to create content. Now of course Hugo being another flavor, another choice that happens to be out there, which of course, Martin took.

So this is a case where if you have ever decided, maybe I should check out Hugo and what they’re doing, or as we’ve also mentioned, some of the things that are done with content management is we’re gonna see with Decap, this could be a really good way for you to explore another option that happens to be out there when it comes to web publication. Great point there Jen. Now, one thing I do want to mention is that when we are taking a look at our overall content, make sure that you are remembering that we are going to [00:03:00] be, here we go. We’re gonna be talking about Martin’s project, which he has available as a open repository on github.com. So if we are so inclined, make sure you’re checking out the show notes and we’ll make sure you have a full list of access to all of the things that we’re gonna be talking about today, including this overall project repository.

So everything we’re gonna be covering, it’s something that you can start accessing and start using right away within your own projects. So this is definitely something that we hope you start to use and fork it, clone it, download it, whatever you need to do from GitHub, but be able to start incorporating this into your overall projects for content publication, ease.

And we should also mention that all of our podcasts that we have done for the DevJams program, whether that’s a live stream, whether that’s a recorded podcast, those are all gonna be available at cloudinary.com/podcasts. And as you can see, we have years of content that happens to be available there for your learning purposes.

So make sure to check that [00:04:00] out. Once again, cloudinary.com/podcasts. And finally, before we bring in our friend Martin, I should mention that the Cloudinary community is the go-to place to having peer-to-peer conversations with other Cloudinary users. So if you hear about something on the podcast and you wanna explore it to see if other users are using it maybe in a slightly different way or with a different perspective than what we provide on this episode, make sure to be going to community.cloudinary.com where you can be able to have those conversations with users and notice that we also do have an associated Discord server.

If you do prefer to have conversations inside of Discord versus our overall form-based service. So with that said, let’s go ahead and bring on our friend Martin. So Martin, whoa, not Martin, welcome to the program.

Martin Jagodic: Hi, great to be here. Thanks for inviting me.

Sam Brace: So Martin, I talked a little bit about you mentioning [00:05:00] PM, of course, the agency that you work for. I mentioned that you’re a senior web developer, but let’s get a little bit more flavor. Tell us a little bit about you and the work that you do.

Martin Jagodic: I’m a senior web developer. We’re working with JAM Stack since 2020, I think when we introduced the Netlify, Hugo, and Netlify CMS to our stack. And later on Cloudinary, of course so I’m focused in that department.

Which is mostly frontend, but yeah. Backend is handled by all those services. I enjoy this stack and this work very much so that’s shortly about that, what I do.

Sam Brace: So you mentioned Hugo, which is one of the big stars of, in the overall project that we’re gonna be talking about here.

So talk to me a little bit more about Hugo, for those that aren’t familiar with it, maybe give us a little bit of detail of why you incorporate this as the static site generator and the products that you’re working on.

Martin Jagodic: Hugo [00:06:00] is very fast. I would dare to say the fastest static side generator. Like for one project, I guess largest project that we have builts around 10,000 pages.

And that happens in a matter of seconds. I would say some other generators would take minutes to build that. So that’s one thing. Another is it’s very feature rich. So we, it’s, it basically can help you with whatever problem you’re having with whatever solution you’re looking for. For us, for instance, very important is

having good content organization with large sites a good internationalization support which is great and works well with Decap [00:07:00] cms. What else? The templating engine is from Go it’s a little bit different than what some or maybe most frontend developers are familiar with when using nunjucks and stuff like that.

But once you get used to it, it’s really powerful. Yeah, I could go on. But that are, I guess the most my favorite things.

Sam Brace: You mentioned a lot of really important things too. So the fact that I know that we’ve seen, at least on the Cloudinary side, a growing community of Go developers. So it is to say that if you are familiarized with Go, it seems like Hugo might be a natural choice when you’re choosing a static site generator.

Is that correct?

Martin Jagodic: Actually you don’t have to know Go.

Sam Brace: Oh.

Martin Jagodic: I personally don’t. So it’s you just install it on your machine and you’re ready to go. All you have to know is the HTML and yeah. You have to [00:08:00] learn the templating engine. And you’re good to go. Yes.

Sam Brace: Oh, its even easier. And I like the use of “Go” there too.

Jen Brissman: Yeah. Good to “Go”.

Sam Brace: Excellent. That’s actually great to hear.

Martin Jagodic: Sorry. Another great thing with that is it comes with pre-processors and the JS bundler ES link. You don’t even need Webpack. You don’t need even package.json if you don’t wish to.

So yeah, that’s one of the, also one of the big reasons why we chose it, because dependencies can be a big hassle, and this way we remove a lot of that problems.

Jen Brissman: That’s awesome. Yeah, it seems like there’s a low barrier to entry. Like it would be easy to get going within a day or less and it seems like the Go is more under the hood and it’s not so you don’t really need to [00:09:00] use it. It’s really okay if you don’t work with, Go on a regular basis.

Martin Jagodic: Exactly. You will, you would need to know, Go only if you want to contribute to the project, which is open source, of course. And I must say very well maintained. I haven’t found many issues with it. So yeah big shout out to maintainers.

Jen Brissman: Yeah. Awesome. Yeah, this is like an advertisement for Hugo at this point. I’m just kidding. But, it just seems and I was doing some research too before episode. It just seems like the “go-to”. Now I’m thinking about all the ways that we’re using, go. Get it going, go to. But yeah it seems a really obvious choice if you’re interested in doing fast work, which most developers are. So let’s see. Let’s take a look at some of your code and see how this all works.

Martin Jagodic: Okay. So yeah, I would like to explain. [00:10:00] How Hugo, Decap CMS and Cloudinary could work together and how we do it with our projects. So first let me explain a little bit how this project is set up.

So this is how a Hugo Project look like. You would get an assets folder where we have our styles. The CSS is processed by Hugo. So we don’t need a webpack or something like that for it. We have the content folder where we will store our content in markdown files which have YAML.

Then we have layouts folder where we will define our html. So this is how the templating engine [00:11:00] syntax looks like with the curly braces. And then there’s the static folder where we usually puts that are not not handled at build time. And we will put our admin, so the cms

in this project, but usually this will be where we store our media assets. But in this case, we’ll handle that with Netlify sorry, Cloudinary. And yeah, there’s the hugo.toml where we will define the settings for this for this project.

Yeah, what we’re gonna do so we want to build a website just in this simple example that uses that has a homepage and a simple [00:12:00] blog with some posts, and we will connect the CMS where we can add those posts, and most importantly add an image to this post,

and then add transformations with Hugo to it. Yeah, let’s let’s first try, let’s first see how to add Decap CMS.

Sam Brace: Okay.

Martin Jagodic: Which is really simple. All you have to do is add two files, one of which is index html in your admin folder. By the way, this works with any static generator. You just have to put this into your static public or whatever the name is of the folder for your generator.

In this case, it’s static, and this is gonna serve as a placeholder for the cms. So this included via CDN, and [00:13:00] this is a React app. And the other file for the CMS is the config file in yml format. And this is where we, that this is where the all the magic happens. So we’re gonna define one, the most important collection is the blog.

It’s a folder collection. So for all posts in this collection it’s gonna have the same layout. And I’m also gonna define a file collection where each post with each file here, can have a different layout. In this case I want to have ability to edit the homepage and the blog list page. So that’s how I define that here.

And another thing, Decap [00:14:00] CMS. It has the default media library, but it’s really easy to add the Cloudinary as your media library. So all you have to do is add five lines of of code here. So we would just say the media library is Cloudinary and you need to have your cloud name and API key, and you’re good to go.

So if I bring up my Hugo server to, to launch the website and then run the CMS locally and see that. Okay, so now this is the website that you’re working on, and this is the cms. And so these are the two collections that I created. One is blog where I have my my pages.

And and the pages [00:15:00] list where I created option to edit homepage and the blog list. And since I connected the media library let me just refresh this. If I, right now, so this is the state. Before I commented it, I didn’t save it. So this is the, this would be the default media library.

And if I save this and refresh. I get my media library.

Sam Brace: That’s great.

Martin Jagodic: Yeah. That I’m connected to one, one thing to notice though, you have to be logged in the browser to this Cloudinary cloud that you’re using.

Jen Brissman: Wow.

Martin Jagodic: Okay.

Jen Brissman: So you just have like with those five lines of code that you just showed us that you just commented back in, you have a CMS that ships with Cloudinary, with this media library widget. That’s all you need.

Martin Jagodic: Exactly.

Jen Brissman: Awesome. Awesome.

Martin Jagodic: [00:16:00] Okay for now let’s let’s see what we have here. Or let’s create a new post. And that title I don’t know office I think is cause I know which image I’m gonna choose. Okay. There we go. So I’m just choosing this image of an office and I click insert.

And I have my image here, so if I say this or publish this, and now in my in my content in Hugo, I added the office.md where I said office and what you’re interested right now, here we have restored our Cloudinary URL of this asset. Let’s see how we can show this asset and most importantly, transform it [00:17:00] in a way that cloud Cloudinary will send us back the most efficient image.

So, that means we have to go look back at Hugo, the layout. So we have the base of layout, which is. Layout that all other layouts we use. So here we, we define the head and import our styles and scripts if we have them in this case, we need one script like Cloudinary that will that will get us the correct width of the image.

And then we have three layouts in this case. The index one is for homepage. And in the default folder, we have also list and single layouts, which are for the blog. So the list would [00:18:00] be the one on this. So where released are articles and the single would be if you click one of them then the single layout and let’s see how we can get this image and get the best possible transformation.

And let’s look at the single one. So it’s pretty simple. I print out the title, description, and then I created a partial, which in Hugo is like a component. So we can reuse this many times, and I’m reusing this on all layouts. I have images so I don’t have to worry about transforming them every time.

And in this case let’s see how it looks. So I’m gonna open the image partial, and this is where the magic happens [00:19:00] of transforming. So I want to be able to send in some basic parameters, which usual image tag in HTML would have. For instance, the source, width, height, style class or something else.

So in this case, the most important one is the source. And if I go back to the single, so this is what I’m sending in. Source is the parameter in image. Yeah. There we go. And I’m storing this into a variable that will, I will use later on. And I will also get Cloudinary base URL and Cloudinary common transformations that I stored in my hugo.toml because I want to make this stuff easy for myself and I will [00:20:00] apply the same transformations on most images that I store them in the global config.

The most common transformations that I found are best to use are the crop fill, which will take any dimensions that you specify usually width, and then and then apply crop it so fill the dimensions.

Sam Brace: Yeah. You got it. You got it.

Martin Jagodic: Okay. Then gravity auto. Since fill can change the aspect ratio.

We want to make it we want to ask Cloudinary Okay. Gravitate to the most apparent object in this image. Quality auto, self-explanatory, and dpr_auto. So this would be for instance, for thinner displays, which have I [00:21:00] think this is dot per pixel so basically how many pixels are there? How many dots are in a pixel?

So in this case would have two and normal display have value of one, and f_auto means auto format, which is very useful because some browsers don’t support more image formats and Cloudinary will return the most efficient one.

Sam Brace: And I agree with this yeah, I just wanna make sure it’s clear. This is great what you’ve done here. This is a very good set of transformations that would apply for most use cases. So I think that why having that as the default makes a ton of sense when you’re looking at optimization make things are cropped to the right aspect as well as to making sure that you’re focusing on the most interesting aspect of the image, which is what your gito is having here. So this is great. Hopefully people that are trying to figure out how to use Cloudinary [00:22:00] transformations there, they can use exactly what you’ve done Martin, and say, great, this is a good place to start with, and of course be a thousands of transformations, but this is good place.

Jen Brissman: Yeah.

Sam Brace: One thing I did wanna ask you before we jump away from here. Is you do have the breakpoints that are emphasized. So you have the 1920, the 1440, the 1200. How did you come up with that designation? How did you decide these are right breakpoints to be using for the various breakpoints you do have?

Martin Jagodic: I’m not sure. I’m actually copy pasting this for a few years now.

Sam Brace: And that it shows, it works. If you found something that works, then you can just keep repeating it. So once again, this is also a good test to say 1920, as we know, that’s probably the screen with for a lot of high resolution images and that you have, so all the way down to 566, we probably work really well for mobile purposes. So then you have a nice range. They happen to be there. So I think this is good. And I also agree a hundred percent what we have [00:23:00] here, not too many break points, but not too little. So it hits a sweet spot for most the viewports that you’re gonna be dealing with. So again, theres a lot of intelligence here.

Martin Jagodic: The steps around 200 and some of these values are from, I think, common css libraries, like bootstrap, stuff like that.

I think I found that, these are pretty common, and for maybe listeners who are not watching the screen right now. So we have break points defined from Xs so extra small, small, medium, large, extra large, and extra extra large in the span of around 200 pixels from 576 up to 1,920. And yeah. But these break points are not even used right now.

This suggesting because I [00:24:00] used like I wrote a small library for breakpoint, so for mixing and I’m just copy pasting this in all my projects. So…

Sam Brace: I love it.

Jen Brissman: And also for our listeners, I feel like it’s important to note that. Martin’s globally storing these variables. So like the URL cloud name and all the, all of these common transformations that we’re talking about, those are stored globally.

So it can be used so that like when he’s doing a check, if it passes the check, the URL is built again. And I think that’s probably where we’re get in, we’re gonna get into talking about now.

Martin Jagodic: Yes. Yeah, and also what you said previously, Sam, that these are some really common transformations and really, Cloudinary has tons and I would lo love to use all of them.

They’re really good. But I’m lazy and try to be efficient. And this is, I found like covers 80 or 90% of all [00:25:00] cases. So that’s why I’m storing this globally. I’m using this everywhere and if I see, if I’m like developing a component and I see, okay, now I need a special use case, then I use something special.

This would be like for most use cases.

Jen Brissman: A catchall. Yeah.

Martin Jagodic: Yeah. Let’s now look how we’re gonna apply those.

Sam Brace: Okay.

Martin Jagodic: In my image partial. I get the source, I get these global values, the base URL of Cloudinary Cloud, and the transformations that I talked about. And then first thing I wanna do is check, is this even image hosted on Cloudinary?

Because what if editor adds in, I don’t know, an image from GitHub or something else, somewhere from the internet? And then in that case, I can’t transform it, right? So I’m [00:26:00] gonna skip that if it’s not, but if it is, I’m gonna split the URL and I’m gonna get the relative asset URL. So just the last part or the slag, let’s call it the slag.

I’m also gonna get the width and the height if I send them in. I want to be able to, when I use this partial define sometimes these values, and if I do, I wanna also use it in transformations. And when I have all that, I’m just gonna combine this again together to get the URL with with the base.

The transformation and the slag which I stored here under the src variable. And then I’m just gonna use this in the image tag [00:27:00] cause we’re still in html. And one thing that’s important also here is that when you’re using Cloudinary, make sure that it’s data-src and use the class cld-responsive cause in the baseof, we’re using a library called cloudinary-core-shrinkwrap, which is gonna upon loading get the source and then get the width of the window and then get the… so change the request URL and then get back the correct width. I think rounding up to 100 pixels by default.

Or maybe a better solution to use this breakpoint that we defined. In that case, we’re gonna use less of our [00:28:00] transformation because those can get out of hand pretty quickly if we have a lot of images.

Sam Brace: Absolutely, and that’s thanks to that w_auto transformation, you’re also invoking there too, so that we’re all working together in conjunction.

So bringing in the right class, the right data source, being able to bring in the right JavaScript. But then because of w_auto, it’s saying use the JavaScript to be able to give you the break points that you’re specifying. So that’s also a great way where if you forgot to specify the break points, or maybe let’s say there’s some brand new fancy device and you’re like, what would the be break point for it? It can just automatically do that for you. So it’s an excellent approach.

Martin Jagodic: Yeah. And then, yeah, so if it’s not Cloudinary in this image, lets just bring in the original source that we have. Any class that is stored. I use loading lazy because it’s supported by most browsers by this point. [00:29:00] And then, add in just some other attribute that maybe we want to set. I, of course, advised to always use alt, but I’m also guilty of not using it all the time.

Sam Brace: Okay.

Jen Brissman: Well, it’s a best practice for sure, so it’s good you’re doing it. So, by the time that any of the images get to the website, they’re already optimized. And I guess I say image. We’re also talking about video here, right?

Martin Jagodic: Yeah, of course. This goes for video tool one thing to note is that in the per the base URL, we need a different URL.

Jen Brissman: Yeah.

Martin Jagodic: Because I’m storing this image here, but I could do Cloudinary video URL and put here a video. I think that works on the top of my head. And then I would just use this URL.

Sam Brace: Exactly.

Martin Jagodic: And I’m doing that also.

Sam Brace: And Martin, that was amazingly [00:30:00] fast, I’m very impressed.

Jen Brissman: Yeah.

Martin Jagodic: Now we can look how this looks actually in the browser. So this is our single layout, right? We printed out the title, description, and here we have the image with the partial. We’re sending the data source, which and then yeah, on the bottom we have this script, which loaded up and took the width of 600 pixels, which is probably the width of this browser.

Sam Brace: Yeah.

Martin Jagodic: So slightly less. It’s only gonna round it up to the next 100. And yeah, it’s gonna, it’s gonna transform this URL. The width, the height, c_fill, g_auto, q_auto, dpr 2.0 because I’m [00:31:00] on a 2.0 screen. And yeah, the format is auto. So in that case, I guess it would be, would probably be what could it be?

Sam Brace: Looks like it became a WebP, if I see that correctly.

Martin Jagodic: Yeah. Right now I don’t know where I would look at that, but. It I tested it really thoroughly and it always returns the best.

Sam Brace: It does. It does, and it’s, and to your point, like it a nice catchall frankly for optimization because WebP does seem to be supported by most browsers now, but it’s also where if it doesn’t see any improvement by changing it to WebP will keep it as it’s existing, which in that case would be jpeg. So it’s aware there’s no harm practically in setting f_auto on it. It only will add additional features and additional improvements to the overall loading processes of what [00:32:00] happens to be there. So I think it’s a good thing to have.

Martin Jagodic: Exactly. Oh yeah, so this was the post that we added. Yeah. So initially why there was a short leg, this image was transformed on the fly.

But if I refresh now, it.

Sam Brace: Yep. Thank goodness for caching and content delivery networks. So it makes it all very possible.

Jen Brissman: And so this code that we’re looking at just for the watchers and listeners is part of an app that Martin put together to demo what he’s doing on the Maistra case, which is how Sam and I first heard about Martin and the work that he’s doing at PM.

I thought it’d be cool to look at the Maistra website and see how fast everything loads and how beautiful it is and how important it is to have a beautiful website like this, and why we were like, oh, we have to talk to Martin. This stuff, this is awesome. And it’s so important. And really [00:33:00] part of the reason why Cloudinary is such an awesome product is because, people are deciding on, let’s just say what hotel to book based on beautiful images, beautiful video, and that’s exactly what’s happening here.

Martin Jagodic: Yeah. All these what I’m showing right now is also on this project. This is basically where we came up with this solution. So obviously it’s a website with a lot of images. It’s a hospitality group, so chain of hotels, resorts, and campsites in Croatia. And of course, it relies heavily on showing visually what they’re selling.

So that’s why we switched to Cloudinary because initially we were [00:34:00] using first. Git large file storage for these assets, for some of the, for some of the projects Netlify also provides some some of that with Netlify large file storage or Netlify large media. But yeah, we needed more.

They came up with this for this project, and now I’m using this approach. Through also other projects because I find it easy to use and get the best results for the least amount of work. Cause, I said,, I’m lazy.

Sam Brace: But honestly, lazy is a good thing when it comes to development cause it means you want things done quickly, you want things done the right way. But it’s also where you don’t wanna put a ton of work into it, having to have that happen because you have a lot of things you have to get done. So I think the lazy is not a bad thing by any means. We’ll talk about this way. But what I love about this is that what we’ve shown with this [00:35:00] project you’ve developed where it’s using Hugo, Decap, Cloudinary, it’s not just used for, let’s say, a personal project or a small project.

This is meant for a major company that is representing hotels and resorts and campsites throughout certain parts of the globe. And what I love about this example that we’re showing here is that to Jen’s original point, can this be done for video? This expresses that it absolutely can, because if I just go ahead and use our media inspector on this real fast, and I go ahead and separate this, you’ll see that you have this blank image here that’s used as a placeholder in case the video doesn’t load or for certain screen sizes, but it’s doing exactly what you expressed it to do.

Where if we take a look at the image here, And the browser bar you’re seeing that its bringing forth the biggest breakpoint you have here, the XXL, the W 1920. It’s also using our c_fill, our g_auto, our q_auto, our dpr_auto, and our f_auto altogether to make sure it loads perfectly. And then similarly, [00:36:00] if we go ahead and take a look at the media details here, it’s also doing the exact same transformations for the MP4 that you have in the background.

All that amazing B-roll and footage of the countryside. That Maistra has gone and created. You wanna make sure you’re expressing that as best as possible. So I love the fact that we took this project and were able to show, not only did you take a lot of time in developing it, but it can be used for real life projects too, just like we’re showing here with the Maistra site.

Jen Brissman: Yeah, and I gotta say, like just having this B-roll and these awesome images and video going as we’re talking right now, I’m like, “Oh, I really wanna go to Croatia”. Like it really is important to have beautiful visuals to help people be sold on where it is they’re going or what it is they’re buying.

I understand why you guys changed to Cloudinary when you were scaling up and having this big use case and this important company. And I’m glad to hear that you use it on other projects as well. I know we’re talking about just this one, but glad to hear that when you found something [00:37:00] that worked, you decided to keep using it and keep going with it.

Maybe because you’re lazy or maybe just because you found a great solution that works. And why change it if it works? So let’s talk a little bit about Decap CMS and what happened with your journey there with PM and how it got to be that you, you’re working with them or taking it over.

Martin Jagodic: Yeah, that, that’s an interesting story. In this case, Maistra, we also use Netlify CMS, which is I would say not intended for such large websites. But when we research CMSs we didn’t find anything else that we would say, okay, this is obviously better because Netlify, or now Decap CMS had a lot of functionalities that are just not present in some of those and yeah, we were used [00:38:00] to it. We said, okay, let’s go with it. And yeah I am I could say we tested the limitations of the CMS, but I wouldn’t say we have reached the limits or maybe we reached the limits, but it works in this stack.

Yeah, we were really sad to see that I think last Spring Netlify kind of stopped maintaining it because they turned their focus elsewhere and yeah, we were kinda we were hoping that someone else would take up and nobody did. So we were like, okay, we’re using this CMS. We like it a lot.

We contributed a little bit to it. And we had good relations with Netlify and we said, “Hey, can we maybe take over the maintenance if you’re not [00:39:00] interested anymore”? And yeah, after some talks they said, okay, let’s do it. Yeah. And then in February we re named it to Decap CMS.

And now we’re we’re working on our first release, which will contain a lot of updates, but not functionality wise. Just we need to bring up some more dependencies. Some tests are failing for no reason, so we want to make sure that we that we bring the first release that’s gonna be maintainable for the long run.

Sam Brace: This is incredible and it’s great to see the story that’s behind this. And what I also love about this is that even though yes, your team is now taking a major stake into what the Netlify CMS what its become, calling it Decap and moving forward with it. It’s also [00:40:00] still completely an open source CMS. So it’s where people can be contributing to it.

It’s something that’s readily available. For anybody to start using in their projects today. So it’s great to see that the Netlify CMS found a great home and that you guys are fostering it really well. So this is great to see. And then of course, how it’s applicable for the various projects we’ve shown with what you’ve done here with Hugo and Cloudinary and Decap. And then also see the applicability with the Maistra site. So this is great stuff.

Martin Jagodic: Yeah. I have to say the community is great. I think it’s the best start or the highest start. How is it called? Git based CMS on the JAMStack website where there’s a list of of headless CMSs.

And yeah, we’re really happy to have this, but we are also aware of the responsibility we have to the community. [00:41:00] And also the community is great. A lot of contributors. Were happy to see that this is going to continue. I know a lot of them are maybe getting nervous because it’s been now a few months since we took it over and it’s still as it was.

But yeah, we’re working on this as much as we can. The issue is a bit more complicated than we thought, but yeah, we’re gonna get there. We’re committed.

Sam Brace: Very exciting. Very exciting.

Jen Brissman: Yeah. Anyone listening, just keep an eye out for their first release. And also, Martin, congratulations because, I think that’s just a testament to, you’ll never know if you don’t ask.

And the fact that you just asked, Hey, can we take this over? We had the bandwidth and we care to do it well, and we know what we feel like we owe to the community and we’re gonna do a good job. And the fact that they just said, yeah, here you go. [00:42:00] That’s really cool. That’s awesome.

Sam Brace: So Martin, before we break away from the project, is there any final thoughts you have about anything that you say let’s say that you have a developer that’s hearing this conversation, we’re like, okay, great. I know that there’s an open repository, there’s ways that I can easily implement the areas to this. What are some recommendations, any first steps, any best practices that you’ve had with working with this overall stack when it comes to content publishing?

Martin Jagodic: Yeah, I would say. Find the problem that you have and then search for the solution and try not to go with the, maybe at the most mainstream solution.

Because today there’s a lot of, I think JavaScript frameworks in particular, and JavaScript based generators in particular. Generating a lot of traction, but that’s not necessarily what you need. So, for a website like this [00:43:00] that doesn’t use like loads of JavaScript. It does. It does actually, there’s a lot of Vue behind this.

But for the core purpose of like having pages maybe look for a solution that actually builds HTML pages and that’s what Hugo does. And also Git based CMS is something to consider with like small to medium sized projects. Because your content is stored in your Git repository and you can easily modify it.

You can bring in a CMS that’s free to use open source. It’s really easy to install. And I think this setup has easy entry. So there’s not a lot of traction to use it. So yeah, maybe this [00:44:00] demo repository that I made is gonna help someone. But yeah, if anybody has some questions, they can also add me on Discord and ask questions there, or if they’re interested in contributing to Decap.

They can join our Decap discord server, or just, write on GitHub issues or discussions.

Sam Brace: When you, you answered the question I was gonna ask you. I was gonna say how do people get ahold of you, Martin? If you have additional questions, but you did it very well. Where I can see here on your GitHub main profile, you can see here that you have links directly to Decap.

You have areas to the overall projects you’re working on. You have links to your LinkedIn, your overall. So it seems like if you, if people find you on GitHub and they point to the project that we are showing in today’s episode, we have plenty of ways to contact you and I’m really appreciating that you’re willing to talk to developers if they have additional questions too.

So that’s wonderful. [00:45:00]

Jen Brissman: Yeah. And just if anyone doesn’t know Martin’s discord handle, it’s his first and last name. No numbers or characters or anything like that. First and last name.

Sam Brace: Perfect. Perfect. Perfect. Martin, thank you again for being here. This is, this was wonderful and I can’t wait to see what you guys are up to at decap and stay in touch.

Martin Jagodic: Yeah, it’s been a pleasure. And keep up the good work with the podcast.

Sam Brace: Wonderful.

Martin Jagodic: I didn’t know it before, but now I’m a regular listener.

Jen Brissman: Oh, good. So glad.

Sam Brace: Thank you, Martin. So, Jen.

Jen Brissman: Yeah.

Sam Brace: I wanna ask you, what’s your big takeaway from here? What do you, what stood out from our conversation here with Martin?

Jen Brissman: Yeah. A lot of things I think, obviously we talked a lot about Hugo and I was joking that it sounds like an advertisement for Hugo, but it’s just really encouraging because, there are a lot of static site generators out there, besides [00:46:00] Eleventy, you mentioned a few, and there’s Astro, there’s Pelican, and there, especially because I think a lot of developers go with what they know, and as we talked about on the web, on the episode it’s okay to go with what, it’s not lazy.

It’s what works. But I think I would hear, oh, Hugo, that’s with Go. I don’t know Golang. I’ve never worked with that and I, I wouldn’t gravitate toward using it and trying it out. So I think a big takeaway is that Hugo doesn’t, you don’t need to work with Go previously and there might be other static site generators out there that you might think there is a barrier to entry that there actually isn’t.

So I thought that was a cool takeaway for me.

Sam Brace: No, absolutely. And you are right about that for sure. And I think one thing that was also really great to see is just how easy it was to be able to publish. I think.

Jen Brissman: Yeah.

Sam Brace: It shows that what Netlify did develop with the Netlify CMS, and what it’s becoming when Decap CMS now. Showing how easy it is to be able to publish through overall Git, is awesome and he makes a really excellent point [00:47:00] that the incorporation of just being able to render HTML, Markdown in that case, being able to easily create that type of content.

It does work very well for, as he says, small to mid side projects. So it is something where I think this is a really nice package that he has gone and developed that makes it very easy for any developer when they’re trying to say we have a way to create a content authoring format for overall teams to be able to do.

Jen Brissman: Yeah.

Sam Brace: This is a great mix. So I was really proud to see what Martin and the team have pulled off, and of course they’re using Cloudinary perfectly, so I’m excited to see that too.

Jen Brissman: Oh yeah. I mean, he really found all the best transformations and just really great use case in general.

And I also just really when we were talking about Decap and I know I mentioned it before, but really the initiative to reach out and just ask, “Hey can we take this over?” And when we were talking to Martin earlier, he said even when he was learning to code when he [00:48:00] decided to go into it, it was, he was building a website for his band.

And just decided okay, this is something I wanna do. And I don’t know, I just think that a lot of developers take initiative and and play around and figure things out and we didn’t even know when we asked Martin that he doesn’t work with Go regularly. He just works with Hugo and just it’s inspiring to hear that and just any developers listening, just ask questions, poke around. It’ll pay off.

Sam Brace: Yep. I definitely agree with that and I can’t emphasize enough, take the chance to go check out the repo that Martin has gone and developed online for his GitHub repository. Of course, this will be linked in the show links, but of course, it’s also his main name and has links to many awesome repositories as well as many of the links on how to contact him.

On top of all of this, of course, if you liked this episode, and hopefully you did, then go and check out more of ’em. They’re gonna be always at cloudinary.com/podcasts. You can see that we have fantastic content from [00:49:00] developers for over two years now being published in this space. So plenty of episodes to check back into and learn from the best and brightest in the overall development field or those that were just emerging into the field trying to understand how to properly work with images and videos in their products. And lastly, but not indicating any type of priority, it is to also say that our Cloudinary community is a great place to continue the conversations that took place in today’s episode. So if you have questions about certain static site generators, some of the transformations that were covered, Anything between working with images or videos.

There was a lot of things that we did cover here today. Make sure you’re checking that out at our Cloudinary community to talk with users like you. That’s gonna be at community.cloudinary.com. So on behalf of everybody at Cloudinary, Jen and I included, thank you for participating, being a part of this DevJams episode of this here today, where we will continue talking with developers who are doing [00:50:00] interesting, innovative, inspiring things with images, videos in their projects.

Take care, and we hope to see you at the next one.