The name of this module says "select" in its name, so the chance is high that this project focuses on extending the select widget with hierarchy support. ;)
But - If followers are not aware: there is a project called "select or other" which imitates the requested part extending select widgets with the feature to add another (new) term to select widgets. Sadly the widget replaces any other widget so it cannot be combined with cshs or similars. But I wanted to point you to this direction in case users have ideas or the wish how to maybe combine both widgets into one or to maybe ask here or in the issue queue of the other project to support each other (FR).
This could be a possible go-to road map for the future. Hope it helps.
+1 for raising this. My vote for it and 100% agree with the argumentation and reasons. And it would close a group of other issues. Additionally it minimizes the efforts to keep track with those tips and all possible combinations of allowed tags etc and it never really looked well seated under the textareas of body and comment fields and was kind of circumventing to style. And since we do not have any hard wired dependencies in core with this part of filter.module it would be mainly removing the respective parts in web/core/modules/filter (tips) and making sure that it does not break contrib in case that modules use tips to place their own (if any?)
When formatting tips are actually needed, we already provide field descriptions which site admins can edit - this would allow them to give a couple of markdown examples, link to external resources etc.
And which gives far more flexibility. Also in how it looks or how it is implemented (markup). Only drawback is that it do not change it's tips automatically regarding the allowed tags when switching between formats, I worry? Maybe we should provide a token which picks up the allowed tags from the formats to be used in the field description?
Before adding tags read the issue tag guidelines → . Do NOT use tags for adding random keywords or duplicating any other fields. Separate terms with a comma, not a space.
#3 Also, I noticed that the 3.0.0 tag was already created in this module's Git repo... [...]
That's because I planned a release end of last year with some more issues I planned to fix before my brother sadly died. And I was off for the time after until end of last year and beginning of this year. I am pretty sure that I would have added some more issues before a final release and would have preferred another BETA before. But if it makes people feel better with a final release tag, I am glad that you are happy for now.
For those who have similar situations with other modules and Drupal 11 ready MR in an issue I recommend reading about how to add a MR to composer stack as temporary package source until the issue is commited.
I would love to see some more issues worked on and I hope to see you in there in the upcoming time. Belated Happy New Year @all.
#7 📌 Create logo for Conditional Fields for Project Browser Initiative Active Thanks for the compliment! Was actually just a first shot in the hope to help and to discuss possible agreement regarding the direction. I am happy that it was to your likings immediately.
And thanks for all the contribution in here and the inspiration in #3 helping for the direction it sh/c/ould go.
@heddn: let me refine the borders and spacing a little bit to look consistent with the inner frame radius on pages with white background in the next time. Hopefully next days. So let me set it to "Needs Work" and I will assign myself temporarely to have it in my notifications.
@faterhshawn: you asked me to review 📌 [POC] Implementing some components of the Ajax system using HTMX Active and I will come back to it soon when I am finally back on my desk.
To prevent clutter in the Slack threads for those who want to chat about it (which makes sense sometimes before posting refined thoughts into the issue queues), I just created a Drupal Slack channel #htmx for everybody open to join. I try to collect all open threads of Slack in it, so:
For @all following and contributing/discussing HTMX into core topics: feel free to join the Drupal Slack contrib channel #htmx
wrong status regarding unresolved/unanswered review questions.
Thanks for the report, but "fixes the error" for one person is not enough reason to RTBC an MR after 2 review comments not resolved/answered yet. Can somebody please answer/elaborate on the review comments raised? If it turns out to be finally OK or not an issue at all: great. @davps awesome work! +1
Just wanted to inject shortly: I think implementing HTMX support into Drupal will not turn HTMX into
a base of a complete frontend application
here on Drupal's concept.
@quietone: That makes absolute sense to me. Thanks for taking care of it and coming back on this so quick.
The definition for 'support request' currently discourages use in Drupal core
Oh ... that is not good. You are right. Then it should not be used here. +1
The priority for committers is usually the RTBC queue and issues tagged for manager review. So, as a 'Feature request' this will not make noise for them.
Ah, good to know! +1 this will help me to not do "over-care" on such points.
Setting to 'active' since their isn't an MR.
That's what I thought, yes, but I wanted to leave it up to you (or others) to decide.
I was also thinking that this work may fit into the 'Local server setup' into a new guide or page for things to do after a development site is initially setup.
Ah, yes, that could be a real good possible roadmap and clear goal for this issue then. Let's wait and see what the creator and contributors to this issue think of it. I am all in! +1
Again, thanks for helping out!
Sorry, my fault (not my native tongue, I will del in my comment) ... :) And it was not meant in any critical way ;) Discussion is good. And important. Thanks for coming back on this.
Another belated "Welcome to @1cg!" (creator of HTMX) from me and a Million thanks in advance for your invitation to help with being there for questions and for any support required in case of implementation. +1 (This should not be allowed to fall by the wayside during heated debates here)
If you are interested in some thoughts, links and discussion happening in the moment at Slack Drupal #contribute, started by a question I raised over there (this is how I belately came here some days ago from @mstrelan who has kindly linked me here) feel free join us. Link: https://drupal.slack.com/archives/C1BMUQ9U6/p1737655260942599
@quietone: Same here, wondered about "Needs works" too. Still no MR in progress or any explicit goal or extending feature concept yet reviewed already, from what I see. But I didn't want to discourage any discussion.
Why I considered SR in #18 ✨ Easy way to bypass all caching with Drush or settings.php Active :
to prevent too much noise for core maintainers I will set it to "Support request" until ...
In this state it wasn't clear for me if it was rather a support request of users needing assistance in easely disabling cache since the title and the fact that disabling cache is a quite simple task featured already in many ways, lead me to it. Maybe the issue needs a better phrased scope then?
@ressa: If there is anything in progress extending the framework functionality which not exist yet and which I do oversee, can you elaborate on this please? Thanks in advance.
To your question in #20: A support request prevents noise for framework managers, since they have a lot of work to do. And to review code and issues with provided code or MRs get a certain priority. And so I left it up to framework maintainers to choose the proper category if there is anything in progress or of interest to start at. And btw, "Needs work" is rather preferrable for work in progress and code changes reviewed and with work still left to be done or any other scenario in progress. Otherwise "Active" would maybe be more accurate here at this state.
Hope it helps.
This would be a very useful example for documentation. Please consider to contribute to this great project by documenting your use cases. Make yourself familiar with how the drupal docs work, if you not know already. There are great examples of how users wrote down their use cases to help other users to understand what this module is for.
Not sure if we need to keep it open. We run on this in staging scenarios (from local dev to online) with Drupal core version ^11 when caching gets enabled. If disabled no problem. But after re-enabling caching some css files cause this error, even if the files exist and have proper access permissions, cache flushes, cron runs. Further investigation required here from our side to evaluate but I would not close it to get more user reports just in case. Strange enough that it seems random which files get affected. Will try to find the reasons to come back on this.
#54: Regarding your second paragraph: I often phrased my worries (carefully and sensitively) on the "JS frameworks on top of Drupal" trending concept. I've never been convinced of it as a solution for every inactivity priorising project from day one when it started to take off so much. Too much. Especially not for random use cases. But it should not be demonized. It is a corner case concept. After my long-term experience with such concepts already long long time before (over 16 years), which actually brought me to Drupal 5/6 back in the days (as I filled an award-winning agency Flash site with content from Drupal) I was wondering how this boomerang came back and became such a new buzz with JS frameworks reinventing the wheel. It was an exiting Flash (actionscript) meets PHP project bringing me to Drupal, sure. And it was feeling like walking thru' a starship (game). But it showed actually also the reasons for my worries and limitations alerady and that this should be only done when Drupal is not the core of the project (the content administration part of the project only). It had already the same limitations like JS frameworks have on top of Drupal today. As the word "decoupling" perfectly describes. It decouples some of Drupals strength to be unreachable at frontend. JS frameworks can surely interact better with Drupal than Actionscript does back in the days. And again, there are very good reasons to use them for projects where the strengths of these JS frameworks have priority over all the features Drupal bring with core. But the base issue on the concept persist. But in the days of the starting JS framework hype there were only a few ears hearing me.
Great to see an attempt to embrace HTMLX exactly for that gap/bridge in between, where Drupal is the core of the concept which just needs some more interactivity without loosing Drupals strengths. We hope to make some time available to contribute to this eco system soon. We are all in! +1
Awesome work in here! +1 Thanks for your contribution. I will try to discuss this with maintainers. Feel free to add the "domain" channel I have created a while ago on Drupal Slack fpr further domain project contributors. This or the other way, I will try to come back to this issue asap!
Hi and Thanks for chiming in here, @joseph.olstad - I worry if I got misunderstood. I am not after a certain way to go with the project, since I do not use the theme nor do I plan to or have clients using it. I just humbled over this issue and comments and started to worry about the decision made to duplicate project "Bootstrap Barrio" into the v5 branch of Drupal project "Bootstrap" (at least as it reads) and just labeling it as the new version of Drupal project "Bootstrap". Without any discussion about it nor any info on bnoth project pages. I hope I was able to make my concerns clearer. Thanks for sharing your thoughts and a belated Happy New Year.
#3 📌 Path to upgrade for version 8.x-3.x to 5.0.x Active The version of this theme for Bootstrap 5 is basically the Boostrap Barrio theme.
Wait, what? ... Who decided this on such a large project without a readable user discussion? Or do I not find the issue yet? If that's 100% the case, then this long-awaited "new" v5 version of the original Drupal Bootstrap implementation is actually like a "cheat package" hijacking the original projects url with no warning to the user. Unless it will at least become clearly pointed out on the project page. But still then: Sorry if I maybe misunderstand something here, but this really worries me and others and it does not follow nice practises and community embracing concerns in the best way. We seriously consider to point some moderators to this situation now.
Try to imagine the following scenario: A customer or Drupal user is trying out different Drupal Bootstrap implementation themes over the last years and dislikes most of them in their approach, except the original Bootstrap implementation theme here. And keeps using it with Bootstrap version 3 as long as possible with the hope there will be a real update to Bootstrap v5 under exactly this original project's concept one day. Since the user already disliked other implementations it will be a big surprise to finally find one of those other implementations under the v5 version of this project here now...
I really do not agree with the ethics of this way handling the project and the making of decisions on its future (no offense). Please elaborate.
Still not reachable. I also doubt that this api is belonging to the new way of the project anymore. Please read the discussion on https://www.drupal.org/project/bootstrap/issues/3474190 📌 Path to upgrade for version 8.x-3.x to 5.0.x Active
Apart from that, it is a bug report and not a support request regarding the project page links not working or not correctly being set.
#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
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.