🇩🇪Germany @mrshowerman

You're right, the issue only applies to OC Admin and Administrator roles. Other roles don't seem to be affected.

mrshowerman → created an issue.

Got it.
But when a site chooses to use the same label for form and output, they have to write their own hook to revert the upstream logic.

Here's what we did:

/**
 * Implements hook_ENTITY_TYPE_view_alter().
 */
function mymodule_node_view_alter(array &$build, NodeInterface $entity): void {
  if ($entity->bundle() === 'date' && $build['#view_mode'] === 'full') {
    foreach (['field_location', 'field_event_description'] as $field_name) {
      $label = $entity->getFieldDefinition($field_name)->getLabel();
      $build[$field_name]['#title'] = $label;
    }
  }
}

I wonder if there is a better way to achieve different labels in form and view displays that is easier to disable, without having to write custom hooks.

mrshowerman → created an issue.

I see an issue with recurring dates: additional empty rows are added for each following date item.

Excellent. Wasn't aware from the title that it was handling the same issue.
Will post my feedback there.

mrshowerman → created an issue.

Rebased.

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

I know this is a tough one.
We used the Entity Reference Integrity → module in one of our projects in order to deny people from deleting nodes that are still referenced somewhere.
But I have to admit that this introduced so many problems (e.g. false positives) that we decided to remove the module again.

Thanks for improving the solution, @jurgenhaas. The changes look good to me!
Not sure if this single feedback is enough to set the issue to RTBC, so leaving as NR.

