Thanks for the clarifications all
@vvuksan-fastly please forgive me for re-opening this, but I understand closed issues won't get much attention.
Fastly is definitely a niche module and doesn't apply to all projects, but I do agree with all of the above people. Maintaining a split has always proven to be cumbersome and it is something we prefer to avoid for simple things.
AdvAgg, another performance related module supports disabling the module on settings.php level (source: https://git.drupalcode.org/project/advagg/-/blob/5.0.x/src/Form/Settings....
In reality, Fastly is something you will only need on a live environment. It would be great to be able to do just that on module level, and not require an overly complicated extra module.
Again, forgive me for opening this again, feel free to close it again and I believe we'll all understand and stop requesting this. I certainly hope you reconsider though.
Thanks
New MR against 2.2.x, new patch attached for use with composer, same state as MR (from https://git.drupalcode.org/project/honeypot/-/merge_requests/60.patch)
Attaching new patch.
Notes:
- I would love to bump hook_update_N to 8201 (from 8105) to match with version 2.2.x
- Can't update the MR as the forks don't have 2.2.x and won't sync themselves
- Please add https://www.drupal.org/u/jaims-dev → to credits, as he helped with the new patch
@nicxvan added some feedback as a gitlab suggestion
Much appreciated mate!
Have a nice day
It's good to know it wasn't intentional, that means a lot :)
As a maintainer you can see at the bottom of the drupal issue (above the green action buttons) the "Credit & Committing" section.
In there you should have an option to check/uncheck who participated.
I am adding a screenshot of this area from a different module, just to highlight how it looks like.
You can chose whoever you want. It is customary to pick people who contributed with a patch and/or testing notes (even if not providing code patches).
Once you fix the issue, and after 14days pass when it gets closed, people will get credit.
It also gives you the commit message if needed, but I believe it is enough to just do the checkboxes.
@lobsterr it would be wise to grant credit to the people who have worked on this over the last 7 years and provided fixes to the issue by contributing patches until one of the maintainers sat down to deal with the issue.
Crediting yourself alone is not the way to encourage people to work on open source projects.
Running the latest dev version (almost equal to 4.3.7) I am getting these reported too but properly categorized under ignore in both the UI and drush.
$ drush us-a weather
[notice] Processing /var/www/html/web/themes/custom/weather.
================================================================================
Weather, --
Scanned on Mon, 26/05/2025 - 08:50
FILE: web/themes/custom/weather/templates/form/select.html.twig
STATUS LINE MESSAGE
--------------------------------------------------------------------------------
Ignore 13 Since twig/twig 3.12: Twig Filter "spaceless" is deprecated.
See https://drupal.org/node/3071078.
--------------------------------------------------------------------------------
Closing this
Thanks @ki
Let's hope this helps people out there even more.
I can verify that it works as expected with the latest dev version!
@ki I'm glad you like the initiative! It means a lot.
Regarding the new colors committed it looks like the environment are indistinguishable for people with Protanopia and/or Deuteranopia (and Tritanopia for that fact!).
This is how things look with the current dev version:
You can see that:
Protanopia and Deuteranopia affected people can't tell the difference between Local+Dev and Stage+Live.
Tritanopia people can't tell the difference between Local+Stage.
#AD1818
suggested by @gkffzs also has the same issue.
I am testing with https://davidmathlogic.com/colorblind/#%237B1DD3-%230057AD-%23486119-%23...
The colors are originally suggested are just a bit better on this aspect:
Here is the link to the comparison tool: https://davidmathlogic.com/colorblind/#%234A0080-%23005B94-%2359590D-%23...
The colors that were used up to now had no such problem:
but they did suffer from low contrast scores against white... (comparison: https://davidmathlogic.com/colorblind/#%234A0080-%231E90FF-%23DAA520-%23...)
So, the latest commit solves the contrast issue, but adds other issues.
I'd suggest we change them, either in this or make a new one and address color-blindness there.
Closing this as it for Drupal 7.
@gkffzs adding another environment type ('lo', 'dd') should be a different task and not part of this one.
Here I am only trying to make sure that the current codebase is a11y-compliant
MR !6 doesn't apply properly (patching via composer). MR !4 does
vensires → credited bserem → .
Uploading new patch for current version of JS file for those who need it.
We need to think if this has any security implications. If a user with permissions to edit the message adds malicious scripts?
There need to be some checks if it is not just text anymore.
Logo added
New functionality added, some areas also got improved down the line.
A new release will happen soon
This is now merged, please use dev version of the module until a new release is made
Thanks a lot for this, and for Drupal.theme()
bserem → changed the visibility of the branch 3522968-add-option-to to hidden.
bserem → changed the visibility of the branch delete_all_node_feedback to active.
bserem → changed the visibility of the branch delete_all_node_feedback to hidden.
bserem → created an issue.
bserem → created an issue.
The MR worked fine in my tests.
I'd love to see trash use core Views, that would allow sorting, filters and full customization. Until then, this gets the job done.
bserem → changed the visibility of the branch 3521710-use-accessible-colors to active.
bserem → changed the visibility of the branch 3521710-use-accessible-colors to hidden.
bserem → changed the visibility of the branch 3521710-use-accessible-colors to hidden.
This now merged, more work is required
Issue has no description and wrong status, closing
Also switched to the dev version because of this.
Maybe it's time to release a new version, the dev version seems to be the better choice right now.
Code review pass, all are looking ok.
Testing without the fix against current 4.0.x I couldn't upload a WebP logo.
Applying the fix I could upload a WebP logo and I could see it in the sidebar.
Approved.
Well done
checking
Testing this, I did get the empty space without the patch/MR applied. Applying the changes everything worked as expected.
The testing notes are useful for getting into the edge case of having an empty region. @anruether if you can describe what you do to come up with that region being empty then I can check further.
In any case, the MR is clean, well written and approved.
Well done all
checking
Can we get this merged please?
@tr that's the plan, it's a monthly thing. Do you want me to remove the tag?
Attaching patch for latest non-dev version (v2.0.2) for use on production site.
The MR is against the dev version.
@adrienliegmann you should update to Drupal 10.3.x or higher. Reverting the change seems like a step back.
Merging following the "looks perfect" review. Thanks both of you.
Should the need arise for further improvements we can open a new issue in the future.
Related 🐛 Layout builder fails to assign inline block access dependencies for the overrides section storage on entities with pending revisions Needs work
There is a patch on that thread that looks to be on the right track too
I believe we need to change the target branch to 11.1 or something. The commits are awfully wrong in Gitlab after the rebase.
It's been less than 10 commits, we are seeing things already merged in Core.
List of issues that we were looking at: https://www.drupal.org/project/issues/search?issue_tags=GreeceWinterSpri... →
vensires → credited bserem → .
PS, `field_items` class is introduced to single value fields with the work on the branch. Thinking about it too
LB related tests fixed, working on CKEditor ones (the ones we haven't solved in years)
In the meanwhile, I don't really like the naming conventions and some of the classes that we are introducing here
- field--multivalue-field -> field--multiple-value-field, or field--multiple which is what already exists in Core
- field--single-value-field -> as is, or field--single which is what already exists Core
- field--has-multiple-items
- field--has-single-item -> field--has-one-item
- field--items-count-X -> is this really needed? Do we care about something like that or do we just pollute the DOM?
Attached screenshot with before and after.
MR !10503 fixes the schema.
Nice find @eduardo