🇫🇷France @dqd

#19 📌 Automated Drupal 11 compatibility fixes for eck Needs review : There doesn't seem to be a good reason to drop support for Drupal 9.4, so I'm adding that back.

Absolutely right. 200% Agreed. TBH, I was in conflict on this previously already twice, but it was based on a "trend" in many contrib regarding PHP version support in sync with Drupal core. I wondered why so many users wanted me to remove Drupal 9 support on projects I maintain and they convinced me at this time. But this surely affects not all contrib modules.

#13 📌 Automated Drupal 11 compatibility fixes for eck Needs review : Sorry, but to be clear for the logs, there haven't been raised any issue but only work has been continued on MR50 in line with update bot and previous contributors and it just got some minor basic adds/changes for ^11 compatibility as a starting point. And functional and procedual changes and updates in the code base should always be rather discussed carefully with the project maintainers anyways. Also, please do not assign update bot issues to yourself.

Thanks @dieterholvoet for finally updating/fixing and merging a carefully written out commit. Do you prefer any existing follow ups to work on with prio for an upcoming release?

#235: please file a new issue.
#236: please read about issue workflows, patches, MR's, dev snapshots, commit and release policies. This issue is fixed and merged like nicxvan already explained. Follow ups should point against latest dev. All maintainers and contributors in the issues of CF here try to help to get a final release asap, if times allows us to work on it.

Many things have changed over the years already. And the standard install profile of Drupal core - which was somewhat unspokenly the basis of this issue attempt - will maybe become less important in the near future. Especially with the starshot initiative getting momentum. So, many of the thoughts in here can be considered outdated. Or rather "absorbed". In a positive way.

To clarify: Most of the misunderstandings in here in between were mainly caused by the fact that the IS tries to cover the "no-code" impressions from average users UI perspective on a standard install profile. While some participations on the disucssion are referring to ways to change that in code or non standard profile scenarios, f.e. custom entities and such.

Misleading or not, maybe too non-technical in some aspects, also, yes, and last but not least too theoretical and mostly based on the assumption, that users are rather familiar with creating node types and fields on node types like provided in the standard profile, the idea behind all this has been somewhat absorbed already in different evolutions of the whole Drupal concept and eco system over the years. Users get more and more used to custom entities and the understanding of fields, base fields and labels are evolved.

So, after thinking about it for a while now if it makes sense to invest more time in here to clarfiy or narrow the idea into a more understandable concept, while parts of it are already "fixed" in other ways, I came to the conclusion to close this issue as outdated.

In case some of it could need further discussion it would rather make more sense to create a new issue to prevent wasted efforts of users reading all of the previously obsolete content.

Interesting. Thanks for the report. Can you make sure that you did not fall into: 🐛 Referring the same entity multiple times breaks _referringItem Active or 🐛 Can only intentionally re-render an entity with references 20 times Needs work ? Otherwise we need more other reports on this since yours seem to be a very special steps chain to reproduce.

Yes.

Did you used the module the first time? If not - Can you both please check out a previous commit of the 2 dev branches like .. let's say 2 weeks ago or sooner? We had multiple commits to be done in the last week to overcome long holding issues and then it would be obvious where to look at. Please provide both your server, browser and php version too. Browser can be interesting because of javascript involved. Oh by the way: do you have JS error output in the browser console?

Follow up: 📌 The merge plugin is discouraged and should not be used Active

dqd → created an issue.

Hm, that makes sense! +1 and million thanks for coming back on this. I will start a new issue following dropzonejs on this. Seems the most reasonable road map for this scenario.

@hongpong: Thanks for your awesome work and your calm responsiveness here +1 And sorry @kevinquillen: I forgot that old threat actually and I missed your last reply. I am not sure after which amount of night shifts of me we both did collide...

Sorry, I am not going to respond or engage in harassment or personal attacks / snark, which is how that comes off. There is no reason for that.

There was nothing of me intended like that in any way. If it read like this, then please accept my apologizes. I actually very rarely lost my composure in life. I don't know what triggered me at the time or how I maybe interpreted your comments. I do not even think that it was meant like it reads now. It is too long ago. And not my native tongue. I assume it was at this time when I realized a certain down going contrib activity rate on Drupal.org and a diminishing quality assurance motivation of maintainers in general at the time of that core lifecycle. It was rather in a "fight for Drupal" type-of energy as a whole, and nothing against your comments at all.

