Feeds

Akademy 2024 is a wrap, and others have already begun to write about the conference in beautiful Würzburg, Germany, with some posts already visible on https://planet.kde.org. This year’s Akademy was fantastic, probably the best one I’ve ever attended. Other than the A/V situation (which we’ll be addressing next year, pinkie-promise), it was well-organized and smoothly run.

But more substantively, the talks and sessions were incredible, and really wove together a coherent narrative: KDE has mature and effective leaders who are pushing forward strategic projects that combine to become more than the sum of their parts. Among them:

Design

Andy Betts introduced us to the concept of the design system and how he and other VDG designers are building one to help unify layout and style across KDE software. …then Arjen Hiemstra introduced us to Union, a new styling system intended to be a single tool to style everything, and it can be informed by the design system’s semantics as well.

Apps

Nicolas Fella explained how our app development platform is lacking, inhibiting the growth of a more vibrant KDE-centric app ecosystem. This is also the topic of one of KDE’s newest high-level goals (full disclosure: I’m a co-champion of this goal along with Nicolas as primary champion). Carl Schwan laid out his “App Initiative” which is directly related, and David Edmundson talked about how we can improve the ability of our software to work in sandboxed environments.

Distribution

Harald Sitter introduced us to “KDE Linux” (tentative name), a new technologically advanced OS that will offer a radically high level of stability, security, and polish for those wishing to get KDE software directly from the source. David Edmundson’s talk about sandboxing is also heavily related here as well.

Recruitment

But how are we going to do all of this? Paul Brown, Aniqa Khokhar, and Johnny Jazeix introduced us to the “KDE Needs You ” goal, aiming to reach more people to broaden the pool of potential contributors so KDE is sustainable for years to come.

Eco

And finally, some perspective on a different sustainability issue: this was the hottest year on record, breaking records set just a few years prior. Our planet’s capacity to sustain human life in certain regions is starting to be impacted, and we need to consider both how our work exacerbates it, and how we can do our part to help make it better. Accordingly, we heard from Joanna Murzyn, Cornelius Schumacher, and Joseph P. De Veaugh-Geiss about KDE’s efforts to prolong the lifespan of old hardware so it doesn’t become e-waste. And Nicole Teale gave us some concrete hope by informing us about a program to introduce German schoolkids to the idea of upcycling old computers by installing Kubuntu on them, very similar to a similar program here in the USA that I was tangentially involved with!

Hopefully the themes and synergies here are clear. KDE is becoming more professional, more comprehensive in scope, will take more initiative for the distribution of its own software, will evolve that software’s design in a way that’s supported by modern design tools and professional designers, and contributes to solving the world’s biggest problems. I find this to be super exciting, and I hope you do too!

My personal role in Akademy was a bit more behind-the-scenes this year. I did take part in two presentations: the former goal wrap-up and the KDE e.V. Board of Directors report.

In these, I described the successes and challenges of my now-concluded Automation & Systematization goal, and helped to inform the community about KDE e.V.’s activities since last Akademy.

I also participated in Many birds-of-a-feather (BoF) sessions about various topics, including:

• A tech discussion about KDE Linux — install it today and help make it great!
• Plasma planning and roadmap — Plasma is in a great state, and we’re going to resume Monday meetings, this time in video form. I’ve got five specific features, UI changes, or bug-fixes I want to add to 6.3, and others have even more ideas.
• Design team decision-making process — super useful; we came up with one to enable us to make important decisions again.

Beyond the BoFs, I found myself constantly talking to people between sessions, during lunch, and in what seemed like every spare moment! Including:

• Björn Balazs about his work to create https://privact.org, a foundation building a next-generation method to gather metrics from users with zero risk to their privacy.
• Jos van den Oever about KDE developers applying for sponsorship from https://nlnet.nl to work on important KDE and KDE-relevent projects. Seriously, go do it!
• Eike Hein about KDE’s history and the 100% drama-free Trinity Desktop Environment.
• Neal Gompa about the challenges involved in shipping an immutable-base-system OS outside of single-purpose appliances (i.e. as a desktop OS for regular people, enthusiasts, and developers).
• Xaver Hugl live-debugged an issue on my laptop that he was able to speedily conclude was a Libinput bug.
• …and many more I didn’t have the remaining brain capacity to remember!

All of this was completely exhausting, and I had to excuse myself from a few group events and dinners to rest and process the day’s events. But Würzburg being a ridiculously beautiful city certainly helped!

Döner kebab count: 3

This has been my favorite Akademy so far, and thank you so much to everyone who helped to make it possible — David Redondo, Kieryn Darkwater, Victoria Fierce, Lydia Pintscher, and the rest of the Akademy team! Job’s a good ‘un, and I’ll see you around the internet!

Gamification on Drupal Websites Editor Fri, 09/13/2024 - 13:26

Gamification is the integration of game elements into non-gaming environments like websites to enhance user experiences. Its purpose is to make the user's experience more fun, motivating, and rewarding. Like Grand Theft Auto: San Andreas, where players explore a big landscape full of problems and prizes, gamification adds excitement and advancement to typical digital platforms.
Drupal provides an excellent setting for incorporating gamification elements because it can adapt to changing needs. Like in the game, developers using Drupal can encourage users with rewards such as badges, points systems, and interactive tasks that create a feeling of accomplishment while also promoting involvement within the community.
This article provides a detailed look into combining gamification with Drupal's strong features. Grab a coffee, and let's begin our adventure utilizing Drupal's gamification.

A new record week: 26 MRs merged! :D Too much to cover, so going forward, I will only write about the most notable changes.

The simplified zoom interface landed thanks to Jesse “jessebaker” Baker and Gaurav “gauravvvv” — with not only better controls, but also a much smoother UX:

Smooth zoom with pinch and using the slider!
Issue #3464025, image by Jesse.

Bálint “balintbrews” Kléri, Jesse and Ben “bnjmnm” Mullins integrated the existing “undo” functionality with the component props form, resulting in the UX you’d hope:

Your browser does not support playing videos. You can download it instead.

When undoing, the component props form on the right-hand side updates and the preview updates in real-time.
Issue #3463618, video by Bálint.

Now that many fundamental pieces exist, it’s time to build upon the foundations that we have. Five weeks ago, Ben added Redux integration to the component props form, resulting in live updates. That started out with a limited set of form elements supported. Harumi “hooroomoo” Jang added support for one more this week: <select>.

SDC prop shapes using enum now work thanks to expanded Redux integration. For example, you can now change the column width.
Issue #3471083, image by Harumi.

(By the way: Bálint’s epic video showing undo/redo above? That’s also powered by the Redux integration!)

Bálint and Gaurav improved the UX by removing six lines of CSS: instead of an abstract placeholder being dragged and visualized in the currently hovered drop target, now a ghost of the component being moved is visible:

Ghost of the component at the drop target: better visualization of what is about to happen.
Issue #3469895, image by me.

