Drupal News

I am building a site using Drupal 7, in which users can upload content in a form, also images. The images will be uploaded and stored with the Media module version 7.x-2.x-dev.

I want to allow users to upload any image up to 10 MB of size.

But, I don't want to have many pictures as big as 10 MB on my server. I prefer to save the image only after it has been resized to 800x600 to have more space on my server.

How can I achieve this with the Media module?

In addition, what is the difference between the field type "file" to "image" when rendering images with the Media module?

There is an option to chose "Field Type: File" and "Widget Type: Media Browser", and then chose rendered file, and then image on the Media settings (here is a great guide to the Media module). Another option is to chose "Field Type: image" and "Widget Type: Media Browser".

I'm trying to programmatically create a media file. Here's what I got so far:

$file_data = file_get_contents('http://www.africau.edu/images/default/sample.pdf'); $file = file_save_data($file_data, 'public://3010.pdf', FILE_EXISTS_REPLACE); $media = Media::create([ 'bundle' => 'file', 'uid' => '0', 'field_media_file' => [ 'target_id' => $file->id(), ], ]); $media->setName('Hello') ->setPublished(TRUE) ->save();

Unfortunately this returns me the following error and the media file doesn't get saved:

Error: Call to a member function getSource() on null in Drupal\media\Entity\Media->getSource() (line 138 of core/modules/media/src/Entity/Media.php).

What am I doing wrong? How can I fix this error?

I'm using Drupal 7, with Rules and Rules Scheduler.

I have a content type "Tutorial Class", with fields as below:

• Class Date and Time
• Feedback requested (Radio button: Yes/No, default is no)

I would like to create a Rule, so that whenever the cron runs, it will check on all "Tutorial Class" content type.

If current time is larger than "Class Date and Time" field, and "Feedback requested" is no, an email will be triggered and "Feedback requested" will be changed to Yes.

Currently I know how to trigger email after "Tutorial Class" is created, but I can't get the above Rule done.

Any idea of how to set this rule?

I would like to alter/change a certain paragraph behavior plugin setting.

If I debug the paragraph entity, I can find the behavior_settings value, but it's json encoded and I don't think the best option is to decode it, change the values, encode it again and then assign it back to the paragraph, there must be a much better way.

I'm new to Drupal 8. In the user registration form, i've added a Date field via manage fields in user account settings. However, I need to customize this field and change its format. I tried 'manage display' but it's not taking effect. Is there something I'm missing. (Ideally, it should look and behave just like field datetime in Drupal 8 webform)

Appreciate any help given.

Thanks

There are some transactions which are made using drupal commerce module along with commerce ccavenue module. I have the order ids, transaction ids and list of line items purchased in each of the orders. But the problem is I if a product price is updated in past then I am not able to find the cost of the product in the past order when the product was purchased.

Is there any place where drupal stores product price for a particular order anywhere.

I have switched the Image toolkit from GD2 to Imagemagick. It’s working great for new images, however previously uploaded images still show up with lowres quality.

How can I regenerate ALL images using Imagemagick?

I've followed up: Rebuild images from image style

• drush: drush image-flush mystyle
• rm -rf sites/default/files/styles
• Clearing Caches a couple of times and hit save on all image styles.

However all images still show up with lowres quality. When I manually update a node, the image quality looks correct. Also, the file size changes. Looks like imagemagick isn’t triggered. What can I do?

At DrupalCon Lille 2023, Dries announced a new strategic initiative to build a Next Generation Page Builder. The goal of the initiative was to improve and expand Layout Builder to provide a truly intuitive out-of-the-box page building experience.

We have started defining what experience would look like by identifying user journeys from beginning to end, from customizing Drupal to match a brand and content strategy to creating and editing pages. We have identified that to provide the desired experience, we need to define a standardized way for builders and creators to transform designs into optimized digital experiences. To realize the Ambitious Site Builder vision announced by Dries in 2022, we are providing visual, browser-based tools that require minimal technical expertise. This will make it easier for users without prior knowledge about Drupal or coding to implement a digital experience with Drupal. Our working name for this is Experience Builder to highlight that the module seamlessly integrates a page builder and a theme builder.