I am always positively surprised by the healthy self-confidence of some users nowadays. Offering to co-maintain a module after being a Drupal user on Drupal.org for about a week with no details, nor any developer history outside of Drupal nor any credits on the user page ... that is at best and with good will ... courageous. No offense. Sorry ...

Apart from that: this is not how Drupal works. Drupal modules are community work and maintainers hold the responsibility for a whole community to conduct its development. Therefore users with a traceable history should be considered. And in this case this module is opted in for security, so the contributors should be long term users and already maintainers of multiple other modules. Especially on projects with a DL rate if 50k+.

But I do not want to discourage you in any way. We are happy with any help and contribution. Consider to join a mentorship program and let others guide you into the Drupal-verse. This would help you to avoid any mistakes and would speed up your entry into Drupal's community.

Gin has "fixed" icons hard-coded/rendered into the theme-markup, which do not "update" if new icons come into play. At least from my last test of the theme and one of the reasons we hat to stop using it. We felt like this would be a too different attempt to discuss for Gin at this point.

Since there are no new changes, only some minor corrections it could be set RTBC

Added same changes to a new branch with correct color code and consistent code style, like #ffffff instead of white and #0099ff instead of #0000FFFF (wrning anyway). Chosen a slidely more green shift in the blue to get closer to Drupal colors.

Usually we wold close the newer in favour of the older issue, but in this case the other issue had work in progress and active reviews, commits etc. So I close this one as duplicate of ✨ Crop limit is not clear Active

Jaspeet-Kaur #4 I think that was not a very careful review. As commented on code change the color code is wrong.

Maintainer here. +1 @eelkeblok: exactly like you have suggested. Thank you for your careful thoughts on this. Fully agree. Especially in case of projects like this with +50k downloads.

@berdir sorry that I missed your comment previously. That was work done on the road with a laptop on my lap as a co-driver front seat in the car at night with the display light dimmed. From my understanding the merge plugin issue is ✨ Support Composer merge for libraries Postponed: needs info ... this issue here is for adding composer library json file, which - at least what I thought - works without the merge plugin, no?

And I am still not sure if we have already optimized the documentation in this regard: https://www.drupal.org/project/image_widget_crop/issues/2845343#comment-... →

Perfect. Thanks!

Major Follow up to update library: 💬 The Cropper library referenced in the README and in the libraries info is deprecated Needs work

Please join there to help so that this issue here incooperates nicely with the updated library version.

Thanks for coming back on this +1 - If we agree on #16 than this issue is not RTBC and needs work. It still points to https://github.com/fengyuanchen/jquery-cropper instead of https://github.com/fengyuanchen/cropperjs but the IS clearly states:

Instead let's upgrade to use just https://github.com/fengyuanchen/cropperjs in the first place. Not the jQuery wrapper, just Cropper.js.

Also we need to take the new composer file into account here now. Patch #17 needs reroll and jQuery needs to be removed. Also the README needs to be updated regarding library installation.

Please let's focus on fixing this issue and let us move personal support into a seperate support request. Apart from that please help to answer the questions in #69 mandatory to move on. Thanks for understanding.

Thanks for the awesome work in here +1

This will have less chance to be committed until #16 💬 The Cropper library referenced in the README and in the libraries info is deprecated Needs work has been adressed or at least commented on. jQuery is partly moved out of core and should not mandatory if not required. Also please review if this issus is able to incooperate into the already committed issue with composer.libarary.json added.

Please lets review if this issue needs a new scope now with composer.library.json added to 8.x-2.x and 3.0.x already.

Thanks for the report, work on this simple fix, and the helpful reviews.

dqd → changed the visibility of the branch 3149840-displaying-crop-type to active.

dqd → changed the visibility of the branch 3149840-displaying-crop-type to active.

dqd → changed the visibility of the branch 3149840-displaying-crop-type to hidden.

Thanks for the work in here. Added seda12 to the credits.

Has also been merged into the new 3.0.x semantic versioning dev branch based on 8.x-2.x for the upcoming semantic versioning release with long holding RTBCs committed to both branches.

Thanks for the awesome and helpful review @eelkeblok - Seems this still neds work. Just wanted to let know that some of the required issues linked have been committed know. So wrk can go on in here. +1

