It seems that this is the Site e-mail adres in the 2.x version
You can find this under /admin/config/system/site-information/ -> E-mail.
$default_from_email = \Drupal::config('system.site')->get('mail');
webform_email_reply/src/Form/WebformEmailReplyForm.php
Apparently the merge request was at the wrong branch...
Fixed this issue at the 2.0 branch.
ok then let's set focus to #20.
Hide all other files...
Added merge request
Martijn de Wit → created an issue.
image styles have a convert task to create a different file format. That is Drupal Core functionality.
Did you use other modules as well? Such as Image Api or other contributed modules?
And is the image style working in just plain Drupal?
To much unknown to reproduce the issue.
Please share some more information about your situation. Now it is not clear it is a bug or something is missing in the configuration or caused by an other module or custom code... etc....
Hiding all old patches
Resolved merge conflicts after 📌 Convert FieldFormatter plugin discovery to attributes Active was committed.
This is already in 10.2 @abelass
See: https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... → Why it is : "catch committed bcaa369c on 11.x"
Feature plans: Make this module Drupal 10 proof.
The field group module → is already offering such "feature". More kind of a work around because things are not wel managed in core.
The issue ticket where that was developed:
#2652642: Allow to position the group in the advanced (sidebar) column →
Hope this ads some extra info / context.
Great to see some fresh conversations are there.
I would like to take maintainer-ship off this module, if possible.
Does the 🌱 [Plan] Improve field creation experience Active fix this issue concerns?
it's the X its self that is not white, but it should always be when a black background color is used as circle.
see https://about.twitter.com/en/who-we-are/brand-toolkit
It is strange that this module is not using the original brand colors on all icons.
Same with Linkedin and Facebook. the F should be always white I guess.
(https://about.meta.com/brand/resources/facebook/logo/)
Maybe something for a flow-up to make other the logo's as they should be.
It was submitted in ✨ Add support for "Search API (tags based)" caching in Views Fixed on the 2.x branch
@camslice did you try the https://www.drupal.org/project/twig_field_value → module?
so it should be fixed in #2901148: Double "Message" wizard naming in views for message entity → for anyone wondering.
Thank you @samir_shukla, indeed this request needs more info.
Browser version. Drupal version. Other libraries when used.
Some screenshots of the browser console with error's
thank you for the help artemboiko. Renaming it to 10.2.x will make things clearer.
Drupal V 10.3 will be branched from 11.x. I don't this will land in 10.2.x because of the size and changes.
So I think all effort should be at the merge request for the 11.x branch.
I think we need al lot of people testing this, maybe a sign off from a (sub)core maintainer ?
We are developing the new version at the 3.x branch.
PHP part is roughly done. JS part has to be done.
@manojbisht_drupal please use the merge request.
And if you need a patch, everyone can download a diff/patch from gitlab and load it local with composer.
(hide patches to get focus on merge request.)
Martijn de Wit → changed the visibility of the branch 2546212-entity-viewform-mode to hidden.
Martijn de Wit → changed the visibility of the branch 11.x to hidden.
Why using the patch from #48?
There is a merge request that is far more recent? containing solution after several discussions with good points ..
It is the new Drupal core branching:
https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... →
Drupal 10.2 is released
xmacinfo did you already try the new theme/template generator in Drupal ?
Martijn de Wit → created an issue.
Realy like this feature.
Patch works as advertised.
Only asking my self if this could be done with permission. Because there are different permission for for voting up or voting down. Would make more sense to me to use those, then an extra option.
✨ Add Media revision UI Fixed is committed to core 10.2 that will be released end this year
The fact that no one is responding to your question doesn't mean the module is not maintained anymore.
To start with, if you want someone to help you, please add a proper test path.
Maybe some screenshots or a short video of your configuration.
Reading your question; is resulting in a lot of other questions.
- How did you configure the node display settings.
- how did you configure the field display settings.
- what kind of drupal theme are you using
- Are you using the repsonsive image module
- How did you configure the image styles.
- etc..
set to needs review, because there is a patch / merge request.
Hide patch in favour for merge request
set to needs review because there is a patch
and remove assignee
ran into this issue. Patch seems to fix te problem.
Maybe some extra white space between these two fields:
I would opt in for option 3 from #4
Funny fact: If you enable Field Layout (core) module, option 3 is working out of the box.
Agree lets discus it further at ✨ Allow node/entity to display title/label field as normal Needs work
yes I meant content.title
. sorry for the confusing.
I didn't check this recently, will try to do it this week and come back at it.
Seems we have to rewrite a part of the module and create an upgrade path.
Ran into this problem during a project. Where we use the JSON API to unlock Drupal fields to a decoupled front end.
After installing the patch we get values back and the error message regarding sterilization is gone.
Our error message:
TypeError: Drupal\serialization\Normalizer\PrimitiveDataNormalizer::normalize(): Return value must be of type ArrayObject|array|string|int|float|bool|null, DateInterval returned in Drupal\serialization\Normalizer\PrimitiveDataNormalizer->normalize()
Core patch is committed 🐛 hook_image_style_flush doesn't get the $path passed to Drupal\image\Entity\ImageStyle::flush() method Fixed
Will check this in coming weeks.
This issue is fixed in 📌 Automated Drupal 10 compatibility fixes Fixed
@Ajeet
You changed
if (strpos($form_key, '#') == 0) {
into
if (strpos($form_key, '#') === 0) {
But your new patch is also changing the document/patch structure with extra spaces etc.
Please provide an inter-div so the new patch can easily be reviewed.
@damien
There is also a discussion here: 📌 Add image preload option to help boost actual and perceived performance Needs work on adding extra options to this list.
It was already in 10.1 right? see https://www.drupal.org/project/drupal/issues/3222107#comment-15007055 🐛 Library order asset weights do not work properly when a large number of javascript files is loaded between two jQuery UI libraries Fixed
Made a structure :)
Missed the opportunity to make subgroups. Used to al contrib modules we have in sites, so had the feeling I missed some menu links
Don't understand why the last one fails.
The same logic for testing a logo is not failing
$theme_installer->install(['test_theme']);
\Drupal::configFactory()
->getEditable('system.theme')
->set('default', 'test_theme')
->save();
$theme = $theme_handler->getTheme('test_theme');
drupal_static_reset('theme_get_setting');
// Tests logo set in test_theme.info.yml.
$expected = '/' . $theme->getPath() . '/images/logo2.svg';
$this->assertEquals($expected, theme_get_setting('logo.url', 'test_theme'));
Claro also doesn't have a favicon in its theme root 🙈 So I will use Olivero for that case. Rest of test cases still uses Stark.
@anpolimus can you create a new issue ticket as follow up ?
unassigning this, because there is no response (yet). and others already worked on it.
Tried to debug the latest version and get it working on [site]/media/add/image, but there is still a lot to do.
Test is failing because the Stark theme itself has no favicon.ico.
3 options to solve this.
- Use an other core theme for this test, (only Olivero has a favicon)
- Add a favicon to the Stark theme.
- Add a favicon to a test theme and use that.
Added an issue fork. Used patch from 33.
Then I alter the test to be in sync with the tests used for the logo option test.
---
hiding patches
With the test now using stark
Last to do is making a change record like:
https://www.drupal.org/node/2939152 →
and when released adding to documentation:
https://www.drupal.org/docs/develop/theming-drupal/defining-a-theme-with... →
Bartik is no longer there. Using Olivero instead.
A yeah, now I get it :)
I have 2 image fields on my video entity. one named 'image' and one named 'thumbnail' from previous tests.
Sorry for the confusing post.
Then it works as advocated, so it was a good test :)
Testing the new image style feature.
A user has now 3 options within the poster field:
- None
- Thumbnail
- Image
As showed below the thumbnail option and the image option are equal. With both a user can select an image style. So I was wondering what is the difference?
@jmee if you experiencing any new problems. Please open a new ticket as follow up.
Sounds like a good addition!
Only thing that is left is a proper test to move this issue forward.
just a bold guess; could 🐛 hook_image_style_flush doesn't get the $path passed to Drupal\image\Entity\ImageStyle::flush() method Fixed be related to this?
All code after #11, doesn't allow an empty value.
This removes the 'arbitrary aspect ratio' feature. Don't know if this is a required feature for this functionality.
Unsetting the float is a neater solution, then adding extra styling.
Using patch #6
The bug in our case:
With the patch:
thnx!
We have tested this patch for over a month now and I agree with catch. without an image style it is not usable for content-editors.
For site builders the option list is getting really long now and with adding image style options inside this screen I think we need some extra structure like fieldsets/details to group some settings. (also used an other patch to add some other video settings)
Sounds like a steady plan. I think a lot of people are waiting on a 10.x stable release for this module.
np, thank you :)
Still the problem for [site]/media/add/image is not resolved #33
a ^10 is missing in the info file
Martijn de Wit → created an issue.
Saw a demo via Twitter. It looks very promising all. I think it up to the real editors if they gone use / love this new module.
Does the bot still works? l-)
Will this be the same functionality as provided by https://www.drupal.org/project/responsive_image_preload → ?