Thats what should do but drupal ignores just the setting
What caching did you disable, and how?
You could change hosting providers, but generally its better to build your project locally, and push the built project to the remote server, rather than running Composer on the server.
The problem is a caching issue. The reason you don't see the caching as an admin, is that pages will be dynamically calculated for dynamic users.
Caching is applied before templates are processed, which is why you cannot handle this at the template level.
Because disabling caching on this block would blow out caching for the whole page, you're better using a #post_render callback to build the block contents so that they are built dynamically after caching.
Fixing incorrect references to a .module file in a theme.
As Drupal 7 is now unsupported, documentation regarding comparisons with D7 has been moved to the bottom of the page.
My method:
- Export current config: drush cex
- Commit current config: git commit -m "Some commit message"
- Add content type through the UX as normal
- Export new config: drush cex
- Do a diff to find out any new/changed files: git diff
Whoops, sorry, I missed that! Thanks for updating.
Making it more clear where variables available to the component's template file are defined.
Removing reference to Drupal 6 Colophon theme, replacing them with 'fluffiness' theme used on this page as it is more relevant.
Deprecating this page as it refers to a Drupal 7 module.
Deprecating this page as Mollom was shut down in 2018.
Deprecating this page as it refers to a Drupal 7 module.
Deprecating this page as it refers to a Drupal 6 module.
Deprecating the page as it refers to a Drupal 6 module.
Page refers only to D7 and older modules. Needs an update for current Drupal versions.
This module does not have any compatible versions with current Drupal. Deprecating.
This module no longer has compatible versions since Drupal 7, so I'm deprecating it.
Removed references to Drupal 6 and 7, and modules for Drupal 7.
Removed references to Drupal 6 and 7, and changed 'Drupal 8' to 'Drupal'. The content still needs a review for currency and accuracy.
This page refers to a no longer supported Drupal 6 module, and is no longer relevant.
This page refers to a Drupal 7 module, which is no longer supported.
Removed outdated D5, 6 and 7 modules. New examples are required for current versions of Drupal.
The page refers to Drupal 6 and Drupal 7, neither of which are supported, so I'm marking the page deprecated.
Cleaned up text for declaring theme hooks and creating templates.
Cleaning up text on section regarding path() and url().
Re-wrote text on unsafe translation (using variables).
Updated example so that output of twig would be grammatically correct in English.
Making text in one section more clear that it is showing an incorrect method.
Made some changes to text and formatting for clarity.
Config files are exported and imported as a snapshot for the site, generally you shouldn't need to be dealing with individual files for anything, though I use Cypress e2e testing, not functional tests, so it may be that I'm missing something from that.
Can you give more details about what you mean by finding config files? How/why are you finding them?
How did you install composer? Did you install as the root user? It sounds like permissions issues.
I would ask on a composer forum if you can find one. Something is wrong with your composer installation.
As a start, I'd delete the entire vendor folder and run composer install from the project root.
They generally aren't so different, usually version updates are more along the lines of keeping up with underlying libraries.
It's better to start your project on Drupal 11 if you can, and if you find that one or more modules you need are not updated for D11, you can switch to D10 and upgrade later.
It's mostly still relevant. If you find something doesn't work, google it to find how it's changed, but all the concepts discussed essentially remain the same.
A tutorial I wrote on Composer a few years back in a different life. It's still about 90+% relevant: https://www.morpht.com/blog/drupal-and-composer-part-1-understanding-com...
It looks like this module could potentially be used to achieve your goal: https://www.drupal.org/project/term_reference_tree →
I haven't used it, so I can't provide assistance, but it seems like an avenue to explore.
I was able to get something working using a computed field approach with custom PHP logic, but I quickly ran into the same limitation: it only recalculates when the node is edited, not dynamically on every page load.
Computed fields by default should calculate every time they are loaded, unless something is explicitly cached. Can you show your custom field code?
I meant the first, and the second is an add-on for the first, which looks like it could achieve your goals.
Basically, the groups module gives you the ability to add the idea of sections, or areas, or spaces, or groups, to a website. For example on a news website, a group could be a section like sports, or business. Groups is great for school websites, as you can set up groups for classes, so a teacher can manage their own class. Or projects, where stuidents can all participate and upload content, maybe managed by a teacher.
You create the content types you want, then you set up groups that are able to own/manage that content. Then if necessary, you set up users to manage their group content.
Did you add a new module or some custom code? This isn't something that would usually (ever?) pop up suddenly, but rather when new code is introduced (potentially after the first cache clear).
Panda's Profiling is a python script and does not appear to have a Drupal module associated with it. Reported as spam.
The Groups module is made to be the base architecture behind this type of scenario. It allows you to have groups which each have their own members and permissions with what they can do with in that group.
Problem/Motivation
I ran into a collision between the Subgroup module and the Group Content Menu module. When trying to delete a subgroup, I was getting an error that a relationship could not be deleted when the subgroup content still existed. Upon debugging, I determined that the Group Content Menu module is deleting plugins it does not own in this GroupContentMenuHooks.php:
// Remove any group contents related to this menu before removing the menu.
if ($entity instanceof ContentEntityInterface) {
if ($group_relationships = GroupRelationship::loadByEntity($entity)) {
foreach ($group_relationships as $group_relationship) {
$group_relationship->delete();
}
}
}
This code was deleting the relationship between the parent group and the subgroup, but that relationship was not ready to be deleted yet (the subgroup module handles that).
Steps to reproduce
Enable the subgroup module, create a group and subgroup. Attempt to delete the subgroup with $subgroup->delete()
Proposed resolution
I have determined that a check to ensure that the relationship being deleted in the code above first requires a check to ensure that the relationship has a plugin ID of group_content_menu.
Remaining tasks
Reviewing, testing and merging.
User interface changes
None.
API changes
None.
Data model changes
None.
Views sorts are plugins. You could create a custom views sort plugin using the logic/code above, and then you could manage it directly through the view interface. Here's an example of a Views sort plugin from core: https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Plugin%...
In my experience it's better to set the webroot up in /web. But, if you want to switch it, you can change that in composer.json.
There you go :)
If you want to read more about composer, I did a write up in a former life. It refers to Drupal 8, but it's mostly still applicable. https://www.morpht.com/blog/drupal-and-composer-part-1-understanding-com...
Two things:
1) You are running composer with root permissions. As it says, this is not a good thing. You should reinstall composer as your regular user, not as the root user. I don't think this is your issue though.
2) Drupal modules are hosted on an external repo, that requires that repo be declared in the Drupal composer.json file. I'm thinking you may not have a Drupal composer.json file in your project, meaning the repo isn't declared, so it can't find the eca module. What does your composer.json look like?
Please paste the full output, right from your command to the end of the output, rather than summarizing parts of it please.
Your command is two commands mixed together. You're asking for the composer version, then adding a command after it. You need to remove --version, and just do:
composer require drupal/eca:^3.0
Is the file actually created in the file system? Is a reference to it created in the file_managed table of the database? If the answer to both of those is yes, access to a private file is determined by access to the entity the file entity is attached to. So if you have file.jpg, and you have a File entity wrapping file.jpg, and you have a node to which the file entity is attached, then access to the file is given to anyone with access to the node, and denied to anyone without access. So do you have access to whatever entity the file entity is attached to?
Added a section clarifying the difference between the global drupalSettings object, and the settings argument passed to attach().
If I may, importing into content then leverages all of Drupal's caching mechanisms, and exposes your data to be used in all the ways Drupal handles data - views, content exports, REST backends, web front ends, however you need, and adaptable as it changes over time.
Generally when people feel the way you do, it's because they are trying to work with the web as they understand it, and not knowing the 'Drupal' way of accomplishing the same goals. Maybe you could explain why you feel importing into content doesn't work for your goals?
You need to get in the logs to find out what the error is.
Hopefully someone else can come along and do that, I do e2e testing (Cypress) on my projects, and have not worked with Drupal's testing suite for over a decade.
It sounds like you might want the Entity Queue module → . This allows you to create custom sets and order them by order of the entity queue.
I believe I have it working as follows, for a custom field with two elements:
* String field
* Serialized - Text (plain)
$fields['target_types'] = BaseFieldDefinition::create('custom')
->setLabel(new TranslatableMarkup('Vehicle Types'))
->setDescription(new TranslatableMarkup('Vehicle Types'))
->setSetting('field_settings', [
'brand' => [
'type' => 'text',
'weight' => 0,
'check_empty' => FALSE,
'widget_settings' => [
'label' => 'Brand',
'translatable' => FALSE,
'settings' => [
'description' => '',
'description_display' => 'after',
'size' => 60,
'placeholder' => '',
'maxlength' => 255,
'prefix' => '',
'suffix' => '',
'required' => FALSE,
],
],
],
'models' => [
'type' => 'map_text',
'weight' => 0,
'check_empty' => FALSE,
'widget_settings' => [
'label' => 'Model(s)',
'translatable' => FALSE,
'settings' => [
'description' => '',
'description_display' => 'after',
'table_empty' => '',
'required' => FALSE,
],
],
],
])
->setSetting('columns', [
'brand' => [
'name' => 'brand',
'type' => 'string',
'length' => 255,
],
'models' => [
'name' => 'models',
'type' => 'map_string',
],
])
->setCardinality(FieldStorageDefinitionInterface::CARDINALITY_UNLIMITED)
->setDisplayConfigurable('view', TRUE)
->setDisplayConfigurable('form', TRUE)
->setDisplayOptions('form', [
'type' => 'custom_flexbox',
'region' => 'content',
'settings' => [
'label' => TRUE,
'wrapper' => 'div',
'open' => TRUE,
],
])
->setDisplayOptions('view', [
'type' => 'custom_formatter',
'label' => 'above',
'settings' => [
'fields' => [],
],
'third_party_settings' => [],
'region' => 'content',
]);
Vishal.kadam's response is AI generated garbage that does not provide any solution and should be removed.
Are you using any custom templates for the blocks? the title_suffix needs to be outputted in the template for contextual links to show. Another possibility is a permissions error - are you logged in as a user who can view contextual links? Is the module enabled that shows contextul links?
I’ve noticed that the forum URLs look like
/forum/n*(e.g.,/forum/1,/forum/2) instead of using the forum name in the URL (like it is here on this site). How can I fix that?
This is handled with the Pathauto module → . You set up path patterns for forums, and the URLs will be re-written. The URL you see above is the canonical URL. You can customize it to anything else with Pathauto, which creates path aliases, that look along the lines of what you want.
How do I properly create and use categories and tags for my blog posts?
Taxonomy is the science of categorization. Taxonomies are a Vocabulary - a type of category (ie animals, vehicles, or in your case blog tags, and blog categories), and Terms, which are the category/term in the vocabulary. So for your situation, you would create two vocabularies, Blog Tags and Blog Terms. You set up the tags to be created if they don't exist. Then, on your blog content type, you would add two fields, of type Taxonomy Term. In the field configuration, you would choose the Blog Category for the first field, and Blog Tags for the second field. In the manage form settings for the Blog content type, you would set the widget for blog categories to be a selector of some sort, and you would set the widget for the tags as to be 'tag-type'.
And how can I customize the homepage to display article previews, instead of a blank or static page?
For this you would use the core Views module. At it's core, Views is a GUI for setting up database queries. But it's so much more, it also handles theming of the retrieved data intof pages, menu items, blocks, RSS feeds or other. It is extremely flexible. For your case, you would wet up a view of content (nodes). You would set up a 'Page' display, and give it whatever path you want. The view would be set to be filtered by the content type 'article'. The display would show 'entities' rather than 'fields' (those are the two options in the view). You then choose to show the content using the 'Teaser' display mode.
Finally, you would go to Admin -> Configuration -> System -> Site Settings, and for the front page path, you use the path that you set in your view.
In short, we’re still far from the simplicity of WordPress.
And Wordpress if far from the performance of Drupal. That's the payoff. If you're looking for simplicity, Wordpress is what you want. If you want performance, scalability, and flexibility, Drupal takes time to learn. But it's extremely powerful which is why corporations, government, and massive sites use it as the framework.
As a side note, Drupal.org could benefit from an on-site notification system, to catch users (like me) who may not check their email, but be on Drupal.org regularly.
My apologies, I have my Drupal.org email filtered to a folder I haven't been checking lately. I've added bluegeek9 as a full maintainer of Duration Field. Go at it, and thank you.
I still use the module on multiple sites. It's very beneficial, and still feels like it should be part of core.
This will break in Drupal 10.0.0
From those messages, it would appear you're on Drupal 9 which is unsupported. It's likely some of the issues you are finding will be resolved through an upgrade to a supported version.
If there's only 1 instance in core that could use it is this fully needed?
It's an API helper function that can be used by developers. I often need to set the destination on URLs.
I strongly recommend DDev over xxamp or wamp. DDev is much, much easier to work with.
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.
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.