Open brunopbarbosa opened 3 years ago
These issues may be related to what you want:
These issues may be related to what you want:
265 (How get content from other repos ?)
736 (Fech data from an external app)
Hi, thanks! Although these are more related to getting the content, which I am already doing successfully.
My issue is reloading it into the frontend without having to rebuild the app.
Hi @brunopbarbosa
To understand, you want to refresh the Api content when files changes in production?
So you are using Nuxt with the server target?
Hi @Atinux!
Yes, that's my case exactly.
It's planned to implement this since we want to open live edit on Nuxt websites soon, have to be a bit patient :)
Oh so at the moment there is no way of doing that, right? At least I can stop racking my brain trying to figure out how to do it 😅 I will keep an eye on it, thanks for letting me know 👍
Still no update on this? I am getting data from external service, add json file to my /content/ folder and then nothing? Are there any work-arounds?
Is Content not supposed to work with SSR?
Hey there :)
Multi-source will be supported natively from @nuxt/content v2.
I think the behavior you are talking about (updating content when remote source changed) should be supported by default, but I'll keep this open as I think it's not yet the case.
We are close of having multi-source ready to handle multiple kind of sources (remote / fs), but I think filesystem ones should be handled by default.
My only question is knowing if the content cache will get populated with these new datas at production time, but I'm leaving this answer to @farnabaz.
Thanks for opening this issue, expect updates soon.
Here is an example from gatsby https://www.gatsbyjs.com/docs/refreshing-content/
Hi @Tahul,
I'm very interested in hot reloading the data when the source is updated, in my case it's the changes on the filesystem of the '/content/*.json' folder using the @nuxt-content module to recover these dates.
To date in env=dev mode, the hot reloading of data on the page works very well, when will the same behavior occur in env=prod mode?
Have you any news ?
How impatient :D
Hey there :)
Multi-source will be supported natively from @nuxt/content v2.
I think the behavior you are talking about (updating content when remote source changed) should be supported by default, but I'll keep this open as I think it's not yet the case.
We are close of having multi-source ready to handle multiple kind of sources (remote / fs), but I think filesystem ones should be handled by default.
My only question is knowing if the content cache will get populated with these new datas at production time, but I'm leaving this answer to @farnabaz.
Thanks for opening this issue, expect updates soon.
Checking since it's been 7 months and Content V2 is already out - are there any updates on this?
Hello, any progress on this issue so far ? It's been more than two years.
Unfortunately, I structured my project so that its backend is based on the /content/ folder, whose files can be changed very regularly by users (a bit like wordpress). When creating the production build, the /content/ folder no longer exists. Also, I do not want to produce a new build each time the user saves or create a file.
Nuxt studio (https://nuxt.studio/docs/studio/live-preview#how-does-it-work), which is linked at the top of the nuxt-content website, created by nuxt-labs, now supports a 'live-preview' in production mode like asked for in this thread.
I would honestly not hold your breath for this getting to nuxt-content itself at this point but fingers crossed
Though you might just be able to use nuxt-studio yourself instead so hopefully that'll help :)
I have the same requirement as you. My markdown files are all saved in GitHub, and I hope that nuxt-content can automatically update after I update the markdown files in GitHub.
I have the same requirement as you. My markdown files are all saved in GitHub, and I hope that nuxt-content can automatically update after I update the markdown files in GitHub.
By using a pipeline, you can trigger a (static) build of your nuxt project each time you upload a file in Github.
However, if your project runs on a nuxt server and you want to update your prod in realtime, without having to trigger a build, I suggest using nuxt MDC (https://github.com/nuxt-modules/mdc) instead of nuxt content.
I have the same requirement as you. My markdown files are all saved in GitHub, and I hope that nuxt-content can automatically update after I update the markdown files in GitHub.
By using a pipeline, you can trigger a (static) build of your nuxt project each time you upload a file in Github.
However, if your project runs on a nuxt server and you want to update your prod in realtime, without having to trigger a build, I suggest using nuxt MDC (https://github.com/nuxt-modules/mdc) instead of nuxt content.
As far as i'm aware, MDC is used with nuxt content too - how do you suggest to use MDC instead of Nuxt Content for live content updating?
Afaik I would store articles in my own database, and use mdc to convert markdown to vue components. So you wouldn't be using Nuxt content at all, as if you were building your own CMS.
OK, thanks, that does seem like an idea worth investigating!
@farnabaz , just for clarification, is there any movement on this or should we assumed it won't happen as it's a feature available on Nuxt Studio? No harm done if it's the case, would just like to know if it's something we can expect to have or not.
Hello All,
I have been going through the documentation for a few weeks without any success.
We have a scenario where the 'content' folder in production is updated separately from the build (it's fed from a different repo) so that people maintaining the markdown docs don't have access to the build files.
Trouble is that whenever that content is updated, the pods need to be restarted in order for new files / updated files to be available to the frontend.
Is there any way to trigger the reload of the content folder automatically, either by reading changes on the filesystem or as a workaround, as a manual trigger?
Thanks in advance, Bruno