dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
Promoted AdamPS to maintainer. :-) Thank you for your hard work!
esmoves → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
dan2k3k4 → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
Thank you for picking this up.
I see the argument around the status change. But given that this bug affected no one enough to engage since 2017 makes me feel it can't be that major.
Happy to fix it, thx for the work.
Now we need test coverage for future QA (and also for easier review now).
spitzialist → credited miro_dietiker → .
dasjo → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
spitzialist → credited miro_dietiker → .
Yes sure. As a first step, we need to re-allow manual cancel (maybe with a strong warning) and can easily display such a message.
miro_dietiker → created an issue.
pjonckiere → credited miro_dietiker → .
miro_dietiker → created an issue.
Sure this should be fixed.
But from the way i used it, i thought from / to direction don't matter. As long as they are different.
Are you sure about bigger / smaller check is needed?
Maybe we can just swap the revisions when the sequence is wrong?
Making it just work is better than telling the user to choose something different...
Interesting, i think this part should be improved with an array sort / search, without loop.
Uhm, for globally "every revision id", not even limited to the entity id?
Or you have hundreds of thousands revision ids on this single entity?
Note that an iframe from the same domain is not a full isolation.
The problem is mitigate a big by the fact that we show mostly outgoing mails and not random incoming mails.
Other systems identified the need for full isolation to deliver the iframe from a different domain to clarify the CORS (cross domain) situation.
As soon as a user payload could end up in the mail, this could cause a security issue.
I guess then this would need to be an opt-in with some warning?
Thank you for giving this a try, i checked the original code:
The addRemoteMapping can not change, since we then would break identifying the item when translations return.
The addMessage should move to the job outside of the loop.
Supertext identifies item ids by just receiving GroupId (translation job item ids) and we don't need (and we don't get) a per-item remote id.
I don't get why this alter would be needed.
Could you explain what such an alter could do? Maybe your specific use case?
miro_dietiker → created an issue.
Yes, i agree, in the most basic initial translation process, simply excluding them is great.
However note that they can easily get outdated. And then they would need another translation cycle.
TMGMT is not too helpful in supporting evolving items currently..
See also the deduplication proposal over at ✨ Deduplicate job suggestions Active
miro_dietiker → created an issue.
Note that items with a pending job are already excluded from the suggestions.
miro_dietiker → created an issue.
miro_dietiker → created an issue.
Paragraphs allows you to move paragraph (entity reference revision) items with a Paragraph entity using the "drag and drop" feature.
Inside a Paragraph, there are regular fields.
I understand your request is about moving field items from one field to some other field.
We don't change how regular fields work. Drupal core fields don't support moving field items between fields.
(I don't think we should consider more changes to the fields system in Paragraphs.)
If you use a media entity, you can unlink it and readd it at a second place without the need to upload it again.
Is this inheritance already applicable with the example styles that we offer in the collection?
Does this work similarly to styles or once more a bigger difference?
One thing that i learned with isolated components is that duplication is a feature. If you derive work from an original layout, you don't get accidental changes. This adds freedom to evolve the original, without fear to break things. Drupal core exactly decided for this approach with theming: copy instead of subclass a base theme.
Maybe, to still know what the original was, a property could make sense, to display a warning that the styles might need update after a major change in the original... But without inheritance.
You choose the base layout related to grid count, with a variation for vertical alignment. Does the base has no vertical alignment definition or the inherited overrides it? How about other aspects like responsiveness modifiers?
For me, looking at a single layout definition without going to the parent, is less abstraction and more simple to review. For instance also, it's way easier to grep "where is modifier x in use?".
So let's assess of this really improves maintainability in real life scenarios.
Yes, this looks great as a first step.
It provides some level of grouping and makes the list visually easier to handle.
Further improvements to the UI can be build on top of that step.
So tests still pass... Do we need something to cover on top of the current tests?
@acbramley revisions that don't show under some conditions, especially in multilingual / translation contexts, is highly confusing. But beside the seemingly buggy behavior of isRevisionTranslationAffected() which is maybe a separate issue, we should maybe discuss improving the presentation and filtering of language specific revisions in a separate issue... i have the feeling that simply outputting all of them and applying a client side filter with the option "all" (in addition to specific languages) would sometimes be much more helpful...
We tried to start something similar in context of Diff contrib:
#2452523: [Meta] Offer a revisions tab for all entities →
We would be very happy to see this happen in core.
Note our discussions that the revision summary is a problem and there should be a handler that allows alteration in contrib.
A problem is here that i see you referring to $revision->revision_log that is only present in node revision entities from Node.php baseFieldDefinitions().
All other entities will provide an empty description.
I'm confused the patch above only implements the whole functionality on Node only? I thought the issue is about displaying a revision tab for every entity type.