🇩🇰Denmark @ressa

I just got confirmation about something great: Maintainers can grant credit, even after an issue is closed, simply by checking the checkbox and saving the issue, see 📌 Embed fonts to comply with EU GDPR Active and https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... → .

Fixing sentence:

Initially, no one will be listed as a potential contributor,  so no one will be credited automatically 📌 Use gitlab-ci Needs work .

Thanks for confirming :)

That's really valuable knowledge, and I have updated the crediting documentation, under https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... → , adding the tip box below:

Giving credit: Check and uncheck the names of users listed in the table, depending on whether they contributed to moving the issue towards resolution. The credits will appear on the user and organization profiles when the issue status is Fixed, or any Closed status, including when it automatically changes to Closed (fixed).

Even after the issue is closed, you can grant credit to a user:
Simply check the checkbox next to the user name, and save the form.

Adding useful tip: "Even after the issue is closed, you can grant credit to a user, simply by checking the checkbox next to the user name, and saving the form."

Also moving 4 important info items at the top into a "cautionary" template.

Just adding a comment that I also saw a slightly strange behaviour, where a Boolean field was added to the index, but not present after re-indexing. I tried changing Type to String, and some other stuff, but then deleted and added the field again, and this time it got indexed as expected, with bs_field_main_image:true, ¯\_(ツ)_/¯

I just ran into this again today, and I think the maximum should be bumped up ... 10 is too low in my opinion.

Alternatively, if the "Default result rows" value is 10 (the default after an installation) we could show a message, to alert the user that in 99% of cases, they should set the value to "0", or definitely increase it.

Many users are wasting time needlessly, looking puzzled at the View only returning ten items, when there are many more indexed. Thanks!

Thank you very much for a fast reply @grzegorz.bartman!

It has already propagated, perhaps instantly?

Open Intranet issues credited to ressa

◀︎ Back to ressa’s profile
Embed fonts to comply with EU GDPR updated 5 hours 50 min ago

https://www.drupal.org/u/ressa/issue-credits/3513334 →

Can I ask you to explain in detail the steps you took? Because then I'll update the crediting documentation -- it would be awesome to have the minimum steps fleshed out, for other module maintainers. Perhaps it was as easy as simply just checking the box and saving? Thanks!

ressa → created an issue.

It may not fix it for all cases (like in the original post) but for others finding this page having the problem with a more "regular" field, just saving the field might work:

• Open Field list page (/admin/reports/fields)
• Open the Entity type
• Edit the field and save it

Awesome tip @rgnyldz, thanks! Simply clicking "Save" on the field edit page fixed the error:

• Open Field list page (/admin/reports/fields)
• Open the Entity type
• Edit the field and save it

Thanks for fixing this @grzegorz.bartman and @sebastian.langierowicz.

PS. It looks like I wasn't credited ...

Contributions to credit

The following are examples of types of contributions that should be recognized:

• Creating a well-written issue that describes a problem
• Proposing a solution (either in the form of a patch, or a text comment)
• [...]

From Granting credit to issue contributors → .

I would really love to have Open Intranet listed as a project I have contributed to, on my profile :)

It may be as easy as setting a check mark next to "ressa at Ardea" and click save?

I am very curious if this would be enough, and if it is, I'll update the doc page above. Perhaps try that first, and check under https://www.drupal.org/u/ressa/issue-credits?field_issue_last_status_cha... → if Open Intranet shows up, after a day or so?

If it doesn't appear, the Status may need to be updated (1. Set to "Active", 2. Grant credit, 3. Set back to "Fixed").

PS. If it works for you, feel free to update the old documentation you found, or create a page, if it doesn't exist. Thanks!

The example in settings.php worked well for me:

$settings['locale_custom_strings_en'][''] = [
  'Your comment has been queued for review by site administrators and will be published after approval.' => 'Customised test message',
];

From settings.php:

/**
 * String overrides:
 *
 * To override specific strings on your site with or without enabling the Locale
 * module, add an entry to this list. This functionality allows you to change
 * a small number of your site's default English language interface strings.
 *
 * Remove the leading hash signs to enable.
 *
 * The "en" part of the variable name, is dynamic and can be any langcode of
 * any added language. (eg locale_custom_strings_de for german).
 */
# $settings['locale_custom_strings_en'][''] = [
#   'Home' => 'Front page',
#   '@count min' => '@count minutes',
# ];

Thanks for a fast update @apmsooner and keeping the momentum, it helps not having to try to backtrack, and attempt to understand what my ideas and thoughts were some time ago :)

The updates you made are great, even though I haven't yet looked into the more complicated Reference/Paragraphs scenarios.

