Update to Bootstrap 4 - Githubissues

eht16 commented 5 years ago

Pull requests are welcome. Otherwise this is not a priority.

codebrainz commented 5 years ago

@eht16 I was looking at maybe taking this on, but I couldn't figure out how to do it without having two copies of Bootstrap/jQuery. It appears Bootstrap 3 is embedded in Mezzanine, so I don't know, would I also have to patch that to support BS4 as well?

eht16 commented 5 years ago

Yes, currently we use the embedded version of Bootstrap 3 from Mezzanine. To get Bootstrap 4, simply copy the necessary files (minified CSS and JS and maybe fonts/glyphs) into geany/static/(css|js) and adjust the base HTML template accordingly. This is easier than patching Mezzanine and we make the frontend part of the site less dependent on Mezzanine.

codebrainz commented 5 years ago

Ah, ok. So Mezzanine doesn't affect the main website. Is it like a GUI to edit the markdown in? (Their website seems to assume you already know what it is).

Another thing that's confusing me is, say I wanted to use a bunch of cards/panels/buttons/etc from Bootstrap, do I literally embed all those divs/anchors/buttons/etc. inside the Markdown? I'm pretty sure it would work, but it seems to defeat the purpose of using Markdown if it's basically just a bunch of HTML anyway. Is that right?

eht16 commented 5 years ago

Mezzanine is a CMS and so yes, after logging into the admin area, among other things, you can edit page contents and add new pages (even though our page contents are synced from the page_contents directory in the repo; will document this later).

Do no touch any of the markdown to include HTML, please. In the geany/templates folder you find the HTML templates which are used to render the basic site and the markdown contents are rendered dynamically into the main block (see geany/templates/skel.html). Only the homepage itself(geany/templates/home.html) is plain HTML without any Markdown, so there you can use fancy Bootstrap cards and so on.

codebrainz commented 5 years ago

Mezzanine is a CMS

Seeing as it's not well maintained (hypothetical vulnerability in old Django it uses, outdated Bootstrap) and especially that all users of the backend of the site are developers, I wonder if it's even worth having a CMS? For me, it seems like it would be easier to plop a Markdown file in page_contents, add it to a site map or whatever and then commit to Git.

Do no touch any of the markdown to include HTML, please.

So how would one make the individual pages look less like they're rendered from a text file (ie. more "designed" like the home page)? To give a concrete example, I was thinking of putting each of the mailing lists in cards in a grid, each with a little search form (to send a search query to the archives), a "subscribe" button, and maybe and icon representing each list in the card.

P.S. Sorry for being OT on this Issue, I didn't want to keep spamming the issue tracker with more question Issues.

eht16 commented 5 years ago

Mezzanine is a CMS

Seeing as it's not well maintained (hypothetical vulnerability in old Django it uses, outdated Bootstrap) and especially that all users of the backend of the site are developers, I wonder if it's even worth having a CMS? For me, it seems like it would be easier to plop a Markdown file in page_contents, add it to a site map or whatever and then commit to Git.

Then we have to implement much more ourselves like the menu, the dynamically created sitemap (/sitemap.xml) and more. At some point, I checked available static site generators but I didn't find a single one which was usable. So I went the way with Mezzanine which is an awesome and simple CMS, IMO. Furthermore, I consider the currently outdated state as tolerable and I assume development will continue at some point in the future.

Do no touch any of the markdown to include HTML, please.

So how would one make the individual pages look less like they're rendered from a text file (ie. more "designed" like the home page)? To give a concrete example, I was thinking of putting each of the mailing lists in cards in a grid, each with a little search form (to send a search query to the archives), a "subscribe" button, and maybe and icon representing each list in the card.

This is not possible currently, except putting HTML into the Markdown text. Given the fact that there was not much interest in the website in the last years and that we like to focus more on Geany itself (obviously and what is good) I thought to keep maintaing the website content as easy as possible and Markdown is something each of us can write easily. So it seemed meaningful to me to have as much as possible of the page contents as Markdown.

After all, if we want to change the backend of the website and/or replace it by something static or generated, let's do.

codebrainz commented 5 years ago

Given the fact that there was not much interest in the website in the last years

Speaking for myself, this is because it used to be a wiki and now it's a real website.

and Markdown is something each of us can write easily.

Agree, but also so is HTML, which gives much more control over layout/structure/appearance.

After all, if we want to change the backend of the website and/or replace it by something static or generated, let's do.

I'd be interested to working on this, but unfortunately except for using Flask a few times, I don't know much about using Python for making websites. Most of my experience is in JS/Node with stuff like NPM, Express, Webpack, Vue, etc. and I don't know whether other developers are comfortable with this kind of tech stack/tooling, or if it's even supported by our web host for the backend stuff.

eht16 commented 5 years ago

After all, if we want to change the backend of the website and/or replace it by something static or generated, let's do.

