Steeph's Web Site

Go To Navigation
Show/Hide Navigation

Entries tagged 'cat:SBWG'

SBWG 0.12.8

I've recently published a new version of SBWG, my web site generating bash script. The time that I'm able to allocate to working on SBWG fluctuated a lot in the last year and when I do work on it, I often just feel like doing one type of thing. So, when that is starting a new feature, all the other types of tasks can take on a pile that takes months to resolve. But eventually I managed to test and stabilise the features that I've added and changed, edited the README file and tried out the new version with real web sites. Well, testing could be more professionel, but it's okay for a hobby project, I think.

It's been well over a year since I wrote a blog entry about what's new in SBWG. This entry goes through the main new things since version 0.11.1.

A big new thing, at least from the view of the author/me, is that certain options where that makes sense now support multiple arguments. For example if you've edited three entries and want to re-generate just those three, you don't have to run the script three times but rather define the entries like this: sbwg -e ENTRYNAME_1 ENTRYNAME_2 ENTRYNAME_3. The same goes for pages, tagpages, entry attachments and galleries. This doesn't just make it easier and quicker to generate just some changed pieces of content. It also allows the usage of shell globbing (like *, ? and […]) and brace expansion ({…}). For example you can now regenerate all entries that are stored in one subdirectory or all entries whose names start with a vertain string of characters. Another practicle use case is to add external entries and/or to the site that are not stored in the respective directories in the web site's input directory. Using option -E/-P on the contents of an entire directory creates HTML files in the web site's output directory that look like any other of the web site's pages, but without integrating them in the structure of categories and other tags.

There is now a way to create a custom menu in the navigation bar without writing any code in the settings file of a web site. By using the new 'menu:' tag type in the header of a page or entry source file, the page or entry will get added to the menu. This allows for a list of pages you want to link to from the site's navbar, or a nested tree of interesting blog entries. The tag can be used similarly to the 'topic:' tag with the main difference that it doesn't add the entry or page to a list of entries with that topic, but rather directly in the navigation bar. In the default style set that is a drop down menu like the list of categories, authors, languages and topics. But it is just an unordered list, so it can be styled like any web site menu.

The default style set has changed a bit over the year. It basically looks the same but it's a bit cleaner now and is split into more file more logically. It will become even cleaner in the future though. It now also makes use of the new possibility to present the list of categories in the navigation bar in the form of a tag cloud. Audio attachments are better to look at now, especially when there are several audio files attached to an entry. Image attachments are can now be previewed in a modal without loading the (large) original file and without leaving the page. This almost gallery-like display is about as far as I'd like to go without starting to use JavaScript in the default styleset. Some parts of a web site generated with SBWG are now collapsible/expandable. The parts with this new feature are: entry attachments, entire entries on tagpages, entire entries on their own pages, the custom menu, the category list, topic list, language list and author list in the navbar and the entire navbar. By default all of those things are extanded upon page lead and collapsible by clicking/tapping on their titles. But you can add a setting in your settings file for each of those types of things to be collapsed upon page load and expandable by cliking/tapping on them.

Another thing that behaves similarly is content warnings. Hiding the content of an entry, or parts of it, could always be done by hand, e.g. by adding a <details> and <summary> tag pair to the body of the entry. But it is now easily possible by adding a warn: tag to the header of an entry. For example adding warn:This entry contains spoilers. to an entry header results in the entire content being hidden behind a collapsed <details> tag. Initially visible is only the summary "This entry contains spoilers. (click to open)". The default style set makes this warning line very visible but dunking it into a strong red. If the entry has attachments, those will be collapsed and their title marked in red, too. Both the entry content and its attachments will be collapsed by default if the entry has a warn: tag, independently of what your settings for those parts is in the settins file.

New special tagpages: If there are entries that have a language tag and others don't have one, 'nolang.html' will be created that lists all entries that don't have a language tags. Similarly, if at least one entry on the blog has an author tag, but other entries don't, 'noauthor.html' is created and linked to from the navigation bar.