It's a big improvement that the Paragraph/reference target drop-down is only displayed when it's relevant. That will prevent much confusion.

I suppose it's more or less impossible to reverse the general order, and define data source first, and only then data target, in the second step? (Note, not Paragraph source/target) Because that would logically make more sense, and align with for example rsync (source first, then target). But I assume there are good reasons for the current order, with defining data target first, and only then data source?

Mapping: Some fields seem to be missing

I always start with the simplest option first, from one plain text field to another, and ran into an oddity, where some fields were not available as options at the second step of Mapping, setting the source ... I think it's best to get this sorted out, before proceeding with the more complicated stuff.

So maybe you can try and create a few plain text fields (long and short), and verify if they all show up, as expected or not, in the two steps?

Reverse order on Field source Mapping?

Is it possible to reverse the order, and show "Fields" ("Body", "My field", etc.) first, and then "Default values" ("NULL", "Custom value") in the Mapping drop-down? Since the options under "Fields" are the most relevant ones, I think they should be listed first.

Feature request: Token support in "Value source" field?
A killer feature would be Token support in the "Field Source" > "Custom value" > "Value source" field, since the user could then string together multiple fields, and combine them into a single field. But perhaps that's best dealt with in another issue? I am just thinking , that maybe in this phase, it might be ideal to keep all options in one place, until the dust settles. What do you think?

Fix formatting.

Automating code writing and speeding up development is always nice, and sounds like a cool feature. And I do hear you ("This module was always intended for a developer audience.").

But the thing is, being able to easily transfer data from one field to another is a killer feature, that a lot of Drupal users can find extremely useful. And only a minority of those who can use this feature will be developers, but more like site builders, and (like I wrote) not able, nor in need of writing an update hook. Many of them also cannot write migrations, and this module can solve the task of transferring data, easily.

So I think it should be made clearer, that it's actually really easy to transfer data from one field to another with this module. The developers will have no problem scanning the project page, and see that update hooks are an option.

Thanks @apmsooner I really appreciate your openness to my suggestions. It sounds really great that you are reworking the UI, and only show the source field if it's relevant -- like you write, probably most likely for Paragraph or reference fields. That'll simplify the interface, and make it more immediately understandable. Sadly, I am not on Slack ... but I would be more than ready to try out a test MR (here or in another issue), check out a screenshot with Gimp/Photoshop scribblings on with suggestions, or just in text.

Sadly, this is a common misconception among module maintainers, and I agree that it's a complicated set up ...

But this is from the documentation page (I updated the page a while ago, and added it):

• [...]
• Credit is only granted via the checkbox next to each user name
• The commit message is not for credit attribution, only for Gitlab history

From https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →
(linked to below, under "Credit & committing - Learn more about granting credit → .")

See also the related Leaflet issue I added, where crediting users is also discussed.

I am not trying to single anyone out, but the credit system is there to incentivize user involvement, and reward good contributions, so I think we should try to do that. Thanks!

Yes, it does look like the user input for this issue was minimal, so it was probably not the best example. I just noticed that in the last few issues, no credit was given ...

Great, I have added "Write a test" under "Remaining tasks" in the Issue Summary, to make it clearer, what still needs to be done.

It could be this issue?

It could be this issue?

Thanks @tobiasb, is the MR ready for review? Because the status is "Needs work", so could be missed by people ...

Admins: Please block this spammer.

ressa → created an issue.

@hatuhay: It looks like you forgot to credit the users, who supplied solutions to this great project, in the last few issues that I checked ... Maybe it has been like this for a while?

I think we need to acknowledge the work and effort of these issues, by giving them credit. (Check the boxes at the bottom, under "Hide Credit & committing").

Thanks for maintaining this great module!

I raised this issue in the DDEV Drupal Contrib issue queue, because I think the add-on should take care of this instead of the individual modules, see Add .gitignore file, excluding vendor, web, .ddev, .editorconfig, etc. by default #25.

Having the old 8.x-1.x version as the default branch on GitLab still, in June 2025 is not great.

@dave reid: Please elevate @damienmckenna to Maintainer on GitLab, to keep this module in tip-top shape. The stalled progress of fixing tasks such as this can harm the module, allowing minor issues to pile up, and become problematic in the bigger picture. Thanks!

Thanks @knalstaaf! Adding a Taxonomy term relationship in Views under Advanced is still the solution, and works well in Drupal 11, in 2025 :)

Still helping Drupal users in 2025, thanks @gsquirrel! :)

The issue with a solution: 💬 Sort by term weight (taxonomy) in Views 3 Fixed .

