🇷🇴Romania @claudiu.cristea

claudiu.cristea → changed the visibility of the branch 2320877-10.5 to hidden.

claudiu.cristea → changed the visibility of the branch 2320877-10.4 to hidden.

• MR !5876 is for 11.x and review.
• MR !12421 is for 10.5.x

Services were removed in a minore release. That broke our site. We should not remove but deprecate.

New features should go in 3.x

@xjm, I don’t understand what “Restoring credits” means (diff don’t show what was changed) but I’ve noticed that I’ve worked on this without being credited

claudiu.cristea → created an issue.

Thank you

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

automated-tests.md was removed but it's still in TOC

Should target 3.0.x

This happens because we use ✨ SVG is not valid or cannot be sanitized, return an error. Active . Moving the fix there and closing this.

claudiu.cristea → changed the visibility of the branch 3530477-error-on-validation to hidden.

claudiu.cristea → created an issue.

I have a functional question: There is the Drupal\filter\Plugin\Filter\EntityLinks, which I see it very useful because it preserves the link alive in the case the file is moved. I had recently such a case handled by LinkIt similar filter, in which the file has been moved and, because of this filter, the file is still reachable on click. However, while editing, the editor can still see the old URL and this can make it confusing. Is it possible that on loading the form we apply the same "check for real URL", so that the link is updated? Or we should totally drop the link and use a Drupal-proprietary HTML tag, in the same way as we're embedding media, so we're not confusing anyone about the href attribute?

claudiu.cristea → created an issue.

Thank you. Released in 2.0.0-alpha3 →

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

claudiu.cristea → created an issue.

claudiu.cristea → created an issue.

claudiu.cristea → created an issue.

claudiu.cristea → created an issue.

Thank you

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

Changing project

claudiu.cristea → created an issue.

Thank you!

claudiu.cristea → changed the visibility of the branch 3524323-edge-cases to hidden.

Thank you for this refactoring.

Works as expected.

No input here. Should we close this?

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

Hiding patch files

Tested by changing source field 'mysql_type' from 'blob' to 'longblob'. Why this could not be an option?

Thank you!

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

Thank you for your contribution.

Looking a the proposal, here are my points:

• This is a feature that should NOT be strictly a tmgmt_ec_etranslation stuff. It should cover all machine translators
• Problem is: I don't think there's a way to automatically determine which translator plugin uses a "machine translation"
• A workaround would be a configuration where the site builder declares which translators are considered by them as "machine" translators

That said, I don't see the place of this feature in tmgmt_ec_etranslation. My suggestion is to create a new module that only depends on https://www.drupal.org/project/tmgmt → and which tries to solve this issue in a generic way, for all machine-based translators.

Still, relying on job records seems a weak option to me, as is mentioned already in #6 and #8. Maybe there's other way to mark an entity as machine-translated?

I will mark this as "won't fix".

claudiu.cristea → created an issue.

Yes, I forgot. Thank you for contributing.

Crediting @eelkeblok

No more input here for a while.

Merged.

Thanks you for catching this

A patch cannot be reviewed. Please open a MR and add tests.

Also, new features should go in 4.x

Yes, please provide a patch

This still happens with big configs. Hit with a webform

Before going to review the code:

• What happens if the jobs are purged? See tmgmt_cron().
• I wonder if this feature should live here or in a submodule

Working in this

claudiu.cristea → created an issue.

claudiu.cristea → created an issue.

claudiu.cristea → changed the visibility of the branch 2381293-delete-action-10.2.x to hidden.

claudiu.cristea → changed the visibility of the branch 2381293-delete-action-10.2.x to active.

Note that this was in RTBC once, in #223 ✨ Actions reordering on views bulk forms RTBC , but the MR didn't apply anymore. Then a lot of changes in core required some work. But, compared to #223 ✨ Actions reordering on views bulk forms RTBC , there are no changes.

Also, I didn't add config constraints because that should be solved for views in a child issue of 🌱 [meta] Add constraints to all config entity types Active . That would had increase the footprint of this MR, making it hard to be reviewed.

Ready for review again.

Hiding palt patches

claudiu.cristea → changed the visibility of the branch tt to hidden.

claudiu.cristea → changed the visibility of the branch 2381293-delete-action-11.0.x to hidden.

claudiu.cristea → changed the visibility of the branch 2381293-delete-action-11.x to active.

claudiu.cristea → changed the visibility of the branch 2381293-delete-action-11.x to hidden.

claudiu.cristea → created an issue.

OK, I have a complete solution but in an early stage of development, the File Visibility → module.

Solution from #24 is abandoned.

We can add a hook somewhere, so a third party might do whatever they want, including storing more info somewhere

Thinking more... with the current architecture is not possible because an entity might refer the same target via 2 different fields:

node(nid456) -> field_term -> taxonomy_term(tid123)
node(nid456) -> field_other_term -> taxonomy_term(tid123)

But currently, we only store once the relation between node(nid456) and taxonomy_term(tid123). We don't care which was the field, we're only interested if the relation exists. But did you try https://www.drupal.org/project/entity_usage → , that stores also the fields

The goal was to keep the table as compact as possible and I didn't see any reason to store also the fields. Probably, if we do, we should store also in the JSON field but is that worth it? Right now I don't see a use case

I badly needed Entity Usage module but with the refactoring described in 📌 Refactor module architecture in a simpler, opinionated and more performant approach Needs review . That issue is stuck for a long time, also I didn't need the UI part. For this reason, I've created the Track Usages → module which, I think, covers most of the aspects described in 📌 Refactor module architecture in a simpler, opinionated and more performant approach Needs review .

I needed such a functionality to build the File Visibility → module. Maybe some ideas could help here.

As there's no move here, and because I badly needed something like the refactoring has envisioned, I had to create a new module which is more or less based on this idea. Enter Track Usages → .

Here are some key differences:

• Track Usages → only registers relations between source (top-level) entities and target entities. Traversable (middle-level) entities are traversed but not registered as distinct records/rows. This allows the database to scale, as with Entity Usage, very often the usage table becomes unmaintainable.
• The configuration is stored in config entities, meaning you can record usages for different scenarios. For instance, you may want to track the relation between nodes and their files, but for a different scope, you may want to track record the relation between node and taxonomy terms. For each scope, you will define a different configuration.
• This module doesn't offer any UI to end users, its only business is to offer the usages

Posted this comment for those who might be interested.

PS: I needed this kind of functionality to achieve the scope of File Visibility → module

claudiu.cristea → created an issue.

Published the CR

Released in https://www.drupal.org/project/og/releases/8.x-1.0-alpha13 → . Thank you

Looks good. Thank you

Thank you. This looks and works as expected

Great. I was looking to the MR and everything looks good. I think we still miss a CR because some sites might rely on annotations precedence. I know, very unlikely, but let's add a record to announce this change.

Do we need a test to prove it?

You should use MR 5876 for 11.x

MR !5876 is for 11.x and review.

claudiu.cristea → changed the visibility of the branch 2320877-10.4 to hidden.

claudiu.cristea → changed the visibility of the branch 2320877-9.3.x to hidden.

claudiu.cristea → changed the visibility of the branch 2320877-9.4.x to hidden.

claudiu.cristea → changed the visibility of the branch 10.1.x to hidden.