Frogs-in-NZ

In Canada and the US, the vast majority of provinces, states, and territories observe daylight savings time. We are scheduled to change our clocks on Sunday, November 1, 2026, falling back by 1 hour at 2:00am.

However, on March 2 of this year, the province of British Columbia decided not to observe any more time changes starting on November 1, staying on permanent daylight savings time. On June 18, Alberta made the same decision. And most recently, on September 17th, Manitoba decided to follow this precedent and will likewise stay on daylight savings permanently, starting this November. 

This created some work for content editors and website developers in those provinces, and what should have been a simple update ended up requiring some investigation. Here's the story of why event calendars started to display the wrong time for events, and how we fixed it.

This year, two Canadian provinces, BC and Alberta, moved to make Daylight Saving Time permanent. This created an issue with event registrations for some of our library clients, an interesting technical solution, and the potential for future implications down the road as other provinces (and the US) potentially join the trend. This and more in August’s Mugo Digest!

Our library client wanted to allow patrons to apply for library cards via their website. The client had existing restrictions on access to cards. Local residents receive free cards while visitors and non-residents pay a fee. Individual patrons should not have access to more than one library card.  Therefore the system had to automatically validate and standardize addresses to support duplicate detection, determine a geographical position for each address, and finally classify addresses as local or non-local. We supported this using GeoJSON and integrating with the library's ILS. We tested this functionality a number of ways, including an exploration into the mathematic principles behind the solution.

When developing a Symfony application, you often need to inspect the emails your application generates without actually sending them. While tools like Mailpit or Mailtrap are excellent choices, sometimes you want something even simpler: write every email to disk as a standard .eml file.

This approach is particularly useful for:

• Local development
• CI pipelines
• Automated testing
• Staging environments where no real emails should leave the application
• Debugging complex email templates

In this article, we'll build a custom Symfony Mailer transport that stores every outgoing email as an RFC 822 compatible .eml file.

When creating content in Ibexa using the RichText Editor, it is easy to realize that not every RichText field needs the same toolbar. A ”Body” field may need headings, embeds, and tables. A ”Short Description” or ”Caption” field usually needs bold, italic, and little else. When every field gets the full CKEditor toolbar, it might make editors waste time or even make them think they can add markup your templates were never built for.

Legacy eZ Publish solved this. Ibexa DXP does not, at least out of the box. In this blog post we describe how we added this feature to Ibexa 4.

Welcome to Mugo Web's new monthly digest, a quick way to catch up with some of the things we've been working on. In July we marked a momentous anniversary, launched a brand new site for a client, and offered free educational opportunities. 

A new update to the Mugo Page Bundle now allows for a straightforward migration from eZ Flow to Ibexa DXP. We’ve also added functionality to this versatile tool with a new rich text block type.