PS. Yet another testament to what a great resource the Drupal Forum is -- a constant, always available source of great information.

This is required to make the module work in Views, otherwise the user will click an image, and nothing happens ...

In my opinion, this is a pretty big deal, since the user will think that the module doesn't work, and potentially waste significant time searching, to try to find a solution ...

In that sense, the Views instructions in the README has a major problem, so increasing the Priority.

I have added link to the Views documentation, and hope this MR can get committed ASAP, to help new users avoid wasting time needlessly :) Thanks!

ressa → made their first commit to this issue’s fork.

I needed this today, and remembered this Forum post :)

I also recalled that Drupal 10 got a new “Views Responsive Grid” a few years ago ( #3151553: Create new “Views Responsive Grid” format for Views Core → ) and it even works with different image formats. The Responsive vertical style is especially impressive, where images of different heights smoothly aligns:

Windows or not, is not a factor here, as I see it. But about Project Browser, like I already commented, I  agree with you that it seems odd, that allowing to install code is sort of not recommended, but still Project Browser relies on this, by overriding the constriction via settings.php ...

And also great that we agree that WordPress and Drupal with Project Browser work more or less the same, and allow installing plugins (WP) or modules (Drupal), taking no stance on whether it's safe or not.

About DDEV, I very much disagree: DDEV or Lando, or the other Docker-based developer environments, are far superior Drupal development tools to the non-Docker based, and also why DDEV is now the recommended solution.

But we are of course all allowed to have our own opinions :)

That aside, I wonder if you refined your comment 18 June 2025 at 08:30?:

@tolstoydotcom
One reason not to like ddev is the file permissions aren't realistic. It lets the webserver modify code directories. Which is fine on local machines, but on the server that's a huge security risk. Unfortunately, Acquia et al seem to think that's OK (see Project Browser).

Because I would probably not have replied to the current wording with this:

@ressa
You don't run DDEV on the server, so what is the problem? I forget if you created an issue about your gripe, but please share a link here, if you did. Thanks!

From what I recall, it was more like a blanket statement, that "DDEV is unsafe".

But are you're saying that Project Browser would not work with the recommended permissions on https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → ?

Because if not, that would be an interesting topic to delve into.

Thanks for a fast reply.

But it doesn't really make sense to me, to hide this great feature ... Adding a "Hide Issues" checkbox would probably be a better UI design choice, in case some users get overwhelmed. (You write "I suspect", but are you not in touch with those who built it, and the thoughts behind the decision?)

