Closed bep closed 9 years ago
Lets agree on "what is really needed for the first version". Deployment is easy, so focus on the big picture, get it in a working state, then we can add pagination, filters etc. in the next version.
I agree that we should focus our work on the core problems that you listed above.
README.md
, because most themes (and repos in general) use this format as far as I've seen it on Github.description
, author
, logo
, slogan
, banner
etc. -- I have hard time seeing any problems in these areas.symbolic link
i meant a link from /post > /blog or whatever, so the content would be duplicated. But it is a stupid idea.hub
(a command line tool from GitHub). My list is out of date. That was something I did to get the very basics in line, getting all the theme.toml files in line etc. And many themes has arrived since.If we both can have a look at a couple of the themes that doesn't work nicely in demo mode, and think a little bit about what would be needed to change, then we can discuss a game plan -- create a list and split the work.
Re. post vs blog, it doesn't seem to bee an issue, if my search is correct:
find . -name "index.html" | grep layouts | xargs grep 'where'
./angels-ladder/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Type" "post") }}
./angels-ladder/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Type" "post") }}
./beg/layouts/index.html: {{ range first 10 (where .Data.Pages "Type" "post") }}
./bootie-docs/layouts/index.html:{{ range where .Site.Pages "Title" "_index" }}
./casper/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Section" "post") }}
./greyshade/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Type" "post") }}
./hurock/layouts/index.html: {{ range first 5 (where .Site.Pages "Section" "links") }}
./hurock/layouts/index.html: {{ range first 10 (where .Site.Pages "Section" "posts") }}
./hyde-x/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Type" "post") }}
./next/layouts/index.html:{{ $paginator := .Paginate (where .Data.Pages "Type" "post") .Site.Params.perPage }}
./persona/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Type" "post") }}
./pixyll/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Type" "post") }}
./shiori/layouts/index.html: <a href="{{ .Site.BaseURL }}/post" class="btn btn-primary btn-block btn-lg">View All {{ len (where .Site.Pages "Section" "post") }} Articles →</a>
./slim/layouts/index.html: {{ $paginator := .Paginate (where .Data.Pages "Type" "post") }} {{ range $paginator.Pages }}
./startbootstrap-clean-blog/layouts/index.html: {{ range first 4 (where .Data.Pages "Type" "post") }}
./twentyfourteen/layouts/index.html: {{ range first 10 (where .Data.Pages "Section" "post") }}
Would it be possible to let generateThemeSite.sh
output error messages during the generation of the site? This would it make much easier to locate possible issues that could be added to the list.
Furthermore, what would be a good tool to manage this list? Should we use simple Github repository or somethink like your table made in Google Docs?
And what themes should be added to the blacklist? Some have only trivial problems like missing screenshots and others are simply incompatible with a current version of Hugo that we use to generate the theme gallery.
./generateThemeSite.sh http://localhost:1313 && hugo server -s hugoThemeSite/themeSite
is the level of error reports you will ever get.
A Google spreadsheet is good for this, lets use this one:
https://docs.google.com/spreadsheets/d/1QNdevhMM9M0ba5Y00sJ6GIbtyR4svb37hc2JsHCVgiU/edit?usp=sharing
Just add new columns as needed. But be pragmatic when checking a theme, think "good enough".
Blacklist = breaking change, generateThemeSite.sh fails or the theme cannot be rendered / demo shown. It is only temporary. Attach a PR reference near the blacklist. But this is mostly relevant when we go live. While in progress it is OK with some breaking sites.
I can start with adding some script support for custom params for the themes -- then we can split the themes between us. Many of them is, hopefully, just to check that it rendered OK.
Sounds like a plan?
This sounds good. Hopefully we will finish it soon. But some pull requests will take time.
I'm not conviced there will be many pull requests, but time will show ...
I notice some of your themes have some complex data dependencies (agency, artists) that doesn't fit well into this scheme ...
Do you mean the files that need to be copied from examples
?
Yes, I think we need to make some standard
about that one, too.
Most themes follow a simple post + page section layout that we can use the exampleSite for. Then there is agency, artists ... where we need to pick up the example from the theme itself.
Your setup is good, but I would name it exampleSite (to be in line with the other exampleSite).
So the logic will be something like:
exampleSite
folder, use that for the demo.exampleSite
Sounds good?
Maybe we should create a list with requirements named CONTRIBUTING.md
that explains, what require to be standard
. If those requirements are defined I'll begin to adapt them to my themes.
There is already a standard in the README.md. in hugoThemes. We will append to that one as needed.
But this can get complex ... and thinking about it, I'm not too keen on letting the theme authors control content on the hugoThemeSite. Let me sleep on that.
This could be indeed a problem. But do you know a workaround for themes that require custom data in order to work (like my themes)?
Will think about it.
One could argue that the theme authors already got some control of the content through the README.md
@spf13 what do you think about this? Short story: Some themes are so complex that they provide their own exampleSite. Is this OK or bad in the sense that it gives them control over the content on hugoThemeSite?
I think it's ok.. but maybe a v2 thing. Reality is that some themes will need their own content to convey their purpose.
I also think we should take the approach of trusting our theme creators and remove them if they don't play nice.
OK, then we have a good game plan.
@digitalcraftsman I will update the README.md on hugoThemes with this new information. Can you do the renaming of "examples" to "exampleSite" in your themes where applicable? Then in v1 we can at least make sure that your themes look good, then others with similar needs can use them as guides.
@digitalcraftsman I have added some initial config support in the script ++. More work to do here (there are conflicts that must be fixed). But now Casper looks good.
To fail fast in the script, look at
https://github.com/spf13/hugoThemeSiteScript/blob/master/generateThemeSite.sh#L10
@digitalcraftsman see https://github.com/spf13/hugoThemesSite (the README) for info about how to add theme specific config. We should aim for the least amount of files possible here -- if it gets too complex, then a theme should create its own exampleSite.
@digitalcraftsman and note: the ERRORs about URL and sageHTML etc: I have already created PRs for all of these. It just take some time to get them merged.
@spf13 We could also add an option to report and flag themes by the visitors in the case of an abuse.
I renamed the folders in my themes to exampleSite
.
@spf13 I would even encourage maintainers to add some (dummy) content to the exampleSite folder. Otherwise is a demo of a blog, where you can't see a rendered post, not really a demo.
Work in progress site preview:
Maybe some border/divider of some sort would be good on the front page?
This is looking really good. Thanks @bep !
@bep Something like this would be ok? http://i.imgur.com/LqE444b.png
@dplesca that would be perfect!
I've just pushed a change with that border.
@dplesca there is a border, but it doesn't look like the screenshot you posted:
@bep what are you using, it looks ok to me, I'm on Chrome on Windows.
@dplesca I'm currently on OSX (love, hate). It looks good in Safari -- kind of ugly in Firefox:
It looks atrocious in firefox, let me see what I can do.
edit: @bep just pushed another tiny change
@dplesca yea, now it looks great in both Safari and Firefox (OSX). Thanks!
@spf13 One of the themes that would need to be updated is your port of Hyde. There are already PRs made (some from me) to make the theme compatible with newer Hugo versions. It doesn't seem that you maintain this repo actively because some commits are a bit older. Therefore @bep or I as collaborators could merge those PRs and make other changes (if necessary).
The same applies to the Herring Cove theme where @bep made a PR.
Those were the first two themes for Hugo largely to demonstrate how to make themes. As I don't use either, I'd be happy to have others help maintain them. Adding you both now..
I think it looks good enough for a release now:
There are open pull requests, but nothing blocking. If we can get some simple deployment in place, we can fix these in the upcoming releases.
/cc @digitalcraftsman @spf13
@bep That's true. Most PRs are only for trivial fixes. Since the todo list above seems to be done we should be ready to deploy. Is there already something planned, when the theme gallery will be running under themes.gohugo.io?
@spf13 would have to help us get this over the finish line. I guess there will be regular updates to this site, to a "one click deployment" kind of thing would be needed. I don't think it can be connected to a Git commit, either, because there are three GitHub repos in play ... But I might be wrong.
@spf13 any clue on when this could happen? It's no rush, but good to have some sense of time.
It would be interesting to know who this project will progress.
@digitalcraftsman ditto. @spf13 will get to it, eventually; the site is ready and I guess we will see a boost in Hugo activity once released.
Closing this. It is finished, but may be outdated the distant day in the future the site gets online.
In stead of creating a lot of small tasks in separate issues, lets try to agree on a more compact list here.
readme.md
vsREADME.md
etc. -- get the themes to be uniform. Much easier in the long run./cc @digitalcraftsman