🇩🇰Denmark @LupusGr3y

Yeah, this still requires the patch to work on our site

To test it, just make something renderable and cachable that depends on a config. Render it so it's cached. Change the config for a specific domain. The renderable should be invalidated and therefor be rendered again, now with the domain specific changes. If not, the cache has not been invalidated correctly.

Appears that the issues was not just multiple entity references, but also that Paragraphs is flagged as shouldn't be cached, but was still cached, but without caching data so they all ended up with the same cache key.
But hopefully 1.1-beta5 resolves the issue.

We could probably add a cache tag for the regions configuration.

Transform API 1.1 does not return FieldTransform objects when transforming fields on entities, is this related to Transform API 1.0?

Also can the issue not be resolved by a transform_alter on the field?

I made some comments to your pull requests some time ago

I tried this on a fresh install and it worked fine

Why do you recommend the .module description like that? Seems very non-standard and redundant.

1. Master has been deleted.
2. Oh, there's a newer version of the code sniffer. Corrections have been made.
3. I have never seen this before and no other contrib module I could find does this. When was this changed?
4. Constructor comments removed.

It only seems to fail if you transform an entity while there are currently no "full" or "default" transform modes configured. It cannot fall back to "default" since the config doesn't exist and it cannot add cache tags for configs that don't exist yet. However, if you then add the "full" transform mode later, it will pick it up.

There we go. Wasn't sure what the correct status was.

LupusGr3y → created an issue.

Then disable collapse regions

I think I might have found the culprit. I've updated the patch.

I think that would be the wrong place to fix the issue as at that point, the entities should already be the correct translation and might change the language of entities that was meant to have other languages.

I've added another patch that I think should solve the issue at better place.

Added IntegerTransformer, FloatTransformer, IntegerFormattedTransformer and DecimalFormattedTransformer.

Do be aware that only ID and label are actually fields. However they are also fields that are not exposed for display purposes, otherwise they would already show up.

There might be other ways to add these in a configurable manner on transform modes, like display plugins or directly on the transform mode.

Controllers aren't meant to be services, so all code that you want to be accessable otherwhere should be in services. Thankfully this is also already the case as the EntityController just uses the Transformer service. You could just do the same for your purposes.

Why on earth has this not been released yet? This is so important!

LupusGr3y → created an issue.

@lipinponmala007

No, that is currently the only way to transform non-entity routes, at least existing routes. Of course if your make your own routes you could just get the Transformer service and output the JSON via a custom controller directly, but those are currently the options.

@irowboat

An uodate for the module now allows configuration of base fields that are allowed on view modes to also be configurable on transform modes, does this solve your Commerce issue?

Is this trying to replicate the terms list usually done through views?

If that's the case, then yes, this is probably the way to do it currently, you could even get it to replace the current view for HTML. I figure we could make plugins for views that allow it to handle transforms as well. Although my Views knowledge is very limited.

Also EntityTransform has some shortcut static functions if you already have the entities.

Sounds reasonable

LupusGr3y → made their first commit to this issue’s fork.

Perfect!

As far as I'm aware, it's standard in Drupal to serve external urls as absolute. Also, if using a CDN, and working with Transform API, it would be best to let Drupal handle the CDN.

What would be the use case for this? You can still transform taxonomy terms of that vocabulary.

Looks good. Could you add dependency injection on the "file_url_generator" service, then it's good.

I don't know exactly what Commerce is using here, but Transform API does currently need something similar to "Links" and "Moderation Control" display options from core. However even if that is what Commerce is doing then a plugin for Transform API still needs to be implemented.

Same goes for any extra field types from modules out there, it will show up on "Manage Transforms", but without a Transformer plugin, you can't utilize it. Hopefully the community can help expand the field types and other displays Transform API can support with time.

For now I'd advice using hook_transform_entity_alter to intercept the transformation of the product and add the transforms that way.

This is a little beyond the current scope of the module which is transforming into JSON, but maybe we expand upon it in the future.

For now I would suggest using REST or similar module to achieve this.

Yes, the documentation still needs some work. I'll be training some colleagues in the coming month so hopefully that will give some insights into what is confusing for new developers.

How are you trying to extend the transformations? Altering an existing transformation, a new transformer or a new transformation type?

Okay, this complete lack of response and no idea of what happens next, if anything, is too stressful. I'm closing this application.

So... now what?

No, scratch that. The YamlDiscovery that core uses is a different YamlDiscovery than Atoms uses. Core uses it to produce plugin derivatives, while Atoms just needs the YAML data and that YamlDiscovery does not have support for marking keys as translatable.

So there does not appear to be a way to avoid using t() or TranslatableMarkup directly without rewriting Atoms to use plugins for the atoms. Which could bring interesting new features, but also seems overkill just to make it do what it already does, but just through the other YamlDiscovery instead.

What is this different method for translating YAML files?

There are calls to t() in the module where it's not literals, but that's because the values originate from YAML files, and the sniffer also says "where possible". So my assumption is that it is done with a good cause.

Yes it has. I took over the namespace as the previous project has changed to a new name and the old was abandoned.

I assume you got confused by the branches of the previous atoms project. They are unrelated to the current project, but I am not allowed to delete them. But the 1.0.x branch is the one to look at.

Huh? All of the commits have been done by me!

LupusGr3y → created an issue. See original summary → .

LupusGr3y → created an issue.

That does sound like a project with a lot in common with Transform API. I will have a look at it and see if any collaboration makes sense.

Ah, I see. We will wait then.

LupusGr3y → created an issue.

LupusGr3y → created an issue.

We could really use this and the patch seems to work.