🇨🇦Canada @Jaypan

What do you mean by 'not clearing' - the form fields are still filled in after submission?

Standard Drupal will clear the fields, so if you are finding this behavior, it would be something specific to your system. Either a module you've installed, or something in your overall environment that is preserving these details.

DDev has its own ddev.settings.php, that may have values in it that you are not expecting. None of the settings files are cached.

There was no core folder in Drupal 7. Core was not in a folder like it is in Drupal 8+.

I report them as spam. It's appears an attempt to increase the SEO of his name, as seen by the bolding of it. I don't see any value in the posts otherwise, so they seem spam.

Do you have a template in your theme called views-view-unformatted.twig.html? Looking through the debug backtrace, that:s where I'd start.

 You need to first retrieve the paragraph, then you can check for the field on the paragraph.

// Determine if the node has the field that contains paragraphs, and if a value exists.
if ($node->hasField($paragraph_field_on_node) && $paragraph = $node->get($paragraph_field_on_node)->entity) {
  // Determine if the parapraph in question has the field being looked for.
  if ($paragraph->hasfield($field_on_paragraph) {
    // The paragraph has the field.
  }
}

That's great! When I found Cypress, I never went back.

To be sure, I did the install steps until then end and during the install process, I didn't got the screen to enter DB connectionString neither username-pwd. At the end of the install, I got a clean fresh DB emptied of my previous sql import => it means that the settings.php was the right one.

So now you can import your DB dump.

That generally means that your DB settings in the settings.php file are not correct for the DB in question, so Drupal thinks Drupal is not installed.

Hi All, in a headless Drupal setup I need to do some checking after the user has logged in and if needed logout the user programmatically.

I would add validation to prevent them from logging in, in the first place, rather than trying to log them out after the fact.

What is the architecture? It's not entirely clear what entity type the comments are attached to - is it the auction material type? Or some other type? And what type of entity is the auction material type?

Making it clear that this page only applies to version 1.

Yes, this is not clear. 

Feeds very likely will be an easier migration to manage. Migrations are excellent and extremely dynamic, but also more complex and therefore require more figuring out.

I'm seeing this in my console as well.

I would google a few videos on Views Attachments, to learn how to use them.

A Drupal 9 .info.yml file would look like this:

name: Module Name
description: A module that does something
core_version_requirement: ^9
type: module
dependencies:
  - application:application

Core Views comes with an 'Attachment' display type, which can take it's values from the parent view. It sounds like this is what you want.

Take a look at the Migrate Plus Module → . It comes with an example module, and an advanced example module, that provide decent guidance.

I would do this with views, and use the aggregation functions to get your totals. There isn't really a need to do this with custom queries most likely. I've found since D9, it's very rare to need to do custom queries, Views is dynamic enough, with enough plugins, that you can do most anything.

It's usually better to add a cache tag to the block.

path.alias_manager is now path_alias.manager. It changed around Drupal 8.8 if I recall. You'll need to find where this reference is coming from and update it. I'd do a search of your codebase for this string.

https://api.drupal.org/api/drupal/core%21modules%21path_alias%21path_ali...

Just like I can create WPMU  this is not avaialble in Drupal 

Of course it's not, it's WordPress Multi User. Drupal is not WordPress. But for the multi-user part, Drupal does users and permissions much more dynamically than wordpress, and with Drupal core, not an add-on module.

Then I would say you need to build a breadcrumb builder.

'header' is an key of the 'cells' array, so I think the documentation should set it as a child of that array.

What is your goal?

You can get the processed value:

// Get the unprocessed value, as a fallback.
$body = $form_state->getValue('body')->value;
// Determine if the value has been processed.
if ($processed = $form_state->getValue('body')->processed) {
  // Overwrite the fallback with the processed string.
  $body = $processed->__toString();
}

This is how I would handle it.

https://www.drupal.org/project/visual_editor →

I just gave dww full access, to administer maintainers, and sickness29 permission to write to the VCS (Git). I'll let you add permissions if you would like dww.

That may potentially indicate you haven't added the subgroup correctly when doing it programatically. I would start by doing a comparison of one added through the UI, and one added programatically, to make sure you haven't missed something.

You would have to code something to store the files in the DB. But I'm guessing you want a private file system, and Drupal does offer that.

Seems like Drush may not be compatible with Drupal 11 yet.

When you're working with an alpha version, you're pretty much on your own, as pretty much no one else will be using Drupal 11 yet, and will run into plenty of issues like this with incompatibilities.

The updated documentation listed the header attribute as a child of a header cell, but it is not. It is a sibling to data</data>. Also, there are multiple instances of <code>table.html.twig in core, and each instance needs to be updated.

I would start a Utah group on Groups.Drupal: https://groups.drupal.org/og/all?keys=utah&gt_tid%5B%5D=141

I did contact my provider and they were able to tell me what databases they thought my domains were pointing to.

They would not be able to determine this without knowing Drupal architecture. That's why I said to ask them which directory was being used, then gave Drupal methods to determine which DB is being used.

Actually, drush status even gives the DB info:

DB driver: mysql
DB hostname: db
DB port: 3306
DB username: db
DB name: db
Database: Connected

The alias you are referring to is an alias for the path to the Drupal page of the media entity that the file is embedded into, it is not an alias for the filepath of the file attached to the entity.

To clarify, are you wanting the alias so that you can link to the page for the media entity, or are you wanting to use that alias in place of the filepath that you are currently using, with that alias pointing at the file (not the media item)?

Taxonomy is the science of categorization. Tags are a type of category, and can be used to related unrelated items of content together, allowing you to filter various types of content by that tag.

However, I’d really like to be able to access the document using the URL Alias set for the document within the media library.

Can you give some more information about what you mean by this?

The server will be configured to point at a given directory. So you need to either look at the web server settings (apache or Nginx etc) to determine which directory the domain is pointed at, or, If you have a fully-managed server or shared host, ask your provider, and they'll be able to tell you which directory the domain is pointed at.

When you find the directory, ssh into it, and run drush status to get information about the installation. You can determine the settings that is being used: [Drupal root]/[Site path]/settings.php. Note that sometimes there are include directives inside the settings.php file that will include other files, like settings.local.php, so reviewing settings.php is worthwhile.

From the settings file, you can determine the database name and user.

1: Recent Blog posts. I want to be able to add a block in Layout Manager to show recent Blog posts that relate to the function area. So, for axample, if there are Blog posts on photography, other posts on cooking and others on elephants, I wan to show, in the elephant section, 'recent elephant blog posts'. I've wondered if I could do this by filtering tags from a single blog, or by having an Admin account for each function, with each Admin having their own Blog and having a block for 'recent blog posts by Elephant_Admin', and a different block on a different page for 'recent posts by Cooking Admin'. So far, I haven't achieved either (blush). Might anyone be able to show me the obvious trick I'm missing? :-)

You have mentioned 'functions', but none of this requires any coding. It is all done with the Taxonomy module for tagging your content, and the Views module for showing different result sets filtered as you would like.

1. (Taxonomy module) Either use the default 'tags' vocabulary that Drupal ships with, or create a vocabulary with which you'll tag your content.
2. Add a taxonomy field to the blog post with the tags vocabulary
3. Tag your blog posts with 'Elephant'
4. Create a view of Taxonomy terms with a block display
5. Add a filter to the view for vocabulary 'tags'
6. Add a filter to the view for the term name (the tag) with the value set to 'Elephant'
7. Add a sort to the view on the Created field, Descending
8. Set the pager on the view to show a fixed number of items (5)
9. Save the view
10. The block will be available in Layout Builder

2: Media Library. Pretty much the same thing. Can I create a Library view that is filtered to a function (whether by some form of tagging or by filename filtering)? So rather than add files to a selection individually, I can show a grid which automatically knows 'all the elephant pictures, and a different one that automatically knows 'all the cooking pictures'?

I don't know that the media library itself can be altered to do this, but you can use the Entity Browser module → to create your own replacements for the media library. You can include an uploader as a widget in the entity browser, and you create a view to determine which items to show. In this case, you would tag your media items with the same tag vocabulary as in your first question, then the view you display in the Entity browser would be a view set to show media items, filtered by having the tag 'Elephant'.

Then either field_featured_image is not an image field, or you have not uploaded an image yet.

You should be able to do this:

$file_uri = $post->field_featured_image->entity->getFileUri();
$url = \Drupal::service('file_url_generator')->generateAbsoluteString($file_uri);

Is the image an image field, or a media entity containing an image?

Sure, I would add a field to each entity with the font-awesome value, then show that field in the view instead of the name of the service item.

I would use ECA for much of it, yes. ECA is a very powerful module.

Yes, it's possible.

I think it's adding additional work that Drupal already does, by bypassing Drupal APIs, and adding an additional unnecessary library. And any time you bypass Drupal APIs you creates hard-to-debug unexpected results later on, due to a non-standard procedure that people cannot recommend you on.

So I'd use a library myself.

hook_cron()

Or Ultimate Cron → with a custom hook.

What are you trying to do?

There will aso be a styles.css.map file in the directory. What this file does is create a mapping that allows browser inspectors to reference the .scss file instead of the .css file that is actually being used.

You can test this by looking at the HTML source of the page, and you'll see that styles.css is being used, not the .scss files. The other way you can test is by renaming styles.css.map, and reloading the page - the browser inspector will show the reference to the .css file when the *.map.css file is not there. I prefer to leave the *.map.css file in place, to make it easier to know which .scss file to edit.

Note that browsers cannot read .scss files, so the .scss file is not being referenced. The inspector is just being nice and showing you the file that actually is.

Does anyone have a solution on how to uninstall the patch while still having the groupmenu module work?
I don't, but when facing a rough Groups upgrade recently, I ended up exporting the Group and Group content to .csv, then deleted all the content, re-built with Groups 3.0, then created a migration script into the new structure, with the .csv files as the datasource.
It was a headache, but not the nightmare that trying to get the upgrade to work was.

DDev is instantiated at the webroot of the Drupal folder. You will upload the Drupal folder to your production server. You don't need to include the .ddev folder when transferring remotely. If you don't want Composer on your production server, you can just put the whole package, including the vendor directory on the server.

Yes, Drupal requires usernames to be unique.

Which head of the Hydra do you grab hold of? Do you follow the install docs in web/core? or do you just use DDEV and let it do all of that?

DDev is the environment that Drupal is run in. It is not Drupal itself, and will not manage Drupal itself. DDev provides Composer integration, which is used to manage the codebase. So after downloading Drupal, and instantiating a DDev instance at the Drupal project root, you can then use Composer within DDev to pull whichever version of Drupal core and modules you wish to use, using standard Composer practices for managing code.

Here's a write up I did in a former life that explains how to use Composer with Drupal 8 - which is still about 90% relevant information: https://www.morpht.com/blog/drupal-and-composer-part-1-understanding-com...

As for which version to use - Drupal supports Drupal 7 for now, but I would not start new projects with it. Drupal also supports the current version, which at the time of this post is 10.2.x. as well as the previous minor version, 10.1.x. You should always keep your code at either the current, or still supported branch. So any new projects are best started with Drupal 10.2.x, but if you have existing projects that were still on 10.1.x, it would not be a problem, though it's time to start thinking about upgrading to Drupal 10.2.x. Once Drupal 11.x.x has a full release out, then it will be supported alongside Drupal 10 for a period of time, allowing for time to upgrade between the two.

As for modules, it's best to try to keep them on their newest full releases when possible.

Interesting module, I've not seen that one. It's a good idea.

I didn't know about this module, but I will definitely be using it in the future. Thank you.

Drupal only allows screenshots from drupal.org. You'll have to post a link to the screenshots.

With DDev, you only install DDev on your machine (which requires other dependencies however). Everything else is installed in the DDev container, and DDev is configured specifically for Drupal, with common Drupal tools ready to go. So you don't have to pollute your machine, and/or have conflicting software between projects.

There are some other modules that work well:

• Honeypot →
• Protected Forms →
• Antibot →

You can try installing a combination of these to see if it helps. Antibot and Protected Forms seem to work well on a couple of sites I am using.

If you proceed through the installation, does it ask you the database details? If it does, then you have the settings for your DB incorrect in your settings.php file, or the file is not being read. If the installer does not ask you the database details, it means it is able to load them, but is finding an empty database, maybe it's been misnamed in settings.php, or the wrong database is being connected to.

• Or should I use DDEV?

Yes. It takes all those questions out of your hands. Much, much easier to work with.

Some of us still like to learn with books, even in 2024.

You can try searching directly on Drupal Answers. It's got the most comprehensive set of Drupal questions and answers.

 What's even better is that Drupal doesn't have any accessibility errors, they're all fine.

It's nice to hear that. Projects I work on usually have to go through WCAG 2.0 tests to ensure they are accessible, but I don't often hear it first hand.

That's awesome! I'm really glad to hear you're able to figure this out, and welcome to the community.

Drupal 8+ has become an enterprise level system now, that while extremely complex, is also extremely configurable, secure, and performant. The complexity has led to a smaller number of smaller Drupal sites, because it's a bigger hurdle for the average person to get into it. But it's in wide usage, and increasing, amongst governments and corporations, as it is very well suited to their needs.

Backdrop is a very good branch and continuance of Drupal 7, that sticks with the Drupal 7 style of development, and will be better suited to entities that were happy with Drupal 7.

No, they won't populate automatically. You have to do it yourself.

The Environment Indicator module → does this.

It's probably a page--front.tpl.php file.

the /modules/contrib folder is correct, although they will also be picked up if they are in the /modules folder. But, it's not normal that they would not be installed to the same folder - are you using different composer.json files for the environment? If they are a copy of each other, they will install to the same directory.

you can use the Markdown → module. You would then choose Markdown as the input format for the textarea you paste the text into.

Oh, yes, I would definitely use Media entities. I answered the question directly without thinking it through.

I failed to notice how the formatting collapsed.

You can use the button in the editor with the <> mark in it, and paste your code in the modal that pops up. That will format it correctly.

Glad it worked out.

It's a bit hard to follow because of the formatting, but I'm seeing you're somehow trying to mix in webform module elements - I'm guessing this is where your issue is coming from somehow. Can you give some more context on that? Webform has its own way of doing things, and may be putting the values into different elements of the form values.

In a submit handler, if you dump your form values, do you see the value you entered in the form:

die('<pre>' . print_r($form_state->getValues(), TRUE) . '</pre>');

I'd probably use the Image Field Caption module → .

I'd need to see your code to know why the values are not part of the sanitized form values.

getUserInput() returns unsanitized values, and using theses values is a security risk.

The Layout Builder module, that ships with core, is what you want. It allows users to build out page layouts with a drag and drop interface.

If it is a custom theme, made for Drupal 8, then it probably is not ready for D10, and will need some work done to it.

If it is a contributed theme, downloaded from Drupal.org, there is a good chance it will have an upgraded version. If not, you may be able to entice the developer into updating it for a payment. If the theme is from a 3rd party vendor, you will need to contact them to see if they have an update. If they do not, you may need to pay a developer to do some work to update your theme to D10.

All steps in becoming a Drupal developer! Glad you got it sorted out.

Did you clear your registry after adding that function? Hooks are cached, and need a cache clear to be picked up.

Is your module installed?

Is your module key birthdaycurryear? Is your info file named birthdaycurryear.info.yml?

I was assuming that it was the function name.  Is that correct?

Yes, it is the function name, not the comments. Although in other parts Drupal the comments do get picked up. But not for hooks, for hooks it is only the function name.

Content types are all entities of type Node. Person is the bundle type, not the entity type. So your hook would be: curryear_birthdate_node_presave().

Also, echoing things is not a great way of debugging within Drupal, due to various caching, and redirects and this and that. At the least, you are better putting out a message: \Drupal::messenger()->addStatus('some message');

Is Person maybe a content type, rather than an entity type?

Interesting, it appears things changed when I wasn't looking: https://www.drupal.org/node/2382513 →

Mod re-write is required for clean URLs in Drupal. I've never heard of anyone disabling it for a Drupal site.

There's no way of knowing. If they are well used modules, that have been around for multiple versions of Drupal, and are well used, there is a good chance they will be upgraded to D11, making your upgrade not too difficult.

But that's with the caveat that it's also possible something could happen and they will both cause your upgrade to be really, really difficult.

There's really just no way of knowing at this time.

The GUI and Composer do not play well together (at the moment - I believe there is an initiative to fix that). For the time being, if you are using Composer, you can/should only use Composer.

I uninstalled the module from the admin/extend/uninstall page and things seemed to go OK.  When I tried to re-install the module, however, the system tells me that the module is already installed and won't re-install it.

This is not standard Drupal, and appears to be a bug on your specific instance, as Drupal out of the box does indeed uninstall modules when you uninstall them. Though you should note that the code will still be there. But when the module is uninstalled, Drupal ignores the code.

We would need more specifics about the steps you took, what exact error messages you got, and ideally screenshots to be able to potentially give help.

I have done some debugging and determined what is happening.

The Twig template states:

tag: The HTML tag name to use; either 'th' or 'td'.

From within the context of the Twig template, this is correct. However, the template does not document how to set this variable.

In theme, inc. I can see that the tag type is set here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/includes/them...
With the $is_header value being set here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/includes/them...

So, to set a table cell to use a TH tag, the header attribute for the cell must be set. Here is a simple example:

$table = [
  '#theme' => 'table',
  '#rows' => [
    [
      [
        'data' => 'Header cell',
        // Setting header to TRUE will cause this cell
        // to be a <th/> rather than the default <td/>.
        'header' => TRUE,
      ],
      [
        'data' => 'Normal cell',
      ],
    ],
  ],
];

Maybe an update to the table.html.twig documentation to indicate how to set a table cell as a header, would be beneficial to developers.

I'm replying to your ticket with a summary of my findings.

I have figured it out! header needs to be set to TRUE. Here is a simple example:

$table = [
  '#theme' => 'table',
  '#rows' => [
    [
      [
        'data' => 'Header cell',
        'header' => TRUE,
      ],
      [
        'data' => 'Normal cell',
      ],
    ],
  ],
];

I solved this by going through the core code to determine where the tag is being set. I wonder if/where this is being documented however. 

I think the rendering engine actually makes data structures that match the twig template. Like, each row will have a cells array and so forth. But it's not honoring manually-created ones.

This makes sense, as the table cell type is outputted as a variable, and not hard-coded, so they must be set somewhere. But as you and I seem to have figured out, there isn't a way to manually set this value, which would be a bug seeing as the documentation states that you can.

I think you or I should file a bug report, that can be changed to a request for documentation if it turns out that there is in fact a way to set the element type. You are the one to have found this and spent the time on it, would you like to open the ticket? I also am ok with doing it if you would rather not.

I just spent a little while on this, and was not able to get it either. It does seem to potentially be a bug. I can't find any examples in core where they are setting a th tag, nor any tests that are testing to ensure it works. And my own attempts at getting a th tag to render have failed as well. I can see the place in the template where the tag should be rendered, but doing variable dumps of the row at this point, and then testing various formats for building the #rows array, has not lead to any way of setting the tag type that I can find.

There are two Drupal concepts you need to understand, and there is a module that brings these together.

The first concept is text formats. When creating fields on a Drupal entity, there are 'text, formatted' types. The formatted part is the relevant part. When a field is set to use text formatted, any textarea that takes data automatically comes with a field call the 'text format'. An example is the body of nodes - all nodes are long text formatted. What text formats do is that when the text is saved, it is passed through the text format. The text format is a series of rules, individually called input formats, that alter the saved text according to each rule. When you install Drupal with the default profile, it installs two text formats - Full HTML and Basic HTML. The text formats installed on your system can be seen at Admin -> Configuration -> Content Authoring -> Text Formats and Editors.

The other concept is tokens. You are trying to create a token. Drupal has a robust Token API, which you can extend with your own tokens either through code, or using a module → .  

You can tie these two concepts together with the Token Filter module → . When this module is enabled, each text format configuration gets an additional checkbox titled 'Replaces global and entity tokens with their values'. This filter goes through the text, and looks for an tokens in the Drupal token API format, and replaces them with the value.

So you can create custom tokens, enabled the token filter on a given text format, then use that text format with the textarea when creating your content. The content will be parsed for any tokens, including your custom tokens, and the values will be inserted.

Wouldn't I lose anything related to those modules if I do that?

No. Configuration is stored in the database, and Composer acts on code, not the database.

Rough process:

1. In Drupal, uninstall any modules that don't have a Drupal 10 version (lose the functionality, or figure out an alternative. Either way, remove them). Then remove the modules from the codebase using Composer
2. Remove Drush (it gets in the way of upgrades) from the codebase using Composer
3. Try upgrading core. If it doesn't work, use composer prohibits to determine which module is blocking the upgrade. Since any modules blocking the upgrade have a D10 version (or you would have removed them altogether in step 1), you can remove them from the codebase using composer. Keep the removed modules in the list.
4. Upgrade drupal/core-* with Composer.
5. One by one, use Composer to re-add the modules you removed in step 3 to the codebase
6. Re-add Drush to the codebase with Composer
7. Rush drush updb

As a tip, when doing upgrades to D10, when I run into modules that are blocking the upgrade, that I can see have a D10 compatible version (on the module page on Drupal.org), I remove them from composer, upgrade core to D10, then re-add the module after upgrade.

Getting sticky modules out of the way makes upgrades a lot smoother, as it is easy to re-add them after upgrade. Removing the code with Composer does not affect the status of the module within the Drupal database, and as long as you don't do anything to Drupal during your Composer upgrade you're ok.

I would NOT do this on a live site though, if I read your last comment correctly. You should be working this out locally.

If you enter an email address on the SMTP settings page, it will send a test mail. The debug info should show up on the top of the page after submission, but sometimes a redirect happens afterwards that clears it out, so you may have to watch fast.

The SMTP module has a debug option, maybe that can help.