Two weeks ago, we gained support for actual trees. This revealed a number of bugs in the UI that had up until that time, been ahead of the back end. Another one of those was squashed this week by Bálint, Ted and I: you can now actually drag components into empty slots :D

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Empowering SDC developers

Less visible, but equally important because it boosts the productivity of the fine folks working on the Starshot Demo Design System by making XB be more explicit about what Single-Directory Components (SDCs) prop shapes it provides a complete UX for. Since last week, a sibling Component config entity is auto-generated for every SDC meeting the minimum criteria. This week, Feliksas “f.mazeikis” Mazeikis expanded the list of criteria:

1. Since #3469461, any SDCs that we know for sure won’t work well in XB (yet!) no longer show up in the XB UI. (In more detail: when we have no way to store a particular prop shape yet: XB does not yet support type: array prop shapes yet, for example.)
2. Since #3470424, SDCs marked as obsolete won’t get a Component config entity auto-created. But if it already exists (and hence may be in use), the config entity is not deleted, just disabled.

Evidently that could lead to surprising situations, especially while developing SDCs. So, he’ll be adding a UI that lists the reason for an SDC not being available in XB next.

In the background, back end folks empowering the front end

Ted “tedbow” Bowman helped the back end race ahead of the front end: while we don’t have designs for it yet (nor capacity to build it before DrupalCon if they would suddenly exist), there now is an HTTP API to get a list of viable candidate field properties that are able to correctly populate a particular component prop. These are what in the current XB terminology are called dynamic prop sources 1 2.

Travis “traviscarden” Carden and I made XB’s use of OpenAPI go much further than it did when it landed 3 weeks ago): rather than only validating API response bodies, it now also validates request bodies — hence catching an entire category of bugs on the client-side automatically. Clearer errors = faster iteration!

Week 16 was August 26–September 1, 2024.

1. Dynamic Prop Sources are similar to Drupal’s tokens, but are more precise, and support more than only strings, because SDC props often require more complex shapes than just strings. ↩︎

2. This is the shape matching from ~3 months ago made available to the client side. ↩︎

• Drupal
• Acquia
• Experience Builder

• Smooth zoom with pinch and using the slider!
• Real-time updates of the props form and preview when undoing.
• Ghost of the component at the drop target: better visualization of what is about to happen.
• SDC prop shapes using `enum` now work thanks to expanded Redux integration.

Note: This article has been reviewed by Level Access Senior Accessibility Consultant Mickey Williamson.   Takeaway: Streamline Section 508 compliance with proven strategies and DUSWDS, a tool designed to modernize federal websites while ensuring accessibility—saving time, reducing complexity, and meeting legal requirements efficiently. Ensuring equal access to information is not just a moral imperative—it's a legal requirement for federal agencies.

Enhance Drupal with the CKEditor 5 Plugin Pack: a free set of rich text editor enhancements at no cost for drupal web projects.

This week, I spoke with Eirik Morland again on the Beyond Blocks podcast about recent improvements to violinist.io, such as team/multi-user subscriptions.

Listen to the episode now.

I was great to speak to Eirik again and for him to be the first returning guest on the podcast.

Listen to the first episode with Eirik.

In this episode, we started down the path of migrating School Desk off of Heroku and onto Digital Ocean. Most of the effort was on tool changes and beginning to make a Dockerfile for deploying the app to the new setup.

Friday, 13 September 2024

KDE today announces the release of KDE Frameworks 6.6.0.

KDE Frameworks are 72 addon libraries to Qt which provide a wide variety of commonly needed functionality in mature, peer reviewed and well tested libraries with friendly licensing terms. For an introduction see the KDE Frameworks release announcement.

This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.

New in this version Attica

• Ci: add Alpine/musl job. Commit.

Baloo

• Set up crash handling for baloo_file. Commit.

Bluez Qt

• MediaTransport: Added setVolume. Commit.
• Ci: add Alpine/musl job. Commit.

Breeze Icons

• Remove 48px draw-freehand symlink. Commit. Fixes bug #491887
• Add info(-symbolic) icon symlinks. Commit.
• Add new 64px dialog icons. Commit.
• Add icon for Apple Wallet passes bundle. Commit.
• Add battery icons with power profile emblems. Commit. See bug #483805
• Add remaining symbolic icons required for Discover. Commit.
• Update accessibility icons. Commit.
• Ci: add Alpine/musl job. Commit.
• Add system-reboot-update and system-shutdown-update icons. Commit.
• Add a couple of missing monochrome category icons. Commit.
• Don't generate symlinks for app icons if we not install the icons. Commit.
• Fix issues with zoom-map icons. Commit.
• Add Spinbox-specific decrease and increase icons. Commit. See bug #491312
• Make list-remove look like a red X. Commit.

Extra CMake Modules

• ECMQueryQt: don't cache QUERY_EXECUTABLE. Commit.
• Add fallback value for SASL_PATH. Commit.
• Add SASL_PATH to prefix.sh so that libkdexoauth2.so is found. Commit.
• Allow qml target to be actually optional. Commit.
• Fix FindLibExiv2 version detection from header. Commit.
• Ci: add Alpine/musl job. Commit.
• ECMEnableSanitizers: fix greedy linker parameter replacment. Commit.
• Add private code option to ecm_add_qtwayland_(client/server)_protocol. Commit.
• Add a PRIVATE_CODE option to ecm_add_wayland_server_protocol. Commit.
• Add [PRIVATE_CODE] also to the second signature of ecm_add_wayland_server_protocol. Commit.

KAPIDox

• Unify format string usage. Commit.
• Avoid double assignment. Commit.
• Remove unnecessary escape. Commit.
• COLS_IN_ALPHA_INDEX has been deprecated. Commit.
• Footer.html correct URL for trademark_kde_gear_black_logo.png. Commit.

KArchive

• Ci: add Alpine/musl job. Commit.

KAuth

• HelperSupport: don't send debug message on application shutting down. Commit.

KCalendarCore

• Export KCalendarCore namespace to QML. Commit.
• Add read support for xCal events. Commit.
• Add KF7 TODOs to make ICalFormat::fromString methods static. Commit.
• Refactor libical <-> KCalendarCore enum conversion. Commit.
• Avoid computing the next recurrence interval based on an invalid time. Commit.

KCMUtils

• Set a QQmlEngine property on the QApplication. Commit. Fixes bug #488965

KCodecs

• Ci: add Alpine/musl job. Commit.
• Ensure we find test data on Windows. Commit.

KColorScheme

• Use passkey to avoid issues with private constructor. Commit.
• Additional public API. Commit.
• [kcolorschememanager] Fix crash. Commit. Fixes bug #492408
• Add KColorSchemeManager::instance in favor of public constructor. Commit.

KConfig

• KStandardAction: Use windowIcon for AboutApp icon again. Commit.
• Fix macro documentation. Commit.
• Ci: add Alpine/musl job. Commit.
• Fix warning from staterc migration when there's no "old" file to migrate. Commit.
• Update KF6 TODO comments to KF7 given that they weren't addressed in KF6. Commit.

