🇵🇱Poland @gugalamaciek

I think, that when taxonomy unique is disabled, nothing should be added to the config files, so also taxonomy_unique.message should be unset. I made small change to achieve this. I replaced:

if ($form_state->getValue('unique_message')) {

with:

if ($form_state->getValue('unique_message') && $form_state->getValue('unique')) {

Patch for drupal 11.x (based on #27)

xjm → credited gugalamaciek → .

#26 extended with configurable parent and weight on detail page, not just form display.

I found small bug related to the scenario, when no fields are selected for update and I click “Update”. #5 fixes it.

There were problem with checking options on first loaded page, when filter were multivalue. Code will explain this (lines starting with + are new ones added in #19, compared to #18):

// On first loaded page, url can have filters passed in query. They are
// present in window.location.search. Let's add them to initial filters,
// when getting back to first loaded page.
$.each(parseQueryString(window.location.search), function(filter_name) {
+  // The options.data object stores entries keyed by filter name,
+  // which works well for single-value filters. For multi-value entries,
+  // the filter name includes '[]' at the end. We need to remove it
+  // before checking if options.data has the filter with given name.
+  filter_name = filter_name.replace(/\[]$/, '');
    if (!options.data.hasOwnProperty(filter_name)) {
      options.data[filter_name] = this;
    }
});

I’m not 100% sure if UUID is actually a required field (I assumed that) - so you can (potentially) have entity types without a UUID. Nevertheless, I believe this patch is a good starting point

The patch adds an additional sort by language code when the entity type supports translations.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

One more small improvement to #74.

#68 for me won't work. I have scenario where:
1. I selected 2 entities
2. I can update one of them, as there will be no errors. For the other one I know there will be error.
3. #68 skips all updates, while on #52 one item is updated (as expected).

There is small bug in #52 (php error, when you try to submit, but nothing selected to be updated), I improved it in #74.

Patch to fix the problem.

gugalamaciek → created an issue.

The previous patch didn’t resolve the issue. I’ve written a new one that:

• Ensures that operator_id exists before checking whether it’s empty.
• Adds an additional check to verify that $input[$this->options['expose']['operator_id']] exists before using it. If it doesn’t, the default $this->operator is used instead.

Fix for Drupal 10.x and 11.x (the only difference is that in Drupal 11, file.js is located in the js/ folder).

gugalamaciek → created an issue.

Proposed patch to fix fix the problem.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

If you still need it in version 2.0.0, here is the patch

Minor improvement: The preview remove button form #name was not always unique.

gugalamaciek → created an issue.

Proposed patch makes sure, that:

$entity->setRevisionTranslationAffected(TRUE);

is set before save operation.

gugalamaciek → created an issue.

Consider scenario:

1. You are allowed to edit/delete content in original language
2. You are not allowed to edit/delete EN translation

On “Translate” tab, “Translate” button was visible when you opened original translation only. When you went to EN translation → clicked “Translate” tab, create translation buttons were not visible. It was because access to create translations was checked based on EN translation (where you don’t have access), not original one (where you have access).

So, by changing:

- $create_translation_access = $handler->getTranslationAccess($entity, 'create');
+$create_translation_access = $handler->getTranslationAccess($entity->getUntranslated(), 'create');

we make sure that create button on translation tab is always calculated based on original content, not current translation.

Improved patch for 11.1.x. Should work with previous drupal versions as well.

I added preview improvement. So now, when something is selected you can setup preview of it in widget configuration. How it looks like:

#18 works, but it still won't allow to paste strings longer that #maxlength.

On module configuration, I'd like to have these configuration options to define how limit should be treated:

1. Allow input and saving of text that exceeds the specified limit. This option is available in current version of the module. It just displays information that you exceeded limit on edit form, but nothing more.
2. Block input and saving of text that exceeds the set limit. This option is provided by patch #18. It's partially supported by hard limit option in current version of the module - the missing thing is to add validation during save. But #18 solves it.
3. Allow adding text beyond the specified limit, but show an error message when attempting to save. This is the missing puzzle and most tricky one.

I analysed code of the module. I think that before we'll be able to implement last option, we have to refactor part of the module. The case it that MaxLength settings are defined on widget level. But, to implement last option, we have to add constraint on field level (to validate during save). So, all the configuration should be moved from widget level to field level. As example, see implementation of unique_field_ajax → module. It's very similar, but instead of validating length, it validates uniqueness.

When I think more, it's also one more good reason to move configuration from widget to field level. If you configure things on that level, no matter which widget you select, they will be applied. You don't need to check widget type, it's enough to define field types that should be able use MaxLength feature. But what if I define my custom type in my module and I want to add MaxLength to it? So this list should be alterable. Or... in admin/config create section for MaxLength. And every webmaster will be able to decide for which field types module should be enabled. Also we can use plugin system and define something like MaxLength processors. That way any user can extend this module to it's custom field with custom processor to define how this should be validated.

These are like ideas, how it can be implemented from my head, without deeper analysis. Also I don't have knowledge that inspired authors of the module to write it in a way that's written now. Some concepts might be to havy, some missing. But it sounds for me more like version 4.x of the module.

Patch with proposed solution.

gugalamaciek → created an issue.

This patch adds one more feature - "Advanced search" link at the end of autocomplete suggestions. When clicked, it opens entity browser.

Patch for 3.x

gugalamaciek → created an issue.

I added small improvement. I changed:

$form['check']['timeout']

to:

$form['check']['linkchecker_check_timeout']

@sakthi_dev I'll try to produce 11.x version in free minute... but can't promise when exactly.

Ups... I forgot about schema updates. So this is #49 + schema fixes.

#50 is #49 extended with End date optional #153 ( https://www.drupal.org/project/drupal/issues/2794481#comment-14839868 ✨ Allow end date to be optional Needs review )

Improved patch which covers:
- adds all_day column in DB for datetime range fields. Set it as disabled for all existing data with datetime type
- allow to enable all day dates for datetime type & set default value for it in field settings
- widget to set all day, making sure that date is stored in UTC when all day is selected (in general timezone is ignored when all day event is set)
- GraphQL - share allDay property for datetime range fields
- formatter - for now only supported inn default formatter. You can specify date format for all day and non all day dates
- js - when you'll select all day, time is set to 00:00:00 for start & end dates

Small improvement on admin settings form added.

gugalamaciek → created an issue. See original summary → .

joseph.olstad I'm glad I could help :)
FYI #11 looks good, I've added it to our site :)

@Joseph Fine for me :) That's why it's on review ;) I checked briefly, and I think you should change linkchecker.schema.yml as well.

As I see you've changed setting:

check.skip_unpublished

to:

search_published_contents_only

But when I check linkchecker.schema.yml, I have a feeling, that this property should be under check. So it should be rather check.search_published_contents_only. Also, if you want this change, I suggest to rename everywhere (e.g. form property as well). It will be less confusion for developers reading this code ;)

Ups... wrong patch. Don't use #2 and #3.
This patch catches TransferException and assigns 404 status code to errors "could not resolve host".

This patch catches TransferException and assigns 404 status code to errors "could not resolve host".

This patch catches TransferException and assigns 404 status code to errors "could not resolve host".

gugalamaciek → created an issue.

Proposed patch adds feature described in point 1. and implements performance improvements described in 2. - 4.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

Consider scenario:
1. Open node page using shs. Terms are cached based on interface langauge (e.g. langA)
2. Open translations form. Data is get based on interface language (in most cases the same as in point 1.). So you create translation to langB, but you see term labels in langA.

What can be done is to change caching strategy from interface to content. So change this:

$this->contexts = ['languages:language_interface', 'user.roles'];

into this:

$this->contexts = array_merge(['languages:' . LanguageInterface::TYPE_CONTENT, 'user.roles']);

Terms are content, not interface. They should take into account content langauge, not interface langauge.

Proposed patch provides this change.

gugalamaciek → created an issue.

Small improvement for #2.

Patch for proposed resolution:

gugalamaciek → created an issue.