I don't think we need that module as a dependency. If this is just a views filter than we can create a custom version of that for our needs. We would just need to create that here: https://git.drupalcode.org/project/custom_field/-/tree/3.1.x/src/Plugin/... and modify the filter type here: https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/custom_fiel...
I can take a look at it when I get more time but open to patches if you wanna take a stab at it first.
Merged. Thanks for the patch.
apmsooner → made their first commit to this issue’s fork.
Merged. Thank you!
Thanks for the report and the patch but please rather create an issue fork and open an MR and I'll review.
@coaston,
I'm working on this for you but it would be really helpful if you would join the #custom-field slack channel to correspond. Can you do that?
Join the Drupal #custom-field slack channel.
Thanks Ben. It's merged!
apmsooner → made their first commit to this issue’s fork.
No review response which is unfortunate. Help me... Help you...
Calling it good and merging.
apmsooner → made their first commit to this issue’s fork.
apmsooner → created an issue.
apmsooner → created an issue.
apmsooner → created an issue.
apmsooner → created an issue.
I can't really support something like this as it's a bit of edge case on it's use case. The 'Hidden' widget now works as designed to not render anything. You could always extend that widget though and change the element type to 'hidden' instead of 'value' along with whatever other custom settings you need.
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
Added a setting to both table/flipped (table) formatters that allows you to hide empty rows or columns (based on the formatter). Please test the patch out and update the ticket if it works for you as expected.
almunnings → credited apmsooner → .
@valthebald,
Add an image or file field to your entity and make it translatable. Without the patch, you should get error during translation extraction. Unfortunately there's a test fail in the patch that is blocking it from getting merged so yes we should probably document it somewhere just so users don't think there's something wrong with ai_translate.
valthebald → credited apmsooner → .
Closing this as it was resolved via alternate token settings in ECA.
apmsooner → created an issue.
apmsooner → made their first commit to this issue’s fork.
Okay, i think i understand.
- Create an update hook that adds a 'timezone' column to the datetime subfield OR possibly just create a new field type since datetime type = 'date' would be irrelevant.
- Add a timezone form element to the widget.
- Settings for whether to show timezone in form?
- Settings to make it required if a value is set?
- Should it be permissioned? Example: If you as admin set a timezone value, should other user ALWAYS be allowed to override it to some other value?
- Settings to filter the timezone options? Maybe you want to make it simple and just have a couple relevant timezones to select from?
- The datetime form default value would look the same (e.g. not converted) but the actual value rendered in the formatters could be in timezone specified.
- Assuming we should add multiple options here for output of which timezone to display the date in. Site timezone, user timezone, new timezone value on date field?
- Views stuff may need to remain the same perhaps for now at least at least for sorting, not sure how multiple values in different timezones would work?
- Seems like the "VIEWS option for both berlin and utc time" maybe should just be handled in the sub-field formatter so its used everywhere as an option?
There's a long running issue around this type functionality that has seemed to have just gone off the rails. We don't need to do anything complex here with messing with existing date values... will keep it simple: https://www.drupal.org/project/drupal/issues/2716891 🐛 DateTimeIso8601::setDateTime() vs. DateTimeItem::schema(): (at least) one of them is broken Needs work
If the above doesn't work, maybe you can split the Get custom field value into 2 separate parts and target the property directly vs. just the field.
Example: field_custom_numeric_field.number_1 as token number_1 AND field_custom_numeric_field.number_2 as token number_2. It seems like #5 though should be working though. You might ask jurgenhaas in the ECA slack channel otherwise if he has any clues.
Odd cause I'm not seeing this issue when you use the same tokens in the manage display type 'Custom template'. If you have token module installed and browse the custom_field tokens for the decimal value, you should see it render 0.00 as it should. In ECA though maybe its doing something different with the tokens? Could you try appending ':value' to the token(s) you're using?
E.g. [numeric_field:number_1:value]
The issue you linked is completely unrelated as it was a feeds plugin issue with the other one. You're getting the correct value out of the db (0.00) so I would assume this issue is with the tamper module. Without knowing what the error is, I can't really help point you to the problem. You can probably debug what data is somewhere in here: https://git.drupalcode.org/project/tamper/-/blob/8.x-1.x/src/Plugin/Tamp... but ultimately you should identify what error is being thrown.
I suppose we didn't account for that but it might require a formatter settings as some people may want to show the empty cells at least in a regular table. Honestly I think I may have left it open for something more advanced (like optional fallback value). I'll come up with something for the next release and perhaps a patch soon when i get a chance.
apmsooner → created an issue.
apmsooner → created an issue.
My opinion is still that it would be better to allow Multi-value in a subfield.
It's not technically even possible due to how the data is stored. You'll notice there is no cardinality setting at the sub-field for this very reason, only single values can be stored in a table row. So, its not a choice.
Custom field is not always going to replace paragraphs or entity_reference field. If you need multi-valued entity references and don't need any other complementary fields with them, just use entity_reference. If you need multiple single value fields grouped together, use custom_field. If you need both, you can use a paragraph containing the best of both worlds: multi-valued entity_reference field + custom_field.
I can assure you there is a performance benefit with custom_field vs. multiple regular fields purely based on the fact that regular fields are all stored as individual tables. Paragraphs only compound the problem by introducing more tables and revision bloat. That being said, you have to have balance in your application based on what you need.
I've looked into replicating what the Geofield module https://www.drupal.org/project/geofield → is doing and it would just be way too heavy of a lift to handle this in custom_field. This particular need makes much better sense to just split out as its own field. If these fields should go together as a multi-valued component or you just want them structured together for API reasons, I would still use a paragraph here as an entity wrapper that contains both fields, otherwise just split them out as separate single values on the node or whatever parent entity type the fields are attached to.
BTW, what admin theme are you using and what is the version of Drupal Core you are on? The storage and widget settings sections should not be floating together like that and breaking up the table.
Although the autocomplete widget makes it look like you can add more than 1 value, this isn't possible with sub-fields which is why you're only seeing 1 value saved. While a custom field at the field level can be multiple, there will ALWAYS only be a single value allowed in a sub-field. What you're trying to do here looks to be one of those edge cases where you'd want to use a regular multi-valued entity reference field type. We actually discussed this topic in the Talking Drupal episode if you want more insight around why: https://www.youtube.com/watch?v=dC5ec8FG6vQ
However when I add date "18-June-2025 at 21:00" it stores it in database as "18-June-2025 at 11:30" UTC and reports shows that engineer completed task before it was scheduled.
With this scenario, assuming you enter the date "18-June-2025 at 21:00" and were able to set the timezone to berlin, what value would you expect to see in the widget next time you edit. I think it would be 18-June-2025 at 13:00 which in US (1:00 PM)? I just don't even know if this would make any sense at all unless we create a completely new field type that actually stores the timezone so maybe then the stored datetime value is always reflected in the widget as the value with the set timezone. And in this case, I would assume you would also need the formatters modified for this option as well but they are currently generic to regular datetime fields so just not really sure how to even accommodate this.
I'm getting back into this and still I guess trying to wrap my mind around what you need here. Are both you as project manager and the engineer setting the value to the same field or are you as project manager trying to set the date value on behalf of the engineer in his timezone? If the latter, I'm guessing you would just want a timezone select with no default value since it wouldn't be saved but you would choose his timezone on save and the actual date saved would be in his timezone but value shown to you would be in your timezone? I'm just confused as to what date you would expect to see next time you edit? Sorry, I'm just really confused with how this would work.
Patch is ready to test.
apmsooner → made their first commit to this issue’s fork.
Add extra test step for custom_field to enable sub-module custom_field_ai.
Reverted this issue in favor of https://www.drupal.org/project/custom_field/issues/3533534 📌 AI translate update extractor Active that will move the extractor into a new custom_field_ai submodule.
The 3.0.x version this issue is tagged to is no longer supported. Noone has reported any issues with 3.1.x versions related to this but if you are seeing issues after you have ensured you have the latest version of the module, open a new issue with detailed steps of how to reproduce, screenshots and/or video would be helpful also. This issue remains closed as it is tagged to an unsupported version.
Thanks for all your work here @svendecabooter! Merging now to dev.
@valthebald,
Everything is working properly for me after recent changes from @svendecabooter so putting back to needs review for others. Probably need to document the need for the core patch somewhere if properties on file/image fields are desired to be translatable but otherwise, I'm having consistent success with this patch.
I figured out the issue I was having and pushed a commit. The original value wasn't being set to the translated entity before being passed to the extractor. Everything now seems to be working now for me with that fix!
Your changes are making it work for me now. I did push up a change to the custom_field patch to prevent the same warning for undefined array key 0. My setup is i have a basic page with an entity reference field to an article node. The article node has filefield, image and custom field. All of them get translated when the basic page gets translated however the only weird thing is the custom field has an image and file subfield. The image alt text gets translated but the target id value doesn't get set for some reason when the translation is driven off the reference extractor. When i translate the article directly, the custom field image and file target ids get set like they should. I can't remember if they were getting set before your update or not. Seems like the original value I guess isn't getting copied over in that case for some reason. Perhaps you can try this same setup on your end with the updated custom_field patch?
No, it was working fine prior to the commit mentioned in #24. Waiting for @svendecabooter to either revert or come up with alternative solution. Personally I think where I left it was adequate and he can build the additional logic for the async lb module on top of that but giving him time to address first.
Revised patch: added base class and interface to accommodate both entity_reference and image. Also updated the patch at default_content to take advantage of new interface. Please test and provide feedback for this to get merged.
I tried messing with it to get past the errors but it seems like its just no longer even creating the translation for the referenced entity at all anymore. Seems you may have stripped out alot of logic that is needed so unless you can revise to get it working, i'd say revert.
@svendecabooter,
I pulled in your changes and I'm getting errors for all the extractors that get called from the ReferenceFieldExtractor. They are all similar to the following.
Warning: Undefined array key 0 in Drupal\ai_translate\Plugin\FieldTextExtractor\TextFieldExtractor->setValue() (line 43 of /var/www/html/web/modules/contrib/ai-3531717/modules/ai_translate/src/Plugin/FieldTextExtractor/TextFieldExtractor.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(166): _drupal_error_handler_real(2, 'Undefined array...', '/var/www/html/w...', 43)
#1 /var/www/html/web/modules/contrib/ai-3531717/modules/ai_translate/src/Plugin/FieldTextExtractor/TextFieldExtractor.php(43): _drupal_error_handler(2, 'Undefined array...', '/var/www/html/w...', 43)
#2 /var/www/html/web/modules/contrib/ai-3531717/modules/ai_translate/src/Plugin/FieldTextExtractor/ReferenceFieldExtractor.php(220): Drupal\ai_translate\Plugin\FieldTextExtractor\TextFieldExtractor->setValue('title', Array)FYI, The errors are on a different test and seem to be related to this line from what i can tell: https://git.drupalcode.org/issue/drupal-3386915/-/blob/3386915-Fix-savin...
The patch applies clean for 10.5.1. I followed the steps and it works without error. Additionally, combined with patch for AI translate module ( https://www.drupal.org/project/ai/issues/3531717 ✨ Add text extractor plugins for image and link field types Active ) and following the steps outlined there, all translatable properties on image/file fields get translated as the the batch process is allowed to finish due to this core fix.
@svendecabooter,
The custom FieldTextExtractor plugins for the assymetric modules could probably also be included into the ai_translate module, rather than a separate module, but then the FieldTextExtractor plugin might need some extra logic to decide whether the plugin needs to kick in or not.
Maybe this is handled as a third party setting or just simply in the ai config settings. I think the existing lb plugin could then first check for that setting and do call alternative functions or something?
We can document the module version requirement on the project page but I would prefer we stick with the 1.2 version as the source of truth. Otherwise, someone could make their own patch for 1.1 compatibility if really desired. I don't think there is even enough users that are going to be affected anyhow since ai_translate & custom_field usage together is likely gonna be very low at least for now until more people adopt AI.
Re-rolled core patch here for 10.5.x: #25 https://www.drupal.org/project/drupal/issues/3386915#comment-16174131 🐛 InvalidArgumentException: Invalid translation language (en) specified Active to get file/image fields working.