fidzu : Drupal

Search Across Multiple Drupal Sites with Pantheon SOLR

Joel Steidl Thu, 06/18/2026 - 13:34 Drupal

composer require drupal/search_api_pantheon drupal/pantheon_solr_api
drush en search_api_pantheon pantheon_solr_api

composer require drupal/search_api drupal/search_api_solr drupal/search_api_solr_proxy
drush en search_api search_api_solr search_api_solr_proxy_pantheon_connector

drush pantheon-solr-proxy:register

drush pantheon-solr-api:update-index

Joel Steidl

18 Jun 2026 7:34pm GMT

B2C eCommerce usually gets all the attention, because that's what most people engage with. They buy stuff from Amazon, Etsy, or a Shopify store without thinking too much about it. The customer comes to the website and makes a purchase. Usually, there is a portal to track the order and some transactional emails for updates, and finally, the package is delivered to their door. If they bought from a company that has its act together, they might spend the next 3-6 months being remarketed to because the company really wants to make this customer a repeat customer.

But this B2C eCommerce experience, while ubiquitous and recognizable to most, is only scratching the surface.

The scale of B2B commerce is actually much larger than its B2C cousin. The global B2B eCommerce market is expected to reach roughly $37 trillion in 2026, approximately six times the size of the global B2C market. Yet despite that enormous footprint, B2B digital commerce remains far less mature than its B2C counterpart. Software that serves the latter doesn't work for the former. The differences between B2B and B2C commerce run deep, from how deals get made to how orders get shipped to how platforms are architected. Different customers. Different requirements. Different expectations. To add further complications, businesses increasingly need to operate in both worlds simultaneously.

Read more

18 Jun 2026 2:50pm GMT

18 Jun 2026 2:04pm GMT

Markdown has become a practical drafting format for Drupal teams working across notes apps, code editors, documentation systems, and AI-assisted writing tools. Jorge Tutor's CKEditor5 Markdown module addresses the handoff into Drupal by converting pasted Markdown through an explicit editor dialog, then letting CKEditor5 enforce the active text format's HTML rules. In written responses to The DropTimes, Tutor framed the module as a narrow fix for teams that want Markdown during drafting but not as the stored or rendered content format.

18 Jun 2026 6:27am GMT

DrupalCon Rotterdam is one of those events that naturally attracts attention across the Drupal ecosystem. Not only because it brings the community together, but because it creates a space where technology, strategy, contribution and real-world digital projects meet.

For anyone working with Drupal, open source or digital experience platforms, the question is not just "what happens at DrupalCon?", but it might be: "If you have never been before, why should this be the year to go?"

Image

^{Photo by Joris Vercammen}

Why Rotterdam?

Rotterdam feels like a strong fit for an event like DrupalCon. It is a city known for innovation, architecture, international connections and a forward-looking mindset - qualities that align naturally with the spirit of the Drupal community.

Bringing DrupalCon to Rotterdam creates an opportunity to connect the European Drupal community in a dynamic and accessible setting. It also gives professionals from different markets the chance to meet, exchange perspectives and discuss how Drupal continues to evolve in a fast-changing digital landscape.

Learning from real experience

One of the strongest reasons to attend DrupalCon is the quality of the knowledge shared by the community.

This is not only about product updates or technical presentations, It is about learning from people who are building, maintaining and improving digital platforms in real contexts, often with complex requirements, long-term governance needs and ambitious user experience goals.

From technical sessions to strategic case studies, DrupalCon gives attendees access to practical insight that is difficult to get from documentation alone.

Meeting the community behind Drupal

Drupal has always been more than a content management system; It is an open-source project supported by a global network of contributors, companies and professionals.

For someone who has never attended before, this is one of the most compelling reasons to go: Online discussions, issue queues and documentation are valuable, but meeting people face to face adds a different layer to the experience.

Conversations during sessions, between talks or at community events can lead to new ideas, partnerships and a better understanding of how others approach similar challenges.

Image

^{Photo by Matthew Saunders}

Inspiration beyond the technical track

DrupalCon is also a place to see what organisations are doing with Drupal today.

Real-world examples often show the platform's value more clearly than feature lists. They reveal how Drupal is being used to support public sector platforms, media websites, higher education, enterprise ecosystems, multilingual content, accessibility requirements and complex editorial workflows.

That is why DrupalCon is relevant beyond development, project managers, designers, UX professionals, marketers, content teams and business leaders can all find useful perspectives on delivery, governance, accessibility, platform strategy and the role of open source in long-term digital transformation.