Also, what do you think about my second suggestion about version confusion? ("[...] should 11.3.x or 11.x be used under "Introduced in branch")

I created a new page, maybe it can be added to the menu?

https://www.drupal.org/docs/drupal-apis/migrate-api/fixing-errors-due-to... →

For a manual method, see Orphaned nodes in Drupal 11 after interrupted migration → .

I ran into this after interrupting a Migrate import: Never do that! And it was only to save half a minute ...

The interruption left orphaned bits in the field and field revision tables. I got a single errors like below when I ran the migration again:

 [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1265-0-0-en' for key 'PRIMARY': INSERT INTO "node__field_image_category" ("entity_id", "revision_id", "bundle", "delta", "langcode", "field_image_category_target_id") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array
(
    [:db_insert_placeholder_0] => 1265
    [:db_insert_placeholder_1] => 31974
    [:db_insert_placeholder_2] => city_image
    [:db_insert_placeholder_3] => 0
    [:db_insert_placeholder_4] => en
    [:db_insert_placeholder_5] => 546
)
 in Drupal\mysql\Driver\Database\mysql\ExceptionHandler->handleExecutionException() (line 45 of /var/www/html/web/core/modules/mysql/src/Driver/Database/mysql/ExceptionHandler.php).

 (/var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:817)
 [notice] Processed 1 item (0 created, 0 updated, 1 failed, 0 ignored) - done with 'images_info'

In MigrateToolsCommands.php line 1094:                                    
  images_info Migration - 1 failed.  

I looked around, but finally used the clue staring me in the face in the error message:
[...] INSERT INTO "node__field_image_category"

when I looked in that field table, I found a single orphaned node ID:

$ drush sql:query "SELECT * FROM node__field_image_category;"
city_image  0  1265  22895  en  0  300

$ drush sql:query "SELECT * FROM node_revision__field_image_category;"
city_image    0    1265    22895    en    0    300

I found the column names like this (you can use PHPMyAdmin in DDEV):

$ drush sql:query "DESCRIBE node__field_image_category;"
bundle    varchar(128)    NO    MUL        
deleted    tinyint(4)    NO    PRI    0    
entity_id    int(10) unsigned    NO    PRI    NULL    
[...]

$ drush sql:query "DESCRIBE node_revision__field_image_category;"
bundle    varchar(128)    NO    MUL        
deleted    tinyint(4)    NO    PRI    0    
entity_id    int(10) unsigned    NO    PRI    NULL    
[...]

I deleted them:

$ drush sql:query "DELETE FROM node__field_image_category WHERE entity_id=1265;"
$ drush sql:query "DELETE FROM node_revision__field_image_category WHERE entity_id=1265;"

I got some more errors, found the field tables and deleted the orphaned nodes:

$ drush sql:query "DELETE FROM node__field_city_image WHERE entity_id=1265;"
$ drush sql:query "DELETE FROM node_revision__field_city_image WHERE entity_id=1265;"

$ drush sql:query "DELETE FROM node__field_city_ref WHERE entity_id=1265;"
$ drush sql:query "DELETE FROM node_revision__field_city_ref WHERE entity_id=1265;"

$ drush sql:query "DELETE FROM node__field_origin WHERE entity_id=1265;"
$ drush sql:query "DELETE FROM node_revision__field_origin WHERE entity_id=1265;"

$ drush sql:query "DELETE FROM node__field_main_image WHERE entity_id=1265;"
$ drush sql:query "DELETE FROM node_revision__field_main_image WHERE entity_id=1265;"

Maybe this can help someone in the future :)

@marc.bau: It would be great if you outlined in detail:

• The steps you take (which pages, which buttons, etc.)
• The expected outcome
• What happened
• How you like it to work

I have just worked with translations, and had a hard time understanding how it all ties together -- like "There's interface translation AND configuration translation, working in each their own way, huh?".

There are many different methods, so understandably, we all have a hard time understanding your challenge, unless you supply the details. Do you want to use a .po file, do you use Drush, the interface, or something else ... If you are moving .yml files individually, if yes, from which folders, etc.

Also, what exactly do you mean with a "custom view"? Like, if it's just clicking on the button and creating a View, I wouldn't consider that "custom", that's just a View, in my opinion. When you use the word "custom", we start thinking that perhaps you coded it in some strange way, but maybe you didn't? In other words, if you created the View with the regular method, you can drop the word "custom".

I can confirm this, and it was also reported in another issue. So I am adding bits of the description in the Issue Summary of the other issue, and closing this one.

Adding "Steps to reproduce".

Thanks for sharing @marcoka, I'll surely use parts of your example to create a great caption.

A simpler example, and mentioning that you can assemble a custom caption text with a custom textfield could be included in the README, maybe under a new "Custom Views caption" section?

https://git.drupalcode.org/project/photoswipe/-/blob/5.x/modules/photosw...

Also, I think the README is missing a sentence or two, that when it's set up, the user can choose any field and use that as caption. It feels like the README stops too soon :)

I can confirm this: The "Photoswipe image caption" option is present on the regular Display page of fields (/admin/structure/types/manage/library/display), but it's missing for the same field in a View.

Please let me know if you need more info @anybody.

By the way, what I would love to see on Planet Drupal are more articles about recipes, for example outlining the minimum required steps to create a basic recipe, and cover individual specific recipe aspects, and good practices. It's still black magic to me :)

The documentation page is empty:
https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/do...

Perhaps you could consider writing an article, aimed at becoming a documentation page?

• Write the article, linking to the new documentation page
• Create a new Recipe documentation Page, perhaps called "Getting started with recipes" under https://www.drupal.org/docs/extending-drupal/drupal-recipes/getting-started →
• Add a source link at the bottom, to grant credit for the great work, like "Source: https://joshuami.com/recipe-tutorial"
• The content could eventually be transferred to the README file (the index.md above)

I have made the same suggestion in 📌 Add Pronovix to Planet Drupal Active , maybe you can do a collab, or coordinate and cover different aspects? Thanks!

Sounds great, I am looking forward to seeing your articles on Planet Drupal in the future!

Personally, what I would love to see on Planet Drupal are more articles about recipes, for example outlining the minimum required steps to create a basic recipe, and cover different recipe creation aspects, and good practices. It's still black magic to me :)

The documentation page is empty:
https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/do...

Perhaps you could consider writing an article, aimed at becoming a documentation page?

• Write the article, linking to the new documentation page
• Create a new Recipe documentation Page, perhaps called "Getting started with recipes" under https://www.drupal.org/docs/extending-drupal/drupal-recipes/getting-started →
• Add a source link at the bottom, to grant credit for the great work, like "Source: https://pronovix.com/articles/recipe-tutorial"
• The content could eventually be transferred to the README file (the index.md above)

I will make the same suggestion in 📌 Add Joshuami.com to Planet Drupal Active , maybe you can do a collab, or coordinate and cover different aspects?

Also, if it's not too difficult to include an image in the feed items, perhaps that's possible? I would love to get more images in Planet Drupal, because it can be a bit too heavy on the text sometimes ...

You're welcome @joshuami! Planet Drupal just pulled a fresh version with the updated format, and it looks great, just perfect 🎉

Recipe Unpack: This Blog Is No Longer on Drupal CMS, and That's a Good Thing

Posted by Joshuami → - 20 Jun 2025 at 23:00 CEST

With the release of Drupal 11.2, the Recipes feature gets an important new capability. You can now "unpack" recipes after they are run so that your composer.json will have the direct dependencies from the recipe rather than a dependency on the recipe itself.

I am looking forward to your next blog post!

ressa → created an issue.

I am also looking for this, using the "File (Field) Paths" module in a migration, and it seems like _0.jpg files are created when I run migrate:import --update, so I need to rollback, to not get a lot of duplicate files.

Wow, very interesting articles and deep dives into interesting subjects such as recipe code installer, Internationalization and Localization and Large Language Models. This is definitely ready for Planet Drupal.

In my case, it was due to malformed JSON. So as soon as I found and removed the lingering commas, the migration worked as expected.

Thanks, but maybe just replace the title and Body text with "Deleted"?

ressa → created an issue.

Thanks @smustgrave!

Awesome and unique blog post about recipes, exactly the kind of content I love to find on Planet Drupal!

However, the link points to https://joshuami2.ddev.site/blog/2025/recipe-unpack-blog-no-longer-drupa...

Also, perhaps the title and two dates could get excluded from the <description> field:

Recipe Unpack: This Blog Is No Longer on Drupal CMS, and That's a Good Thing
joshuami Fri, 20 Jun 2025 - 2:00 pm
Posted on 20 Jun 2025 - 2:00 pm

... and maybe also the feed link at the bottom ("Drupal")? The output at Planet Drupal:

Recipe Unpack: This Blog Is No Longer on Drupal CMS, and That's a Good Thing

Posted by Joshuami → - 20 Jun 2025 at 23:00 CEST

Recipe Unpack: This Blog Is No Longer on Drupal CMS, and That's a Good Thing
joshuami Fri, 20 Jun 2025 - 2:00 pm
Posted on 20 Jun 2025 - 2:00 pm

With the release of Drupal 11.2, the Recipes feature gets an important new capability. You can now "unpack" recipes after they are run so that your composer.json will have the direct dependencies from the recipe rather than a dependency on the recipe itself.

Drupal

For more control over feeds, there is https://www.drupal.org/project/views_rss → which can be slightly hard to set up, but I just followed the instructions, and got it working. See also 📌 Add Timbers.Dev to Planet Drupal Active .

@drumm I created 📌 Add "This is archived/old content" banner for old documentation pages Active .

ressa → created an issue.

I think the great functions and commands in Search API Solr Admin (search_api_solr_admin) module should be moved into Search API Solr module itself, and available by default, since many users often miss that the feature or commands they are looking for already exist.

The delete-all command is a crucial tool, and I use it all the time for development and testing, as well as deployment on the server, like this:
drush search-api-solr:delete-all solr_server && drush search-api:index

I know the argumentation why Search API Solr Admin is in its own separate module (to guard the user from making a mistake), but I think it's the responsibility of the user to be careful, when running Drush commands.

After all, you can just as easily do much, much damage, like destroying a Drupal installation with a multitude of commands -- for example simply by running drush site:install -y, and Boom!, your web site is now gone.

If you're in doubt, it's the comment "I agree that installing DDEV" you didn't answer.

Because it would be great to get this cleared up:

Installing code

I still don't think you answered my question about what DDEV has to do with permissions on the live server. Won't XAMPP allow the user to write to those same folders, and would that not also encourages bad habits?

Also, how does adding a module in Drupal with Project Browser via the GUI differ from adding a plugin in WordPress via the GUI? If you think there is a huge security problem, I urge you to create an issue in the Project Browser issue queue ASAP, because then it should be solved. Otherwise, it just looks like you are spreading unfounded fear here in the Drupal forum.

If you think there is a problem with DDEV, you should feel free to create an issue, so it can get fixed:

https://github.com/ddev/ddev

I just don't think there is one ... so it would be great if you could clarify ... like I asked originally:

Thanks, I did post two comments, maybe you missed the first one?

I found an issue ✨ Consider supporting Package Manager's new direct-write mode Active , and I do agree that it seems odd that Project Browser is aimed at making it easier for beginners to build Drupal sites, but it's not recommended to use PB on a live site.

The best practice here would be to enable it in settings.local.php only, which should not normally be deployed to a production environment.

There seems to be a conflict there.

Still, how is that different from how WordPress operates? (Without judging it as safe, or not)

I agree that installing DDEV requires a few steps. But whenever a user has a problem, they should absolutely create a DDEV issue, and the DDEV team will answer them very quickly, and help them get started:

https://github.com/ddev/ddev

And thanks for the links. In this recent Reddit post, PHP developers love DDEV (47 thumbs up), so you can find both sides:

https://www.reddit.com/r/PHP/comments/1kv24oq/is_it_finally_time_to_move...

Installing code

I still don't think you answered my question about what DDEV has to do with permissions on the live server. Won't XAMPP allow the user to write to those same folders, and would that not also encourages bad habits?

Also, how does adding a module in Drupal with Project Browser via the GUI differ from adding a plugin in WordPress via the GUI? If you think there is a huge security problem, I urge you to create an issue in the Project Browser issue queue ASAP, because then it should be solved. Otherwise, it just looks like you are spreading unfounded fear here in the Drupal forum.

If you have already created such an issue, please share a link here. Thanks!

Thanks @catch, the video looks great. It's awesome to get this speed improvement available for everyday Drupaling.

Adding @dydave's excellent image in the Issue Summary.

Please only post once. Admins, can you help delete this? (It's a duplicate of https://www.drupal.org/forum/support/post-installation/2025-06-19/questi... → )

catch → credited ressa → .

Yes please, this would be an awesome feature. I could easily imagine having a Drupal installation, with the only task of being a Markdown editor :)

Yes, maybe you're right ... I just thought that perhaps you might want to extract other data, to use a different metric, to trigger the alert email. But let's see if that's necessary, it can always get expanded. It sounds good that I can reach out for help later, if necessary -- Have a nice day.

Thanks for taking a closer look at this @justcaldwell, as well as refining @amit.mall's MR, your plan sounds great. Adding the related CKEditor index and position issues you shared issues as such, to connect them all.

Thanks @dydave for a fast and positive answer as always! Great idea to include this in the merge request.

I recently worked with the deployment part of translations, and was finding that translating block titles and field names ("configuration") required too many manual steps, as opposed to interface translation, which automatically registers all t()-wrapped (PHP) or |trans-ending (Twig) strings, and can become part of deploy process, all contained in a single po-file.

So I checked out the options, and initially planned to use https://www.drupal.org/project/config_translation_po/ → . But it still wasn't great to add another slightly working step. So I instead experimented with adding |trans in the relevant Twig templates.

This turned out to work really well, and 99% percent of all translations are in a single .po file, one for each language. Only Site slogan, and some meta tag settings are still in language specific configuration files.

I updated the documentation pages in case you are interested:

• Translating site interfaces →
• Translating configuration →

Great that the French version got some more translations! Translating can take time, but https://www.deepl.com/ works pretty well (Tip: Sometimes it DeepL gets confused, but adding line breaks before and after tag signs (< and >), and then restore line breaks before inserting in the localize.drupal.org field sometimes helps) so I also made these two 100% translated in Danish :)

https://localize.drupal.org/translate/projects/token
https://localize.drupal.org/translate/projects/pathauto

... and I see French is also doing well there, kudos!

Yes @dydave, I did also notice occasionally that the CKEditor toolbar would have the 80px offset with "Hidden" or Hidden, show on scroll up", which is being worked on in 🐛 element hangs, when Toolbar is hidden Active , it could be all connected :)

When I tried earlier to recreate it reliably, I could not ... but I tried again just now, and succeeded, so I have added fixing CKEditor toolbar offset as a task in the other issue.

To successfully recreate it, you might need to have content in the field, as well as place the cursor in the field.

Perhaps it's most ideal to look at all these position/z-index tasks in a single issue, and moving your observations and required tasks to 🐛 element hangs, when Toolbar is hidden Active , and closing this issue, since it only deals with a single scenario, and recent work is happening in the other issue?

Thanks @justcaldwell for creating the dependencies issue, it would be great to get that cleared up. I agree with your proposal #1:

Stick with the module's de facto approach for the purposes of this issue, and remove core/drupal.displace.

MR 160 still works well for me, for all combinations.

@dydave mentioned:

I'm wondering if this could be a solution as well for 🐛 zindex issue between admin toolbar and ckeditor 5 Active (?!)

(Same issue, with the CKEditor toolbar / a problem of offset calculation)

I did previously notice that the CKEditor toolbar would occasionally also get the 80px offset, but could not reliably re-create it in the CKEditor ...

But I tried again, and this time I could reproduce it reliably. So we probably need to make sure that it works as well for CKEditor ... So I updated the Issue Summary, and am adding the related CKEditor issue, in case these two issues need to be coordinated. Thanks!

You don't run DDEV on the server, so what is the problem? I forget if you created an issue about your gripe, but please share a link here, if you did. Thanks!

I created a new page, maybe it can be added to the menu?

https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →

You're welcome @vaish, I am grateful there a so many volunteers in the Drupal community such as yourself, who maintain amazing and feature rich free and open source Drupal modules, it truly is something unique.

Adding the Crawler Rate Limit module is a great suggestion, and I have added three bot blocker modules to the page.

I haven't yet looked into how to extend the alert script, using one or more of your examples of grepping in the log ... but if you feel inspired, you're more than welcome to add a new script, which uses the grep methods you just added in the Crawler Rate Limit README :)

