Progressive Web Apps (PWA) provide an enhanced user experience by combining the features of web and mobile applications. For Drupal developers, integrating a PWA can transform a website into a high-performance mobile application. This article offers a technical approach to achieving this integration.
This is the second part of a series of articles looking at the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.
In the previous article we looked at how to setup the batch process using a form, with the batch methods being contained within the structure of the form class. When the form was submitted the batch process ran through 1,000 items and then printed out a result at the end.
Whilst there is nothing wrong with running the Batch API with everything in a form class, it is normally better to abstract the batch processing code into a separate class.
Using a separate batch class to contain the process and finish methods is a much better way of setting things up as it allows you to abstract away the batch process from the action that starts it. This means that you can start the batch from anywhere, even a Drush command.
Allowing you batch processes to be run via Drush is a really powerful feature for a module to include. It means that any big process that can be run by a user can be run automatically via a Drush command.
To create a batch class I normally create a directory called "Batch" inside the module "/src" directory that contains any batch class I need to define. The contents of the class are the two batch methods from the form class used previously, namely the batchProcess() and batchFinished() methods.
The following shows the basic structure of this class.
Due to concerns that the launch button would funnel business to one vendor at the expense of others, Starshot leadership announced that the launch button would use WebAssembly to run site trials in a user’s browser without external hosting. This approach has the advantages of being able to run Drupal off line and not needing anyone to pay for hosting. However, it is technically challenging and will not work for everyone. Sites running in WebAssembly cannot be visited by others and are not persistent.
Darren Oh Fri, 08/30/2024 - 15:40The first prominent leap forward this week was built by Harumi “hooroomoo” Jang: they added the ability to Experience Builder (XB) to first pick the location to add a component to, and then pick the component, rather than only the other way around:
Hovering a section (XB calls top-level components sections) now offers placing another section and triggers the component list form.Clearly, it’s important to support both paths towards placing a component!
Great news: this week, Bálint “balintbrews” Kléri joined the team working on XB full-time :) Satisfyingly, he landed an improvement that he started working on as a volunteer contributor: #3458535: Middle click + drag doesn’t work correctly if middle click is inside preview iframe.
Utkarsh “utkarsh_33”, syeda-farheen, Harumi and Jesse “jessebaker” Baker fixed the undo/redo functionality and added end-to-end tests, ensuring that XB cannot regress anymore on that essential functionality.
Ben “bnjmnm” Mullins and I collaborated to overhaul XB’s all-props test-only Single-Directory Component (SDC), whose purpose is solely to exercise the full spectrum of prop shapes (JSON schemas) that SDC can use:
The all-props test-only SDC facilitates testing/developing missing pieces of XB: it makes it easy to see the editing UX that is generated for a particular SDC prop shape.Last week, we landed component previews, and that was a big leap forward! We firmly believe in rapid iteration, and landing something as soon as it’s at least partially usable, rather than polishing it to perfection — for a mature codebase like Drupal core that makes sense, but not for something that is still in its infancy, like XB. So, unsurprisingly, we found an (obvious) bug: the preview caused styles to bleed:
Notice how pink outlines appear everywhere as soon as the Hero component is previewed — that’s obviously not the intent! :DJesse, Utkarsh and Gaurav “gauravvvv” used shadow DOM to properly encapsulate this.
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!
Back during week 3, Lee “larowlan” Rowlands opened an issue to create an OpenAPI spec for the (then) mock HTTP responses. Back then, the client (React, JS) and server (PHP, Drupal module) were being developed completely independently. Because things were still moving so rapidly back then, some request or response shape was changing almost daily, and nobody had OpenAPI experience … it sadly didn’t become a priority.
then, in the past ~5 or so weeks, having an OpenAPI spec that both the mocks and the actual server responses were validated against would have prevented several problems, and would have boosted productivity.
Thankfully, Philip “pfrilling” Frilling had already gotten significant parts working (and he was able to reuse Lee’s work on the Decoupled Layout Builder API module!). It was not yet mergeable because it didn’t validate the actual server responses yet.
So I started pushing it forward and ran into PHP dependency hell, was able to fix that, and then got us onto OpenAPI 3.1.0 (instead of 3.0.0), enabling XB’s openapi.yml to use patternProperties, without which we actually cannot express all of XB’s response shapes.
Hurray! A whole class of productivity blockers gone! (And Lee was right all along, of course.)
Last week’s StorablePropShape worked okay, but Ted “tedbow” Bowman’s work on #3446722: Introduce an example set of representative SDC components; transition from “component list” to “component tree” revealed an interesting edge case: JSON object keys are always strings, so 50 is encoded as '50', meaning … the type is changed, and information is lost. Fortunately, Drupal core solved this a decade ago: we (re)discovered Drupal core’s ::storageSettingsFromConfigData(), which was added for precisely this purpose! A simple fix by Utkarsh “utkarsh_33” later, and we were good to go :)
That wasn’t the only problem #3446722 surfaced: we figured out why exactly the JSON schema validation refused to accept a sample value generated by Drupal core’s uri field type … and it turns out that’s simply because that field type indeed generates invalid URIs! We worked around it by swapping the class and overriding the logic to generate valid sample values. 1
In other words: matching the SDC props’ type information (expressed as JSON schema) against Drupal’s Typed Data/Entity/Field/Field Property type information (expressed as DataType plugins + validation constraints) is definitely revealing interesting problems that probably nobody else has been running into :D
P.S.: we set a new record by a significant margin this week: 16 MRs merged!
Week 13 was August 5–11, 2024.
We’ll eventually create upstream issues in Drupal core, but first we’re working accumulating a range of these kinds of problems, to identify the best strategy to fix this upstream. We’re now at ten overrides for field type classes, for a variety of reasons — most for missing validation constraints and/or incorrect field property class implementations. ↩︎
Hovering a section (a top-level component) now offers placing another section and triggers the component list form.The all-props test-only SDC facilitates testing/developing missing pieces of XB: it makes it easy to see the editing UX.Notice how pink outlines appear everywhere as soon as the Hero component is previewed.This week was all about catching up on notifications and open PRs from last week, and creating a mega amount of new PRs.
Dries Buytaert announced recently that the product name for the result of the Drupal Starshot Initiative will be Drupal CMS. Exciting! Activities on features for Drupal CMS are divided into tracks - a set of deliverables focused to provide valuable solutions for different parts of the product strategy.
Let’s see what’s cooking in the Drupal CMS kitchen as since the announcement of the track leads, quite some work has been done. We are happy to share a brief overview to highlight the progress made!
The Events Track has been busy with transferring the Events recipe to the Drupal CMS and now we’ve got the beginnings of an event system. As with all the Drupal CMS components, the ultimate plan is for each one to be available as its own project, but at the same time all be developed within the same repo.
The Data Privacy / Compliance Track is busy developing a survey for the international audience. We are looking forward to sharing it with the community very soon.
The Trial Experience Track in coordination with the Drupal Association has devised a solution to leverage GitLab Pages. After checking in with the rest of the Drupal CMS team, it was decided the trial codebase would be added to the monolithic repository. You can find more details at the dedicated blog post by Matt Glaman.
The Starshot Demo Design System initiative is supporting the Experience Builder demo next month by providing Drupal-branded components within a design system theme. The team has made excellent progress and needs more help in the next two weeks to test components within Experience Builder. Learn how to get involved!
The SEO Track managed to add Basic SEO recipe to Drupal CMS. This recipe will be applied by default, is idempotent (can be applied multiple times), and sets the simple best practices configuration we feel every site needs. The team is continuing to work to define an advanced SEO recipe that we will propose to be optional that has more tools for optimizing for search engines.
The Advanced Search Track has drafted a proposal for the track. It is being reviewed by the leadership team and the idea is to provide a recipe for at least two different approaches and collect community feedback. We expect this to happen in September so stay tuned!
The Media Management Track is undertaking discovery to gather common practices and new insights that will lead to a proposal for the features and recipes for media in early versions of Drupal CMS. The track will also propose how improvements and innovations could look for media beyond the launch of Drupal CMS. Tony Barker has created a survey as part of the discovery and welcomes the community to provide their thoughts and feelings on media in Drupal using this form.
We are observing the progress each track team is making with excitement and will keep you up to date on upcoming developments!