KContacts

• Make the depedency to QML optional. Commit.

KCoreAddons

• ExportUrlsToPortal: check for dbus error. Commit.
• KDirWatch: don't try inotify again if it has already failed. Commit.
• Relicense some files from lgpl2-only to lgpl2.1-or-later. Commit.
• Ci: add Alpine/musl job. Commit.
• KPluginMetaData: Avoid reading metadata from plugin loader twice. Commit.
• Kcoreaddons_add_plugin: Fix typo in error message. Commit.
• Fix configuring error when QtQml is not around. Commit.

KCrash

• Document that KCrash::initialize should be called after KAboutData. Commit.
• Drop ptrace forwarding code. Commit.

KDBusAddons

• Ci: add Alpine/musl job. Commit.

KDeclarative

• QPixmapItem: Adjust rendering to dpr positioning. Commit. Fixes bug #481219

KDE Daemon

• Use KAboutData. Commit.
• Initialize KCrash. Commit.

KDNSSD

• Ci: add Alpine/musl job. Commit.

KFileMetaData

• UserMetadata: fix Win k_setxattr. Commit.
• [OfficeExtractor] Do not add word/line count if nothing has been extracted. Commit.
• [OfficeExtractor] Only try to extract content if PlainText is requested. Commit.
• [OfficeExtractor] Remove duplicate findExecutable calls, fix debug output. Commit.
• Cmake: Use KDE_INSTALL_FULL_LIBEXECDIR_KF instead of manual path mangling. Commit. Fixes bug #491462
• Add missing initializer for "Empty" PropertyInfo displayName. Commit.
• [Taglib] Use non-deprecated constructors for MPEG::File/FLAC::File. Commit.
• [Taglib] Replace deprecated length() with lengthInSeconds(). Commit.

KGlobalAccel

• Ci: add Alpine/musl job. Commit.

KGuiAddons

• Port towards QNativeInterface. Commit.
• Fail at CMake configure time if xcb Qt feature is not enabled. Commit.
• Waylandclipboard: Dont explicitly clear when transfering sources. Commit.
• [kjobwidgets] Store window in a QPointer. Commit. See bug #491637. See bug #448532
• Ci: add Alpine/musl job. Commit.
• KOverlayIconEngine: Adjust to API change in Qt 6.8 in scaled pixmap hook. Commit.
• Generate wayland code with PRIVATE_CODE. Commit.

KHolidays

• Ci: add Alpine/musl job. Commit.

KI18n

• Spinboxdoc. Commit.
• Formatting. Commit.
• Ci: add Alpine/musl job. Commit.
• Fix test to actually use a QDoubleSpinBox as intended here. Commit.
• Unambiguous documentation of formatString. Commit.

KIconThemes

• Allow building without breeze-icons. Commit.
• Extend initTheme to ensure we properly follow the system colors. Commit.
• Add path for Android to theme locations. Commit.
• Take logical pixels in KIconEngine::createPixmap. Commit.
• [kiconengine] Adapt to Qt behavior change in scaledPixmap. Commit. Fixes bug #491677

KIdletime

• Ci: add Alpine/musl job. Commit.
• Generate wayland code with PRIVATE_CODE. Commit.

KImageformats

• XCF: fix crash. Commit.
• README update. Commit.
• RGB: added options support. Commit.
• PCX: added options support. Commit.
• Fix crash on malformed files. Commit.

KIO

• Test: skip kfilewidgettest focus test in Wayland. Commit.
• KFileWidget: Fix selecting directories. Commit.
• [trash] Fix restoring entries with absolute paths in disk-local trash. Commit. Fixes bug #463751
• Add missing include. Commit.
• Also search kservices5 for service menus. Commit.
• Accept service menus that use ServiceTypes to specify their types. Commit. Fixes bug #478030
• Ignore application/x-kde-onlyReplaceEmpty in paste dialog. Commit. Fixes bug #492006
• Apply 1 suggestion(s) to 1 file(s). Commit.
• PasteDialog: hide application/x-kde-* formats from the combobox. Commit.
• PreviewJob: remove obsolete support X-KDE-Protocols aware thumbnailer. Commit.
• Fix documentation for ThumbnailRequest. Commit.
• Remove dead code for changing job priorities. Commit.
• Remove unused sslMetaData member. Commit.
• Remove unneeded friend. Commit.
• KFileWidget: Enable word wrapping for the message widget. Commit.
• Add missing include. Commit.
• Remove unused function. Commit.
• Consistently use WITH_QTDBUS instead of USE_DBUS. Commit.
• Previewjob: use contains instead of supportsMimetype. Commit.
• Document variable purposes and move EntryInfo definition to the start. Commit.
• KPropertiesDialog: Add "unknown" fallback. Commit.
• KPropertiesDialog: Use original URL for extra fields. Commit.
• Remove unneeded QPointer usage. Commit.
• PreviewJob: some refactoring. Commit.
• KUrlNavigator: Support modifiers on return similar to web browsers. Commit.
• PreviewJob: fix warnings and a todo. Commit.
• KDynamicJobTracker: Use widgets fallback if server says job tracker is required. Commit.
• Correctly escape unit names. Commit. Fixes bug #488854
• KRecentDocument: add removeApplication and removeUrl. Commit. See bug #480276
• Gui/kprocessrunner: normalize working directory. Commit. Fixes bug #490966
• DropJob: special-case "downloading http URLs" drop with better text. Commit.
• Don't show "Move" item in drop menu for source files accessed using http. Commit. Fixes bug #389600
• Set up crash handling for kiod. Commit.
• Deprecate leftovers from HTTP cache control. Commit.
• KUrlNavigator: Decode url title fully. Commit.
• Make sure KCrash works for kioworker. Commit.
• Previewjob: Use thumbnailer files for any mimetypes we don't have a plugin for. Commit.

Kirigami

• Disable cachegen. Commit. Fixes bug #488326
• PlaceholderMessage: Remove the icon opacity if the message is actionable. Commit.
• ToolBarLayout: Add test for dynamic actions. Commit.
• Read willShowOnActive value as Variant and convert to Bool. Commit.
• PrivateActionToolButton: Replace onVisibleChanged with Connections. Commit.
• Fix registration name for WheelEvent. Commit.
• [icon] Only reload icon from theme if the theme has that icon. Commit. Fixes bug #491806. Fixes bug #491854. Fixes bug #491848
• PrivateActionToolButton: Hide menu if button is hidden. Commit. Fixes bug #486107
• Allow recoloring of Android icon theme. Commit.
• Ci: add Alpine/musl job. Commit.
• [icon] Fix icon colors when using Plasma platformtheme and QIcon source. Commit. Fixes bug #491274
• ShadowedImage: Expose Image.status via a readonly alias. Commit.
• PromptDialog: fix buttons overflow. Commit.
• Relicense Chip to LGPL. Commit.
• Relicense LoadingPlaceholder to LGPL. Commit.

