+1 for a D10/11 version. The problem this module solved is a real pain.
Thank you for your replies and excuse me for replying here with such a delay.
It is probably something that has to do with the environment I tested it and I understand that any note to that issue could be dealt with to the Github repo. I ll try to understand it better and post there.
For anyone who comes here with the same issue this is being resolved as part of core's navigation in issue 3480321 🐛 Second level menu items can't be reached if they have children Active .
Works fine for me! Resolves a very frustrating issue that I couldn't escape from since I upgraded to Gin Afdmin theme 4.x
I didn't manage to apply the patch (5.diff or other) via composer with Drupal 11.1.1, but I did it manually (incorporating the changes in 6e180912) and my view seems to work just fine. Fetches fields from the referencing node and filters using those fields.
I have been trying to solve this issue myself trying all the combinations between Admin tools, Gin Toolbar and the new Navigation.
The goal is to have those Extra Tools available (cron and clear caches mainly).
I ended injecting the following rule via asset injector.
.toolbar-menu__item--level-1 .toolbar-menu > .toolbar-menu__item--to-title {
display: flex;
}
This restores the first level as a separate entry below the button which works just fine for me.
I t will not restore the first links on the third level but it is something.
I had this issue today with image fields that use multi upload image filed widget.
"Warning: Undefined array key "display_field" in mfw_field_widget_value() (line 159 of /home/....../sites/all/modules/multiupload_filefield_widget/multiupload_filefield_widget.field.inc)."
The change in #2 fixed the issue for me.
Drupal 7.101, php 8.1. 29
Confirming the solution.
Please, please consider this seriously! I spent more than half a day trying to find out why roles with the proper perimissions were not allowed to create nodes!
There should definitely be a message somewhere!
I added the patch in #76 to D10.3.0 and got rid of the errors.
In my case the errors appeared in the admin/config/people/accounts/fields page which could not be saved any more.
I have a scenario where this feature would be useful: I have to create a content type for publication abstracts where there is a limit in the words that can be used.
As far as I understand only solution as it is not is to use
Field Validation →
.
Also updated to 10.3.0 today and I have white screens on the main theme and lots of entries of this error.
Well as I see in the following issues, what I was suspecting is the situation: the dependecies for the submodules should be added to the main module composer file.
https://www.drupal.org/project/linkback/issues/2959975 →
https://www.drupal.org/project/project_composer/issues/3304661
🌱
Change how modules and submodule dependencies are handled to have more consistent namepsaces [DRAFT].
Active
So there are two options as I understand:
1. either add the dependecies of the submodule in the main module's composer file
2. or spin of the submodule into a entirely separate module
I don't have experience with the matter but maybe the composer requirement has to go to the main composer.json because when requiring the taxonomy manager obviously composer isn't looking in subfolders.
Yes I can see the same notice under Taxonomy Merge Manager but it is obviously because of the dependency declared in
taxonomy_manager_merge.info.yml
name: 'Taxonomy Manager Merge'
description: 'Intergrate Merge Terms with Taxonomy Manager'
core_version_requirement: ^10
dependencies:
- taxonomy_manager:taxonomy_manager
- term_merge:term_merge
package: Taxonomy
type: module
I went on and
- required the 2 modules again via composer,
- uninstalled them via drupal
- and then removed them again via composer.
It is fine now but something is not handled correctly between 2.0.10 and 2.0.11 as I understand.
I had the same issue with Drupal 10.1.x and Media Directories and it has been resolved with #122.
I got to the same error today and #2 seems to have fixed it.
No errors and the images are being uploaded successfully.
Thanks for the patch!
@poker10
No, I was not at all sure about those changes. I was just trying to make the tests work.
So i am uploading a new patch with only:
1. the change in the definition of MAIL_LINE_ENDINGS in includes/mail.inc
2. and the change in modules/system/system.mail.inc
Reuploading the patch as the last one had a syntax error.
One more patch keeping the logic that distinguishes between PHP versions and uses CRLF only when PHP is 8 or 8+ or when on a Windows server.
The rest of the changes have been kept to a minimum but the result works for me on a couple PHP8 sites.
As far as I managed to understand the tests fail because of the drupal_html_to_text function that is found in the includes\mail.inc file.
But I also found lots of other places where LF line endings are being used.
And from what is stated here
https://www.drupal.org/project/drupal/issues/3270647
🐛
PhpMail : broken mail headers in PHP 8.0+ because of LF characters
Fixed
the line endings should be CRLF for PHP 8+
So in this patch I have tried to define line endings according to the php version and server software and I replaced all occurrences of LF with a variable $line_endings
My experience with code is relatively limited so I don't really know whether all those changes are needed and/or correct but I have tested these modifications at one Drupal 7.98 site and it seems to be working without any issues.
Patch with the proposed modifications.
And here is a patch containing both modifications (#13 + #16).
The modification as in patch #13 had resolved the problem for me but the issue resurfaced the last couple of weeks or so.
I just now discovered another place where the same modification resolves the issue again:
line 67 in system.mail.inc is now
$mail_headers = join("\n", $mimeheaders);
and it obviously ruins the messages.
This modification solved the problem again:
$mail_headers = join("\r\n", $mimeheaders);
I suppose if it is safe to have it universally as CRLF, this could be shortened to something like this:
define('MAIL_LINE_ENDINGS', "\r\n");
@rclemings I did the same thing as you as a quick solution with minimal editing.
And it worked for some system messages but not for webform messages for example.
I read in an old issue that LF ("\n) is what should be used in Linux systems and CRLF ("\r\n") was reserved only for windows servers.
I am not sure but maybe this has changed?
The old issue is this one
drupal_mail(), CRLF, and Windows →