ShinyCMS

While I was feeling on top of the world thanks to the `accepts_nested_attributes_for` win, I managed to get two more PRs written and merged on the same day... one a new feature, one some refactoring and structural improvements. (It's not as impressive as it sounds - the nested attributes PR was merged an hour or so after midnight, so there was plenty of day left to me) :)

So; rather later in the morning I merged allow username logins as well as email logins, which extends and configures Devise to allow people to log in using a username or their email address (Devise only supports using the email address as the user login by default). I pulled this together from a few different blog posts which I'm not going to link, because each of them was wrong in a different place, and/or for an ancient and half-obselete version of Devise - but between the contradictory sets of code and other clues I somehow managed to cobble together something that worked eventually.

(ETA: Pride cometh before the fall. If you decide to use a copy of the aforementioned working code in your own project, ignore the last PR of today, where I removed some of the user login method because my tests showed it as unused. What I should have done was write more tests to exercise that code :) I ended up having to put it back in eventually!)

Today's PR marks something very special for me; this is the first time that I've felt like a professional-level native/idiomatic Rails developer. This is exactly what I wanted to get from this project, exactly what I felt was missing from my Rails competence up until this point, so I was pleased about this PR all out of proportion to the few lines of new code added in it - those lines being the end result of my figuring out how to do something The Rails Way™: Template elements saving in update... using appropriate levels of Rails magic :-p

The magic in question is accepts_nested_attributes_for, a definitively Rails-ish bit of model adornment that allows you to build a form for, and then save, all of the child attributes (has_many) of the main model the form is for. As far as I'm aware, Perl doesn't have a similar trick that will wrap that up and tie a bow in it for you, so I was pretty pleased that in reading around the form building process for my 'templates (and templated resources) have elements' set-up, I found this feature, knocked up some demo code, confirmed it was literally exactly what I wanted right then, and got it in place (replacing a bunch of hand-rolled element-updating code) - all in one very happy-making coding session :D

One school of thought says that code is not finished when there's nothing left to add - it's finished when there's nothing left to remove :) - and this feature packs a lot of useful, common, and tedious to implement functionality into literally one extra line of code in my model (and a couple of extra lines in the form) - so it's pleasingly minimal. But I guess that's basically the definition of 'The Rails Way', right? Convention over code and all that. And like I say, this is the first time I've come out of a bit of development thinking/feeling "I solved that like a Rails developer", rather than just getting by on my general level of experience in web development in other languages. Today is a good day to be me!

I just merged Progress on user features, which builds on Add Devise from a day or two ago.

As well as my apparently limitless need to fiddle with default URLs until I find them more pleasing, I've also added some odds and ends to improve security of sites hosted on the CMS - including a check at account creation and every login against the Pwned Passwords database, as well as some config to restrict logging of passwords and other security tokens.

This stuff is all powered by features of Devise and other gems (the password check uses the pwned gem, for example). My plan is to write as little as possible of the authentication and authorisation code myself, on the grounds that a widely-used community-tested library is far more likely to have had its flaws discovered and fixed. Security is hard to get right in every detail, and you only need to get one tiny detail wrong...

Today I set up Travis CI. The project is already being checked by CircleCI, but I've found in the past that having both running can be interesting.

In particular, Travis CI has very easy-to-use support for testing your project against multiple different releases of your language; the Perl version of ShinyCMS is occasionally tested against the latest release in each branch covering several years, to demonstrate backwards compatibility! I don't think the Ruby version will go quite so far back (due to my decision to use Rails 6), but I'd still like to set up similar testing for whatever versions it can run on.

Today's merged PR worth noting is First run at adding I18n support.

Sadly my range of languages is limited - hablo un poco pequeno de español - but hopefully if the support exists then other people might contribute translations at some point.

Added Webpacker to the project today, to allow me to use some JavaScript twiddles. Specifically, I now have 'Are you sure?' messages for delete actions.

Early impressions of Webpacker are that it seems it feels a bit new and wobbly for Rails (vs. the more established Sprockets). Also it seems bizarrely huge, but I always grimace at the mount of stuff JavaScript package systems pull in to do minor front-end embellishment. If I were building proper whizbang client-side-rendering front-ends in Node.js like the cool kids then it wouldn't seem so excessive, I'm sure.

Not my most triumphant update, but ... sometimes you eat the bear, and sometimes the bear eats you.

Today I did not merge the resourceful routes experiment. Apparently I have strong opinions on what a URL should look like for various bits of functionality, and the people who designed Rails disagree with me in numerous ways, large and small. This quite possibly means I'm wrong :D but I've decided to stick with my preferred URLs, at least for now, and the Rails 'resource' helper could not be bent to my will without making the routes file more confusing than just hand-rolling them as I was up until now.

This morning I merged a couple of PRs that added a Site Settings feature (First bits of site settings feature and Site settings page in admin area). The Perl version uses a settings file, but adding the ability to change the settings via the web interface has been on my to-do list for ages, so I thought I'd do it right from the start here.

It's a really basic key/value table for now (with a helper method for easily retrieving a value from it), but I'm intending to add some stuff around default settings, per-user settings, etc, as the need arises.

Before ShinyCMS, there was ShinyCMS.

Back in 2009 a web designer and I launched a small web development agency called Shiny Ideas. Our goal was to build small-to-medium size web applications for companies that required complex custom back-end functionality (my half) and exceptional front-end design (their half). We wanted a platform to build those web applications on top of, my development experience at the time was almost entirely using Perl, and there wasn't a suitable CMS written in 'modern' Perl at the time - so in July 2009 I started writing one myself.

Shiny Ideas survived about 7 years, but ShinyCMS (the original version) outlived it - I still add features occasionally. And as the feature list in my last post shows, it's grown a fair bit over the last ten years, being extended to meet one set of customer requirements after another.

Today is the (slightly arbitrary) official start date of the ShinyCMS project :)

Slightly arbitrary because although I merged adds basic page features today - turning this project from a generic minimal Rails skeleton into something that definitely intends to be a CMS - looking at that PR you might notice that there were three PRs in the few days before this.

For the sake of a nice memorable start date, I've decided that those first three PRs don't count :-p