nicoschi → changed the visibility of the branch 2546212-entity-viewform-mode-10.3.x to active.
I will add another issue reguarding information: it doesn't specify the csv separatore must be a comma.
nicoschi → created an issue.
@s_leu +1 to promotion of https://www.drupal.org/sandbox/s_leu/3413350 → to a full project. I tested it and seems to work correctly for the filter_html use case.
Hi there, the merge request should solve the issue
nicoschi → made their first commit to this issue’s fork.
Hi there, I'm dealing with the same issue when wrapping a "drupal-media" in CKEditor using "Embed media". I'm not using editor_file, anyway i tried the patch and it doen't work form me too. What I can say in addition is that the editor advanced link doesn't keep in place any tag attribute except the target one which all of you is complaining not working
Observing changes in database after the field is made translatable it seems that providing a fallback it's really hard but a warning message at least should be shown when trying to make translatable a field with data in database.
I will try to describe the real issue step by step:
- given a Drupal site with two languages, ie. English and Italian
- create a translatable content type
- create a field (ie. a plain text one) and leave it not translatable
- insert a content of the created one type in English language
- translate the inserted content in Italian
- make the privous created field translatable
- now value of the field made translatable is gone in the Italian content
Best would be a fallback in English
I did it a new branch and MR which applies to 10.2.x cherry picking commits in the 11.x, but maybe I did something wrong also with branch visibility
nicoschi → changed the visibility of the branch 3008292-imageitemgetuploadvalidators-should-be to active.
nicoschi → changed the visibility of the branch 3008292-imageitemgetuploadvalidators-should-be to hidden.
@scott_euser thanks, maybe we were writing at the same time the comment, it is the same link I posted in #84.
So after that procedure should I use that as my local patch and is it useless to publish it somewhere, for example in the list of patches in this post or produce a new issue fork?
I'll clarify the question, the only solution to continue to use the merge request commits is the application of the procedure in Creating a patch file of a Merge Request for an older stable release → ?
Thanks
Hi there,
how can we apply the patch from merge request in Drupal 10.2.x? At this moment the plain diff doesn't apply while the patch in #77 yes
@Bardir thanks for the the tip of the other patch to apply, it's the first time it happens to me or maybe it's a big deal in a case of an entity view display with tons of fields and configs
It seems this patch has a big side issue and it's weird to me anyone has already discovered it (maybe I'm doing something wrong?).
This is a case:
- a series of custom field formatter used on a node view display which original language is english have translatable settings
- translate them through config translation in the other language, say it is Italian
- then visit the entity display edit form in the italian language and save it and all the original setting in english language will be overriden with translations!
Here's the real reroll the previous one was that in D10 issue.
Here's a patch
nicoschi → created an issue.
Here is 10.0.x reroll
@joseph.olstad, I can confirm infact that:
#105 isn't a valid patch if applied on Drupal 10.0.3
#104 doen't work (I have a profile which has Standard as parent and any element of Standard Profile seems to be installed)
Here is a patch reroll including core_version_requirement key inside the info yaml files
nicoschi → created an issue.