Closed tomkralidis closed 5 years ago
+1 to move on a more featured tool. Another option could be gatsby.js
Maybe related to this discussion. We have the jinja templates that generate the templates, but current JS development methodologies are more and more based on modules (nodejs et al) and JS code is build and deploy. Also it seems that module import in browser is still lacking. Could we over come this ?? Using the proposed to the content managers suggested above
Another option: https://gridsome.org/ ( to please the vue.js boys, me and @justb4, @pvgenuchten )
these tools look fantastic (was worried about seo, but seems covered), but doesn't it add too much complexity to things that should be simple... usefull aspects of any framework:
Nice to have
I wonder could we use pygeoapi as a backend for the page content with itself a git backend
/collections/cms/items/index
/collections/cms/items?content=*installation*
No strong opinion, other then that it must be easy for anyone to update content while still allowing more dynamic stuff like a blog and possibly social media/gitter excerpts. There's I think a zillion solutions to maintain bare content in GitHub and render the result in one way or another. Easiest and most stable is to render the site on gh-pages
(as now), a Travis
build can do any rendering to flat HTML and push to gh-pages
. The content does not have to be maintained in gh-pages
then.
Another option is: we have already a VM running for demo.pygeoapi.io
remember? This is maintained in a separate GH: https://github.com/geopython/demo.pygeoapi.io but could be easily extended to support the pygeoapi.io
home, for example replacing the somewhat ugly/barren landing page: https://demo.pygeoapi.io. This is a Flask Docker Image that is automatically rebuild and deployed on any content push but could be remolded to whatever solution in CMS-like we take (Flask is overkill here). I would rather have one website where this demo-homepage is a sub-page in pygeoapi.io
.
All in all I still think rendering on gh-pages
is the most reliable.
More notes/requirements:
Also like no strong opinion as long it is easy to use and more or less on the scope of our programming language (no JAVA or ruby)
On Fri, 27 Sep 2019, 20:20 Tom Kralidis, notifications@github.com wrote:
More notes/requirements:
- needs to be able to manage content in both Markdown and HTML
- setup is for website only. Documentation remains in pygeoapi rep with workflow to RTD
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/geopython/pygeoapi/issues/233?email_source=notifications&email_token=AAJXMCEJ4LWKSWBQX4RBUUDQLZFILA5CNFSM4IVVFPEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ZW5JI#issuecomment-536047269, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJXMCERZ5D6JU55NBVZEWDQLZFILANCNFSM4IVVFPEA .
First pass implementation now available for review/comment:
Notes:
Good to see this! Some suggestions:
Menu:
Stale link in https://geopython.github.io/pygeoapi.io/community/psc/ for PSC list.
Thanks @justb4. Updates pushed. Notes:
FYI update to theming for review and comment: https://geopython.github.io/pygeoapi.io/
site_url
Jinja2 var).@justb4 CSS localized. The other issues should resolve once deployed live.
Currently the pygeoapi.io website is a pure HTML implementation (in our
gh-pages
branch). To manage website content easier I'd like to move to Jekyll, MkDocs, Pelican, or Nikola (other options?).What do folks think? I think this is a good time to port things given the website is very small. Note also that the website is different than the docs per se.