Why attend for the first time?

Attending DrupalCon for the first time is a way to move from observing the community to being part of it.

It is an opportunity to learn from experienced professionals, understand the direction of the platform, discover practical use cases and build connections that can continue long after the event ends.

DrupalCon Rotterdam represents more than another event in the digital calendar, It is a chance to understand Drupal through the people and projects that keep it moving forward.

For a first-time attendee, that may be the strongest reason to go.

Because sometimes the best way to understand the value of a community is not to read about it from the outside. It is to be in the room where that community comes together.

See you there?
Register now!

- Article by Daniela Moreira

18 Jun 2026 5:32am GMT

17 Jun 2026 6:58pm GMT

// Only allow URL discovery from example.com.
$settings['media_oembed_discovery_trusted_host_patterns'] = [
  '^example\.com$',
];

17 Jun 2026 6:57pm GMT

17 Jun 2026 6:57pm GMT

17 Jun 2026 6:57pm GMT

17 Jun 2026 6:56pm GMT

QED42 has opened a waitlist for EventHorizon, a Drupal-focused code-intelligence suite built on the scanning engine behind its open-source EventHorizon CLI. The CLI runs static analysis locally without AI, cloud upload, or telemetry, addressing audit environments where client code is covered by NDAs, data residency clauses, and security review. The broader suite adds visual dependency maps, code health views, and optional AI through user-controlled provider keys.

17 Jun 2026 1:07pm GMT

Cypress is ideal for testing Drupal content moderation, but the learning curve is rather steep. Well, with the cypress-json-tests package, you can be done within a couple of hours.

17 Jun 2026 12:00pm GMT

The Drupal marketplace is driving a shift toward high-quality, accessible, and easily maintainable templates tailored for specific industry verticals (like government, healthcare, and education).

17 Jun 2026 9:30am GMT

Good news for everyone still polishing their entry, we've extended the submission deadline for the International Splash Awards 2026 by four weeks. You now have until 16 July 2026 to submit your project.

As part of our commitment to a fair process, we want to give every Drupal community and agency ample time to put their best work forward. So we're opening the doors wider rather than closing them.

The Splash Awards celebrate the very best Drupal projects from around the world, with winners announced at DrupalCon Rotterdam 2026 (28 September - 1 October). Submitters will be notified of their status in early August.

Learn more & submit your project

Questions? Email drupal@kuonitumlare.com or reach us in #drupalcon_europe on Drupal Slack.

Image

17 Jun 2026 8:52am GMT

What an exciting time to be a developer. Over the past year, I've gradually begun adopting a number of AI tools to improve the quality of my work, be more efficient, and even dive into areas of development I had never been strong in.

The days of reading blog posts and tutorials or trying code challenges are over. Or are they?

I subscribe to a handful of technical newsletters which arrive in my inbox every week. I always look forward to learning about the new stuff, improvements to old stuff, or the exciting features or tools coming down the development pipeline. I read each one of them in their entirety and if I am too busy, I keep them in my inbox until I have the time to go through them. Sometimes this means I have two issues to read through because I have not been able to get the previous one. I never delete them until I am done with them.

Why waste my time when I can easily ask AI for help? The learning process is exciting for me, it always has been. In the AI era it might even be more important because what if AI is wrong? How do I know the code snippet I am provided is correct or won't cause regressions in my project? Maybe this is the reason I don't use front-end frameworks like Bootstrap or Tailwind in my projects. I have used them for prototyping, but never to dictate the direction or coding conventions in my project.

Let's take a look at a basic example that may seem trivial but could lead to major issues if not understood. Then we will dive into the real reason I decided to write this post.

HTML/CSS Block-level element vs. Inline-level element

If you know CSS really well you can skip these examples, but if you don't know what block-level and inline-level elements are in the context of HTML/CSS, you may run into issues with your code you'd think is not working when in fact it might be working as intended.

.block {
  display: block; /* 1 */
  margin: 24px;   /* 2 */
  padding: 24px;  /* 3 */
  width: 100px;   /* 4 */
}

display:block:

1. every side affects the layout.
2. all 4 sides push surrounding boxes.
3. all 4 sides expand the box.
4. width/height are honored.
5. breaks content flow by creating a line break (i.e. <p>, <div>, <h2>)

.inline {
  display: inline; /* 1 */
  margin: 24px;    /* 2 */
  padding: 24px;   /* 3 */
  width: 100px;    /* 4 */
}