THanks for all the work and tests in here +1

Thanks for all the efforts in here.

Thanks for all the hard work in here! Gitlab CI file has been added by Drupal 11 compatibility issue merged into 8.x-2.x dev yesterday and this issue here is one commit behind with conflicts, but only 2 of them really required to look at. Can we please resolve the conflicts so that I can commit asap? https://git.drupalcode.org/project/image_widget_crop/-/merge_requests/15... It is actually just some example and test code which differs and needs to be looked at and a careful decision which variant of change to keep.

I am fully with you and heddn on this. And please let us do not waste your or other users resources. I asked the contributor from the duplicate issue to add his "ideas" into the original issue and he was kind enough to do so. But of course I did not meant by asking to only copy paste it without looking at the issue scope, the issue parts already fixed and without checking which of his additions are obsolete of useful and still missing and which not. We should start from the MR with the most progress and less things to do.

Looking briefly at the new one, it has a lot of changes unrelated to drupal 11 support: 43 files + 624 − 661.

Hm, that's not good. @mably would you mind to address these reported flaws in your MR?

Never mind, let's merge forces and let's try to pick best of all to narrow down this issue to a reviewable state. I will try my best this night to take a look into each of the MRs deeply...

Sorry I edited my comment. I added:

EDIT: In fact it is not recommended to push into the bot MR and from a glimpse I think the last MR worked on before your additions was not the bot one. Not sure yet. But as you have explained that has been done for different reasons. Anyways your try to help is very much appreciated. As always .

Mine previously of yours was 54 I think.

That is very helpful review @nicxvan. Thank you!

@heddn Agreed in terms of clutter. That was not intended this way. But please lets cherish and value the contributions at first. Read the last issue comments here and on the duplicate issue for a birds eye view. It just takes some minutes. It took me 1 hour to sort the motivations of each issue and I try to prevent additional resources wasted and explained clearly that I tried to merge forces here. And it seemed that nobody cared about that 2 issues where co-existing and running MRs parallel without anyone chiming in to clarify. It should be handled respectful on each of the issues, that contributors put efforts in them. And it would not be OK to close this one here in favour of the newer one, which was already RTBC. In both issues work has been done which could possibly be interacted in each other. Which needs inlaying changes line by line, actually. And that's what I asked for. I only can ask the contributors to cooperate. I cannot force them to do it the way which is most useful to you or me or others passing by. Possible reason for different MRs could be that others can not add into the previous MRs? Not checked yet. I need to take time to look deeper into each of them (like anyone could do) but I am on the road since some days because my brother died tragically some days ago and my heart is broken and we are about to bring the family together and bury him in the next week. So, my apologies for only conducting without going into the lines at this moment.

It would be interesting to know if last MR in here passes tests.

#24: I asked for support and contribution on this issue and I am thankful for each effort but I am not sure if another branch was helpful at this moment.

#28: I actually asked for merging your efforts into this issue here and not just creating another MR without comments. But I am thankful for all contributions.

Awesome! Thanks @mably for pushing your efforts in the other into the original issue. +1 Reviews to move on quick what be great.

That was a lot of hard work though.

Indeed! Very impressive and very much appreciated. It was hard for me to make this very unsatisfying step. But it is a common procedure on Drupal to prevent credit and fix overlapping issues. And I am sorry for the frustration. I recommend to use the issue search before starting an new issue. Or if you feel the original issue is not going in the right direction or too slow, to ping contributors or to discuss in the issue how to move on. I think your contributions are awesome and can move things forward a lot. +1 And your thoughts will weight. So I don't want to demoitilize you in any way and hope you keep up your awesome work! Thanks for pushing into the previous issue!

Thanks for all the hard work in here and the patience for the final commit to latest dev. And to the Drupal 11 compatible upcoming release soon. Any thing you wish to have in the next release, please try to bring according issues to RTBC as soon as possible to be ready to get in.

You all rock! +1

Why do we have a duplicate issue created a month ago while there was already one existing with contribution of original maintainers of this project? (not talking about me here)

Thanks for all the efforts and any contribution is very much appreciated to move on. But please let us keep things sorted and do not let us outframe efforts in other issues already made and please MR this here if required into the former compatibility issue exisiting already since March of this year.

