Manage Media Assets in a Headless WordPress Site using the Cloudinary WordPress Plugin
There are two approaches to dealing with an extensive media library when using a Headless WordPress solution. The first is that during the build step, the assets are queried and downloaded to a static folder that's served using a CDN. The second approach is that you use a third-party solution like Cloudinary to host your images.
In this lesson, we will use the Cloudinary WordPress plugin to migrate all images from our existing posts to Cloudinary. This approach provides the benefit of managing the assets directly on the WordPress interface and using Cloudinary to serve them.
Next steps for you to try:
- Add additional data via WordPress Plugins
- Build a frontend for your data with Gatsby or Next.js
Instructor: [0:00] When you're considering the media library for a large site that's been published like this one, we have images. We might have videos. We might have other thing, [inaudible] . If this wasn't both content, then we'd have our titles or captions or descriptions. They're all tags. Tittering how to deal with this kind of content, a headless environment, there are two main approaches.
[0:19] The first is, during our build step, we would just query these images, and we download them into the static folder, so we're going to serve our clients. Since they're being served statically, they're probably going to be on a CDN already. An alternative is to use a third party service like Cloudinary. Let's see how we do that.
[0:34] I'm going to add new plugin and search for Cloudinary. Install it. Activate it. We have this new setting here Cloudinary. We need to connect, so I'm going to click on Connect Cloudinary. Since you use Cloudinary, you need to get your API key.
[0:46] I'm going to do that. I'm going to go to my Cloudinary dashboard, this thing here. I'm going to copy my clipboard. I'm going to paste it in there. Let's go back to my dashboard. What I'm going to do is I'm going to go to Sync Media. I'm going to auto-sync, and I'm going to use a specific folder to store my Headless WordPress assets.
[1:05] Then, I'm going to initially just sync all of my content. Now, if I go into my Headless WordPress folder, then all the images that I'm using in my WordPress site are available here on my Cloudinary instance.
[1:18] If I look at this post, testing our blocks, we can see that this image inspect it. We'll see that it's currently being called from Cloudinary rather than from WordPress. If I look at that post on the back end, we can see that the source of the image here is a series of Cloudinary source sets.
[1:37] This way, working headlessly, I can still use a third-party CDN, or during my build step, I can suck down the images and serve them from the same place I'm serving the rest of my static file.
Hey Fab! Thanks for the question.
I think this really depends on your frontend solution. Both the Gatsby plugin (gatsby-plugin-wordpress) and the NextJS starters that I've seen have capability to detect and transform these links. Handling it on the clientside means that if you have custom routing logic you can apply it there.
In the headless data layer, I suggest leaving the links as they are rendered. That way they will match what your client layer is expecting.
Hope that helps!
Thank you for your response. Till now, I haven't used any react based static site generators like Gastby or Next. I like Nuxt (vue.js) or simply Eleventy. You suggest to leave those links as they are and to modify them as needed in the front-end code through parsing the url, correct ? But what do you think of having relative links in wordpress (using for example https://fr.wordpress.org/plugins/make-paths-relative/) ? Is it a good idea or is it just more pbls for later ?
You'll know your use-case better than me but to me it would feel like you are making things potentially problematic.
A link in WP to /my-great-post might actually be to /posts/my-great-post on the front end. I feel like transforming all the links in the presentation layer, using a middleware in Nuxt or similar, would make more sense - especially as you handling routing for your application here.
But, as always, your mileage may vary :)
Ok thank you.
It'd be nice to have how to fetch menus :)
Great shout! I'll add it to a list of enhancements. Thanks!
Great course !Would be interesting to see how you managed internal links (for example a wordpress post that makes a link to another post). Within wordpress, that is correct, but how yo you make the link work on a detached front-end that will be on another domain ?