Building for One, Part twelve: Joomla as the household's front door

Building for One, Part one: a calm iPad display for someone living with dementia built a calm daily tablet display for someone in the early stages of dementia. Building for One, Part nine: the free tablet and the paid household built the server that lets a family change the day from somewhere else, and Building for One, Part eleven: two days between finished and in review took the household plan to three stores’ reviewers. This part is about the website the family actually uses: where they sign up, connect the tablet, invite a carer, and change tonight’s tea.

The app was in review, and frozen, so the work moved to daysome.org. It took ten small releases of our server extension and a fair amount of Joomla’s own settings, and it taught us more about Joomla’s login than we had expected to learn.

TL;DR – Joomla already does accounts, sign-in, and privacy properly, so the job was not to replace any of it. It was to make the gaps between Joomla’s pages and ours invisible to somebody who has never heard of Joomla and only wants to get thir mum’s tablet connected.

Three people arrive at the website

We wrote the work down as three journeys, because each of them failed in a different place.

The person who set up the tablet. Often a son or daughter, with the iPad in front of them showing a six-character code and asking for it to be entered at daysome.org. They have no account yet. They need to make one, confirm their email, sign in, and enter the code before it runs out, without losing the thread at any step.

The carer who was invited. They get an email from somebody they know, saying they have been invited to help with a household. They have never seen the site. They should be able to say yes with as little ceremony as possible, and land looking at the day they have been asked to help with.

The family member coming back. On a phone, between other things, to change a meal or add a note for tomorrow. They want to sign in and be there. Anything in the way, a profile page or a list with one item in it, is friction they will meet every single time.

None of these people should need to know the site is built on Joomla, and at the start of the week every one of them could probably tell.

What Joomla already does, once it is switched on

The house rule from part eight still holds: Joomla, used the way Joomla is meant to be used. Much of the work was switching on things it already has, and resisting the urge to rebuild them.

Registration was off. daysome.org had been a brochure with a tester form, and Joomla ships with sign-up disabled. We turned it on with activation by the user, so a new account confirms its own email address and nobody at Multizone has to approve it, put new accounts in the ordinary Registered group, and added a captcha to the form. The first activation email we read had no link in it, which looked like a bug for a few minutes. It was the copy Joomla sends to the administrator, which is a notice and not an invitation. The person’s own email was fine.

Sign-in and sign-up needed somewhere to live. Joomla’s login and registration pages exist whether or not anything links to them, so we added menu items for both, with the registration form visible only to people who are signed out. The login page’s menu item has fields for a sentence above the form when signed out and another when signed in. That is where the words explaining what the site is for belong, so that is where they went, instead of replacing Joomla’s page with one of our own.

Privacy is Joomla’s, not ours. The privacy consent plugin asks new users to agree to the policy and records that they did. The privacy component lets a person ask for everything held about them, or for it to be deleted. Password reset, forgotten usernames, and two-factor sign-in are all there already. Every one of those is a feature we would have had to build, test, and defend, and every one of them is better for having been used by thousands of other sites first.

Two settings were about real life. Joomla signs people out after fifteen minutes idle. That is sensible for an office and wrong for somebody who changes a meal, puts the phone down to help with lunch, and picks it up again, so the session now lasts ninety minutes and the login form offers to remember the person. The tablet’s pairing code was valid for ten minutes, which is plenty for somebody who already has an account and too short for somebody who has to register, wait for an email, and confirm it first. It is thirty now.

The member area is generated, not designed

Part nine described the decision we are happiest with: our server extension, AppSync, does not know what a meal is. Each app registers a schema describing its kinds of item, and the website’s pages are built from it. That paid off again this week, because most of the changes to the household pages were changes to Daysome’s schema rather than to code.

The schema can now say which tabs a household page has and what goes on each. Daysome’s are Meals this week, Today, The routine, and Meal lists. It can say that a section shows only today’s item, that it repeats for each of the next seven days, and that an empty slot on a day should be filled the way the tablet fills it. That last one matters, because the tablet chooses most meals itself, rotating through the family’s lists by a rule based on the date, and nobody stores the result. The website now runs the same rule, so Meals this week shows what the tablet will actually show, with a small “from the list” badge on anything nobody chose.

The schema can also lock one field on the strength of another. A routine item for a meal shows that day’s menu on the tablet, so its own description is never seen, and typing one in was a trap. On the website that field is now greyed out whenever the item is a meal, and the server keeps whatever was stored there rather than accepting a change through the back door.