Add three contrib modules which supports blocking bots, using different methods.

Thanks for a fast answer @mstrelan, and I agree -- getting this small change completed by itself would be optimal, and then dealing with the complicated stuff in a follow up issue. I have updated issues and Change Record.

Perhaps -- if you have time -- you could check the Change Record, which is the last remaining task? And I guess maybe also the MR, since it was updated 10 June 2025 to only add three new date formats, and update the date in the Announcements Feed.

Update Issue Summary, to handle the entire process of deprecating and removing Olivero Medium date in this issue.

Thanks @vaish for creating and maintaining the module, I really appreciate all the great examples for reviewing the logs added in the Crawler Rate Limit README. They could be combined with the script here to send an alert, in extreme cases: https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →

Also, I just now see that a lot of great examples for reviewing the logs have been added in the Crawler Rate Limit README, so that could probably work well for me: https://git.drupalcode.org/project/crawler_rate_limit#logging-of-rate-li...

The grep examples could be combined with the script here to send an alert, in case a bot goes really amok: https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →

Thanks @wombatbuddy for your answers, as always they are very helpful.

I have tried to use them with an existing feed. There is https://www.jsonfeed.org/version/1/ with links to a few example feeds, such as http://shapeof.com/feed.json which can work well. The only difference is that those feeds all have /items as grouping element.