Found it: the ID of the reset button is hardcoded to something that might not match (it doesn't in our case).
Attached patch tries to be a bit more flexible about the ID.

This should do the trick.

mrshowerman → created an issue.

mrshowerman → created an issue.

mrshowerman → created an issue.

mrshowerman → created an issue.

mrshowerman → created an issue.

Updating my profile info, in case credits are still being granted 😉

Providing a first approach.
This one currently does not support fields of type Custom composite which is a lot more complex, as it can contain sub fields that are not of type text. All other types are simply arrays of text fields, so they can be joined together just like it is done with normal fields.

mrshowerman → created an issue.

mrshowerman → created an issue.

mrshowerman → created an issue.

Update to latest state in MR of ✨ Continuation Add Views EntityReference filter to be available for all entity reference fields Needs work

mrshowerman → created an issue.

My point is: do you still get the error messages mentioned in the issue summary? They should have gone after updating to beta6.

🐛 Race condition when using queue Needs review is in.
@dalin, I think we can close this as a duplicate now, what do you think?

Thanks for pointing that out, @mstrelan.
I added back the interface and marked it for removal in 11.1, but this is of course to be discussed.
Change the enum cases to UpperCamelCase.

Guess we now need a follow up for the removal, and also a change record.

✨ Add option to show only start or end date in the DateTime Range custom formatter Needs review is in.

Re-roll.

Re-roll. Leaving in NW as per #15.

I tried to create a new issue fork based on 3.x, but failed. Thus, I'm uploading a patch.
Addressed most of the feedback on the MR and also #10.

Why is the new setting not declared as a boolean?

mrshowerman → changed the visibility of the branch 8.x-1.x to hidden.

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

Tried to clarify the task a little.

Rebased on 1.2.0.

Created MR based on #21. Leaving as NW for the decision about test coverage.

mrshowerman → created an issue.

Not myself. But this is also how it is done in the Bootstrap framework (e.g., buttons), and accessibility plays an important role there.

Opened MR against 2.1.x, adding patch against 2.0.x.

mrshowerman → created an issue.

Opened MR against 2.1.x, adding patch for 2.0.x.

mrshowerman → created an issue.

Converted the enum back to an interface, which should be 8.1 compatible.

To avoid merge conflicts when including both this patch and the one from 🐛 Webform Handler does not work RTBC , I also included the fix from there.

Note that the webform handler only works after applying the patch from 🐛 Webform Handler does not work RTBC first.

mrshowerman → created an issue.

Let me add another aspect to the discussion:
I wonder why Linkit's widget uses a fixed help text for all cases, in contrast to Core's LinkWidget, which has 3 different help texts, depending on the link type setting (internal links only, external links only, internal and external links allowed).

"Start typing to find content" doesn't really make sense when only external links are allowed; same goes for "paste a URL" with internal links only.

Not sure if this is the right place for that addition, or we should create a separate issue.

Left a comment on the MR.

This has been added in #3294172: Use of ds layouts in layout builder breaks drag&drop blocks

Not really: 🐛 Use of ds layouts in layout builder breaks drag&drop blocks Fixed brought core's region attributes to DS's; but this issue is for the other way round. We want to use {{ region_attributes.<region> }} in DS-based layouts.

@divya.sejekan, thanks for testing this issue.
It is about spacing between fields within a paragraph, not the spacing between the paragraph and other node fields.
I updated the steps to reproduce in the IS to make this clear.

@divya.sejekan, did you install and activate the module "Hide Format info (former Allowed Formats)"?

Addressed #4.

mrshowerman → created an issue.

Created MR that sets only revision user and timestamp. I'm also not convinced we need to change the other fields.

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

Addressed #22.
I tried to fix the same issue as in #2769741: Node revisions page might not list a default revision → here too by using an orConditionGroup() that's basically saying "either the revision affects the current translation, or it is the default revision", but that produced two additional LEFT joins of the same tables that are already used, which resulted in the conditions being applied to different versions of the same table.
Maybe someone else can help me out with that one.

This issue is in fact closely related to 🐛 Revisions are not visible for some nodes Needs review , as stated in #9. I created a MR for that issue and added the change from #4 to it, so both issues are fixed with one change.

Created MR based on #13.
It removes the now unnecessary if ($revision->hasTranslation($langcode) && $revision->getTranslation($langcode)->isRevisionTranslationAffected()) { condition, and also sets the correct language on the revision before building the row (see #3269933-4: Inconsistent moderation state for translated content → ).

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

Left a few comments on the MR, thus changing status.

mrshowerman → created an issue.

Many thanks! 🙏🏻

Great, @AstonVictor!
I just realized that I had forgotten to attribute my organization. Is it possible to get credit for the organization as well?
Thanks.

mrshowerman → created an issue.

mrshowerman → created an issue.

Re #163
We use this feature for a kind of "breaking news" block that is displayed on each page on our site.
When the news is outdated, we're unpublishing the block.

Created 📌 Tidy up translatable strings Active .

mrshowerman → created an issue. See original summary → .

I see that now both the terms "Add to Calendar" and "Add to calendar" are used. I guess only the latter is correct and should be the base for translations. Do we need a follow-up for this?

smustgrave → credited mrshowerman → .

Attached patch adds the update operation to the access check.

mrshowerman → created an issue.

I installed the module on another site, and there the "access overview " and "edit entries" permissions were sufficient. So it must be a different issue on the first site, will have to find out myself.

Sorry for the noise, I think this is ready.

Thanks a lot! Also to your lovely sponsor 🏊‍♀️🏊

Not sure if this is a bug or a misunderstanding on my side, but I had to grant the "administer deepl_glossary entities" permission along with "access deepl_glossary overview" and "edit deepl_glossary glossary entries" in order enable editors to access and edit glossary entries.
While editors aren't able to edit the glossary entities (which is good), I had expected that only the last two permissions would suffice, and the "administer" term sounds more powerful than what I wanted to grant them 😉

Adressed feedback from #10

I see your point, @jurgenhaas.
That's why I didn't work on removing any base fields, for the exact reason you mentioned.
My main issue currently is, as pointed out in the IS, the automatic creation of view modes, which with the help of this new setting can now be suppressed per entity type, making the config import on another instance much less painful.

For people still on the 2.4.x branch, here's a patch that should apply to it.