Brimstone is the code I use to run this website. You can find the code on Gitlab and, for the time being, on Github. I want to keep this post as a living post, and keep adding to it. That way I hope this post acts like a philosophy.txt.
The code isn't anything special. I write it for several reasons:
The goal of this software is to provide a simple, lightweight, option for publishing text content online that allows a user (me) to:
And allows others to view my content in a way that suits them. So far this includes:
The name is derived from the old achemical name for Sulphur. I have a bit of a Satanic streak in me, and I decided to call it Brimstone because I see Satanic practice as providing a challenge to established orthodoxies that are potentially harmful. In this case, the centralisation of the web into silo'd content. In these silos, there's also all sorts of features that are designed to keep your focus on the site -- such as notifications, games, etc. 'Features' that, in people like me, encourage the development of twitches that distract them from their other goals and habits. This is also often combined with harmful anti-privacy policies that are used to monetise your involvement in the site by spying on you.
In this way, I see the act of producing a tool that might help myself (and maybe others) from separating themselves from that as Satanic. Hence the name Brimstone. Also, Sulphur is used as a pesticide and I like that imagery when used in the context of dealing with the corporate web.
Equally as important, I wanted to play and develop a few skills.
The current version of Brimstone is built on the Symfony PHP Framework. To run the current version you will need PHP 7.1, and Composer to install the vendor packages.
It's released under the GPL 3. This means that if you fork Brimstone or use any of my code in projects, you're also obliged to release under the GPL. Symfony code is released under the MIT License which, thankfully, allows me to use MIT components inside of a GPL'd project.
It does pretty much what any home-brew blog software can do, but specifically:
2019-01-30T07:52:19+00:00 Last Modified: 30 Jan 2019, 07:52
I had a thought recently when considering the About page, and how a more minimal approach might look. At the moment, the approach is still relatively minimal; the
UserProfile object has a field which can store text used to render the About page using markdown. If it's null or empty, the templates don't render a link to the About page and the controller redirects any attempts to directly go to
/about to the index page.
How then, do I think it may be improved? Obviously these are rough ideas -- I also don't think there's anything explicitly wrong with the way things are done currently. What might seem simple to me might not be simple to others, and in fact I think there's an argument that these design patterns could add complexity in some regards.
Under both of the following proposals, the
UserProfile object has the
about attribute removed, and controller logic is changed to accommodate the new pattern.
Under the current design, the About page is simply a text field containing markdown that is rendered when the visitor calls
/about. This works basically exactly the same as a Post but is a bit less versatile e.g. Posts store a
lastModified attribute which can inform the reader if/when the Post was last edited and give some idea of freshness.
Under this design pattern,
Post receives a new boolean attribute which marks it as the About page. A form or button is implemented, along with a controller to handle elevating a Post to this position with the following logic:
post = post // from controller previousAbout = searchPosts(where: about == true) if ( previousAbout is not null ): previousAbout.setAbout(false) fi post.setAbout(true) return new Response(200)
The About page template can actually remain, with the controller simply changing the variable it passes into it to achieve the goal. Another consideration, however, is the header templates logic when choosing to render an
/about link. Currently it utilises a
UserProfile object already passed in to the template which is used for H-Card generation and Site titles as well as visible elements such as the name and profile image. Since the
UserProfile object also contains the About page, it simply checks to see if it's null or not to decide whether to render the
/about link. If I made the About page a Post, the controller would need to inform the template separately, unless the UserProfile maintained a 1-to-1 relationship with a single post, which is nullable. This changes the previous controller logic above to:
post = post // from controller userProfile = user.getProfile() userProfile.setAbout(post) return new Response(200)
Which I actually prefer. The
UserProfile still has an about attribute, but it's a reference to pre-existing content and can be switched without a search of the database and it prevents duplication; where since
Post already contains the necessary attributes for a good About page it makes sense to leverage it.
This one also utilises Posts, but with a slight twist. Instead of elevating a single Post to become an About page, what if we simply used a Tag? That way, the user could add content to their about page on-the-fly simply by tagging a Post with an about tag?
I don't think this is without issues -- for example how do you order things? What about reordering things on the page? How about editing posts, you have to hunt them down (admittedly just a search for the tag about…)? There's also the issue of the header rendering the
/about link from earlier -- this means every controller needs to do a search for Posts tagged with about and check the length of that result, to decide.
I'm sure there's a way around this, and I really like the idea of a cumulative About page which can be made up of otherwise disparate content, for now I'm going to try out Idea 1 and see how that goes.
2018-08-01T10:10:16+01:00 Last Modified: 01 Aug 2018, 10:10