display:inline:

1. only the horizontal axis affects layout.
2. left/right push adjacent inline content; top/bottom are IGNORED entirely.
3. left/right push adjacent content; top/bottom are PAINTED but reserve NO space - they don't push the lines above/below apart.
4. width / height have NO EFFECT.
5. does not break content flow (i.e. <a>, <span>, <img>)

.inline-block {
  display: inline-block;  /* 1 */
  margin: 24px;           /* 2 */
  padding: 24px;          /* 3 */
  width: 100px;           /* 4 */
}

display:inline-block:

1. best of both worlds, inline element with block characteristics.
2. all 4 sides reserve space.
3. all 4 sides reserve space.
4. width / height honored again.
5. it does not break content flow (i.e. any element with display: inline-block;)
6. because the element is inline, a whitespace of typically ~4px is rendered in your HTML. That's why a row of inline-block boxes set to width: 25% won't fit four-across.

Did you know all those specifics about the display CSS property? What if I didn't understand them and wondered why my layout is broken? What if I want to turn an inline-level element into a block-level element and vice versa? What would that do to my layout or spacing around elements?

The real example that validated my learning thirst

Here is when it became clear to me that you don't need to be an expert, but at the very least understanding your code can provide you with the ability to question AI's decisions and even push back on its recommendations.

The code challenge was relatively simple because I have done this many times, but this time it was at the end of my day and I was exhausted. So I figured I'd make use of AI to help me complete this task.

Build a Card component with SDC in Storybook

I'll focus on only the one piece AI and I had a disagreement on and had to have a heart-to-heart talk about; The card's cta link.

• As any typical card, I needed a title, image, label, and a link/cta field.
• The link needed a label (i.e. "Read the full article"), url, and an icon (svg).

AI built the component for me using Single Directory Component (SDC) conventions along with my custom Storybook's workflow and it worked as expected in Drupal and Storybook, but since this was one of the first components I was building in this new project, I decided that for the link's icon, I wanted to extract the inline SVG from the link.twig template and instead create an <svg>...</svg> asset out of it so I could re-use it in other components.

Originally, AI had opted to use Twig's source() function which is a valid and proper approach for inlining SVGs into components or Twig templates, however, I like to use {% include %} as it provides better cache management especially if I plan to use many icons on my site.

Here's the verbatim conversation about this "simple" change:

Me:
can we extract the icon's svg tag and create a file for it inside src/assets/images/? then twig include it in link.twig? this way we can reuse it in other components

Simple enough, except my project's workflow is unique in that SDC and Storybook share assets (twig, yml, css, js, images), to ensure there is a single source of truth. However, since this was a new project, I had not registered all the required namespaces for Drupal and Storybook to share assets.

AI:
Good call - {% include %} sidesteps source() entirely and avoids the namespace registration work in both Drupal and Storybook.

At this point AI proposed to write a theme hook to register a new Twig namespace Drupal could use to access assets directory.

The proposal of a theme hook to register a new Twig namespace was a NO NO for me because I knew it was not necessary. This takes me back to my original point of being able to understand the code to challenge AI proposed solutions that may not be necessary or an alternative/twig-friendly approach may do just fine.
I immediately questioned the proposal and provided a recommendation.

Me
how about adding a new namespace for drupal that points to src/assets so both storybook and drupal use the same path for assets?

AI
That's the cleanest approach. A single @assets namespace registered in both Storybook and Drupal means the same {% include '@assets/images/icon-arrow.svg' %} line works identically in both environments - no <theme-name>.theme hook needed at all

Needless to say, this was the right call and the final result was summarized by AI as:

AI

For me the main learning lesson of these simple yet real examples is that in the past, "knowing how to code" mostly meant knowing the syntax, semantics and understanding what you were writing. That part is becoming less critical with AI. But the more important skill, "knowing what not to write", hasn't changed. Avoiding poor tradeoffs, recognizing over-engineered or fragile solutions, those still require judgment. That judgment hasn't gone away; it's just being applied later in the process.

In closing

These are interesting times for developers. We don't yet know what this shift means for how we consume knowledge, but I do hope I never lose the desire to read, watch, and try new learning materials, and to still feel excited about them.

Happy learning! 📚

17 Jun 2026 12:00am GMT

An opportunity to help Web standards move in a good direction

theodore June 17, 2026

16 Jun 2026 9:00pm GMT