🇨🇦Canada @jaypan

A facet wouldn't generally be a textfield, as facets are a method of filtering content through aggregations of values found in a result set. For example, searching cars nearby, and then being able to use facets to drill down to given car brands found within that set.

A textfield filter would be an exposed filter in Drupal terms. This would allow you to enter text and then filter it by start with/ends with/contains etc.

jaypan → created an issue.

Added titles for buttons that did not have them

Spinning recipe installation out into a separate documentation page ( https://www.drupal.org/docs/extending-drupal/drupal-recipes/how-to-downl... → ) so that more detail can be included. Added a link from this page to the new sub-page.

A way to prevent this type of issue in the future, would be to remove the call to create() altogether, and then add functions to retrieve the managers that initialize them before returning them. So you can add these getters:

<?php
public function getCustomFieldTypeManager() {
if (!isset($this->customFieldTypeManager)) {
$this->customFieldTypeManager = \Drupal::service('plugin.manager.custom_field_type');
}

return $this->customFieldTypeManager;
}

public function getCustomFieldWidgetManager() {
if (!isset($this->customFieldWidgetManager)) {
$this->customFieldWidgetManager = \Drupal::service('plugin.manager.custom_field_widget');
}

return $this->customFieldWidgetManager;
}

Then change instances of $this->customFieldTypeManager to $this->getCustomFieldTypeManager() and $this->customFieldWidgetManager to $this->getCustomFieldWidgetManager(). This way, if you change the property names in the future, classes that extend your class will not be affected.

I figured out the problem. I was extending CustomFlexWidget to create a custom widget, and I had extended the create() function. I was setting $instance->customFieldManager in 3.1.7, I needed to change this to $instance->customFieldTypeManager in 3.1.8, as it appears the property name changed between versions.

jaypan → created an issue.

The drupal sites/default/files/css folder is missing on my production site, but it is full of css files on my ddev local. Same issue with the js folder.

1. Go to Admin -> Configuration -> Development -> Performance - are CSS and JS aggregation enabled? If not, enable then
2. If they are enabled, clear the registry. Is the folder now created on the server? If not, check the logs, do you see any issues? It's possible your files directory is not configured to write.
3. Go to Admin -> Configuration -> Media -> File System, and review the details. Does it all look correct? Do you see any errors if you click the save button on this page?

ddev causes problems, you might want to try a plain LAMP stack.

I personally find the reverse to be true.

trackleft2 → credited jaypan → .

I actually skipped over your comments on cloudflare the first time I read it. I think that if you are using Cloudflare, you probably don't need Litepseed, it wouldn't provide much benefit at all.

Your host is trying to upsell you, though you probably will see performance improvements if you set up lightspeed. They are different caching layers. You shouldn't see any conflict, the only question is whether you want to pay for the performance boost that Lightspeed will provide.

that you are not trying to imply that I have been rude to you because I most certainly have not.

Not to me, but your response was a little aggressive towards a different user, who is an unpaid volunteer that was helping you out, with no hope of any recompense other than maybe a 'thanks for trying to help'.

May I suggest to any developers reading this that such a setting is added because allowing visitors to omit a name seems rather like an option which relatively few site owners would take, given the choice.

Drupal core developers don't really hang out in the forums. The forums are basically maintained by people who just do it cause we do it. The Drupal organization doesn't promote the forums, and has even buried them to some degree making them harder to find.

As such, you are better off opening a feature request in the Drupal issue queue for a feature, as posting in the forums for change in Drupal core is akin to screaming into a windstorm. Drupal issue queue:  https://www.drupal.org/node/add/project-issue/drupal →

Regarding hiring third parties, I have to manage my own site entirely without any paid help. I would say that many people are in the same boat.

Many are - I maintain my own sites without hiring people. But sometimes you hit a point with a feature where it's either it's hire someone, figure it out, or go without.

You can't really expect ordinary people to go around creating their own modules! I would not have a clue where to begin and that linked page certainly did not look anything other than daunting and time-consuming.

No one expects you to do anything. Drupal is free software, and the forums provide free support by unpaid posters who are just trying to help out of good nature. There are no expectations other than being polite to others.

Hopefully for you, someone can come along with another solution, then there will be a thread with different possible solutions based on the needs of the reader. If no one does come along with something, you now have a pointer as to what you would need to learn to solve this issue. Or as always, 3rd parties can be hired to do work. Wombatbuddy freelances I believe, and as you can see he has a handle on how to solve your problem.

That is the Drupal version of AI imagining humans have six fingers - it looks ok at first glance, but when you look closer you're like 'wait, what?'

That code isn't usable. It's a  mix of normal PHP and some Drupal 7 code, under an explanation that purports to be drupal 8.

Can you provide a little more info? There are a few possible interpretations of what you may be trying to do.

I asked for a feature request for the Custom Field module recently, and they provided it within 23 hours. They are very responsive.

https://www.morpht.com/blog/drupal-and-composer-part-2-managing-drupal-8...

I would like to modify martex, and wonder what tools are the best to use to do this quickly and efficiently.

You can create sub-themes of sub-themes. Ressa and I have been suggesting creating a custom sub-theme of whichever theme you are using - which now I can say is a subtheme of martex.

What you are describing is the use case for creating a sub theme. 

I don't know how to create a sub-theme

ressa linked to the method in his first reply.

These changes will be wiped out next time you update your theme, which is why we recommended a sub theme.

There's already a non-complicated way to do this using the REST API. Or, you can create a custom module with a route that would take parameters and create the node.

Yes, and you can also create custom Drush commands to run Drupal stuff from outside.

jaypan → created an issue.

I have, and it works, but I don't myself like storing CSS in the DB, so I don't use it. I also don't recommend it for the same reason, though that's not to say I recommend not using it, rather that I just personally don't give recommendations for that module. It does work well.

While the theme may have methods for adding your own CSS, if you use a sub-theme as ressa has suggested, it's easier to maintain over time. It's also easier to swap out the parent them in the future when you decide to go with a different theme.

Yes, you can use Headless Drupal as the endpoints for creating apps. I have done it a number of times over the years.

Sites accessed through the browser make requests, that return data, markup (HTML), styling (CSS) and front-end functionality (JavaScript).

The same 'page' accessed through the app will only request raw data from the server. The markup, styling, and front-end functionality are all stored within the app when it is downloaded.

So when creating an app to work with Drupal, Drupal is used to create endpoints that the app requests data to.

Nice. It seems like a beneficial command to me.

Here's a tutorial that I wrote in a former life on using Drupal  with Composer. It's referring to Drupal 8, but it's still relevant for Drupal 10 and 11 for the most part.

As of Drupal 10.3 (I think), modules and themes can only be managed using Composer.

ressa has provided you with the Drupal way to do this.

Drupal has a flow of generating data, then passing it to the theming layer. Data is generated in core and modules. Theming is handled in themes. So the flow is essentially Core -> Module -> Theme. Adding templates would go against the Drupal paradigm, as it would be Core -> Module -> Theme -> Module. This can create difficult to debug errors.

Core and modules provide default templates for any theme hooks they define, so that theme developers have a base from which to custom. Core/module templates should only contain the required HTML to create a semantic document representing whatever the theme hook is displaying. And generally styling in the default templates provided by core/modules should be limited to layout/positioning of elements that will be consistent regardless of theme. Anything theme dependent is handled at the theme layer.

So if you want to override a template not belonging to your theme, you would, as ressa has stated, create a sub theme, and override the template there, rather than doing it in a module.

Nothing stands out to me. If you remove the chunk of code I identified earlier, do you still get the error? I may have misdiagnosed.

Moving to needs review.

Here's a patch for 8.x-1.x for a stopgap, as the merge request is for the -dev branch.

I wrote a tutorial a few years back on extending site configuration. Maybe this is what you want: https://www.jaypan.com/tutorial/drupal-extending-core-configuration-exte...

I'm thinking your problem probably lies with this:

    foreach ($props as $prop => $value) {
      $element->set($prop, $value);
    }
    $element->save();

I'm thinking that it's sometimes passing a value that is not in the correct format. I would try to find a way to replicate the issue, then throw a debugger on the set() line, examining $prop and $value for each iteration to see if something stands out.

Removing D7 example, as architecture has changed.

This issue is still present in version 8.x.

As even further forward thinking, there may even be a case for using the Subgroup module, and making Private Messages a Group type as well, then make them Subgroups of Private Message Threads.
For example, there could be a Group type of Private Message, and a Group type of Public Message. As each Group/message type would have it's own permissions by role, the public messages could be made visible to non members, with the private messages only visible to members. The thread itself could be made public, but the public would only be able to see the public messages, since they wouldn't have access to the private messages.

Please note that I'm just putting this forward as a proposal - I don't have the bandwidth to implement it, nor do I remember the module architecture well enough, nor know the changes that have come about since, to be able to know the work required to bring about this architectural change. I'm just putting forth a proposal for the current maintainers to consider.

jaypan → created an issue.

I would create a page and drop the contact form block into the page with layout builder.

Adding link to patch for maintenance-page--ofline template to work.

DatabaseAccessDeniedException: SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost'

Looks like your DB credentials are incorrect in settings.php.

Did you copy the webroot .htaccess to the server?

Nice work.

But the import then refuses that file. 

Error message?

Views is rendered in the theme of the page that it is rendered on. If it an admin page, it will be rendered in the admin theme, if it's a front-end page, it will be rendered in the front-end theme.

Views pages are like any page in Drupal, that can have sidebars etc according to the them. Or, you can create a page with layout builder, and embed the view in that layout. Both options will allow for sidebars/layout.

The updated interface on the field settings page is nice as well.

Thanks, I was looking under the manage for tab. Much appreciated! Thanks again for the quick turn around.

Thanks for the quick turnaround! I've just installed the latest version of the module, but I'm not seeing how to set individual form elements to not be rendered, Can you please provide some direction?

jaypan → created an issue.

I second DDev.

I don't know this error you are facing. However, I don't see these libraries in your composer.json, so I woud:

1. Make a copy of composer.json and composer.lock
2. Use composer to require those modules (add them to composer.json)

See that resolves the issue.

What does your composer.json look like?

I don't think it was off topic. I was adding extra context as to what was happening with Solr in the background.

This is very true, though technically Solr is not the database, as the Drupal DB is still the backend of the site. But data is duplicated on Solr for querying, and results queried from Solr are much, much faster, than DB queries.

I've never seen anyone do a benchmark comparison with different compatible database types. But MySQL/MariaDB is the primary database used to power Drupal sites, and I've worked on massive corporate sites with tens of thousands of hits, using MySQL as the backend without issue.

I personally avoid multisite, as it introduces a lot of complexity making it difficult to handle. It does have valid use cases, but what it won't do is allow you to share content between the sites. To do that you will need a different method. If you will have lots of content, then using the Domain module → is an alternate that achieves similar goals as multisite but will allow sharing of content. If it was just one taxonomy I wanted to share however, I would create a view that dumps the terms from each site, and parsers on each site, with each site on a schedule to parse the dump and create any new terms from the site it's reading from.

It's now been added to the menu:  https://www.drupal.org/docs/develop/git/git-branching-strategy-for-multi... →

Sorry incorrect info

You probably want internal:/api/27

What is your goal from an end-user's perspective? And is there a reason why you are not defining your links in a .yml file?

As someone who used to develop in MAMP, and switched to DDev, it's a very easy switch over, and any time spend trying to figure out MAMP ends up being time wasted. DDev just does it easier and better, and you'll actually be able to get more support since few Drupal developers develop directly in their local environment anymore, developers these days are using DDev or Lando or others. It's actually quite easy to set up, as it's installed with Homebrew, and it's quite easy to learn too.

Have you looked into DDev? It's really easy to install on Mac with Homebrew, and it will solve all your issues as you won't use your native PHP/Mysql etc, everything is done in a Drupal-configured container that does not interfere with your system. I believe it's now the official local development environment for Drupal.

The reason you are having difficulties, as that you are working against the Drupal design flow of: core -> module -> themes. Code is generated by core and modules, and handed off to the theme layer for theming.

When you put a template in a module, you are disrupting the flow -> core -> module -> theme -> module -> theme. This is why the template is not picked up in your module, because you are piping back up to the module layer from the theme layer.

Modules are meant to provide functionality, and themes provide markup. When functionality is specific to theme (aka - when the theme is changed in the future, the functionality does not need to persist), it can be created in the .theme file. When it's functionality that needs to be maintained if/when the theme changes in the future, the functionality would go in a .module file. In either way however, templates are meant to go in the theme. Modules must provide templates for any theme hooks the module declares, but this is so that a template exists until it is overridden in the theme layer.

I do see the edit link. Just no link to create documentation. That said, I did a little Drupal hackery, examined the HTML to figure out what content type it is, guessed at the URL, and discovered that documentation pages, can be created (by me at least), at  https://www.drupal.org/node/add/documentation → .

I created this page:  https://www.drupal.org/docs/develop/git/git-branching-strategy-for-multi... →

Apparently only the guide maintainers can add it to the guide however. I set it as part of the GIt Version Control System guide, so hopefully they get a notification or something to review it.

I'm thinking it may be a bit much for a single page. And no, I don't see any link on the link you gave to create a page, so I think I don't have permission.

I can't figure out how to create a new documentation page. Do you know?

When a developer tries to drush cim from the Git *.yml baseline folder, Drush will delete any configs from the developer's local Drupal site which are not included into the Git baseline folder. This implies if the developer has new configs for his local site (that he wants to keep), he should not drush cim from the Git baseline *.yml folder (doing so will wipe out his new configs that he has not pushed to Git yet).

With the flow I described above, a developer only ever does drush cim in a clean branch where all changes have been committed. So there will never be anything in their database they would want to keep, because they will already have committed their changes in their branch.

Now, you can imagine that sometimes mid-task, a developer may need to switch to another task, in which they may have changes they want to keep. Here is the full flow:

1. Developer creates a new feature branch 1.x.x -> feature-1
2. Developer makes some changes to config in the database
3. Requirement comes in to immediately work on a different higher priority feature
4. Developer exports their config drush cex - at this point, all changes the developer will have made, are reflected in code, between the exported config files and any changes module/theme files
5. Developer stashes their change with git stash - Now the branch is back to the default state when it was created from 1.0.x. This can be confirmed with git status
6. Developer checks out 1.x.x git checkout 1.x.x && git pull
7. Developer creates a new feature branch git checkout -b feature-2
8. Developer syncs their system with the codebase composer install && drush cr && drush updb && drush cim
9. Developer makes their changes in feature-2
10. Developer exports their changes, and commits them in feature-2 - now git is clean, with no unmerged files
11. Developer is ready to go back to their original work. So they checkout their branch, and 'pop' the stashed code they stashed earlier git checkout feature-1 && git stash pop
12. Developer has changed branches, so they sync their database with the code composer install && drush cr && drush updb && drush cim
13. Now the developer can continue with their development of feature-1

As you can see, drush cim is only ever run in clean branches.

Therefore, a developer should always push his local config into Git first (so any new local configs are synced with Git). Now Git has his new configs *.yml, so he is now safe to drush cim from the Git baseline folder.

You have the correct idea here.

When a developer exports his Drupal site full archive and untar/unzip it into separate *.yml files, overlaying/copying his set of *.yml files with the Git baseline folder will not actually delete any *.yml files that is already in Git. Therefore, for the configs that the developer has deleted locally, the developer needs to visually identify and manually delete the *.yml from the Git baseline folder and commit/push the deletions to Git. There is really no other (easier/faster?) way of doing this. Is that correct?

There are no tarballs in the flow I described. Everything is managed through Git and Drush. If there is some situation where you would export a tarball of .yml config from a site and bring it into another installation, you would first delete ALL the config files in the destination instance, and then add the new configuration from the tarball. Config is a set package, and pulling it apart without a strong understanding of how the internal code relates to each other is likely to cause import problems.

Many of the *.yml has a UUID string. I read that when importing YAML configs, if Drupal sees a different UUID string, Drupal will delete the corresponding entity and re-create it. Since different developers with different local Drupal sites will have different UUID strings for the *.yml configs, wouldn't drush cim from the Git baseline cause entity/data loss from the developer's local Drupal site? Would this be a problem? Should I even worry about this or not so much? (I still am not clear on the implications of having different UUID strings in the *.yml files).

With the flow I described above, you do not have to worry about UUID, the system will accept them. In the case that you are bringing over a specific config .yml file from another installation and want to import it, you can delete the UUID from the file and Drupal will allow it to be imported (if everything else in the file is compatible with your system).

Sure, I'm good with that :)

This is how I handle this. First an explanation of my Git flow, how I address a few situations, then I'll answer your questions using my explanation as the context/reference.

My git flow:

1. I always have a git branch that is a  mirror of production, in the format [MAJOR].x.x, eg 1.x.x. Development is not done on this branch. It should only ever be updated after a successful deployment to production, to ensure that it is an exact copy of production.
2. I clone that branch, to an active development branch, in the format [MAJOR].[MINOR].x, eg git checkout 1.x.x && git pull && git checkout -b 1.0.x.
3. When a developer starts work on code, they clone a new branch from the active development branch created in step 2. As 1.x.x is the same as the code on production, this ensures that the starting point for the code changes will work on production. For example 1.x.x -> feature-1. (Side note - I prefer to use ticket numbers for the branch name, so that everything is cross-referenceable, and means that any code changes will have an accompanying ticket from which to get information about the change)
4. The developer synchronizes their local environment with the git branch:composer install && drush cr && drush updb && drush cim
5. When the developer is finished their work, they export config to the file system, and comit the config .yml files.  they open a pull/merge request, to merge the feature branch into the active development branch, eg feature-1 -> 1.1.x.
6. When a new release is to be deployed, a new Git tag is created in the feature branch, with the full version. Eg. 1.0.0, then 1.0.1, 1.0.2... and so on
7. The this tag is checked out into testing environments, so that whomever is testing that the code works, can review it.
8. If the testing fails, fixes are made in the feature branch relevant to the bug, eg feature-1, then go back to step 4. Repeat as necessary.
9. When testing passes, the git tag is checked out in the production environment, containing all the tested code
10. As the code on production and the main 1.x.x branch have now diverged, the release tag is merged into1.x.x, eg 1.0.8 -> 1.x.x. This once again makes 1.x.x an exact copy of the code checked out on production.
11. Go back to step 2, and create a the next active development branch, ie 1.x.x -> 1.1.x. New PRs will now be committed to 1.1.x
12. If any hotfixes are needed, the flow is 1.x.x -> Hotfix branch -> [next tag] -> 1.x.x -> 1.1.x. Or, in other words, a copy is made from the current production code into a hotfix branch, the fix is applied, the branch is merged back into the previous active development branch, and a new tag is generated. This tag can go through testing and to production. When it is deployed to production, it is merged back into the production mirror branch, and then into the current active development branch.

Note 1: In regards to step 3, branches will almost always be created from the production mirror. However, sometimes during active development, branches will require code that has been developed in another branch in active development. In this scenario, instead of creating the branch as described in step 3 above, it would be created from the feature branch it depends on, iefeature-1 -> feature-2

Note 2:  New major branches are created for major breaking code changes. For example when going from Drupal 10 -> Drupal 11, Git can be branched 1.x.x -> 2.x.x, an active development branch is created 2.x.x -> 2.0.x, and the Drupal upgrade to D11 would be handled as 2.x.x -> [UPGRADE BRANCH] -> 2.0.x. Regular non-D10 development would be handled in 1.x.x, to be merged into 2.x.x when ready.

Note 3: The advantage of an active development branch (step 2) can be seen with the following scenario:

1. Three feature branches are created, feature-1, feature-2, and feature-3
2. These branches are merged into the active development branch: 1.3.x
3. Upon review, the client decides that they do not want feature-3 anymore. 

This creates an issue in that it is tricky to extract a feature branch after it has been merged, and in relevance to this particular thread, can cause issues with configuration. Due to the presence of an active development branch, the above issue can be resolved as follows:

1. Create the next active development branch from the copy of the production code. In the above case that means1.x.x -> 1.4.x.
2. Merge the branches that ARE to be deployed into the new development branch. For the example above, that means merging feature-1 and feature-2 into 1.4.x.
3. 1.3.x is then abandoned.

That covers the logic behind how git branches are structured. It allows for flexibility as well as graduated releases based on a semantic versioning system.

In regards to your questions on configuration, let's dig deeper into steps 3-5 of the overall flow, on how an individual developer will deal with issues.

1. Developer creates a new feature branch, eg 1.x.x -> feature-1
2. Developer commits their changes, pushes their branch, and opens a pull/merge request
3. Someone else has already made a commit that has conflicts. The pull/merge request will report this and not allow merging
4. The developer, locally, checks out the the active development branch, which is conflicting, and pulls any new changes. They then merge the active development branch into their feature branch. If the active development branch is 1.0.x, that would be: git checkout 1.0.x && git pull && git checkout feature-1 && git merge 1.0.x
5. Any conflicts require visual review and resolution of the conflict, sometimes in consultation with other developers to understand what is happening in the conflict
6. Next, Drupal is synced with any code changes that have come into the branch from feature-1: composer install && drush cr && drush updb && drush cim
7. The functionality of the branch is confirmed through the UI or whatever means, to ensure that merging in the changes from the active development branch did not break the new code. If anything needs fixing, it can now be fixed.
8. Config is exported.
9. The updated code is committed, and pushed
10. The original pull/merge request blocked in step 3, is now not blocked and can be completed (unless someone in the meantime has pushed new conflicts)

Now, to address your questions, in regards to the above context of how I structure things:

Configs/YAML files that have been created by other developers representing new features from other developers (pulled from Git)

Any time developers changes branches, they must synchronize their DB with the code in the branch. This is seen in step 4 of the overall flow above, and in step 4 of the process of handling conflicts when running composer install && drush cr && drush updb && drush cim. The last step, drush cim, will import any changes in config that have come from other users, adding any new configuration.

Configs/YAML files that have been deleted/removed by other developers (pulled from Git)

Same as the above, any configuration removed by other users will be removed when the configuration is imported with drush cim.  

Configs/YAML files that have been a developer have added locally (representing new features on the site) (should be pushed to Git)

These are handled with the pull/merge requests. After the developer's code has been committed, and other users pull it to their system, they will import the changes into their local configuration with drush cim

Configs/YAML files that have been a developer have deleted locally (features removed from site) (should be pushed to Git)

Same as the last question, when a PR is merged, any removed config will then be removed from other environments as the code changes are merged, and the configuration is imported with drush cim

Configs/YAML files that have been modified both by the developer locally as well as modified by other developers (pull from Git)

These will result in merge conflicts, which are handled by the process I outlined above for handling conflicts. These can be messy to figure out, so it's best, when possible to not have developers working within the same area creating a situation in which they could be concurrently working on the same configuration. It's sometimes not possible to avoid however, in which case, discussion between the developers when resolving merge conflicts is essential, to ensure everyone's required code is present.

Reported as spam.

Love it :)