Bootstrap, and the template’s opinions

Joomla’s front end is Bootstrap 5, and its default template, Cassiopeia, is a sensible place to start. The member area ships one small stylesheet of its own, for layout only. Every colour comes from the template, so the pages follow whatever theme the site uses, in light and dark mode, without our having to know. Getting even that small stylesheet to work took three attempts.

The stylesheet never loaded, and nothing said so. Joomla registers a component’s stylesheets in a small manifest and adds the css folder to the path itself. We had written css in the path as well, so Joomla looked in a folder inside itself, found nothing, and carried on without a word. The pages still looked plausible, because Bootstrap was doing most of the work, which is why it took a while to notice that none of our own rules were in effect.

Cassiopeia speaks a different dialect of Bootstrap. Bootstrap’s variables normally start with --bs-, and the obvious way to shade a card’s header is to set --bs-card-cap-bg. Cassiopeia compiles Bootstrap without that prefix, so the variable is called --card-cap-bg, and a rule setting the other one does nothing at all. On top of that, our site uses Cassiopeia Themer, our own theming extension, which writes its own rule for card headers. The fix was to set the colour directly, with a chain of fallbacks that works whichever template, and whichever naming, is in use:

.com-appsync .appsync-card > .card-header {
    background-color: var(--appsync-card-header-bg,
        var(--bs-secondary-bg, var(--secondary-bg, #e9ecef)));
}

The browser hid our test from us. To check a link’s colour, we read it back from the page. Chrome reports a visited link’s colour as unchanged, whatever the stylesheet says, so that nobody can find out which sites you have been to. It is a good privacy rule and it made a correct rule look broken. We test colours on an element that is not a link now.

Layout is a matter of what goes next to what. Bootstrap’s columns balance cards by height, which on the Today tab put “Meals today” underneath “Today” in the wrong column. Tabs a schema declares now put their first card on the left and stack the rest on the right, so the most important thing is always where the eye lands. On My groups, a single household’s card now takes the full width rather than half of it, because a single household is what almost everybody has.

We wrote all of this up in AppSync’s administrator’s guide, including where a site’s own rules go so they load after ours. The next site to use AppSync will have a different template, and we would rather it did not spend the same afternoon.

Remembering where somebody was going

The first journey, the person with the tablet and the code, broke in the most interesting way. They arrive at Get started, find they need an account, and go to Joomla’s registration form. Joomla sends a confirmation email. They open it, perhaps on their phone, perhaps an hour later, click the link, and sign in. By then the website has no idea they were ever on Get started. Joomla’s session belongs to the browser tab they started in, and the activation link may not even open in the same browser.

So AppSync now remembers the next step in a small cookie, for a day: “go to Get started”, or “accept this invitation”. When the person next signs in, a plugin reads it and sends them there. The step is used once and then forgotten.

Joomla leaves a door open for exactly this. Its login controller decides where to send somebody before it signs them in, and stores that decision where a plugin can change it. That means the redirect can be adjusted from a plugin, without overriding Joomla’s login page or copying any of its code, and it carries on working when Joomla is updated. We think this is the single most useful thing we learned about Joomla this week.

It also meant deciding when not to. The login menu item has its own redirect, and ours was set to My groups. Somebody following an invitation should be taken to it, not to My groups. But somebody who clicked a link to a particular page, signed in, and landed somewhere else would rightly be annoyed. The rule we settled on, after getting it wrong once, is that only a login with nowhere particular to go, or one heading for My groups, is redirected. A login on its way to anywhere else, including a particular page in the member area, gets there.

The invitation that makes the account

The carer’s journey was the one we were least happy with. They clicked the invitation link and arrived on a page headed “Add a device”, with buttons to sign in or register. They then had to fill in Joomla’s registration form, wait for an email, confirm their address, sign in, and only then accept. It worked, and it was five steps too many for somebody doing a favour.

The invitation page is about the invitation now. It says which household, who invited them, and as what. If they have no account, it offers one on the spot: a name, a password typed twice, and agreement to the privacy policy where the site asks for it. They press one button and are signed in, a member, and looking at the household.

No confirmation email, and we think that is right. The invitation was emailed to that address, and following its link proves they can read that inbox, which is all a confirmation email proves. The account’s username is the email address, because that is what people remember. Nothing secret is ever emailed: they choose their own password on the page. And only a valid, unused invitation can create an account this way, so it is not a way round a site that has registration switched off. An owner chose to invite that address.

Joomla’s privacy plugin only watches its own forms. It records consent when somebody registers through Joomla’s registration page. An account made anywhere else has no record, so the plugin would stop the new member at their first sign-in and ask them to agree again. AppSync now writes the record itself, in exactly the shape the plugin writes it, so the plugin sees what it expects.

Two mistakes reached the test site on the way, both of the kind that only show up when the page is actually loaded. The new plugin asked Joomla for a database connection it did not need, which broke the whole login page. And Joomla’s method for filling in a new user takes its data in a way that will not accept a value written directly into the call, only one held in a variable first, so the join form failed on its first real submission. Neither reached daysome.org.

Not a profile page

The third journey, the family member coming back, had the most visible problem. After signing in, Joomla sends people to their profile by default: a page of name, username, email, and registration date. For a carer who came to change tonight’s tea, it is a dead end with an unfamiliar address, and the address made it worse, because it read like “sign in, view profile”.

AppSync’s plugin now has a setting for where people land after signing in, and its default is the member area. Somebody in one household, which is nearly everybody, goes straight to it. Somebody in more than one goes to My groups. A site that prefers Joomla’s behaviour can choose it.

My groups itself grew up at the same time. It greets the person by name, shows each household as a card with its plan, its devices and members, and a button to open it, lists any invitations waiting for them, explains how to add a device, and has a card for their account. That card is where Joomla comes back in. Changing a name, email, or password is Joomla’s job, and its profile editor does it well, so the card links there rather than our building another one. It also signs out, and links to the page for deleting the account entirely.

We like this arrangement. The member area is ours and looks like Daysome. The account is Joomla’s, and looks like the rest of the site. Each links to the other where a person would expect it to.

The wrong person at the right link

Looking for gaps after all that, we found one we had built ourselves. An invitation link, opened by somebody already signed in, added that account to the household straight away. On a family computer, the person signed in is not always the person the email was for. A forwarded link would do the same.

Now, if the account signed in has a different email from the one the invitation was sent to, the page says so, plainly: this was sent to one address, you are signed in as another. There are two buttons, one to join as the account that is signed in, and one to sign out and use the invited address. An invitation opened by the account it was sent to is still accepted at once, because that is nearly always what happens.

A test that passed when it should have failed

AppSync has a test suite that drives a real Joomla test site over HTTP, signing in, following invitations, and submitting forms the way a browser does. It has 89 tests now. Every change in this part has tests that prove the journey works.

One of them proved nothing at first. The test for “go back to the page you were sent to sign in from” passed on the old code as well as the new. The test site and daysome.org build their addresses differently: on daysome.org, member pages sit under the My groups menu item, which the old code treated as the member area and redirected away from. On the test site they had a different, generic address, which the old code did not recognise. So the bug was real on the live site and invisible on the test one. We rewrote the test to use an address both sites share, watched it fail against the old code, then pass against the new. It is a habit worth keeping: a test you have never seen fail has not yet shown it can catch anything.

Where it stands

Ten releases of AppSync went out over the course of this work, 0.1.16 to 0.1.25, each one small, each tested on our own site before Joomla’s ordinary updater installed it on daysome.org. The app did not change at all. The tablet still shows a code and asks to have it entered at daysome.org, and everything after that now happens on the website.

A person with a tablet can make an account, confirm it, and be taken back to enter their code. A carer can accept an invitation and have an account in one step. Somebody coming back lands in their household. And everything that is properly Joomla’s, the account, the password, privacy, and deletion, is still done by Joomla.

The lesson we would pass on is that the hard part of building on a platform is not what the platform lacks. It is the seams: the moment a person passes from one of the platform’s pages to one of yours, and the platform does not know where they were going. Joomla turned out to have a door in almost every one of those seams, as long as we went looking for it before writing our own.

Getting it, and telling us where we went wrong

The free app is out on all three stores: the App Store, Google Play, and the Amazon Appstore, with links to each at daysome.org. The household plan arrives with the release now in review, and starts with a free trial.

We would like to hear from you, and that matters to us more than an install does. If you support someone in the early stages of dementia who is still living independently, or you work in dementia care and would be willing to tell us plainly where we have got it wrong, that is the thing we cannot get any other way. If you would try a test build, say so at daysome.org/testers.html.

Plainly, so nobody is misled: Daysome is an app centred on a display that shows the day. It is not a medical device, not a monitoring system, and not a substitute for anybody. It does not track whether medication has been taken, and it never will.