With the Experience Builder, site builders can create fully customized pages and themes using no-code/low-code tools in the browser. It provides site builders, developers, and content creators a single platform to collaborate. Content creators are empowered to create and update content without having to reach out to a developer. Site builders can balance brand consistency and creative freedom by selecting which visual editor controls to expose to the content creator. As a result, anyone in your organization can easily build and update sites, accelerating time to market while remaining brand compliant.

To keep the out-of-the-box experience simple for non-technical users, Drupal will continue to optimize the experience for site builders without the need of building custom, code-based headless front ends. We are actively exploring ways for Drupal to enable JavaScript developers to work with Drupal without the need of managing a large custom code base. Meanwhile, we will still deliver capabilities that enable headless use cases and retain much of the work that has been done to enable headless use cases so far.

How should we build the Experience Builder?

The Drupal core committer team has decided to expand on our existing solutions. Incorporating the best features of Paragraphs into an expanded Layout Builder will provide a solution that can significantly surpass the existing options explored. We are still evaluating if there are smaller components that exist in other open source projects that could be utilized by the Experience Builder.

What options did we consider?

We researched the existing Drupal based page building solutions, as well as other open source projects to decide how we should realize the Experience Builder. We evaluated Paragraphs, Layout Builder, and Gutenberg using six criteria: expertise required to realize our vision, effort required to realize our vision, effort required to migrate existing sites, future-proofness of the solutions, how well it matches with our persona, and ability for market differentiation.

Gutenberg was the primary option that we considered adopting from outside the Drupal ecosystem. With the help of the Pitchburgh fund, I had couple long days of working sessions with a group of Gutenberg maintainers, as well as the team behind Drupal Gutenberg. We learned that there are many parallels between the problems the different teams are aiming to solve. However, Gutenberg is primarily built for the content creators, which is at odds with our promise to build a platform for the Ambitious Site Builders. Gutenberg would provide us a fast way to enable content creators, but would slow us down delivering on our vision for site builders.

From the Drupal-based solutions, Paragraphs has the largest user base. Site builders attribute this to its relative simplicity and flexibility to implement nearly any kind of design system. However, Paragraphs focuses solely on component composition and content composition, and therefore doesn't enable non-technical builders to control the display of structured data, or the page as a whole.

Layout Builder originally focused on providing site builders with a way to display structured data from entities using more complex layouts. For this reason, the out-of-the-box experience hasn't been optimized for content creation. As a result, some sites using Paragraphs also choose to use Layout Builder as a tool for builders to customize the page layout, leading to a less integrated UX.

All of the solutions we evaluated came with trade-offs. The core committer team decided to prioritize how well the solution would match with our Ambitious Site Builder persona and having an ability for market differentiation. Based on our research, evolving Layout Builder, and enhancing it with capabilities that exist in Paragraphs today best meets these criteria. This approach requires a lot of expertise and effort to realize our vision, in particular UX design, but makes it easier to migrate existing sites and integrate with other Drupal APIs and use cases.

Next steps

We have identified three lanes of work to implement the Experience Builder:

1. Creating a revamped user experience that is optimized for creating pages using components, as well as defining the layout for structured data.
2. Implementing a new mechanism for defining components, alongside blocks. Components can be defined through the UI as no-code components, or as code components. The experience for creating code components will be similar to Single Directory Components.
3. Implementing a browser-based theme builder that enables site builders to implement themes custom to brand without leaving the browser.

Expected timeline and call for help

The core committer team is convinced that a unified Experience Builder is one of the most important initiatives we can undertake. We are committed to moving quickly and iterating rapidly, but we need your support to succeed. We know that with the help of the community, we are able to develop a proof of concept and demo of the new user experience later this year. The first release as a contributed module is targeted for the first half of 2025.

If you are willing to help fund this project, you can reach out to Lauri or Dries. If you are willing to help with the implementation itself, we are planning to set up a recurring meeting. Join the #layouts channel on Drupal Slack for updates and opportunities to contribute!