That was your method of achieving some goal, not your goal.

No, I don't. But I know Drupal so-so, and thought maybe I could provide an alternate solution. But I don't have anything for you with your current method, best of luck.

What is your goal behind this? There may be some other Drupal solution that does not use your method.

A meaningless AI answer if I ever saw one.

I just ran into this exact issue today, and I was not able to find a way to add/extend configuration to a views block. In the end, I went an alternate route - I created a block plugin, that has custom configuration, and renders the view.

Use case:

1. I have a views block displaying items
2. This block will be rendered in multiple areas on the site
3. The header text for the block must be customizable in each area it is rendered in on the site
4. For a clean UX, the header text must be entered when placing the block, ie in layout builder or on the block layout page (or anywhere else).

Solution:

<?php

declare(strict_types=1);

namespace Drupal\herons_base\Plugin\Block;

use Drupal\Core\Block\Attribute\Block;
use Drupal\Core\Block\BlockBase;
use Drupal\Core\Form\FormStateInterface;
use Drupal\Core\StringTranslation\TranslatableMarkup;

/**
 * Creates a 
 */
#[Block(
  id: "abc_list_block",
  admin_label: new TranslatableMarkup("A listing of ABC block items"),
)]
class RepairJobCancelBlock extends BlockBase {

  /**
   * {@inheritdoc}
   */  
  public function defaultConfiguration() {
    return [
      'header_text' => [
        'value' => NULL,
        'format' => NULL,
      ],
    ];
  }
  
