milosr β created an issue.
Hi @erwinvb
I just tested your case, and it works for me. Here is a video for you to check. You probably have some additional settings on your end that are causing the issue, but with the settings you provided, everything works fine.
Hi @mvnovick
I have tried multiple times to reproduce the issue, but I was not able to. Everything is working normally as expected.
Can you try to reproduce the issue on a clean Drupal installation? Because I couldn't. This seems like an internal issue specific to your site.
Try it on a fresh installation and let me know if the problem persists...
Or, if possible, send the Git repository so I can take a look.
hi @siddharthabm
Can you please send the patterns you are using and provide more details about the content you have created? This sounds like something related to taxonomy.
Are you using modules such as ECK, Entity API, or custom modules that modify taxonomy?
Have you properly updated Drupal and followed the steps outlined in the documentation?
https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-com... β
After the update, you should run the database update
drush updb
Hello everyone,
I have tried multiple times to reproduce the issue you reported, but I was unable to. Everything is working as expected.
The only thing I noticed is that after updating Drupal Core to 10.3.0, there is an update that needs to be run. (Itβs possible that you havenβt run it, which could be causing the issue.)
So, after updating Drupal Core, you should run:
drush updb
If any of you can repeat the steps and provide more details, you can reopen the issue and share the new information.
@missym
Your settings are incorrect:
1. The pattern is incorrect; it should be [node:title]
.
2. "Generate automatic URL alias" should be enabled for every content item.
For example, under: /node/51/edit?destination=/admin/content
, the "Generate automatic URL alias" option should be enabled.
This is also mentioned in the bulk generate message:
"Note that this will only affect items which are configured to have their URL alias automatically set. Items whose URL alias is manually set are not affected."
Once you apply these changes, bulk generate will work as expected.
Check the photos for more details:
I see that this has been corrected in the latest update, so it's not necessary.
milosr β created an issue.
milosr β created an issue.
@Anybody
Because of that, I disabled that option by default. If someone needs to delete logs for deleted entities, then they have options to do that.
I've created logic where 100 logs are loaded on cron. It checks if entities exist, and if they don't, it deletes the log. Deletion is disabled by default, but can be enabled in settings.
MilosR β made their first commit to this issueβs fork.
Hi, I added a new field called 'bundle,' which contains the entity type. Now, it can be filtered in the view by this 'bundle' field. This way, all fields under one entity type will be obtained together.
MilosR β made their first commit to this issueβs fork.
MilosR β made their first commit to this issueβs fork.
Hi @levmyshkin
The Entity log is used for tracking field changes on entities.
It's not used for deleting, so it seems like your custom integration for logging entity deletions caused an issue.
I tried the case you described, but I did not encounter any issues because the module does not log any deletions.
Hi @mdolnik,
This doesn't seem like a bug to me, it looks more like a custom solution you want to implement on your project.
I'm not clear on why you're calling the setEntityLoggedId() method. As you mentioned, if you want to modify logged values, you can extend the EntityLogService class and customize the logFields() method to suit your needs.
I can confirm that I was able to reproduce the issue on Drupal 9 as reported. Upon the first page refresh, there are no flags, but when navigating to another page, AJAX is used and everything works.
After updating to Drupal Core 10, it no longer works, not even with AJAX - nothing appears at all.
MilosR β made their first commit to this issueβs fork.
Hi @roman_pro
This is something that needs to be custom-made for a specific case, it's not something that should be done at the module level.
MilosR β changed the visibility of the branch 3137304-error-when-faceting to active.
MilosR β changed the visibility of the branch 3137304-error-when-faceting to hidden.
I am currently experiencing this issue on Drupal core 10.2.5 and Stage File Proxy Version 2.1.4.
@Asterovim
Hi, you can, for example, add a "changed" field in the view.
@thechanceg
Yes, it is possible, you just need to add field under General. Add the flag you need, and then in the view, add an indexed field like "User flag (indexed field)" as necessary. Additionally, you may need to add a User relationship in the view, depending on what is required.
@jukka792
Can you provide steps to reproduce this issue?
@Youcanlearnit
You're not right. Flags related to users can be indexed.
@jukka792
Can you check when hovering over the flag link if there's something like this in the link: "/typeerror-null-given"?
Thanks @BenStallings
In my case, I had a problem with facets in my custom code, which was called like this:
$request->query->get('f')
So, I changed it to this, and it works:
$request->query->all('f')
MilosR β created an issue.
@larowlan which part of the code?
MilosR β created an issue.
The flags created and used with the flag_search_api module do not have labels. In this case, the 'List item label' should not exist in the form. The fix is to uncheck the 'List item label,' and here is the patch that removes the 'List item label' checkbox for all flags that do not have that functionality. Therefore, in future cases, there will not be any options to check 'List item label'.
Hi, @jukka792, I just tested this case in a fresh new installation of Drupal Core (version 9.5.11), and indexing works as expected in both cases, whether an action is flagged or unflagged. I do not see that the issue you mentioned is caused by this module. Could you please investigate further on a fresh Drupal installation and provide more data?
The patch are not applying on the latest version of the module, we need to work on this.
#91 Patch file does not apply to the latest version.