Here I am using both a standard filter, and contextual filter.

1. Set feed

   Advanced > Other >  Query settings:

   JSON File
   http://shapeof.com/feed.json

   Row Apath
   /items

2. Add Fields
   JSON: JSON Field (id)
   JSON: JSON Field (title)

3. Filter criteria

   x Expose this filter to visitors, to allow them to change it

   Key Chooser
   title

   Filter identifier
   title

   Now you can search for "Acorn" and it shows items with that title.
   Bonus: Use Ajax under Advanced > Other for no reloads.

4. Contextual filter

   Contextual filter:
   Add JSON: JSON Field

   Key Chooser
   /title

   Under the Views' Path (use /shape/% if you require a value, otherwise show them all)
   /shape

   If you visit /shape all articles are listed, but under /shape/Say Hello to Acorn 8 just a single article is listed.

@mstrelan and @penyaskito: I have added deprecating Olivero Medium in the Issue Summary here, and updated the Change Record with this:

Olivero Medium has been deprecated and removed

ToDo: Add description about what this means.

Perhaps only the three new "date only" formats and deprecation Olivero Medium should be part of that Change Record, and the actual removal in a separate Change Record?

Update Issue Summary, to clarify that deprecation takes place in 📌 Add date formats without time Active , and removal in this issue.

