The first and biggest piece of news is that I’ve migrated my code from GitHub to GitLab (and now to self-hosted Gitea). The decision was largely due to the greater amount of features available to free accounts, including private repositories (where I keep the repos for my blogs - can’t have anyone taking sneak peeks at new posts!). Users can log in to GitLab using a GitHub account, so there’s no need to make an extra account for reporting issues or providing pull requests.
Comments by Muut
My goal with the choices of third party options to support in this theme is to include projects that I think will respect their users’ privacy without costing a ton of money to use. This is… more difficult than it should be. There are self-hosted services like HashOver, which BluestNight already supports, but these require other software to be running on the server and are not compatible with services such as GitHub/GitLab Pages or Netlify. Then there are services like Disqus which, though prevalent, don’t seem to respect user privacy as much as they should.
When providing us with content or posting content on Muut’s site or related third-party sites, you grant us a non-exclusive, worldwide, perpetual, irrevocable, royalty-free, sublicensable (through multiple tiers) right AND LICENSE to exercise any and all copyright, trademark, publicity, and database rights you have in the content, in any media known now or in the future.
The above clause basically means that, though you own your content, Muut also “owns” the content and can do whatever it wants with it. According to the “Why do we have this clause” link, they have this clause because
In real conversation, you can‘t take back what you said. You can elaborate, or correct yourself later. Similarly, Muut preserves the state of a conversation – with all it‘s warts – so people that come late have the same experience as those who were there when it happened.
Muut posts are permanent. Once they are more than 2.7 minutes old, have any replies, or have any likes, they may not be edited nor removed by users. The owner and the moderators of a forum, nevertheless, can always delete (but not edit) posts by anyone anytime within the forum, as is necessary for spam control.
In between the ellipses is some rationale for the decision, namely that users deleting or editing their previous comments disrupts the flow of conversation and can ruin the meaning of a post that replied to the original. Likewise, a malicious moderator could edit a user’s post to make them look bad. If you’re curious about their exact reasoning, click on the “Why do we have this clause?” link above.
A second concern for some users is if comment providers include ads in the comment systems embedded on webpages - a practice that Disqus takes part in. It appears - as of the date of this posting - that Muut does not include ads, even in free subscriptions. Their price comparison between different subscription tiers shows “Ad-Free” as a feature in every subscription tier.
There is ultimately a level of trust involved in any third party that is used, and this case is no different. Those ultimately looking to control/own the content posted on their site, including comments, will want to use HashOver instead. As a theme developer, however, Muut looks to be a good alternative for users wanting/needing a third party service that respects its users.
I am not affiliated with Muut in any way, other than as a user of their service. The opinion presented here is entirely my own, based on available information online. In short, I was not paid to talk about Muut.
An important feature for any website theme is Search Engine Optimization (SEO). A theme can only do so much to foster good SEO, as a developer optimizing the HTML for a particular site will always do better. That said, actions such as using good HTML markup (
<aside>, etc. instead of
<div>) and implementing microdata such as Schema.org to help search engine algorithms understand a page goes a long way to improve the point.
I’ll be honest - I still don’t quite understand how to use microdata. There isn’t a microdata linter that checks for good Schema.org syntax. The closest thing is Google’s structured data testing tool, but Google checks for its own microdata preferences, not just valid Schema.org syntax. While testing using Google’s tool, I had a bunch of errors because I didn’t include certain information in certain places - seriously, expecting every page to have an associated image with it? Seriously?
Grievances aside, I searched through the Schema.org specifications and implemented everything I felt I could. If anyone with more knowledge than me wants to search through the theme’s source code and point out places that could be improved, please create an issue on
GitLab Gitea and let me know.
A programmer’s worst nightmare - we like to write code, not write about the code. Still, how should anyone know how to use it if we don’t tell you how? By reading the source? Inconceivable!
Edit 05/26/2018: Documentation for BluestNight can now be found on the official website. The rest of this section is left only for historical purposes and is no longer valid information.
As part of my transition to GitLab, I’ve started putting together a project wiki as a central source of documentation about how to use BluestNight. With the amount of customization and features available, that README file was getting to be a little long…
The documentation isn’t quite finished yet - there’s still some pages left to be created - but you can follow my progress on this GitLab issue.
Contacts And Calendar Sync For MicroG
There’s been a longstanding issue with my zip file for syncing Google calendar and contacts while using MicroG where it, well, doesn’t quite work. Manually enabling permissions on the sync adapters is usually the solution, but I want to provide something to users that works out of the box.
If you look at GApps packages such as those provided by OpenGapps, they come with an XML file that gets placed in
/system/etc/default-permissions/ that indicates which permissions should be enabled by default on system apps and whether those permissions should be allowed to be disabled. The problem is… The only documentation I can find on these files are the files used by OpenGapps.
In testing, I was somehow able to get the permissions for the contact sync adapter to be set, but the permissions for the calendar adapter were not. Why? I’m not sure. These files are basically black magic to me right now.
I’m still working on figuring that one out. For now, users can download the newest version of the zip file from the downloads page and just remember to check the permissions of both sync adapters before expecting them to sync.