πŸ‡©πŸ‡ͺGermany @hchonov

πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
Account created on 19 May 2014, almost 10 years ago
#

Recent comments

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

This breaks the loading of GTM when both usercentrics and simpleklaro are installed, but simple klaro is not enabled. Could we please add a check to ensure that Klaro is enabled and only then run the hooks?

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Whoever comes across this but does not use custom code - the issue in the facets module has been fixed here - https://www.drupal.org/project/facets/issues/3367124 πŸ› Drupal 10: InputBag::get() may no longer return an array in Symfony 6 Fixed

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Committed to 2.x. Thank you all!

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Opened a new major branch 2.x where I will push this patch.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

This should fix the failing test as now it is expected that the library is loaded on new entity forms.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Re #3186353-14: Image effect to crop by aspect ratio only β†’

This removes the 'arbitrary aspect ratio' feature. Don't know if this is a required feature for this functionality.

yes, it is a required since this is the main idea of the image effect - to crop by aspect ratio.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

This is ready to be committed. Please create a new major dev release. Since there are some test failures that do not seem to be caused by the D10 update of the module we would need a new issue to tackle them. Also I closed as duplicate πŸ“Œ Drupal 10 compatibility Needs review so please give credits to the people that worked on the issue over there.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

I am closing this in favor of the one where more people worked on but with a note over there that credits are given to the folks that used to work here too.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

The real issue here is that _webform_update_html_editor() is using the config storage directly to write the config and thus leaving the config without an UUID. We identified this since we use the config_plus β†’ module that has a protection against saving configs without an UUID. The UUID is being added to an entity only when using the entity storage to save the entity. Therefore we should not be using the config storage here to create config entities but rather the config entity storage. I am attaching a patch that properly installs the config entities.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Re-rolled for 1.1.x

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

I have responded to the issue. Please note that the 2.x is still in development. I will be happy for having co-maintainers on the 2.x branch if you would like to actively work on the development of the module for the planned features and help with test coverage so that we get out of alpha.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

The current patch is altering in which language the entity is being loaded as snapshot in conflict_entity_load(). The cause is to be searched at the place that is using it and not loading it. This is only covering up the bug that might come up at a harder place to search for later. So please check about the usages of $entity->{EntityConflictHandlerInterface::CONFLICT_ENTITY_ORIGINAL}. If we would accept the current change then $entity->language() and $entity->{EntityConflictHandlerInterface::CONFLICT_ENTITY_ORIGINAL}->language() will return a different language which would be inconsistent.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Thank you!

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

FYI this was a BC break and a new major release should have been created.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Actually ✨ Remove PHP8.2 Deprecation Fixed was not fixed properly and now we get this error

Plugin "config_patch_output_text" (Drupal\config_patch\Plugin\config_patch\output\Text) must implement interface Drupal\config_patch\Plugin\config_patch\{out
  put}\{Output}PluginInterface.

because before the curly brace we have a slash so we need to escape the curly brace.

Attaching a patch fixing the issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

oups sorry, I did not see that this was already fixed.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

The patch had only one small issue with a double dollar sign. I fixed it and I feel comfortable RTBCing this small issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Re-roll for 10.1.x

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Re-roll for 10.1.x

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

But this issue shouldn't be occurring after https://www.drupal.org/node/3292540 β†’ or am I missing something here?

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Just a re-roll for 2.x.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Re-roll since another hook_update_N() got in already. I also adjusted the patch to respect previously configured settings instead of reseting them since now the update will get executed one more time for sites that had the previous patch.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Just re-rolling.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

I guess it is better to check the exception status code, like $e->getCode() == 429 instead of doing regular expression match on the message, this will be a bit easier.

oh, I was thinking to add the check for the code, so it looks like I've missed this. But checking the error message is needed to get the seconds needed to wait.

And I think it is better to re-queue the items instead of do sleep inside this method from patch. Check queuer plugin, e.g. this one from purge module purge/modules/purge_queuer_coretags/src/Plugin/Purge/Queuer/CoreTagsQueuer.php, it is used in this service purge/modules/purge_queuer_coretags/src/CacheTagsQueuer.php. I think it is better to create some RetryQueuer plugin and just add failed invalidations back to the queue

Of course, if it was using a queue, which is not the case if the API is invoked directly through a drush command.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

We stumbled upon an issue where the calculated dimensions were not rounded as integer numbers so this patch is fixing this.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

I attended too :). It was a nice event and great ideas were discussed!

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

I've just added a related issue - https://www.drupal.org/project/drupal/issues/3353243 πŸ› Unpublished entity reference translations use a fallback while unpublished translations of the main entity do not Needs work and when making a decision both issues have to be considered.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

The following patch implements a simple approach where a translation fallback through the entity repository will be used only if the referenced entity does not yet have a translation for the requested language. Otherwise, it will behave just like the main entity - the access check will be performed on the target translation and if not granted the target entity will not be displayed.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

While testing this patch out I noticed that if the language of the content is changed this does not work quite well with referenced entities and sometimes their language gets changed as well or sometimes the entity remains in its original language and then differs from the one of the content after save ... We should not be assuming that we can simply change the language of the referenced entities since suddenly they might not get displayed in other places if they are reused. Instead, we should be translating them as this is the safe option. Worked on πŸ› Main entity language change does not propagate to nested paragraphs in preview mode Needs review for adding support for propagating the language change and adding support in the patch here as well. I am not sure if this is the right issue though or if another is needed for this.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

