My Monday started with a pleasant surprise that is only possible in cross-timezone collaborations: Ted “tedbow” 1 had made a huge leap forward on #3450957: Prevent modules from being uninstalled if they provide field types used in an Experience Builder (XB) field, where he’s working on the first aspect where XB’s JSON blobs in the database must be queried.
Drupal 11 requires versions of databases that support JSON querying. Ted rather quickly discovered that JSON querying support is not consistent across different databases … but fortunately Brad “bradjones1 is working on #3343634 to add explicit JSON support to Drupal’s database abstraction layer, which is one of the endeavors sponsored by Pitch-Burgh! So: database nerds, unite!

(That means reviewing Brad’s work in that issue is yet another way of contributing to XB — in addition to helping Single Directory Components (SDC) move forward.)

To ensure we are aware of what works on which database from day one, I updated XB’s CI pipeline to run the test suite against MariaDB+MySQL+PostgreSQL+SQLite.

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!

Later on Monday, Ben “bnjmnm” and Jesse landed an MR that starts to connect the UI that you saw two weeks ago to the back end, and brought it alive: there’s now a tree view to provide a sense of place on the canvas, and much more:

Try it yourself locally if you like, but there’s not much you can do yet.
Install the 0.x branch — the “Experience Builder PoC” toolbar item takes you there!

A day later, the first set of unit tests landed: those for StructuredDataPropExpressions (these express where to retrieve values mapped for SDC props).

On Thursday, Harumi “hooromoo”’s MR to provide the foundations for undo/redo support landed, after the most enthusiastic approval I think I’ve ever seen Lee “larowlan” give! :D

