Hi all. GitHub issue #5074 is by far the most commented issue, and beneath that is the predecessor issue. Both of these related building HUGO from a data source. I would like to financially sponsor this feature. My business needs this feature. I have skilled developers on my team, but they are busy on other matters, and likely not as expert as the exalted leaders of this project. I think the best way I can help is to contribute funds for the development of this feature to encourage its development. This feature has been moved from milestone to milestone for some time now.
Does this kind of bounty fit within the terms of reference, governance, and scope of HUGO and how feature development is handled? I plead ignorance here. I do not know if it is gauche to offer a sponsorship.
In such a case, if it were proper to do so how could it be arranged to ensure that funded features could be expedited and accepted? Could any guarantees be made?
What might be an appropriate sponsorship amount to achieve the feature?
Iām a big fan of the way Regis proposed to prebuild pages from a datasource in his recent blog series, and plan to work this way in the meantime. But surely this is a stopgap method.
Git backed content is elegant and wonderful. It provides endless benefits. However, with Forestry CMS sunsetting, we need a way to effectively mount CMS data. There are many CMS out there, but not many are GIT backed. Allowing HUGO to be coupled with headless data will undoubtedly increase adoption and growth. Grateful for feedback on this idea. Am I alone in believing itās a critically important feature for HUGO? Is it reasonable to discuss feature sponsorship?
Welcome to the Hugoverse. I was sitting with the popcorn and wait what would come of your request.
There is no product management for Hugo like you would expect compared to projects like Gatsby, 11ty et alii, so your idea of basically sponsoring a feature will not work. You can sponsor the developer, but that will not lead to YOUR favourite feature being implemented. Only features that are deemed usable or required by the developers will make it to a release and many features that might enhance the usability of Gohugo for many stay open as much discussed issues in the Github repo because nobody in the inerts of the software are interested in implementing or using up their free time to implement it.
Another point is āOpen Source Developer Fatiqueā which I am not sure is a proper term but I hope you get my gist.
There is also no big company sponsoring the developers like in other projects. There are plenty of old issues that sound really good, but probably wonāt make it ever to light of the day before the apocalypse hits.
Your options are twofold:
Look around for another system that implements what you need. I would say you might succeed. But maybe donāt go this route because Hugo can do nearly anything with a little bit of spit and sand to prop it up and loosing all the advantages just to get your content-from-data-dream realised might be a waste.
Find someone who would listen to your requirements and āhacksā their way through Hugoās capabilities. In my opinion nearly anything is possible if you take a step back and use tools and scripts before and after Hugo does its stuff.
Your specific issue ācontent from data filesāā¦ I would like to implement some reverse psychology :] here and insist, that this will never see the light of the day inside of Hugo. Never. Probably.
On the other side, itās not that hard to write a little Bash script, or Node script, that takes a ādatasourceā and creates content files from there. Isnāt that what services like Strapi already offer? Maybe the best solution to this specific issue (content from datafiles) is something that can and should be done outside of GoHugo.
In terms of organizing, there are several quite good proposals and methods within the GitHub issue. I referenced Regisā prebuild method which is quite good. I am using this method, and it works just fine.
It is true there are viable methods which are external to HUGO. I feel that this is both a good and fair response, and yet still something which feels hollow.
My favourite CMS at the moment is Directus. It is a perfect fit for HUGO. I want to use a CMS like Directus. If you havenāt seen it, go have a look. A brilliant CMS. It serves a very clean API. I want HUGO to build content files from that API as part of a simple build step. I want to define my datasource in a YAML/TOML file (methods are well documented on GitHub) and then on build, HUGO fetches the content and builds the pages. It would be very satisfying if this could happen within a Hugo command.
In terms of sparking something, I would be open to discussing providing, or raising money. I suppose I could go to Upwork and find a Go developer to work with. Obviously the big concern would be to move forwards with a solution which was not endorsed by bep or others who would ultimately be in charge of accepting the solution. It seems that this discourse place is where one should really have the discussion. I know how much an hour and a day and a month of development can cost. I donāt know how much time a feature like API integrations would take though. Even if itās a lot, I halfway wonder if we crowdfunded it, whether it could be done. Surely there are five other people who would chip in.