The attached patch executes the form displays and updates the langcodes of all paragraphs entities along the structure. It still requires work but should something to start a discussion on about how this could ideally be tackled.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Now that we have the CR this can go back to RTBC.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Committed and pushed to 1.0.x. Pushed a new tag 1.0.0-alpha2.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

We just experienced this and these are our steps to reproduce it:
1. Have a multilingual site with EN and DE.
2. Set EN as the default language.
3. Configure interface and content language detection to be based on URL.
4. Configure that for DE the path prefix is / and for EN it is /en.
5. Place breakpoints in
5.1. \Drupal\Core\Entity\EntityFieldManager::getFieldStorageDefinitions()
5.2. \Drupal\language\Config\LanguageConfigFactoryOverride::loadOverrides()
6. Execute drush cr with xdebug enabled
7. Observe how the entity field manager now uses "de" for building the cache ID since without passing url to drush the url negotiator returns "de". 8. Observe how but when it goes to load the overrides the language config factory override uses "en" to load the overrides since its constructor takes the site's default language.

Clearing the caches over the UI no matter if on the EN or DE path prefixes does not seem to be causing issues. It breaks only when drush is involved into the cache rebuild.

I also noticed that LanguageRequestSubscriber does not get triggered at all as no KernelEvents::REQUEST event gets dispatched during drush cr.

In contradiction to #32 πŸ› Wrong language field labels after `drush cr` because of Drush language negotiation Needs work for me the MR solution worked but the PHP_SAPI check did not work.

Inspired by both approaches I am providing a mixed alternative that hopefully should be then covering all the cases for everyone and not only the ones we are observing in the entity field manager.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

We had an issue with the webform module client validation where our errors started using the label tag instead of the strong one and then the errors were overlapping the label of the input fields. This patch solved the issue for us, therefore I think it is good to go.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

I think this is caused because of https://www.drupal.org/project/clientside_validation/issues/3322946 πŸ› Once is not well implemented Fixed

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

If mustConsent is false the modal shouldn't be opening automatically.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Thank you, @Svitlana.

Committed to 1.0.x and tagged 1.0.0-rc2.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

hchonov β†’ created an issue.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Re #15 ✨ Add hook_entity_postsave hook Needs work :

I don't think that isNew() works, would definitely need more specific tests than just checking that it is called.

At this point, the entity is no longer new as it has been saved already. That's why we pass the additional flag to postSave().

Well this actually has the answer in it :). The post save hook should be consistent with the postSave method and have a second parameter indicating whether this is an insert or update operation.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

In addition to #9 - getOriginatingEntity() is too general and sounds like there might be multiple origins, while getDuplicateSource() is more specific and semantically relates to createDuplicate().

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

It is a fair suggestion, but maybe we don't even need to store this. Just knowing the source/parent at the time of hook firing would be enough as a first step.

This will be for sure much easier to implement and maybe easier to get into core than what I am proposing and still makes it possible to add the persisting layer later :).

Also introduce a hook_entity_duplicate(). This would allow us to pass $original_entity / $source_entity as a second argument if we feel like $entity->original is too much of a historical oddity.

+1 on the hook, as it allows to duplicate nested referenced structures as well.

I think it would be good to also have a new "source" property and the respective getSourceEntity() method on the EntityBase class, which we could access during the saving process.

I am in favor of adding a new property and not reusing the "original" property, because while being similar those are different operations and it is assumed that "original" is not set during the saving process of new entities.

It might make sense to introduce a storage-level createDuplicate() which calls a hook_entity_create_duplicate().

Yes, this makes sense. We've done this for example with the createRevision method on the storage.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

@bojanz, I've proposed something similar for tracking the revision_parent of duplicate entities in #2725523-30: Add a revision_parent field to revisionable entities β†’ :

If for example we take a food magazine, then we create a duplicate of some recipe and want to offer different extended variants by the users, which create a duplicate and extend/modify the new recipe, but a link between the recipes is automatically created. This actually sounds like a really great out of the box feature for Umami and for presenting Drupal.
I think that this feature might be used by a lot of projects and as such, it would be good to be part of the Drupal core.

I think that in case of revisionable entity types the duplicate entity should reference its source through the new field "revision_parent". For non-revisionable entity types we could add a simply entity reference "parent" field and for config entities we could add a "source" property.

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

@Xano, so your patch is doing the same as mine, but mine is introducing some performance optimizations. Is there anything different beside that, which I am missing?

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

@tstoeckler, the $storage property is static, because this way it lives on the class and not on instantiated objects.

I am also not really sure about the naming, I've just written the first that came to my mind. We need two methods - one public getter method and one helper protected static like the current getStorage($entity_type_id), which would check for the current class if the entity type ID isn't provided. But thinking once more about it probably it would be better to make it more explicit and have three methods by dividing the current getStorage into two methods - getStorageByClass and getStorageById and renaming the getEntityStorage into getStorage:

  1. public getStorage() - returns the entity storage of the current entity object
  2. protected static getStorageByClass($class = NULL) - returns the entity storage for the given entity class or for the called entity class.
  3. protected static getStorageById($entity_type_Id) - returns the entity storage for the given entity type ID.
πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬
Production build https://api.contrib.social 0.61.6-2-g546bc20