Core Conversations

Revamp Transactional Email in Drupal Core

znerol — Sun, 14 May 2023 10:20:20 +0000

Revamp Transactional Email in Drupal Core

Room

HS13 (2nd floor)

znerol Sun, 05/14/2023 - 12:20

Time Slot

Sat 10:00am to 10:45am (7/22/23)

Session length

Long session - 45min, including Q&A

Audience

Intermediate

Session Category

Innovation & The future

Drupal Core currently provides a very rudimentary API for sending transactional emails. This applies to both, the way emails are constructed (markup rendered to plaintext) as well as the way they are delivered (using the very limited PHP mail function).

A growing number of contrib projects are attempting to close this gap. However, to give site builders the tools they need to make their emails look good and work with modern email infrastructure, contrib projects must apply crude hacks to work around the limitations of the core mail API.

This session is a very short introduction into core and contrib mail APIs followed by a (hopefully) long Q&A where the audience is encouraged to bring in their PoV regarding the future of transactional email. The results of this session will ideally lead to a clear and broadly accepted plan for the next step on how Drupal core transactional email is going to be modernized in upcoming releases.

Speaker(s)

Lorenz Schori

Speaker biography

Lorenz Schori (znerol)

Passionate software developer at a swiss weekly newspaper. Occasional contributor to Drupal core and maintainer of a couple of contrib modules.

Session Keywords

Core Conversations

Why we moved the database drivers to their own modules

daffie — Sat, 22 Apr 2023 09:51:10 +0000

Why we moved the database drivers to their own modules

Room

HS13 (2nd floor)

daffie Sat, 04/22/2023 - 11:51

Time Slot

Fri 11:45am to 12:15pm (7/21/23)

Session length

Short session - 25min, including Q&A

Audience

Intermediate

Session Category

Innovation & The future

In Drupal 9.4 the database drivers for MySQL, MariaDB, PostgreSQL and SQLite were moved to their own modules. This session is about why we did that and what we want to do next.

We had a number of problems with the old situation:

1. Having contributed modules with a database driver copy their driver files to the directory drupal_root/drivers is not very composer friendly.

2. The database driver classes are unfortunately not enough to make Drupal work for a specific database. All database drivers need to override things like (views and other) plugins and entity storage classes. Those overrides need to live in a module

3. Tests are not always the same for every database driver. Those overrides also need to live in a module.

4. The by Drupal core supported database drivers are the example for contributed database drivers. Just like the Drupal core module and themes are the example for the contributed module and themes.

5. Database drivers should be able to extend another database driver. Just like modules can do.

Having the by Drupal core supported database drivers in their own modules makes it possible to do:

A. Create a new database driver for MySQL that allows queries to be run asynchronously. For instance with multiple blocks on a page, the block data can be loaded in parallel from the database instead of synchronously. PHP 8.1 has added the Fibers functionality and that allows I/O and database queries to run asynchronously. The database driver for MySQLi allows Drupal to use asynchronous queries.

B. Store content entity data in a document format. Content entity data is now stored in multiple tables and with a high number of entities, getting entity data out of the database will become slow. When used in combination with authenticated users and a lot of content, will result in Drupal becoming slow. Storing content entity data in a document format will make it fast again. The only database that a the moment has enough functionality to make it work with Drupal is MongoDB.
Using caching is great, but has it limitations. If we make hard Drupal calls a lot faster, we can use Drupal without any caching or with a lot less. PHP is fast enough for this. Databases are fast too. Only storing data following the relational database rules makes will result in complicated queries for getting the data out of the database. Complicated queries with large amounts of data will result in a performance nightmare. That is why we are using so much caching with Drupal sites. For anonymous users this is not a problem, only with authenticated users is caching a lot of times not possible. The solution is to store content entity data in a document format. In that way we almost always can get the data out of the database with a simple query (and therefor a fast query). When all queries are simple queries, the resulting Drupal page call will be fast.

I have already build a database driver for MongoDB. The driver is in the form of a Drupal module and the project can be found here: https://gitlab.com/daffie/mongodb867. It is based on Drupal 8.6.7 it hacks Drupal core with a >1.5 MB patch file. This is totally not maintainable. To fix that problem I have started to work on Drupal core to make the MongoDB database driver module work without patching/hacking Drupal core.