All these "Hello I am [A NAME] from [A PLACE] how can I build [SOME TYPE OF WEB SITE]" are suspicious. Also, please check the user profile, it is stuffed with Social Media links.

Sure, maybe you missed the "Linux" link? https://new.drupal.org/drupal-cms/launcher

Thanks for the tip, and I can see that I bookmarked the project back in March, when I got hit by the first wave of bots, but forgot about it ...

But thanks for reminding me! Because that does look a lot like what I request in this Issue Summary. I agree that it would be nice with just some very basic logging of the efficiency, to see if it works, or misses the bots, or blocks too much, etc.

I found the issue, where you suggest some logging, and perhaps, if you have the time, and it doesn't take a big effort, you could make a MR in that issue, adding some basic logging? I would be ready to test any MR's, and if nothing else, those interested could then patch the module, to get logging.

Since the feature I request is covered by Crawler Rate Limit → , I'll close this issue.

Adding related issue about giving Drush more prominence in the Quick Start, while still mentioning the update hook option for the expert developers.

Thanks for replying, though, even if it shouldn't be done on a live site, having the button would be nice.

After all, Drupal migration in the browser → has a button, right? I think the button could be added, with a caveat "Not recommended for live sites".

It could also serve as an easier introduction to the module, for users who are experimenting with it in a Drupal sandbox installation.

