Sounds to me like what you want is to build your own theme. Much faster then having to piece things together IMO.
I would start by building your own theme by maybe re-purposing an existing minimalist theme. Or start from scratch with a lightweight CSS framework that provides a simple grid and built it up from there with what elements you need. Maybe use other themes you like as a guide and implement your favorite elements.
This is what is so great about Wordpress and the Genesis layer by StudioPress. You can Very quickly and easily click a few things to add another sidebar box, or a slider, or and additional footer layer.
I’ve started to build something… in regard of a UI Builder with “block components”… and I am wondering about the frontend development of a CMS Admin though.
What do you guys think would be great for the “backend of it”. I know there is a lot of “PHP” folks out there, so its easier for them to start using that instead of nodejs per example ?
I’ve came across https://vault-ui.io/ , built in Node w/ Vue.JS looks intereting in term of Frontend development to start with that as project.
Anyone have an advice on what framework to use for a basic CMS ?
Toma, you got me! This is what a I want…
Not a theme, but a few FEATURES, acting like a theme.
But features in hugo, are not packaged in a stand-alone way, so much manual editing, copy/paste etc… to weave it all together,
The directtory, Layouts, hints at it, but it does not contain a collection of “layout”'s ie, 5 things I want my site to have… it is a jumbled mess of stuff, all mixed together…
I want one of these, one of those, and some of that…
I gotcha, I just don’t know how one would go about loading in different smaller features into their site in this stage of Hugo other than if a theme carried all of these components that could be configured.
It’s kind of encouraging me a bit to build some sort of theme framework like that.
Yes, my problem exactly! I want each “feature” packaged, separately, sub-themes, ala Git, dump each into Layouts… But things are not done this way in hugo!
Well factored components, with no dependencies! no external stuff needed. Put all needed stuff into Git! and nothing more!
No theme, just a PIECE OF A THEME!
But these theme components would have to be pretty plain and bare style-wise to be plugged in with no dependencies, no?
If someone created a navbar with Bootstrap and another person created a slider with Flexbox Grid and some one else created a header section using their own CSS concoction… I’m not sure it could be put together so easily.
Ok, then skip easy, let us aim for EASIER! plus your own CSS…
and js is evil, so, skip that… No dependencies!
This thread is getting crazy, at least with respect to the number of exclamation points If you want to make something ultra flexible, my thoughts are as follows:
- Create a library of flexible partials you treat like “components” that users can easily clone into a project or a theme.
- Give said components classes (and other attributes) according to a very popular frontend framework (likely bootstrap or Foundation)
FTR, I’m not a fan of any of the above. At all. The idea of “no dependencies,” or more accurately, “No dependencies!”, while asking for the equivalent of a drag and drop GUI is a little silly, IMNSHO. I can assure you that companies like WIX, etc have a clusterf*^%-dumpster-fire of a dependency tree.
A while back I posted a loosely-related idea about supporting feature/behavior tests to kickstart a distributed/community effort to codify features. It probably isn’t necessary for your idea, but it could be helpful. I just wanted to cross-link this in case anyone does attempt to work towards this.
I’m working on something and hopefully people will like it. I’ll post to this thread / discuss and can’t wait for feedback, probably around 2 weeks
Yes. In the end, you still have to do the work.
BAH! exclamation… Kids these days…
I do not need flexible. Markdown is great, I like it. It has rigid conventions, it is small and light, all good. The gui stuff was not my idea, I can live without that. Markdown, with FEATURES. Not themes, but individual styles that can be easily chosen from somewhere and installed, then easily used with a few keys in markdown would be super good!
Currently, I must pick a “theme”. But these are kinda big… I like some parts of this one, and that one has XYZ, but how to extract the bits I like? Then there is a big mess of files, and … but I just want that ONE part… How can I get that one part, and use it? the requires some archeology, and factoring, and pain.
I think the pain is caused by the way things are packaged. The idea of themes is good, but I want to pick PARTS of themes. But those are not packaged. they are bundled, and tied to many other things…
GUI or not, fine. give me a pile of them, alphabetically, with descriptions. I can Git the ones I want…
Then have Hugo weave it all together.
Sub-Themes, or Features, not sure what to call this…
Last, thanks for your thoughts! Idea #1 of yours, seems to fit what I am thinking.
#2, not a fan of JS. I prefer type-safe languages, and think JS is an abomination
Abathur also seems to have eerily similar thoughts.
And RDwatters, can you expand on that a bit? why are you not a fan of #1 in particular?
THANKS SO MUCH for your more informed than I insight… Much appreciated! (exclamation again…)
You don’t have to pick a theme. If you build it from scratch, you build the same sorts of files but at the top of the site, instead of under the theme’s folder.
First hugo site I did a couple years ago, I used a theme to see what it was about, then overrode everything in the theme little by little, until finally, no theme files at all.
Yeh, my first tests used a theme, then decided just to build something from scratch myself using a Framework.
@RobertCvn I think that what you are asking for could be divided into two parts:
- Blocks to build your page structure;
- Reusable and specific blocks such as a slideshow, an image gallery, a post list, a contact form, a menu, or the current page’s table of content.
For the first part, I believe this would be well suited inside a GUI. But I assume that if you already know HTML/CSS a little, you can manage this relatively easily with libraries like Bootstrap. Now, maybe there is a lack in the current/upcoming documentation to lead the end user to build an entire theme from scratch and we can enhance.
For the second part, I have made some work, which you can find here for the presentation, and here for my implementation of that widget mechanism. I actually use it for one of my projects. I will release it soon.
I have personally developed the following widgets, which I use:
- blog: a blog of all last articles from a specific taxonomy
- chapo: the article heading as a Chapô
- debug: the current context
- figure: a figure
- last-posts: lists the n last posts
- menu: displays a menu
- search: simple form to search the site with Google
- section-pages: lists the pages that are children of this page
- table-of-contents: display a table of content of the current page
- text: an arbitrary text. Can be plain HTML.
These widgets are placed in a directory and called inside the config file. Then you can easily rearrange them to fit your needs.
If ever you are interested in using widgets, let me know!
Lebarde, that is well written and clear. And it fits my thoughts. Good job.
Very interested in trying this.
Hello @RobertCvn, I will update my code to the latest Hugo version and write an article somewhere to get a good quick start guide on how to use widgets. I will tell you about this.
I see two ways to get where I want to go:
- start with nothing, and build it up by adding Widgets, love the name, the last consulting company I owned was called Industrial Mega-Widgets, inc, so…
- Start with something bigger, yet configurable. I love the way this guy thinks, too. https://github.com/kakawait/hugo-tranquilpeak-theme/blob/master/docs/user.md#tranquilpeak-configuration
He gives a full featured theme, but allows one to disable what is not wanted.
Either way gets us to the same place. Start small and build up, or start big, and chip away at it.
Option 2 has the advantage of an entire build pipeline, documented, with newish tech to automate stuff. That was all educational to me, as I had been struggling with those issues. But he does not use the shiniest CSS, or the correct JS base packages