I would like to end with a group discussion about what we want to do next. What does the group think. Do they have other/new ideas. Hopefully get other people involved in what is next. This can also happen after the official session.

Speaker(s)

David Bekker

Drupal developer at Finalist

Speaker biography

David Bekker

I am the main contributor in having the database drivers moved to their own modules, I am also the subsystem maintainer for the Database API and I have over 500 Drupal core commit credits.

Session Keywords

So I logged in, now what? The Dashboard initiative welcomes you

penyaskito — Sat, 22 Apr 2023 04:42:03 +0000

So I logged in, now what? The Dashboard initiative welcomes you

Room

HS1 (Ground level)

penyaskito Sat, 04/22/2023 - 06:42

Time Slot

Thu 11:45am to 12:15pm (7/20/23)

Session length

Long session - 45min, including Q&A

Audience

All Attendees

Session Category

Innovation & The future

When you log in into a Drupal Site, by default you land on a mostly empty page which shows you how old your account is in the site. That’s not the best UX out there.

We aim to provide users with useful information and commonly used actions by default in Drupal core.

But different personas have different needs, so we had to go deep into the needs of the provided roles in the Drupal standard profile together with the Personas Initiative, but taking into account what other needs the Drupal community might have. That’s how the Dashboard initiative was born.

Dashboards will provide a better and personalized experience giving the opportunity to get at first glance information in an easily understandable format, even consisting of charts, graphs, and other visual aids.

In this session we will share with the audience the joy of our achievements, tell stories about our journey, and gather feedback about what’s next. There are ways everyone can contribute too, and we will point the audience about what’s needed to get our goal and how they can help.

Speaker(s)

Christian López Espínola

Cristina Chumillas

Senior Frontend Developer at Lullabot

Speaker biography

penyaskito

Christian is a Drupal contributor previously known for being involved in the Drupal 8 Multilingual initiative, and the Migrate initiative. Now trying to get these beautiful dashboards in core. These days he is freelancing.

ckrina

Cristina is a Provisional Front-end framework manager, Usabiity and Claro maintainer, and a lot of other things for the Drupal project. She works as a Senior Frontend Developer at Lullabot.

Session Keywords

Core Conversations

Drupal future

CKEditor 5: One Small Step for Content Editor, One Giant Leap for Drupal

Vladimir R — Mon, 10 Apr 2023 08:15:03 +0000

CKEditor 5: One Small Step for Content Editor, One Giant Leap for Drupal

Room

HS1 (Ground level)

Vladimir R Mon, 04/10/2023 - 10:15

Time Slot

Thu 4:15pm to 5:00pm (7/20/23)

Session length

Long session - 45min, including Q&A

Audience

All Attendees

Session Category

Accessibility, User Experience & Marketing

Introduction of CKEditor 5 to Drupal core has improved the content creation experience for website editors. The new version of rich text editor offers a more intuitive and modern interface than its predecessor. The complete rewrite of core features have made it easier to produce high-quality content with less effort.

Drupal configuration process has undergone some changes, and it is essential to understand how to configure the editor when building new and upgrading existing websites. We will kick off by configuring CKEditor 5 for Drupal 10 highlighting practical tips and gotchas.

Some functionality provided by contrib modules might not be available, so we will list top Drupal modules that are currently updated to support CKEditor 5 and how site builders can utilise them to improve the content creation. If a specific functionality is not available, site builders can contribute back by identifying the gaps and sharing the findings with the community.

The best for the last, demo of the editor's premium features enhancing functionality relevant to teams such as real-time collaboration, revision history, and comments.

Overall, the presentation will showcase the improvements brought to Drupal by CKEditor 5, the changes to configuration process, and the Drupal modules and premium features available to improve the editor's functionality and collaboration.

Speaker(s)

Vladimir Roudakov

Teacher at Tomato Elephant Studio

Speaker biography

Speaker1

Hi, I'm Vladimir. I am a Drupal developer and IT teacher from Brisbane, Australia.
I maintain popular Bootstrap 5 theme and number of Drupal modules.
I contribute to various technologies including Drupal, Bootstrap and Gitlab.
I organise Drupal Brisbane Meetup, DrupalCamp Byron Bay and DrupalSouth conference and free monthly Drupal training sessions.

Session Keywords