KItemModels

• Remove unused license text. Commit.
• Convert license statements to SPDX. Commit.
• Ci: add Alpine/musl job. Commit.
• Fix build without Qml. Commit.
• KColumnHeadersModel: Fix manual test. Commit.
• KExtraColumnsProxyModel: port to Qt 6.8's QIdentityProxyModel::setHandleSourceLayoutChanges. Commit.

KItemViews

• Ci: add Alpine/musl job. Commit.

KJobWidgets

• Only install D-Bus interface files when actually building with D-Bus. Commit.

KNewStuff

• Add especially crappy magic to deal with transient parents in actions. Commit. Fixes bug #491083
• Make staticxmlprovider (more) reentrant. Commit.
• Make AtticaProvider reentrant. Commit.
• Typos--. Commit.

KNotifications

• Don't set desktop file name for XDG activation token. Commit.

KPackage

• Add missing include guard. Commit.

KPlotting

• Ci: add Alpine/musl job. Commit.

KQuickCharts

• Ci: add Alpine/musl job. Commit.

KStatusNotifieritem

• Fix deprecation versions. Commit.
• Deprecate action collection access. Commit.

KTextEditor

• Make tests a bit faster. Commit.
• Fix clashing and missing keyboard accelerators. Commit.
• Add help texts for new editing commands. Commit.
• Move sort implementation to C++. Commit. Fixes bug #478250
• Move natsort to C++ and implement it using QCollator. Commit.
• Move the sortuniq, uniq implementation to C++. Commit. Fixes bug #478250
• Read and write font features to config. Commit.
• Fix doc.text() when first block is empty. Commit.
• Fix block splitting. Commit.
• Try to make test more robust. Commit.
• Restore previous indentation test mode based on individual files. Commit.
• Store startlines in the buffer instead of block. Commit.
• Doc: Fix code example for plugin hosting. Commit.
• No 10 second timeouts, the CI is not that consistent fast. Commit.
• Try to make test more stable. Commit.
• Improve encoding detection. Commit. Fixes bug #487594
• Fix grouping on config dialog page. Commit. Fixes bug #490617
• Optimize cursorToOffset. Commit.
• Dont indent on tab when in block selection mode. Commit. Fixes bug #448695
• Fix selection printing. Commit. Fixes bug #415570

KTextTemplate

• Ci: add Alpine/musl job. Commit.

KTextWidgets

• Fix unused-variable warning (with clang) when HAVE_SPEECH isn't set. Commit.
• Deprecate KPluralHandlingSpinBox. Commit.

KUserFeedback

• Tests: allow to disable testOpenGLInfoSource using envvar. Commit.
• Ci: add Alpine/musl job. Commit.

KWallet

• Set up crash handling. Commit.
• Remove dead kdeinit code. Commit.

KWidgetsAddons

• Hide toolbar when not need (e.g. in tabbed view). Commit.
• FontChoose: Allow setting font features when selecting font. Commit. Fixes bug #479686
• Expand tabbar in KPageView. Commit.
• [kjobwidgets] Store window in a QPointer. Commit. Fixes bug #491637. See bug #448532
• Support page headers in KPageView. Commit.

KWindowSystem

• Generate wayland code with PRIVATE_CODE. Commit.

KXMLGUI

• Port to KStandardActions where possible. Commit.

Modem Manager Qt

• Ci: add Alpine/musl job. Commit.

Network Manager Qt

• Ci: add Alpine/musl job. Commit.

Prison

• Fix WITH_QUICK=OFF by moving ECMQmlModule behind the conditional. Commit.
• Ci: add Alpine/musl job. Commit.

Purpose

• Fix sharing via menu a second time. Commit. Fixes bug #490579

QQC2 Desktop Style

• Read Smallest font settings from the proper config. Commit. Fixes bug #490890

Solid

• Ci: add Alpine/musl job. Commit.

Sonnet

• Revert "fail if none of the plugins can be build". Commit.
• Fail if none of the plugins can be build. Commit.
• Update file spellcheckhighlighter.cpp. Commit.
• Quick: Silence valgrind warnings. Commit.
• Fix uic warning. Commit.
• Ci: add Alpine/musl job. Commit.

Syntax Highlighting

