juagarc4 → created an issue.
Hi sukr_s,
Oh, I haven't read about the initiative you mention to remove hardcoded uid 1. But it's for me ok only to check for the permission.
I tried your solutions and now it's working fine if nthe user that access have the permissions assigned.
Hi smustgrave,
I don't understand why the ticket is not clear enough.
The summary uses the standard template. I only removed the elements not involved in the problem. I can get them back again.
I described the problem I found and ask is there is a good reason for not changing the current implementation by my proposed one.
I don't think, the committed solution is the best way to solve the problem either. So I don't understanb what the title and the summary must be adapted to match this solution.
Would this not be considered an API change? I don't think, it's an API change
Maybe I haven't understood you.
Hi sascha_meissner,
don't worry. it's ok for me. I'm glad to have been helpful :-).
I change then the status to "fixed" if you don't have anything against.
Hi sascha_meissner,
Thanks for considering my proposal.
I'm agree with you regarding "not to force anyone in using a specific way on how to put the files into where they are expected".
For this reason you can use only a composer.json with the reference to the repository and then use a section "suggest" to inform the users about the required libraries to be installed. It's a less intrusive way to let them know that it's important and at the same time let them the freedom to install it however they want.
I updated the MR with these changes. You can take a look and decide if it is an option for you.
In this way the file composer.libraries.yml is only for BC reasons needed.
Hi sascha_meissner,
Sorry, I didn't see the composer.libraries.json. But this explains now why the library was not downloaded as I installed the module the first time.
I suppose the composer.libraries.json is being merged with composer.json by means of "wikimedia/composer-merge-plugin" but I can't see the corresponding "merge-plugin" configuration in composer.json.
Since the Drupal core itself is not using this approach anymore since version 8.8 and Klaro supports Drupal 9+, does it make sense to continue using it here?
https://www.drupal.org/node/3069730 →
I would suggest to add the required library repository and its reference in the composer.json and remove the composer.libraries.json.
Would it be possible?
It will work for new installations and for updates. But I'm not sure how the old library can be removed from system. Will it be removed by the update of the new version of the module or would it require a manual action of the user?
juagarc4 → created an issue.
juagarc4 → changed the visibility of the branch 3.x to hidden.
juagarc4 → created an issue.
Hi all,
I tried the solution of #33 and it works properly. The patch could be applied properly.
Information for all of you that tried to remove the source code using composer once applied the patch.
You will never be able to remove the source code using composer, because the patch is applied after the composer installation. This
produces that the composer-lock file still contains the requirement of media_library_theme_reset in to the bootstrap_styles entry.
So if you try to run 'composer remove drupal/media_library_theme_reset' you will be warned that boostrap_styles still requires this module and it won't be uninstalled.
The only way to get the source removes is not to install it at all, but it will be only possible once the MR has been merged into the base code.
I think, it has been testet enough and can be merged into the code base.
I tested today the new functionality and it works like a charm.
It worked even without clearing the caches and I don't think either, the weight field in the edit form is really necessary.
Thank you very much :-) !!
I tested today the new functionality and it works like a charm.
It worked even without clearing the caches and I don't think either, the weight field in the edit form is really necessary.
Thank you very much :-) !!
I'm agree with this approach @guiu. If fact it's not necessary to be able to change the machine name.
I'll try to test it in the next days.
Thanks!
juagarc4 → created an issue.
juagarc4 → changed the visibility of the branch 3422472-is-it-possible to hidden.
It works like a charm :)
Thank you very much!!!
juagarc4 → created an issue.
Sorry I have already seen, that it was replaced by a new change afterwards.
This issue seems not to be fixed.
I still have the same warning and I installed the last dev version and I can't see the changes of the patch in the code.
And the patch doesn't apply anymore.
Hi japerry,
Thanks for the answer.
Since you can use more containers and more IDs per container, I think it make sense, so that the label and machine name can be used as a kind of categories.
One use case I have for that right now is the use of this module in combination with Domain. Since I'm using different containers per Domain, it would be useful to put the domain name in the label. In this way is easier to identify what need to be changed, deleted, etc. without having to edit all of them.
Moreover the use of a customized machine name in the same way of the label would make easier to get information of the container programatically.
Note: Changing the config entity can be easy done by programmers, but normally the users authorized to change this configuration, don't have the knowledge for that. In this case a change in the UI would be quite appreciated.
juagarc4 → created an issue.
juagarc4 → created an issue.
I faced the same issue recently and the patch work properly.
juagarc4 → created an issue. See original summary → .
You're welcome @apaderno :-)
I could apply and test the patch successfully.
It seems to work properly and I can now apply the "swiper formatter" to fields referencing paragraphs.
Hi @smustgrave,
Thanks for your comments. I'm totally agree with the upgrade path.
As far I've seen, we need to update two modules: layout_builder and layout_discovery and the themes which are already using this class name: Olivero and Stable9.
Maybe we can start adding the new class together with the current one and adding a notice in the code indicating that the current class name will be removed in the next major version. It can reduce the BC issues and let the developers to adapt the code to the new class name.
Should we create a ticket for each case or can we address all changes in this one?
I would tend to create a ticket for each case related to this one as a main ticket. What do you mean?
juagarc4 → created an issue.
Hi @leo liao,
I had this problem too and it was related to some client side caching for contextual links.
I solved it by clearing browser cache. I was in Chrome, so I followed the usual steps to clear the cache:
1. Open Developer tools.
2. Go to Application tab.
3. Open the Session Storage by click the arrow icon.
4. Select the website url.
5. On right panel click on "Clear All" icon.
May be this solutions helps you too.
Regards
juagarc4 → created an issue.