Also, please remember that a large number of Drupal site builders cannot program an update hook. So I think we should make it easier for them, by not only highlighting the Drush option in the Quick Start on the project page, but also adding a button. Thanks!

In the end, I did not use the Config Translation PO module for configuration translation.

Instead, for elements such as block titles, and field names, I copied the relevant Twig template files to my theme, and added |trans to the labels. I updated the doc page with this tip, under Alternative solution: Make configuration elements translatable → .

Adding Streamline interface and configuration translation tip section.

Adding new section, "Alternative solution: Make configuration elements translatable".

I am not sure this is useful after all? I am closing, but anyone who could use it should feel free to re-open (if it's possible).

You can install Drupal CMS in Windows, without doing anything: https://new.drupal.org/drupal-cms/launcher

If anything is unclear or you find errors, create an issue, and @phenaproxima will fix it: https://github.com/drupal/cms-launcher

How to try it

Download the latest release for your operating system.

This app is under development and should not be considered stable. If you encounter buggy behavior, please report it!

Just leaving a tip, since others might run into this: Remember to update Connector Workarounds - Solr version override from "8.x" to "Determine automatically".

I was upgrading to Solr 9.6.1 Cloud with Basic Auth but every time I tried to "Upload Configset" I got this error:

Message 	Drupal\search_api_solr\SearchApiSolrException: Creating collection solrcore failed with error code 400: Solr HTTP error: OK (400) 
{
  "responseHeader":
  {
    "status": 400,
    "QTime": 1040
  },
  "error":
  {
    "metadata": ["error-class", "org.apache.solr.common.SolrException", "root-error-class", "org.apache.solr.common.SolrException"],
    "msg": "Underlying core creation failed while creating collection: solrcore",
    "code": 400
  }
}
in Drupal\search_api_solr\Plugin\SolrConnector\StandardSolrCloudConnector->createCollection() (line 409 of /var/www/html/web/modules/contrib/search_api_solr/src/Plugin/SolrConnector/StandardSolrCloudConnector.php).

It wasn't until I compared a working config with the problematic site, that I noticed an "8" in the config file, under solr_version: '8' in search_api.server.solr_server.yml. After I updated Connector Workarounds > Solr version override from "8.x" to "Determine automatically" I could finally "Upload Configset", as well as with Drush:

$ drush --numShards=1 search-api-solr:upload-configset solr_server
 [success] Solr configset for solr_server uploaded.

Previously I would get this error:

$ drush --numShards=1 search-api-solr:upload-configset solr_server
In StandardSolrCloudConnector.php line 409:
                                                                                                                                    
  Creating collection solrcore failed with error code 400: Solr HTTP error: OK (400)                                              
{
  "responseHeader":
  {
    "status": 400,
    "QTime": 924
  },
  "error":
  {
    "metadata": ["error-class", "org.apache.solr.common.SolrException", "root-error-class", "org.apache.solr.common.SolrException"],
    "msg": "Underlying core creation failed while creating collection: solrcore",
    "code": 400
  }
}


In Result.php line 73:

  Solr HTTP error: OK(400)
  {
    "responseHeader":
    {
      "status": 400,
      "QTime": 924
    },
    "error":
    {
      "metadata": ["error-class", "org.apache.solr.common.SolrException", "root-error-class", "org.apache.solr.common.SolrException"],
      "msg": "Underlying core creation failed while creating collection: solrcore",
      "code": 400
    }
  }

Leaving some details here, in case someone else run into the same strange errors.

Actually, would it be worth adding a warning at the top of the Solr Server page (admin/config/search/search-api/server/solr_server), like this?

After updating the Danish translations to use <br> a while ago, I finally got around to trying to get the latest translations, and I am happy to report back that Admin Toolbar is now 100% translated into Danish, https://localize.drupal.org/translate/projects/admin_toolbar 🚀

I caught a single lingering untranslated string in the interface, which is "milliseconds" here:

$ grep -rinoE '.{0,10}millis.{0,10}' .
./src/Form/AdminToolbarSettingsForm.php:136:ffix' => 'milliseconds',

It just needs to get wrapped in t(), and all is well:

'#field_suffix' => $this->t('milliseconds'),

Add suggestion to add current and relevant projects.

ressa → created an issue.