• Inc version. Commit.
• Update QFace IDL Definition to support single line comments. Commit.
• Odin.xml: Multiple fixes to the syntax. Commit.
• QFace: WordDetect without trailing space. Commit.
• Bash: add \E, \uHHHH and \UHHHHHHHH String Escape, @k parameter transformation and & in string substitution. Commit.
• Zsh: add \E, \uHHHH, \UHHHHHHHH and sinle \ as String Escape. Commit.
• Add definition for the QFace IDL. Commit.
• Modelines: add missing variables and delete some that don't work. Commit.
• Add Kate Config syntax (.kateconfig file). Commit.
• Modelines: fix spaces after remove-trailing-spaces value ; multiple values now stop parsing. Commit.
• Modelines: fix indent-mode value and remove deprecated variables. Commit.
• Detect-identical-context.py: add -p to show duplicate content. Commit.
• XML: add parameter entity declaration symbol (% in ). Commit.
• Indexer: suggest removing .* and .*$ from RegExpr with lookAhead=1. Commit.
• PHP: add { in double quote string as a Backslash Code. Commit. Fixes bug #486372
• Zsh: fix escaped line in brace condition. Commit.
• Bash: fix escaped line in brace condition. Commit. Fixes bug #487978
• Nix: fix string in attribute access. Commit. Fixes bug #491436
• Optimize AbstractHighlighterPrivate::ensureDefinitionLoaded (highlighter_benchmark is 1.1% faster). Commit.
• Ci: add Alpine/musl job. Commit.
• Indexer: suggest replacing RegExpr with Int or Float when possible. Commit.
• Add JSX as an alternative name for JavaScript React (JSX) and TSX for TypeScript React (TSX). Commit.
• Indexer: check name and alternativeNames conflict ; update alternativeNames for generated files. Commit.
• Optimize Repository::addCustomSearchPath. Commit.
• Replace QList contextDatas with std::vector: implicit sharing is not useful. Commit.
• Prefer range-based loops to loop over iterators. Commit.
• Optimize Definition::foldingEnabled() by calculating the result during loading. Commit.
• Replace DefinitionRef type with DefinitionData* in immediateIncludedDefinitions. Commit.
• Remove code duplication related to context resolution. Commit.
• Replace std::cout / std::cerr with fprintf. Commit.
• Use QStringView as key for format. Commit.
• Replace QStringView::mid,left,right with sliced. Commit.
• Replace QString::split with QStringTokenizer to avoid unnecessary list construction. Commit.
• Orgmode: add syntax highlighting to some languages. Commit.
• Optimize Repository::definition[s]For*(). Commit.
• Reduce QFileInfo usage. Commit.
• Theme_contrast_checker.py: add --scores to modify rating values. Commit.
• Theme_contrast_checker.py: displays the selected color space. Commit.
• Theme_contrast_checker.py: fix label inversion between bold and normal text. Commit.
• Ksyntaxhighlighter6: add --background-role parameter to display different possible theme backgrounds. Commit.
• Ksyntaxhighlighter6: rename ansi256Colors format to ansi256. Commit.
• Theme_contrast_checker.py: fix help of -M parameter. Commit.
• Added a link to all available syntaxes and how to test a file in an isolated environment. Commit.
• Python: raw-string with lowercase r are highlighted as regex. Commit.
• JSON: fix float that start with 0. Commit.
• JSON: add jsonlines and asciicast v2 format extensions. Commit.

Threadweaver

• Ci: add Alpine/musl job. Commit.

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 1164 other packages on CRAN, downloaded 36.1 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 595 times according to Google Scholar.

Conrad released two small incremental releases to version 14.0.0. We did not immediately bring these to CRAN as we have to be mindful of the desired upload cadence of ‘once every one or two months’. But as 14.0.2 has been stable for a few weeks, we now decided to bring it to CRAN. Changes since the last CRAN release are summarised below, and overall fairly minimal. On the package side, we reorder what citation() returns, and now follow CRAN requirements via Authors@R.

Changes in RcppArmadillo version 14.0.2-1 (2024-09-11)

• Upgraded to Armadillo release 14.0.2 (Stochastic Parrot)

  • Optionally use C++20 memory alignment

  • Minor corrections for several corner-cases

• The order of items displayed by citation() is reversed (Conrad in #449)

• The DESCRIPTION file now uses an Authors@R field with ORCID IDs

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Yuvania Castillo

Backend Engineer

A graduate of the University of Costa Rica with a passion for programming, Yuvania is driven to constantly improve, study, and learn new technologies to be better every day.

January 1, 1970

Preparing for Drupal 11 is crucial to ensure a smooth transition, and we’re here to help you make it easy and efficient. This guide offers clear steps to update your environment and modules, perform thorough tests, and use essential tools like Upgrade Status and Drupal Rector.

Don’t fall behind! Making sure your site is ready for the new features and improvements Drupal 11 brings will make the upgrade work quick and easy.

Read on to learn how to keep your site updated and future-proof.

Ensure your environment is ready

• Upgrade to PHP 8.3: Ensure optimal performance and compatibility with Drupal 11
• Use Drush 13: Make sure you have this version available in your development or sandbox environment
• Database requirements: Ensure your database meets the requirements for Drupal 11:
  • MySQL 8.0
  • PostgreSQL 16
• Web server: Drupal 11 requires Apache 2.4.7 or higher. Keep your server updated to avoid compatibility issues.

Upgrade to Drupal 10.3. Before migrating to Drupal 11, update your site to Drupal 10.3 to handle all deprecations properly. Drupal 10.3 defines all deprecated code to be removed in Drupal 11, making it easier to prepare for the next major update.

Update contributed modules. Use Composer to update all contributed modules to versions compatible with Drupal 11. The Upgrade Status module will help identify deprecated modules and APIs. Ensure all modules are updated to avoid compatibility issues.

Fix custom code. Use Drupal Rector to identify and fix deprecations in your custom code. Drupal Rector automates much of the update process, leaving “to do” comments where manual intervention is needed. Perform a manual review of critical areas to ensure everything functions correctly.

Run tests in a safe environment. Conduct tests in a safe environment, such as a local sandbox or cloud IDE. It’s likely to fail at first, but it’s essential to run multiple tests until you achieve a successful result. Use:

• composer update --dry-run to simulate the update without making changes
• composer why-not drupal/core 11.0 if there are issues, identify which dependencies require an earlier version of Drupal

Compatibility tools. Install and use the Upgrade Status module to ensure your site is ready. This module provides a detailed report on your site’s compatibility with Drupal 11. Check for compatibility issues in contributed projects on Drupal.org using the Project Update Bot.

Back up everything. Before updating, ensure you have a complete backup of your code and database. This is crucial to restore your site if something goes wrong during the update.

Considerations for immediate upgrade

You may wonder if you should upgrade your site to Drupal 11 as soon as it’s available. Here are some pros and cons to consider:

• Maybe no: Sites can wait up till when the Drupal 10 LTS (long term support) ends (mid-late 2026) and then upgrade. This allows contributed modules to be fully ready for the update.
• Maybe yes: Upgrading early lets you take advantage of new features and improvements but may introduce new bugs. Additionally, if everyone waits to upgrade, it could delay the readiness of contributed modules for the new version.

While Drupal 10 will be supported for some time, it’s advisable to stay ahead with these updates to use the improvements they offer and ensure a smoother, optimized transition.

By following these steps and considerations, your Drupal site will be well prepared for the transition to Drupal 11, ensuring a smooth and uninterrupted experience. Get ready for the new and exciting features Drupal 11 has to offer!

References

• Are You Ready for Drupal 11?
• Drupal 11 on Acquia
• YouTube: Preparing for Drupal 11
• Getting Ready for Drupal 11 – Slide Deck

The post Get ready for Drupal 11: An essential guide appeared first on Four Kitchens.

Premise

The 0.4.0 release of uv does everything I currently do with pip, pyenv, pipx, pip-tools, and pipdeptree. Because of that, I'm in the process of switching to uv.

This blog post covers switching from pyenv to uv.

History

• 2024-08-29: Initial writing.

• 2024-09-12: Minor updates and publishing.

Start state

I'm running Ubuntu Linux 24.04. I have pyenv installed using the the automatic installer. pyenv is located in $HOME/.pyenv/bin/.

I have the following Pythons installed with pyenv:

$ pyenv versions system 3.7.17 3.8.19 3.9.19 * 3.10.14 (set by /home/willkg/mozilla/everett/.python-version) 3.11.9 3.12.3

I'm not sure why I have 3.7 still installed. I don't think I use that for anything.

My default version is 3.10.14 for some reason. I'm not sure why I haven't updated that to 3.12, yet.

In my 3.10.14, I have the following Python packages installed:

$ pip freeze appdirs==1.4.4 argcomplete==3.1.1 attrs==22.2.0 cffi==1.15.1 click==8.1.3 colorama==0.4.6 diskcache==5.4.0 distlib==0.3.8 distro==1.8.0 filelock==3.14.0 glean-parser==6.1.1 glean-sdk==50.1.4 Jinja2==3.1.2 jsonschema==4.17.3 MarkupSafe==2.0.1 MozPhab==1.5.1 packaging==24.0 pathspec==0.11.0 pbr==6.0.0 pipx==1.5.0 platformdirs==4.2.1 pycparser==2.21 pyrsistent==0.19.3 python-hglib==2.6.2 PyYAML==6.0 sentry-sdk==1.16.0 stevedore==5.2.0 tomli==2.0.1 userpath==1.8.0 virtualenv==20.26.2 virtualenv-clone==0.5.7 virtualenvwrapper==6.1.0 yamllint==1.29.0

That probably means I installed the following in the Python 3.10.14 Python environment:

• MozPhab

• pipx

• virtualenvwrapper

Maybe I installed some other things for some reason lost in the sands of time.

Then I had a whole bunch of things installed with pipx.

I have many open source projects all of which have a .python-version file listing the Python versions the project uses.

I think that covers the start state.

Steps

First, I made a list of things I had.

• I listed all the versions of Python I have installed so I know what I need to reinstall with uv.

  $ pyenv versions

• I listed all the packages I have installed in my 3.10.14 environment (the default one).

  $ pip freeze

• I listed all the packages I installed with pipx.

  $ pipx list

I uninstalled all the packages I installed with pipx.

$ pipx uninstall PACKAGE

Then I uninstalled pyenv and everything it uses. I followed the pyenv uninstall instructions:

$ rm -rf $(pyenv root)

Then I removed the bits in my shell that add to the PATH and set up pyenv and virtualenvwrapper.

Then I started a new shell that didn't have all the pyenv and virtualenvwrapper stuff in it.

Then I installed uv using the uv standalone installer.

Then I ran uv --version to make sure it was installed.

Then I installed the shell autocompletion.

Note

I have a dotfiles thing and separate out bashrc changes by what changes them. You can see my home-grown thing that works for me here:

https://github.com/willkg/dotfiles

These instructions are specific to my home-grown dotfiles thing.

$ echo 'eval "$(uv generate-shell-completion bash)"' >> ~/dotfiles/bash.d/20-uv.bash

Then I started a new shell to pick up those changes.

Then I installed Python versions:

$ uv python install 3.8 3.9 3.10 3.11 3.12 Searching for Python versions matching: Python 3.10 Searching for Python versions matching: Python 3.11 Searching for Python versions matching: Python 3.12 Searching for Python versions matching: Python 3.8 Searching for Python versions matching: Python 3.9 Installed 5 versions in 8.14s + cpython-3.8.19-linux-x86_64-gnu + cpython-3.9.19-linux-x86_64-gnu + cpython-3.10.14-linux-x86_64-gnu + cpython-3.11.9-linux-x86_64-gnu + cpython-3.12.5-linux-x86_64-gnu

When I type "python", I want it to be a Python managed by uv. Also, I like having "pythonX.Y" symlinks, so I created a uv-sync script which creates symlinks to uv-managed Python versions:

https://github.com/willkg/dotfiles/blob/main/dotfiles/bin/uv-sync

Then I installed all my tools using uv tool install.

$ uv tool install PACKAGE

For tox, I had to install the tox-uv package in the tox environment:

$ uv tool install --with tox-uv tox

Now I've got everything I do mostly working.

So what does that give me?

I installed uv and I can upgrade uv using uv self update.

Python interpreters are managed using uv python. I can create symlinks to interpreters using uv-sync script. Adding new interpreters and removing old ones is pretty straight-forward.

When I type python, it opens up a Python shell with the latest uv-managed Python version. I can type pythonX.Y and get specific shells.

I can use tools written in Python and manage them with uv tool including ones where I want to install them in an "editable" mode.

I can write scripts that require dependencies and it's a lot easier to run them now.

I can create and manage virtual environments with uv venv.

Next steps

Delete all the .python-version files I've got.

Update documentation for my projects and add a uv tool install PACKAGE option to installation instructions.

Probably discover some additional things to add to this doc.

This week's big issue was building a prototype for "Axe Thrower" so we can "throw" multiple URLs at AXE at the same time.

I reverted my name back to Jonathan Riddell and have now made a new uid for my PGP key, you can get the updated one on keyserver.ubuntu.com or my contact page or my Launchpad page.

Here’s some pics from Akademy

KDE Akademy is meeting this week in Würzburg.

We just had a BoF session where we discussed..

• The current progress to rebasing on Ubuntu 24.04
• The current state of KDE neon Core our amazing forthcoming Snap based distro
• Fixing up broken and bitrotting infrastructure
• Moving to KDE invent
• Issues with Plasma 6 upgrades and looking at integrating more QA tests
• How the proposed KDE LinuxTM distro fits into the mix

This is the last of a series of posts I’m doing as a sort of Python/Django Advent calendar, offering a small tip or piece of information each day from the first Sunday of Advent through Christmas Eve. See the first post for an introduction.

Python contains multitudes

There are a lot of container types available in the Python standard library, and it can be confusing sometimes to keep track of them all. So since it’s …

Read full entry

In this quiz, you’ll test your understanding of the new features in Python 3.13.

By working through this quiz, you’ll revisit how to compile a custom Python build, disable the Global Interpreter Lock (GIL), enable the Just-In-Time (JIT) compiler, determine the availability of new features at runtime, assess the performance improvements in Python 3.13, and make a C extension module targeting Python’s new ABI.

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

Building a custom Drupal theme nowadays is a more complex process than it used to be. Most themes require some kind of build tool such as Gulp, Grunt, Webpack or others to automate many of the repeatitive tasks we perform when working on the front-end. Tasks like compiling and minifying code, compressing images, linting code, and many more. As Atomic Web Design became a thing, things got more complicated because now if you are building components you need a styleguide or Design System to showcase and maintain those components. One of those design systems for me has been Patternlab. I started using Patternlab in all my Drupal projects almost ten years ago with great success. In addition, Patternlab has been the design system of choice at my place of work but one of my immediate tasks was to work on migrating to a different design system. We have a small team but were very excited about the challenge of finding and using a more modern and robust design system for our large multi-site Drupal environment.

Enter Storybook

After looking a various options for a design system, Storybook seemed to be the right choice for us for a couple of reasons: one, it has been around for about 10 years and during this time it has matured significantly, and two, it has become a very popular option in the Drupal ecosystem. In some ways, Storybook follows the same model as Drupal, it has a pretty active community and a very healthy ecosystem of plugins to extend its core functionality.

Storybook looks very promising as a design system for Drupal projects and with the recent release of Single Directory Components or SDC, and the new Storybook module, we think things can only get better for Drupal front-end development. Unfortunately for us, technical limitations in combination with our specific requirements, prevented us from using SDC or the Storybook module. Instead, we built our environment from scratch with a stand-alone integration of Storybook 8.

INFO: At the time of our implementation, TwigJS did not have the capability to resolve SDC's namespace. It appears this has been addressed and using SDC should now be possible with this custom setup. I haven't personally tried it and therefore I can't confirm. Our process and requirements

In choosing Storybook, we went through a rigorous research and testing process to ensure it will not only solve our immediate problems with our current environment, but it will be around as a long term solution. As part of this process, we also tested several available options like Emulsify and Gesso which would be great options for anyone looking for a ready-to-go system out of the box. Some of our requirements included:

1. No components refactoring

The first and non-negotiable requirement was to be able to migrate components from Patternlab to a new design system with the least amount of refactoring as possible. We have a decent amount of components which have been built within the last year and the last thing we wanted was to have to rebuild them again because we are switching design system.

2. A new Front-end build workflow

I personally have been faithful to Gulp as a front-end build tool for as long as I can remember because it did everything I needed done in a very efficient manner. The Drupal project we maintain also used Gulp, but as part of this migration, we wanted to see what other options were out there that could improve our workflow. The obvious choice seemed to be Webpack, but as we looked closer into this we learned about ViteJS, "The Next Genration Frontend Tooling". Vite delivers on its promise of being "blazing fast", and its ecosystem is great and growing, so we went with it.

3. No more Sass in favor of PostCSS

CSS has drastically improved in recent years. It is now possible with plain CSS, to do many of the things you used to be able to only do with Sass or similar CSS Preprocessor. Eliminating Sass from our workflow meant we would also be able to get rid of many other node dependencies related to Sass. The goal for this project was to use plain CSS in combination with PostCSS and one bonus of using Vite is that Vite offers PostCSS processing out of the box without additional plugins or dependencies. Ofcourse if you want to do more advance PostCSS processing you will probably need some external dependencies.

Building a new Drupal theme with Storybook

Let's go over the steps to building the base of your new Drupal theme with ViteJS and Storybook. This will be at a high-level to callout only the most important and Drupal-related parts. This process will create a brand new theme. If you already have a theme you would like to use, make the appropriate changes to the instructions.

1. Setup Storybook with ViteJS ViteJS

• In your Drupal project, navigate to the theme's directory (i.e. /web/themes/custom/)
• Run the following command:

npm create vite@latest storybook

• When prompted, select the framework of your choice, for us the framework is React.
• When prompted, select the variant for your project, for us this is JavaScript

After the setup finishes you will have a basic Vite project running.

Storybook

• Be sure your system is running NodeJS version 18 or higher
• Inside the newly created theme, run this command:

npx storybook@latest init --type react

• After installation completes, you will have a new Storybook instance running
• If Storybook didn't start on its own, start it by running:

npm run storybook TwigJS

Twig templates are server-side templates which are normally rendered with TwigPHP to HTML by Drupal, but Storybook is a JS tool. TwigJS is the JS-equivalent of TwigPHP so that Storybook understands Twig. Let's install all dependencies needed for Storybook to work with Twig.

• If Storybook is still running, press Ctrl + C to stop it
• Then run the following command:

npm i -D vite-plugin-twig-drupal html-react-parser twig-drupal-filters @modyfi/vite-plugin-yaml

• vite-plugin-twig-drupal: If you are using Vite like we are, this is a Vite plugin that handles transforming twig files into a Javascript function that can be used with Storybook. This plugin includes the following:
  • Twig or TwigJS: This is the JavaScript implementation of the Twig PHP templating language. This allows Storybook to understand Twig.
    Note: TwigJS may not always be in sync with the version of Twig PHP in Drupal and you may run into issues when using certain Twig functions or filters, however, we are adding other extensions that may help with the incompatability issues.
  • drupal attribute: Adds the ability to work with Drupal attributes.
• twig-drupal-filters: TwigJS implementation of Twig functions and filters.
• html-react-parser: This extension is key for Storybook to parse HTML code into react elements.
• @modifi/vite-plugin-yaml: Transforms a YAML file into a JS object. This is useful for passing the component's data to React as args.

ViteJS configuration

Update your vite.config.js so it makes use of the new extensions we just installed as well as configuring the namesapces for our components.

import { defineConfig } from "vite" import yml from '@modyfi/vite-plugin-yaml'; import twig from 'vite-plugin-twig-drupal'; import { join } from "node:path" export default defineConfig({ plugins: [ twig({ namespaces: { components: join(__dirname, "./src/components"), // Other namespaces maybe be added. }, }), // Allows Storybook to read data from YAML files. yml(), ], }) Storybook configuration

Out of the box, Storybook comes with main.js and preview.js inside the .storybook directory. These two files is where a lot of Storybook's configuration is done. We are going to define the location of our components, same location as we did in vite.config.js above (we'll create this directory shortly). We are also going to do a quick config inside preview.js for handling drupal filters.

• Inside .storybook/main.js file, update the stories array as follows:

stories: [ "../src/components/**/*.mdx", "../src/components/**/*.stories.@(js|jsx|mjs|ts|tsx)", ],

• Inside .storybook/preview.js, update it as follows:

/** @type { import('@storybook/react').Preview } */ import Twig from 'twig'; import drupalFilters from 'twig-drupal-filters'; function setupFilters(twig) { twig.cache(); drupalFilters(twig); return twig; } setupFilters(Twig); const preview = { parameters: { controls: { matchers: { color: /(background|color)$/i, date: /Date$/i, }, }, }, }; export default preview; Creating the components directory

• If Storybook is still running, press Ctrl + C to stop it
• Inside the src directory, create the components directory. Alternatively, you could rename the existing stories directory to components.

Creating your first component

With the current system in place we can start building components. We'll start with a very simple component to try things out first.

• Inside src/components, create a new directory called title
• Inside the title directory, create the following files: title.yml and title.twig

Writing the code

• Inside title.yml, add the following:

--- level: 2 modifier: 'title' text: 'Welcome to your new Drupal theme with Storybook!' url: 'https://mariohernandez.io'

• Inside title.twig, add the following:

<h{{ level|default(2) }}{% if modifier %} class="{{ modifier }}"{% endif %}> {% if url %} <a href="{{ url }}">{{ text }}</a> {% else %} <span>{{ text }}</span> {% endif %} </h{{ level|default(2) }}>

We have a simple title component that will print a title of anything you want. The level key allows us to change the heading level of the title (i.e. h1, h2, h3, etc.), and the modifier key allows us to pass a modifier class to the component, and the url will be helpful when our title needs to be a link to another page or component.

Currently the title component is not available in storybook. Storybook uses a special file to display each component as a story, the file name is component-name.stories.jsx.

• Inside title create a file called title.stories.jsx
• Inside the stories file, add the following:

/** * First we import the `html-react-parser` extension to be able to * parse HTML into react. */ import parse from 'html-react-parser'; /** * Next we import the component's markup and logic (twig), data schema (yml), * as well as any styles or JS the component may use. */ import title from './title.twig'; import data from './title.yml'; /** * Next we define a default configuration for the component to use. * These settings will be inherited by all stories of the component, * shall the component have multiple variations. * `component` is an arbitrary name assigned to the default configuration. * `title` determines the location and name of the story in Storybook's sidebar. * `render` uses the parser extension to render the component's html to react. * `args` uses the variables defined in title.yml as react arguments. */ const component = { title: 'Components/Title', render: (args) => parse(title(args)), args: { ...data }, }; /** * Export the Title and render it in Storybook as a Story. * The `name` key allows you to assign a name to each story of the component. * For example: `Title`, `Title dark`, `Title light`, etc. */ export const TitleElement = { name: 'Title', }; /** * Finally export the default object, `component`. Storybook/React requires this step. */ export default component;

• If Storybook is running you should see the title story. See example below:
• Otherwise start Storybook by running:

npm run storybook

With Storybook running, the title component should look like the image below:

The controls highlighted at the bottom of the title allow you to change the values of each of the fields for the title.

I wanted to start with the simplest of components, the title, to show how Storybook, with help from the extensions we installed, understands Twig. The good news is that the same approach we took with the title component works on even more complex components. Even the React code we wrote does not change much on large components.

In the next blog post, we will build more components that nest smaller components, and we will also add Drupal related parts and configuration to our theme so we can begin using the theme in a Drupal site. Finally, we will integrate the components we built in Storybook with Drupal so our content can be rendered using the component we're building. Stay tuned. For now, if you want to grab a copy of all the code in this post, you can do so below.

Download the code

Resources

• Storybook docs
• How to write stories
• Single Directory Components
• Storybook Drupal module

In closing

Getting to this point was a team effort and I'd like to thank Chaz Chumley, a Senior Software Engineer, who did a lot of the configuration discussed in this post. In addition, I am thankful to the Emulsify and Gesso teams for letting us pick their brains during our research. Their help was critical in this process.

I hope this was helpful and if there is anything I can help you with in your journey of a Storybook-friendly Drupal theme, feel free to reach out.

Images are an essential part of a website. They enhance the appeal of the site and make the user experience a more pleasant one. The challenge is finding the balance between enhancing the look of your website through the use of images and not jeopardizing performance. In this guide, we'll dig deep into how to find that balance by going over knowledge, techniques and practices that will provide you with a solid understanding of the best way to serve images to your visitors using the latest technologies and taking advantage of the advances of web browsers in recent years.

Hi, I hope you are ready to dig into responsive images. This is a seven-part guide that will cover everything you need to know about responsive images and how to manage them in a Drupal site. Although the excercises in this guide are Drupal-specific, the core principles of responsive images apply to any platform you use to build your sites.

Where do we start?

Choosing Drupal as your CMS is a great place to start. Drupal has always been ahead of the game when it comes to managing images by providing features such as image compression, image styles, responsive images styles and media library to mention a few. All these features, and more, come out of the box in Drupal. In fact, most of what we will cover in this guide will be solely out of the box Drupal features. We may touch on third party or contrib techniques or tools but only to let you know what's available not as a hard requirement for managing images in Drupal.

It is important to become well-versed with the tools available in Drupal for managing images. Only then you will be able to make the most of those tools. Don't worry though, this guide will provide you with a lot of knowledge about all the pieces that take part in building a solid system for managing and serving responsive images.

Let's start by breaking down the topics this guide will cover:

1. What are responsive images?
2. Art Direction using the <picture> HTML element
3. Image resolution switching using srcset and sizes attributes
4. Image styles and Responsive image styles in Drupal
5. Responsive images and Media
6. Responsive images, wrapping up

What are responsive images?

A responsive image is one whose dimensions adjust to changes in screen resolutions. The concept of responsive images is one that developers and designers have been strugling with ever since Ethan Marcotte published his famous blog post, Responsive Web Design, back in 2010 followed by his book of the same title. The concept itself is pretty straight forward, serve the right image to any device type based on various factors such as screen resolution, internet speed, device orientation, viewport size, and others. The technique for achieving this concept is not as easy. I can honestly say that over 10 years after reponsive images were introduced, we are still trying to figure out the best way to render images that are responsive. Read more about responsive images.

So if the concept of responsive images is so simple, why don't we have one standard for effectively implementing it? Well, images are complicated. They bring with them all sorts of issues that can negatively impact a website if not properly handled. Some of these issues include: Resolution, file size or weight, file type, bandwidth demands, browser support, and more.

Some of these issues have been resolved by fast internet speeds available nowadays, better browser support for file tyes such as webp, as well as excellent image compression technologies. However, there are still some issues that will probably never go away and that's what makes this topic so complicated. One issue in particular is using poorly compressed images that are extremely big in file size. Unfortunately often times this is at the hands of people who lack the knowledge of creating images that are light in weight and properly compressed. So it's up to us, developers, to anticipate the problems and proactively address them.

Ways to improve image files for your website

If you are responsible for creating or working with images in an image editor such as Photoshop, Illustrator, GIMP, and others, you have great tools at your disposal to ensure your images are optimized and sized properly. You can play around with the image quality scale as you export your images and ensure they are not bigger than they need to be. There are many other tools that can help you with compression. One little tool I've been using for years is this little app called ImageOptim, which allows you to drop in your images in it and it compresses them saving you some file size and improving compression.

Depending on your requirements and environment, you could also look at using different file types for your images. One highly recommended image type is webp. With the ability to do lossless and lossy compression, webp provides significant improvements in file sizes while still maintaining your images high quality. The browser support for webp is excellent as it is supported by all major browsers, but do some research prior to start using it as there are some hosting platforms that do not support webp.

To give you an example of how good webp is, the image in the header of this blog post was originally exported from Photoshop as a .JPG, which resulted in a 317KB file size. This is not bad at all, but then I ran the image through the ImageOptim app and the file size was reduced to 120KB. That's a 62% file size reduction. Then I exported the same image from Photoshop but this time in .webp format and the file size became 93KB. That's 71% in file size reduction compared to the original JPG version.

A must have CSS rule in your project

By now it should be clear that the goal for serving images on any website is doing it by using the responsive images approach. The way you implement responsive images on your site may vary depending on your platform, available tools, and skillset. Regardless, the following CSS rule should always be available within your project base CSS styles and should apply to all images on your site:

img { display: block; max-width: 100%; }

Easy right? That's it, we're done 😃

The CSS rule above will in fact make your images responsive (images will automatically adapt to the width of their containers/viewport). This rule should be added to your website's base styles so every image in your website becomes responsive by default. However, this should not be the extend of your responsive images solution. Although your images will be responsive with the CSS rule above, this does not address image compression nor optimization and this will result in performance issues if you are dealing with extremly large file sizes. Take a look at this example where the rule above is being used. Resize your browser to any width including super small to simulate a mobile device. Notice how the image automatically adapts to the width of the browser. Here's the problem though, the image in this example measures 5760x3840 pixels and it weights 6.7 MB. This means, even if your browser width is super narrow, and the image is resized to a very small visual size, you are still loading an image that is 6.7 MB in weight. No good 👎

In the next post of this series, we will begin the process of implementing a solution for handling responsive images the right way.

Navigate posts within this series

• Art Direction using the <picture> HTML element

If you've experienced issues or are worried about deploying changes to production, on a Friday or another day, when did you last deploy something?

Can you make deployments smaller and more frequent?

Deploying regularly makes each deployment less risky and having a smaller changeset makes it easier to find and fix any issues that arise.

I'm much happier deploying to production if I've already done so that day, or at least that week.

Any time more than that, or if the changeset is large, the more likely there will be issues and the longer it will take to resolve them.