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:
- You are allowed to edit/delete content in original language
- 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:
- 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.
- 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.
- 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.
gugalamaciek → created an issue.
Patch for all work made in this issue.
Patch for all work made in this issue.
gugalamaciek → created an issue. See original summary → .