dehacker → created an issue.
Same as #24 in 10.2, but I had to disable all filters in order to add styles.
After updating to Drupal 10.2.3 our site has fatal error WSOD from 'Layout Builder Blocks' module, which relies on this module. The fatal error points to a problem that module has with this module. Could this issue be compounding and breaking other modules?
Error from Layout builder blocks:
@param \Drupal\bootstrap_styles\StylesGroup\StylesGroupManager $styles_group_manager
dehacker → created an issue.
Applied patch #31 locally with ddev and was able to get the expected result. Also with #33.
However, build failed on Pantheon, due to upstream patch error in build for unknown reasons Pantheon was not able to help resolve.
Asking the maintainers of this module to fix that dependency problem to make this module Drupal 10 compatible.
dehacker → created an issue.
I would personally suggest remaining open to alternative solutions just in case we can come up with something else/blockquote>
What are the alternative solutions? Media has been out for over 8 years and Drupal still doesn't easily resize a Media image in the basic editor. We're about to lose a major client to another CMS due to lacking editor experience.
Agree w @smustrave on all points, especially with the idea that a contrib module for this feature would be suitable. When neither Media, or Media Image Tag solutions are overly opinionated, but can work modularly to suit a sites particular need, we get back to what Drupal does best.
Most use-cases I would be very happy to use a contrib module that enables this feature. Often, usage speaks to the need for core to then absorb some of these features in future release. I hope @Austin986 would consider this approach, as Drupal really needs more contributors with this kind of UX and dev skill.
Let me thank all of those who freely spend their time to handle enormous projects such as Media, being particularly difficult. I understand it is often a thankless task.
I've been building in Drupal since D6. The fact that we had more practical capability to resize images over ten years ago suggests that Media may be over-engineered and inflexible in certain instances. These are, however, very basic instances. Drupal is always compared to other CMSs for its editing capabilities, and having resizing and positioning as basic features is a must. This is why we often avoid using Media. It's a shame because we just want to provide editors with a repository of images to choose from, and perhaps add an image style upon insertion if desired.
Content Editors expect the ability to resize with handles. I've never encountered a use case that required the extended functionality of beyond what typically provides. Others may have, but this comes at a cost to the broader community. Drupal needs some flexibility within structured data to compete, especially when it comes to this use case. Maybe someday a more structured way to handle this will emerge, but living with this inflexibility is impractical for a basic editing experience.
That's my two cents. If I had the skills to contribute to such an achievement, I would be eager to contribute. But I can speak as a dedicated builder struggling to keep companies and sites moving forward due to this issue Again, thank you to the maintainers of Media and the general core architects for all the work put into Media.
Basic CSS is available for those who choose the option to make img responsive. We use .img-fluid for all of our images, which handles nearly all of our use cases. Not having the basic ability to resize a Media image cripples the editing experience in Drupal. We do not use media for this specific reason, and rely on the old upload image.
Editors demand to be able to resize images in the editor. Media caused an UX regression many years ago and was never fully addressed. This new img tag option is a major pain point relief. Thank you! Austin for stepping up to make Drupal more usable for editors.
+1 for this feature. Seems like a must for content editors. We will continue to use CKE5 image upload widget due to this lack of editor experience.
CK5 efforts are much appreciated on this, as it seems to be one of few contrib solutions to get columns in the body field.
Good find. I spent hours reconfiguring the custom html and twig email handler.
Unfortunately I was searching in the 6.x issues and did not find this until a better search through Google.
As SMTP is widely used, I suggest that this explanation surface easier in the Webform documentation regarding html formatting, as its pretty essential.
jurgenhaas → credited dehacker → .
jurgenhaas → credited dehacker → .
Thank you. Using latest versions. Content fields and Custom block are translatable.
I did experience some unexpected behavior with basic manual translation on my site earlier. Still investigating.
I notice at Block Layout -> Configure block -> Title is not translated.
Also, when in Spanish language switcher mode.
Using Translation tab Operations dropdown -> Update Automatic Translation option,
the Spanish translation only displays English translate.
xyz.lndo.site/es/block/3/auto-translate-form?destination=/es/node/3
I have been testing the combination of auto node and auto block modules on the same page.
The auto block does work to translate the block to Spanish with Google Translate v2 api.
I am seeing an intermittent problem with the auto node translating a new Spanish translation on some types. It also converts the English translation to Spanish, so both version are then in Spanish. Not sure if this behavior is related to the new module.
I have not tried this on a generic install but I am using an existing content type on a site with D9 core 9.5.1
Set content type:
Language Settings - Enable translation selected.
Edit existing node and select Auto Translation.
select: Spanish (new translation)
Result is all node content is now Spanish.
Log errors show:
php 8.1.10
Date Tuesday, February 14, 2023 - 14:16
Location http://xyz.lndo.site/
Referrer http://xyz.lndo.site/es
Message Warning: Undefined array key 1 in Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies() (line 67 of /app/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php)
#0 /app/web/core/includes/bootstrap.inc(347): _drupal_error_handler_real(2, 'Undefined array...', '/app/web/core/l...', 67)
#1 /app/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(67): _drupal_error_handler(2, 'Undefined array...', '/app/web/core/l...', 67)
#2 /app/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(70): Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies(Array, Array)
dehacker → created an issue.
Same experience here. Block styles are disabled and inline styles are selectable with Full HTML
Using CKEditor5. Drupal Core 9.5.2