  /**
   * {@inheritdoc}
   */
  public function blockForm($form, FormStateInterface $form_state) {
    $header_text = this->configuration['header_text'];
    $form['header_text'] = [
      '#type' => 'text_format',
      '#title' => $this->t('Header Text'),
      '#default_value' => $header_text['value'],
      '#format' => $header_text['format'],
    ];

    return $form;
  }

  /**
   * {@inheritdoc}
   */
  public function blockSubmit($form, FormStateInterface $form_state) {
    $this->configuration['hello_block_name'] = $form_state->getValue('header_text');
  }


  /**
   * {@inheritdoc}
   */
  public function build() {
    $header_text = this->configuration['header_text'];

    return [
      '#prefix' => '<div class="abc_list_wrapper">',
      '#suffix' => '</div>',
      'header' [
        '#prefix' => '<div class="header-text">',
        '#suffix' => '</div>',
        '#type' => 'processed_text',
        '#text' => $header_text['value'],
        '#format' => $header_text['format'],
      ],
      'view' => [
        '#type' => 'view',
        '#name' => 'abc_blocks',
        '#display_id' => 'listing_block',
      ],
    ];
  }

}

I've never seen a file extension with a hyphen. A google does not show me any links that say that hyphens are not allowed, but neither can I find any examples of file extensions that contain characters with anything other than numbers and letters. It seems Drupal will only allow letters, numbers and underscores. Is this file extension one you have created, or is it for some existing software?