TDT hired a full-time journalist intern to cover DrupalCon Pittsburgh in 2023. Aidan F. Dean Dunn, just out of college, did a commendable job. Aidan talks about his experiences reporting at the tech conference in this conversation with Varun Baker.

While preparing the recent Markdown Easy 1.0.1 release, I utilized a couple of tools that I hadn't used before in order to help improve code quality as well as the quality of the release notes.

cspell

cspell is a Node.js spell-checker for code that was made available to the default Drupal GitLab templates in February, 2024. There is a new SKIP_CSPELL variable that can be set if you'd like your project to completely ignore cspell (it is enabled by default.) Documentation on using cspell in Drupal GitLab pipelines is available. I'd wager that most Drupal contrib maintainers will have the need for a custom word list (as I did,) so I took a few minutes to learn a bit more about it.

Cspell uses its default wordlist along with a few add-on dictionaries related to Drupal development (anecdotally, words like "mglaman," "gloop," "skynet," and "vampirize" are included) for checking the spelling of both variable names as well as code comments, but luckily, additional words (and patterns) can be added on a per-project basis in order to achieve a clean cspell report in GitLab pipelines. While there are several methods to add a list of custom words, the way I felt was most elegant (and easy for me to remember in the future!) was to add a .cspell-project-words.txt file on the project root (in this case, the contrib module is the project.) This file then includes a list of words that cspell should not flag as misspellings. For the Markdown Easy project, I went with "Anello," "~commonmark," and "~ultimike" (possibly for obvious reasons.) The ~ modifier indicates those words are case-insensitive (additional modifiers are available.) With that change, Markdown Easy now earns a passing score from the cspell pipeline. 

drupalorg CLI

drupalorg is a command-line interface maintained by (who else?) Matt Glaman. I actually learned about this tool a few years ago after Matt blogged about it, but for whatever reason, I only thought about installing and (finally) using it recently. The general idea is to provide a command line tool for contributors to interact with drupal.org. It's available commands are:

help Displays help for a command list Lists commands cache cache:clear (cc) Clears caches ci drupalci drupalci:list (ci:l) Lists test results for an issue drupalci:watch (ci:w) Watches a Drupal CI job issue issue:apply Applies the latest patch from an issue. issue:branch Creates a branch for the issue. issue:interdiff Generate an interdiff for the issue from local changes. issue:link Opens an issue issue:patch Generate a patch for the issue from committed local changes. maintainer maintainer:issues (mi) Lists issues for a user, based on maintainer. maintainer:release-notes (rn, mrn) Generate release notes. project project:issues (pi) Lists issues for a project. project:kanban Opens project kanban project:link Opens project page project:release-notes (prn) View release notes for a release project:releases Lists available releases tci travisci travisci:list (tci:l) Lists Travis Ci builds for a Drupal project travisci:watch (tci:w) Watches a Travis CI job

The maintainer:release-notes command is especially helpful to automatically generate release notes for a new version of a Drupal contrib project. Here's how I installed and used this tool to generate the release notes for Markdown Easy 1.0.1:

1. I downloaded the drupalorg.phar to a new ~/sites/drupalorg/ directory on my local, and renamed the file to just drupalorg.
2. I then gave execute permission to this file via chmod u+x ~/sites/drupalorg/drupalorg

3. I use zsh, so I added the following to my ~/.zshrc file and then restarted my terminal:

   # drupalorg command line tool export PATH="/Users/michael/sites/drupalorg:$PATH"
4. Here's the important part - I then navigated to my local, working copy of the Markdown Easy module. In my case cd ~/sites/d10/web/modules/contrib/markdown_easy 
5. I then ran the following command to generate the release notes: drupalorg maintainer:release-notes 1.0.0  

I assumed at first that I should use the current release (1.0.1) as the argument, but after reading the documentation, I discovered that the command will generate release notes from the tag provided in the argument.

I also originally assumed that the command would take a contrib module's machine name as an argument, but after a few minutes of poking around the documentation, I realized that the command must be run from the module's directory.

You can see the automatically generated release notes here.

Summary

Both of these tools were rather easy to implement (once I read just a little bit of documentation) and seem like they'll be useful for just about any Drupal contrib maintainer.