I'd be interested to working on this, but unfortunately except for using Flask a few times, I don't know much about using Python for making websites. Most of my experience is in JS/Node with stuff like NPM, Express, Webpack, Vue, etc. and I don't know whether other developers are comfortable with this kind of tech stack/tooling, or if it's even supported by our web host for the backend stuff.

For me, it's the other way round. I'm a little familiar with Angular but just because I had to for work. I personally prefer good ol' Python because I like it and so being much more familiar with it. Anyway, I think the technology should not hinder people from contributing, so if you like to make a new site with your stack why not. The only requirement I would like to consider is that the site should work mostly with JavaScript enabled in the browser. Obviously this is quite hard when using Vue or the like for the frontend but I know there are still people outside who don't want or cannot use JS in the browser.

codebrainz commented 5 years ago

I personally prefer good ol' Python because I like it and so being much more familiar with it.

Same here, I've been using it for almost everything I need scripting language for since about 15 years or so, just not for web stuff (with the exception of a few backends using Flask).

The only requirement I would like to consider is that the site should work mostly with JavaScript enabled in the browser.

I assume you mean without JavaScript, if so I agree.

Obviously this is quite hard when using Vue or the like for the frontend

IMO, using Vue or other frontend frameworks isn't really appropriate for a site like Geany anyway since it's not really a "SPA", just a document/info site that is almost entirely static.

I started working on the frontend a bit. Basically it goes like this:

Scan "pages" directory recursively looking for *.md files.
Using front-matter to get meta data for the page (ex. title, description, keywords, output file, etc.).
Convert the markdown body to HTML using markdown-it along with highlight.js for any fenced code blocks.
For each of the pages, process it into a full HTML document using nujucks and a few templates/partials.
Using Webpack, the resulting pages, images, SCSS/CSS, JS, etc. are bundled into a production-ready, tiny, optimized, front-end site.

Basically it just pushes all of the work to "compile-time" to build the site before deploying, without any backend (so far at least, some stuff will likely need a bit of backend like nightly builds, IRC stuff, etc). Updating the site contents involves just adding/editing a markdown file in the "pages" directory and then running the build command to regenerate the site.

I wrote the compiler code in JS/Node because NPM has all of the needed tooling readily available and to start hacking on the site is as simple as running npm install in the source directory. To this point there's about 100 lines of JS for the compiler and about 50 lines of code for a dev server/file-monitoring/live-browser-reloading/etc for development. So far the dependencies (from package.json) look like this:

{
  "dependencies": {
    "highlight.js": "^9.15.10",
    "normalize.css": "^8.0.1"
  },
  "devDependencies": {
    "@babel/core": "^7.6.0",
    "@babel/preset-env": "^7.6.0",
    "babel-loader": "^8.0.6",
    "browser-sync": "^2.26.7",
    "chokidar": "^3.0.2",
    "css-loader": "^3.2.0",
    "file-loader": "^4.2.0",
    "front-matter": "^3.0.2",
    "glob": "^7.1.4",
    "html-loader": "^0.5.5",
    "html-webpack-plugin": "^3.2.0",
    "markdown-it": "^9.1.0",
    "mini-css-extract-plugin": "^0.8.0",
    "node-sass": "^4.12.0",
    "nodemon": "^1.19.2",
    "nunjucks": "^3.2.0",
    "postcss-loader": "^3.0.0",
    "postcss-preset-env": "^6.7.0",
    "pretty": "^2.0.0",
    "sass-loader": "^8.0.0",
    "webpack": "^4.39.3",
    "webpack-cli": "^3.3.8"
  }

So basically the actual site itself only depends on highlight.js package (only for the CSS theme, the rest is done at compile-time) and normalize.css (to make SCSS/CSS easier, since it doesn't use any CSS frameworks like Bootstrap). All of the other devDependencies are for the compiler, Webpack and to make development of the site easier.

What do you think?

eht16 commented 5 years ago

The only requirement I would like to consider is that the site should work mostly with JavaScript enabled in the browser.

I assume you mean without JavaScript, if so I agree.

Yes, thanks for correcting me :).

I wrote the compiler code in JS/Node because NPM has all of the needed tooling readily available and to start hacking on the site is as simple as running npm install in the source directory. To this point there's about 100 lines of JS for the compiler and about 50 lines of code for a dev server/file-monitoring/live-browser-reloading/etc for development. So far the dependencies (from package.json) look like this:

[...] What do you think?

Yeah, sounds reasonable. For the non-static content:

nightly builds happen only once per day (even if we ever change it, the nightly build job could trigger a rebuild of the site anyway),
the IRC users list probably can be dropped altogether (as requested elsewhere already), after all it's not important or useful in any way
the I18N stats can be generated once per day or once per hour or something like this And maybe then there isn't much left for a backend at all. And even if, this could be a small Django backend.

geany / www.geany.org

Update to Bootstrap 4 #9