That same day, his colleague Griffyn “griffynh” ran the second asynchronous XB meeting in Drupal Slack (archive on d.o: #3453097), this time with 21 participants of the ~250 people in the #experience-builder channel (~100 more compared to 2 weeks ago).
The most heavily debated topics were the data model/persistence layer and Cypress vs vitest for tests.

By Friday, I managed to finish up the work that I already shared a video of a week prior (see week 3), where a PropSource (which itself uses a PropExpression) can be chosen for each component prop and edited using Drupal’s existing Field Widgets. Crucially, it now includes a fully annotated end-to-end test that verifies the demo in detail:

• an article using an XB field can be created
• expected data is stored for the XB field, with a handful of placed components, and all prop source types: static, dynamic and adapter
• each of these prop sources can be evaluated/resolved to a concrete value to pass into the corresponding SDC prop
• each of the placed components renders into the expected HTML

In other words: it’s making the concrete implementation of #3440578: JSON-based data storage proposal for component-based page building tangible and debuggable in a way that required reading dozens of files previously! 2

Thanks to Ted & Lauri for reviewing this!

1. Forever infamous for his shining sunglasses moment on stage during DrupalCon Pittsburgh — captured it in exquisite detail by Mike “mherchel”! ↩︎

2. Hence it’ll serve as a canary for the data model/storage back-end infrastructure in the short–medium term. ↩︎

• Drupal
• Acquia
• Experience Builder

• The XB UI now gained a tree view in the left sidebar that provides a sense of place, and is kept in sync with the canvas.

Taking a dive into the deep, dark quagmire of life

Some people have career aspirations from a young age, but for the rest of us, discovering a career-worthy passion, or even learning how to distinguish a job from a career, can take some time. I was nearly ten years into a job in finance (managing insurance/retirement/wealth-building products) when I finally admitted to myself that I couldn’t do it anymore. I felt like I should have a career, not just a job. I wanted to feel proud of the way I spent my days.

Diving in

After some soul-searching, I signed up for a Full-Stack Web Development bootcamp. I was never the kid who tinkered with code or tried to see how my AOL Instant Messenger worked (yes, I was a kid of the 90s) - but I suddenly found myself fascinated with the combination of language, math, and puzzle that was hiding in my browser’s Inspect tool. The bootcamp’s cost made this a risky prospect, but it also made me more likely to commit fully. I can’t say I loved every moment of the grind; working full-time, raising three kids (whom I had adopted just two days into the bootcamp), attending evening classes, keeping up with homework, and maintaining sanity was not always the easiest, but I tend to thrive in chaos. I learned the MERN Stack (MongoDB, Express.js, React, and Node), and after six months I left the bootcamp with one of the highest scores in my class and even higher hopes.

Cue the mass tech layoffs of late 2022, pitting my emerging knowledge against developers with years of experience at tech giants such as the site formerly known as Twitter. My understanding of code was evident, but my ability to explain code was underdeveloped, leaving me flailing in interviews and unable to find anyone willing to take a chance on me. Anyone, that is, until my local Women Who Code chapter posted about Palantir.net’s fellowship program. I applied, spent three months learning Drupal through DrupalEasy's Drupal Career Online program, and started an internship with Palantir.net. That internship turned into a full-time engineering role, and now I’m creating innovative tech and building professional websites from scratch.

Going deep

How could I transition from finance to React/JavaScript to Drupal/PHP in such a short time? Same way I managed to learn French — its proximity to English based on its Latin roots gave me a leg up. Both JavaScript and PHP are Object-Oriented languages, meaning they derive from making real-world objects into code. Object-Oriented Programming, or OOP, is a paradigm that encompasses several coding languages, and since I already had a base in OOP via JavaScript, I mainly needed to learn the syntax of PHP as the concepts were mostly the same. Not only are the languages similar, but the overall folder structure and architecture of both Drupal and React can be set up using the same patterns. I quickly noticed my new Palantiri teammates using the MVC (Model-View-Controller) architecture, which I was already comfortable with.

Another benefit of that MVC architecture is its collaborative nature. By separating sections of the code based on functionality, different people could work simultaneously on building one piece of a site without risking overwriting one another. React most prominently offers collaboration through its separation of interests via Components, delivering an end product to users, while Drupal is set up to not only be collaboratively built, but to allow site builders to delegate content creation, and even site administration, to users.

Surfacing from murky depths

Perhaps the coolest thing I discovered through this journey is the ability to create a site harnessing the powers of both Drupal and React! Drupal’s Content Management System structure creates a powerful backend for React’s simple and extensive front-end library. This just leaves me with the accessibility question - how can we make Drupal a more popular and attainable technology for entry-level developers? According to Statista’s data analytic survey, Drupal ranks 29th among the most-used frameworks among developers worldwide as of 2023. In the same survey, React ranked second only to Node, which is another JavaScript framework.

I think we can find a path for learners of all types, we just need to harness the power of our community to get there. We are not in competition with React or Wordpress or any other framework, Drupal is just another tool that people should have an opportunity to explore at any level. Who knows? Maybe they’ll fall in love like so many others have.

Calm waters

I love the glimmer of awe in people’s eyes now when I tell them I’m a software engineer. I can’t say the path was easy, but I’ve never regretted making the career change, and I never tire of continuing to suck up every ounce of knowledge I can find. I love the curiosity and creativity that I can bring to work with me every day, bouncing from front-end to back-end work, developing brand new technologies, and exploring every little thing that interests me. I’m happy to say I have found my career. 

Authored by Nadiia Nykolaichuk, João Paulo Constantino, Ana Carolina, and Gabriel Passarelli.

People always want to predict the future. They say that is not good, but this doesn't apply to the Drupal 2024 trends. Undoubtedly, Generative Artificial Intelligence will shape tech trends and stimulate further progress in the website development industry.
However, there are other matters worth paying attention to. Mintz, World Wildlife Fund, Chupa Chups, Mattel, and other prominent Drupal websites won’t sit idly by viewing this chaos of innovations and advancements.
Now is the time for unique insights with Golems web development agency about what Drupal 2024 will be like. The more aware you are of prospective game-changing rules, the more up in arms you will act in SEO, marketing, and business growth strategies. Stay tuned to take a sneak peek into the future!

Authored by Nadiia Nykolaichuk, João Paulo Constantino, Ana Carolina, and Gabriel Passarelli.

When a new major version of Drupal is released, custom code often requires updates to align with API changes, including the removal of deprecated APIs.

Because I keep forgetting certain aspects of this workflow, I decided to document it for future reference.

Tools overview

Upgrade Status module

The Upgrade Status module assesses a Drupal site's readiness for major version upgrades by checking for deprecated code and other compatibility issues.

1. Install the Upgrade Status module like you would install any other Drupal module:

   [code bash]$ ddev composer require –dev drupal/upgrade_status[/code]

   Here, ddev is the tool I prefer for managing my local development environment. composer is a dependency manager for PHP, commonly used to install Drupal modules. The –dev option specifies that the module should be installed as a development requirement, meaning it is necessary for development environments but not installed on production environments.

2. Enable the Upgrade Status module:

   [code bash]$ ddev drush pm-enable upgrade_status[/code]

   drush stands for "Drupal shell" and is a command-line utility for managing Drupal sites. The command pm:enable (where pm stands for "package manager") is used to enable a module in Drupal.

3. After enabling the module, you can access its features by navigating to the Admin > Reports > Upgrade status page at /admin/reports/upgrade-status.

Upgrading PHP and MySQL using DDEV

The Upgrade Status module might recommend updating PHP and MySQL, per Drupal's system requirements.

To update the PHP version of DDEV, use the following command:

To upgrade the MySQL version of DDEV and migrate your database content, use the following command:

After updating these settings, I restart DDEV and run my PHPUnit tests. Although these tests are integrated into my CI/CD workflow, I also run them locally on my development machine using DDEV for immediate feedback.

Drupal Check

Drupal Check is a command-line tool that scans Drupal projects for deprecated code and compatibility issues.

1. Installation:

   [code bash]$ ddev composer require –dev mglaman/drupal-check[/code]

2. Run Drupal Check from the root of your Drupal installation:

   [code bash]$ ./vendor/bin/drupal-check –memory-limit 500M docroot/modules/custom[/code]

   I usually have to increase the memory limit, hence the --memory-limit 500M.

How to make use of OpenSearch (and Elasticsearch) built-in data-types specifically designed for filtering and sorting date ranges.

It's fairly common to have content with a date range. E.g., events or content that is only applicable for a given date.

Sorting and filtering results by date can be complicated, especially if you have to support features such as multiple date ranges and optional end dates.

But OpenSearch (and Elasticsearch) have data types specifically designed for this use case.

The key here is to index your data using a Range field type.

Let's consider an example we recently built for NSW.gov.au. The requirements for the field were as follows:

• Index a grant content-type
• The grant content-type has a date-range field
• The field has optional end dates via the Optional End Date module
• The field is multi value
• There is also a boolean 'Grant is ongoing' field that flags the grant as 'Evergreen'

The filtering requirements include a 'Status' field, which has options for:

• Open - the current date must fall inside one of the date-range values
• Closed - the current date is after date-range values
• Opening soon - the current date falls inside a future date range

Additionally, the search results should be sorted in the following order when no keywords exist:

• Open
• Opening soon
• Closed

Defining a date range field in Drupal/Search API

The first step is to inform Search API about the date-range data type. How you do this will depend on whether you're using Elasticsearch connector or Search API OpenSearch.

If you're using Search API OpenSearch, the good news is that it is already supported in the 2.x branch.

If you're using Elasticsearch connector, you should implement hook_elasticsearch_connector_supported_data_types_alter and add date range as a data-type - something like this

If you're using Elasticsearch connector, you also need a processor plugin to put the field values into the index. You can take inspiration from how Search API OpenSearch achieves this.

Indexing Drupal data

Once you have those pieces in place, you simply need to configure your date field to use the Date Range data type in the Search API index.

Constructing the queries

With the data in your index, the only thing left is to construct your queries to make use of the date range data-type.

In these examples, we'll assume your date-range field is called 'application_dates', that the field is multi-value and that the end date is optional.

We will use 1710201396000 as the current timestamp (in epoch microseconds).

Filtering to 'open'

This one is the simplest. You need a new term query that uses the current date

For a date-range field, the use of a term query will match any document where the given value is between the start and end of the range.

Filtering to 'closed'

This one is a bit more involved. We need to combine some conditions

First, we have a should, which is an OR query in OpenSearch parlance. We're saying the grant must not have any future open dates (gte: 1710201396000) AND must not be flagged as ongoing. Then we're saying all of the application dates should be in the past (lte: 1710201396000).

Filtering to 'opening soon'

Here again, we need multiple conditions.

First, we are saying there must be at least one date where the date range is in the future (gte: 1710201396000) and that the grant must not be ongoing OR have any date ranges that match the current date (term: 1710201396000) (i.e. are open).

Sorting

Sorting is a little more complex. We can make use of filters in our sort expressions.

To do this, we also need to index our date-range as an object so we can use nesting.

We duplicate the application_dates field to an application_dates_sort field and make this use the nested data-type. The mapping will look like this

Then, we can make use of this in our sort expressions. E.g. to have open items appear first, we can use

What we're doing here is sorting by the opening date, ascending, but using a filter to only match on records where the current date falls between the start/end date. We're telling OpenSearch to put any objects that don't match (missing) at the end.

We can stack sort expressions like this — subsequent expressions will apply to those that were 'missing' from the first sort. Combining these lets us achieve the desired sort order of opening -> opening soon -> closed.

Wrapping up

OpenSearch is pretty powerful. But to make the most of its features, you need to ensure your data is mapped into the right data-type. Using date-range fields for storing date-ranges takes a little bit of extra planning, but it leads to much more efficient queries and a better experience for your users.

Tagged