Million thanks! And sorry for any inconveniened feelings about it. But it would not be very nice regarding the previous issue work done. This is why we usually follow the rule to mark the newer as duplicate of the former. This way we do not loose track of overlapping fixes and do not loose track of credits on efforts in the issues.

The opposite is the case. We usually mark the newer as duplicate in favour of the former, and if the newer has more progress on the exact same issue it should be merged into the former to not loose track of overlaps and do not loose credits on both efforts.

Thanks for coming back on this @mably. Your efforts and contribution is very much appreaciated! If it is OK for you and the moderators of this issue section, I would recommend to close this issue and wait if upcoming progress on the project is satisfying.

In case if progress stalls and requires action, another request of you, or me or anyone else could be considered. Until then I would recommend to leave the project in the hands of the active maintainers and wait how the responsivness goes on. In the moment I got very responsive support of active maintainers how also invited me to contact them for any help.

@mably: I hope it helps to move on. Do you feel your worries settled for now so that we can close this issue at this moment? From my understanding regarding the situation it is a little bit too early to rush fences here. I think it would be better to cooperate with active maintainers and communicate possible existing road maps and contribute to them before entering the ship.

Quick news: I've been added as co-maintainer at this moment. So things move on. I will help to get a final Drupal 11 compatible release in the next days and the work on long holding issues and RTBCs will go on to make the project ready for the further future. So things are moving on now. +1 I hope it helps.

That was the message I send to @woprrr using the contact form on D.O.

Hi @woprrr,

How are you? I hope you are well in these strange times. Thanks for all your
awesome contributions to the Drupal community! You rock! Since the company I
chair as CEO (MAROQQO digital media) and my team has agreed to support
contributions to this project and to move on with some feature additions and
patches in the issue queue to make this project Drupal 11 ready and prepare
it before Drupal 12 lands, I would like to invite you to add me to the
co-maintainer tab for this project to come over long holding waiting times or
the need to contact maintainers each time for another review or new patches
or commits on RTBCs.

My consideration is based on the assumption that you and other maintainers of
the project do may not have enough time to keep track on this at the moment
(which is absolutely understandable) and I would like to help out for your
project to move on. So I hope this message does not reach you mistakenly. If
you plan to put more time into the project soon, consider/regard my request
as settled (obsolete).

Have a nice Week!
@dqd (Sebastián)

Good news: I am added. So things will move on now! :+1: I will make you patiently waiting users happy soon ;-)

I just wanted to prevetn too much noise here, that's why I haven't reported yet in here that I have contacted @woprrr already some days ago inviting to add me as co-maintainer to help out for a final Drupal 11 release and beyond So let us be patient and wait a little bit. A I know very well maintainers have a lot to manage. We will move on here as soon as possible.

Decrease issue prio. Descriptions of the Priority → and Status → values can be found in the Drupal project issues → documentation.

I have contacted @woprrr already some days ago offering to co-maintain and help getting a final Drupal 11 release. As I know very well from own experience as a maintainer of multiple contrib modules, maintainers possibly have a lot to consider and to manage on a time table and it is fully understandable that they cannot repond immediately. So let's be patient please and wait some days if he responds. In case my invitation to help is welcome, I will help to get a Drupal 11 release asap. To request a take over feel a little bit harsh to me for that situation.

Does thoughts point 2 and tasks point 2 have been addressed in the latest patches?

Issue summary has #anchor points now to refer to.

Thanks @jeffschuler for keeping track on this (and the typo correction hah :) Let's move to MR's to speed up work in here.

Thanks for all the reports. This indicates that we maybe need a proper exception handling and warning for such cases to prevent WSOD and sites being unmaintainable in this state.

MR!4 fails because dependency contrib notification is not yet ready for Drupal 11.

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

MR is green now. Some review would be helpful to move on.

Marked as duplicate in favor of an older issue with work in progress 📌 Local Storage for Coffee Needs review

Simple enough. Thanks @bramdriesen +1 and RTBC. Needs to be merged into 📌 Automated Drupal 11 compatibility fixes for coffee RTBC

If this issue is not about config option to change the shortcut key, this is rather a documentation issue. And I think it would be better seated in the help() part of the module. This is the common way of project inside documentation. Feel free to provide a MR to review if this is still a requirement in your project.