RSS feeds are now created for every tagpage. That means visitors can now subscribe to individual topics or categories or authors or languages. It also means a longer generation time for a complete regeneration process. But permanent caching reduces that to an acceptable amount. Other feed formats are still not created because I reckon that writing those will be particularly fun and satisfying. So I want to get to that when more of the less interesting todo bullet points are done.

Many small changes make web sites with different structures than mine cleaner. Empty directories or menu entries aren't created. There are new hooks for the various different new functions and loops which a user might want to hook into. Various changes around the default language being used for RSS feeds and HTML documents in order to abide by the standards. Many bugs around all sorts of things have been fixed. The logging option works pretty reliable now. It may still be completely removed one day because it's a large chunk in the code, makes the script slower when enabled and can now be entirely replaced by redirecting output from the script on the shell level. The new flags 'hideinfeeds', 'noshow', 'nogal', 'noatts' and 'noheader' control how and where entries are presented and which parts are visible. See the README for descriptions of those flags.

Reading these update blog posts shouldn't be seen as a replacement for reading the CHANGELOG file. If you have a SBWG web site and consider updating SBWG, at least check the CHANGELOG for lines marked with ! since your current version. That makes it much much less likely that you miss something that you should change upon updating SBWG. I mean, I don't think anybody except me uses any version of SBWG. But I've always approached this project working as if it would be used by others in order to produce something that is practically usable without reading and understanding the codebase first.

The list of things that I'd like to do with SBWG is still long and includes heavy changes on how content is placed in the website's input directory. I reckon that it would take me something like 10 - 16 years to get there is I would continue advancing through the todo list at the pace at which I have in the last year. But if I would loose interest at any point along this path, I could feel okay for at least have gotton as far as testing and publishing version 0.12.8 because it's getting closer to looking how I want it to look in regards to the results it produces.

SBWG 0.11.1

I'm glad to have this version done and published. Even though it has new features compared to the last published version, I've used it enough to feel relatively comfortable saying it is also more stable and has fewer bugs than the last version. There are known bugs still left. But those aren't new.

Caching options and settings are slowly getting a bit elaborate, but also close to what I imagined them being able to do. There are new cachegroups and parts of entries can now be chosed as individual cachegroups, giving the user more control over what is cached and what caches are used. The lifetime of caches can now be set to make sure that no matter how the caching options are used, no outdated content, tags, attachments, etc. will stay on the web site for too long because cache files have been forgotten to be purges. The cache lifetime can be chosen from 1 second to unfinite. The directory used for persistant caches can now be chosen via command line option. I think the caching options are now in a state in which they can seriously be used reliably. Changes to existing cachegroups, like in previous versions, will probably not be made anymore. Just more cachegroups will be added.

The README file has grown a lot. Not only from new features and options. It's now also more complete. A lot of bugs have been fixed. And some general little code quality improvements took place. The stylesheets of the example web site have been improved a bit.

The messaging and logging system has been completely rewritten. It's not really an important part of the script and strictly doesn't matter for its functionality at all. But I decided to have a messaging system and a logging option that doesn't rely on shell redirects. So I did want to redo it properly. Different message types can now be redirected using file descriptors. The option parser has also been party re-written. It's approaching a state in which it's close to what I think personally a complete option parser for Bash should be like.

Alternate styles can now be defined in a web site's settings file. That way alternate style sheets will be offered to the web browser. If the browser supports alternate style sheets, the visitor can select from them to view the page in a different style. There is now an option to change the tagstyle, enabling a web site to have tags of the same type grouped for a more readable look of the entries' headers. Tags now show in parenthesis the number of entries that carry that tag. The number of file attachments is also displayed below entries.

The options for generating a single entry, page or gallery that is not located in the input directory/isn't actually part of the web site can now be used. They were very buggy or nonexistant before. Entries (and other items) with duplicate names are handled in defined ways now. Text files can now be used as file attachments to entries. But if the script determines one to look like a SBWG source file, it is omitted/not displayed/not linked to.