jaypan → created an issue.

What is the error? This could maybe be a server configuration issue. Is the error coming from Drupal or the server?

Export the content, find or build a sharepoint importer, import the content to Sharepoint.

But you won't find much more info than that here, as people would know how to import data from Sharepoint, not too. You're better off finding a Sharepoint forum to find out how to migrate data into sharepoint.

You can open a ticket in the Drupal issue queue as a support request, requesting these be removed: https://www.drupal.org/project/issues/search/drupal →

You need to create the config directory as a sibling directory to your webroot.

So if your webroot is /path/to/webroot, it would be /path/to/config

This is what view modes on entities are for. Each view mode allows for a different way to view the entity. You can choose which fields to show, and how they will display, and have different templates for each view mode.

Due to the lack of detail, it's not at all clear what you are trying to do, that said, I doubt it's possible.

At the time of writing, Drupal 11.2 has not been released and does not exist. The current version is 11.1.2. Did you manually change your composer.json file?

Thank you!

What does the PEVB module do wombatbuddy? I'm reading the module page, but can't fully understand what it does.

In the end I went with a non-views solution. I think this may be a problem with Drupal core views, rather than this module specifically. I wasn't able to find a solution.

I have recently for the first time used the Custom Field module → , to accomplish the goal of what I used to do with Paragraphs module → .