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.
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.
- Go to Admin -> Configuration -> Development -> Performance - are CSS and JS aggregation enabled? If not, enable then
- 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.
- 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.
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.
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.
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.
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.