There are still big plans for future versions. Small and big features as well as a complete re-thinking of how the input directory is structured. Nicer looking web sites, more flexible command line options, more options for speeding up the script in cases where a complete website is updated/re-built. A pause like the one before this release will probably occur more often in the future.

SBWG 0.10.11

It's been two months since I published a new version of SBWG (and therefore since I worked enough on it to make me feel that an increase in the version number may be justified). I hardly get around to working on it, lately. But when I do, I try to make some solid small steps towards the improvements I wish do be done to SBWG.

So, now there is a new version (0.10.11) but I haven't published it yet because before I do I want to test it a bit more when I'm not as fucking tired as I am right now. Writing this entry could actually be considered part of the testing that I still want to do. But as I said, I'm fucking tired right now. So I'll continue this entry another time.

Edit 2022-09-12: I did some tests with fake content offline and feel confident that I fixed more than I broke in this version. I'll add it to the project page soon.

Two long procrastinate areas that have been overdue to get fixed for a while now are permanent caching and parallelisation. For permanent caching, the bugs that I found are fixed. Aggressive caching with option `--cache` (`-C`) works and certain groups can be selected (excluding others) for permanent caching. In my test this speeds up everyday web site re-generations by up to 100%. But it also means the user has to be aware of the cache files that persist after SBWG is done and will be used the next time. Changes to existing entries will not take effect without removing the relevant cache files. For parallelisation, the bugs that I found and that affect the generated HTML are fixed. I still consider parallel mode to be experimental. Sometimes messages on stdout are weird or cut off. But who uses very verbose mode and looks at every message anyway? Parallelisation is functional and usable is what I mean to say. In my test on a Core i5 with 4 cores (8 threads) it speeds up everyday web site re-generation by around 380% with default settings. It depends a lot on how much of web site generation is generating thumbnails and other image sizes of file attachments or gallery images. Those aren't sped up that much because the CPU already is the bottleneck for those. HTML file generation profits more from having more parallel threads than CPU cores (or threads) running.

SBWG 0.10.10

I decided to publish a new version of SBWG. I hardly got around to editing it in the last few months. So it doesn't really contain the new things that I had for a while intended for v0.10.10. But there were a few bugs that I wanted to have fixed in the latest published version. There still are known bugs. But now there are a few less.

Well, since it doesn't really contain anything new that's relevant, I didn't have to create this entry. But I did, so I'll use it to say I also fixed the RSS feed of draft0 and the menu link of steephlog on mobile. Bugs that I didn't know I had introduced in the last update and that were very happy that I didn't test things beforehand.

The things that did change since my last SBWG update just aren't that interesting. But I'll list some here, nevertheless: Entries can now have custom notes (using the 'note:' tag; Topic tagpages now also show the author names of entries; Srickied entries are now excluded from the RSS feed because they're just used as notices at the top of tagpages and don't belong context-less in the feed (there is a better solution planned); Error reporting inside of the script now includes information on the basis of which the clean-up routine can decide how to handle things differently for different errors and stuff; SBWG now locks directories; There is now a flag that hides attachments to an individual entry that are of a specific mime type, and, you could just read the CHANGELOG file instead of this if you really are interested in these little changes.

It'll probably continue to be slow in the foreseeable future. There are a lot of ideas in my head and several bugs in the code and probably vice versa. But time… not so much.

Edit: Oh, and another thing: I started to test updates and changes that I made to SBWG live on this web site because it's more fun if something breaks every other day. I'll pretend I don't mind.

SBWG 0.10.7

So many ideas, so little time. So many todos, no little time. So little time, so much rest of my life. But the todo list has actually started to become a little shorter for the first time in a long time. As with the previous entries about my progress with SBWG, I'm not going to address or list everything that I've improved or added. But I feel like it's time for another update.

File attachments pretty much work as intended now. Text files still can't be file attachments to entries, because text files are entries. But I think that will stay as it is for now because I don't need to attach text files to entries and if I would, I could gzip, bzip or 7z them. I mainly wanted file attachments for entry images and podcast support. Both works as well as I need it to. But some things could still be improved in the future.

Referencing tags are improved, their notes look better and there is now a way to mark an entry as an update of an other entry, giving both entries a note that tells the reader about the newer/older version. And since this works now, I dropped the idea to introduce any form of content revisioning. An entry revision system would be over the top for a feature that I hardly use. This could still be implemented just with hooks.

SBWG was relying on a feature of ImageMagick's mogrify that turned out to be a bug and was fixed. So I had to switch to convert with worse tolerance/support for broken image files. That's annoying, but I'm over it now. I mean, I wasn't complaining. Those tools are amazing and I'm so glad that they are free.

There were a number of other bugs that I've fixed. Some of them old and overlooked. But most of them were introduced not long ago. Well, I guess that's what happens if you don't do proper tests every time. SBWG is starting to become a feature-rich tool and every new feature that gets implemented could cause trouble with other features or combinations of features. In early versions of SBWG I didn't always test everything I changed. I now do, and I now also try to think of some related things the change could have effected unintentionally and test those basically. But proper tests of all sorts of scenarios every time I publish a new version? That would be professional but not worth the effort in this case. If I'm not using a feature, it doesn't matter much if I break it. I think I'll probably do more extensive tests every now and then.

Entries can now have comment links. If there is an email address available for an author, all their entries get an email link below them to allow readers to reply to them. For a public blog it might be best to use throwaway addresses that can quickly be replaced if they start to receive spam. I'd have some ideas to improve the email composed by this comment feature. But they would have to become HTML emails. So I forgot about them again.

New tag types, expanded README file, improved navigation by adding parent links and things like this, improved CSS a bit here and there, very small improvements to the code style. I didn't make any relevant improvements or corrections in terms of code quality. I think this is where SBWG could improve most. It's not a professional thing, so I declare myself fine with the way it is (which isn't that bad compared to some other software, I think) but I could learn a lot there.

Command line options can now be grouped to make typing commands easier. Long options (starting with --) didn't change (I may make those things POSIX-like, too, some other time) but short options (starting with a -) now don't need to be separated and all have their own dash. So sbwg -v -p -e blub can now be shortened to sbwg -vpe blub. And if you want to run the command again but with added verbosity, you can add the second -v wherever you want.

There is now a waiting animation that starts to play if there is no update on stdout for three seconds. Both the animation frames and the time delay can be changed. The animation is only enabled if SBWG runs with any verbosity. Then it is enabled by default. It will be disabled by default in future versions though, I think, because it's such an unnecessary messing around with terminal output. It does work pretty well though. I thought it may be harder to make it work as smoothly as it does now (which isn't 100% perfect, but pretty good).

The new default style set 'elth' is a working hybrid with different styles for small phone screens and larger screens of phablets, tablets and laptops. It's composed of several CSS files, which should make it easier to create a custom style now, since just the basics (without any colors and fancy embolishment and without any tag-specific stuff) can be copied for a template, or just the mobile style can be copied and used to create a new mobile style. Style sets can now also include files whose name don't end in '.css'. That means they can contain any file type. So JS or background images or whatever will be copied as part of the style set and placed in the 'styles/' directory of the generated web site.

More things are now cached that may be used more than once in one run of SBWG. Permament caches (option -C/--cache) can now be enabled for only parts of the web site. I still need to decide how permanent caches should be managed. The way I had/have it in mind does not seem very intuitive. It is to me because I know how it's built. But... well, maybe it's enough that I think that it makes sense. Maybe I should just start using it and if it works well, write it down in the README file.

Added new hooks, gave the helper scripts makeovers, made how HTML footers are made logical, sorted much of the remaining todos. Overall: progress.

So, I've published SBWG version 0.10.7 now. I wish I'll find the time to create and publish new versions more frequently again in the near future. But I doubt I will.