Hi,
I confirm that it is fixed with the MR in the related issue.
Thanks!
Hi,
Thanks @jastraat for your work in this.
I confirm:
- I no more see the error message when saving the view
- I now have access to the additional fields set through the UI
grimreaper → created an issue.
Hi,
The module is expected to generate the robots.txt file dynamically by providing a route+controller for that.
The physical file robots.txt file at the root of the Drupal installation should be removed for the module to work as expected.
grimreaper → changed the visibility of the branch 3507681-10.1 to hidden.
Patch to cumulate changes from 📌 [D11.1] Remove ui_icons_backport dependency Active and 📌 Remove Layout Options dependency Active .
grimreaper → created an issue.
Thanks :)
There are plenty explanations and links to examples on the project page https://www.drupal.org/project/ui_icons →
https://project.pages.drupalcode.org/ui_icons/
https://www.drupal.org/docs/develop/drupal-apis/icon-api →
Using it in https://www.drupal.org/project/sobki_profile_bootstrap →
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
grimreaper → created an issue.
Currently I don't have a use case.
Just in general, I almost (in case I already did that) never put classes as internal. If people wants to override stuff, it is their responsibility to ensure the override still works.
If there is a method I absolutely don't want people to override, I mark it private.
Interface for public method where backward compatibility is checked.
For protected method, maintaining backward compatibility if possible, if not.
People have to use tools like PHPStan or something to scan their codebase and it will normally highlight problem.
Hi,
I had been able to reproduce the issue and confirm that the MR fixes it.
grimreaper → created an issue.
grimreaper → created an issue.
It works!
use Drupal\Component\Render\FormattableMarkup;
use Drupal\Component\Render\MarkupInterface;
use Drupal\Core\Theme\Icon\IconDefinition;
use Drupal\section_library\Controller\ChooseSectionFromLibraryController as ContribChooseSectionFromLibraryController;
use Drupal\section_library\Entity\SectionLibraryTemplateInterface;
/**
* Overrides ChooseSectionFromLibraryController.
*/
class ChooseSectionFromLibraryController extends ContribChooseSectionFromLibraryController {
/**
* {@inheritdoc}
*/
protected function getSectionLinkLabel(SectionLibraryTemplateInterface $section, string $default_path = '', string $image_style = ''): MarkupInterface|string {
$defaultMarkup = parent::getSectionLinkLabel($section, $default_path, $image_style);
if (!$section->hasField('field_icon')) {
return $defaultMarkup;
}
$iconField = $section->get('field_icon');
if ($iconField->isEmpty()) {
return $defaultMarkup;
}
$iconValue = $iconField->getValue();
if (!isset($iconValue[0]['target_id'])) {
return $defaultMarkup;
}
$icon_element = IconDefinition::getRenderable($iconValue[0]['target_id'], [
// Fontawesome.
'width' => '2em',
'height' => '2em',
// Bootstrap.
'size' => '2em',
]);
return new FormattableMarkup('<span class="text-center mb-3 section-library-link-img">@icon</span>@title', [
'@title' => $defaultMarkup,
'@icon' => $this->renderer->renderInIsolation($icon_element),
]);
}
}
grimreaper → created an issue.
MR updated with a cleanup proposal of the cloning logic.
Not tested, so if too risky, let's only keep the first commit to avoid fatal error with UI Icons.
I confirm that there is no need of update hook.
Ok, testing.
I don't think there is a need to clear cache, as dependency injection is done with a create method and not by a services.yml file.
Ok, even if I think it is rare that such image style is removed. I understand the dependency on the image style concern. And to avoid config nightmares.
grimreaper → created an issue.
@jastraat, thanks for the quick feedback.
Ok so no update for existing websites.
I understand that people can easily customize if they want but for example, by default media library view is using this image style. It is like ✨ Add menu link to section library Needs review or 📌 Bring back contextual links for admin views Active . Providing better default behavior to avoid people to change it on every project.
As you want. You can close the issue if you want.
Thanks!
Link to core issue added on project page.
I made a simple fix.
But I think after 🐛 Error after importing section/template that contains blocks with paragraphs without available source content Active will be merged, cloneReferencedEntities and cloneReferencedParagraphsEntities could be simplified.
On Section Library 1.2.2.
In app/modules/contrib/section_library/src/DeepCloningTrait.php:
protected function cloneReferencedEntities($entity) {
...
// The general rule for any entity.
if ($entity_field->getName() != 'type' && isset($value[0]['target_id'])) {
The problem is that UI Icons field https://git.drupalcode.org/project/ui_icons/-/blob/1.1.x/modules/ui_icon... has a target_id:
public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition): array {
$properties = [];
$properties['target_id'] = DataDefinition::create('string')
Without being an entity reference field.
So Section Library detection if a field is an entity reference field may be lurred into error.
Should a hook_update be made? Or no hook_update to not break potential existing websites customizations?
grimreaper → created an issue.
Thanks a lot for your work.
One or two minor review comments, so changing status to needs work.
I confirm that the current behavior is preserved.
I have not tested to override with a custom controller, I trust that it will work.
Hi,
Confirming that there is no problem with entity reference revisions field on node entity for example.
Fix with MR is ok with paragraphs.
Reproducing the bug.
I have not tested the fix yet.
I wonder if the problem also occurs more generally with any entity reference revision fields.
Hi,
I used the contact tab of aspilicious to contact him regarding this proposal.
Thanks,
I am ok to introduce a setting or even better if core support it directly.
Assigning the issue to not forget to update the project page.
Thanks :)
Hum, I think you can ask Rajab for a quick review. :)
@pdureau can you please confirm that you get the behavior and after applying the MR change it is ok?
Media library edit modal save correctly but does not close on save.
Same cause as 🐛 Incompatibility between Bootstrap 5 and Claro / Gin Toolbar Active , Claro CSS loaded in front theme.
Showing screenshots.
Need help with contextual link JS, how better to integrate.
Thanks for the quick reply.
"scoped": that's the word I was searching for, thanks :)
Thanks for the proposals, currently I have a limited bandwidth and occupied with higher priority issues, so for the moment it will stay like that.
I don't forget that you are ok with changes, so if needed I will open a follow up :)
Have a nice weekend too :)
Thanks for the feedback :)
I understand that it is not possible for the admin theme to provide by itself styling in front even for stuff we (can) consider admin.
That's also why the Gin Layout Builder module exists :p
But the problem with loading admin theme assets on the front theme is side effects. Or the admin theme should prepare assets for this usage. Example in the case of CSS prefixed with a selector (.my-modal .my-usual-selector) to avoid side effects.
Currently if I use a media library modal (with for example Layout Builder and a content block with a media field) with Core 11.1.2, Olivero, Claro, I got the following screenshot:
Not exactly like the result in admin theme unfortunately.
Next screenshot is the same situation but with Gin 4.0.4 and Gin Toolbar 2.0.0, also not in admin theme:
And I think that's normal, because some preprocess and/or Twig templates overrides are not in the front theme.
See the following screenshots with UI Suite Bootstrap 5.1.x (no more Gin Layout Builder, just Gin Toolbar):
And as soon as claro/media_library.theme library is loaded:
(Because both Claro and Bootstrap 5 (the framework) use the "icon-link" class, so...Boom)
So between all those side effects, I no more want to load assets from the admin theme in the front theme that's way too risky. And I am slowly getting out of maintaining Gin Layout Builder, I don't think it is technically feasible.
I spent last 2024 trimester to make the media library/offcanvas/modals in UI Suite Bootstrap nice by using Bootstrap elements directly so no more need of admin theme assets in front and no more need of core offcanvas styling.
Unfortunately, that's hard to think that each front theme needs to do the same work, but to avoid side effects I don't see how different it is possible to be done.
The issue can stay close, no problem.
Side note: now in Sobki Bootstrap, Gin is only on admin theme and using Gin Login. No more Gin Toolbar and Gin Layout Builder.
Good for me.
If you want to review and test with my changes.
When I tried to reinstall section_library, I got the following error:
Configuration objects (views.view.section_library) provided by section_library already exist in active configuration
The view had not been deleted when uninstalling the module.
Thanks for the work.
Testing and reviewing.
Agreed to close this issue.
grimreaper → created an issue.
Seeing directly with @laetitia_al, cannot reproduce.
Provide a default theming for autocomplete results.
Or maybe in USB we can override contextual links to use https://getbootstrap.com/docs/5.3/components/popovers/ to render it. And the direction should be automatic.
Thanks!
I will try to try-out that this weekend.
When clicking on the contextual links pen, it opens and you can scroll down.
This is a Core feature/behavior, nothing special done in Sobki.
I guess in Core, there should be a check in JS to open to the top instead of to the bottom, but would require to use an external library that handles that.
Hi,
+1 for having contextual links enabled by default too.
Nice!
Yes push.
I will not have time to work on that until this weekend, so you have the time :)
This is due to JS, for Field Group tabs, once JS is loaded it is executed to make proper tabs.
There is no existing issue on Field Group about that, so I am not sure what we can do about that.
We can change the field groups in manage form display to use something else than vertical tabs.
I am not in favor of splitting "section" and "template" into 2 bundles, the current structure is OK.
One of the content entity type from core that has no bundle is user. And it's equivalent of index is "admin/config/people/accounts" which is a global user account related settings form. So way more similar like the settings form you propose.
As mentioned in the MR comments, I had to have a route to attach the Field UI routes on. And currently, no better stuff than an empty controller. Maybe with an explanatory text.
So:
1 if you prefer let's move out of structure to go into Config > Content authoring (admin/config/content) as other Layout Builder related modules put their config entries into.
2 if agreed, I make the route change, cleanup the MR
3 I let you convert the empty controller into a settings form (or I can convert it into an empty settings form and give you the hand) because I am not sure what and how you want to save into config.
What do you think about that?
If using view mode is too risky, then yes, helping a website to override the link title easily will be a very nice first step.
Calling/overridding a service, with parameter the section library content entity is passed.
The problem occurred on Twig 3.16.0, but no more on Twig 3.19.0
grimreaper → created an issue.
grimreaper → created an issue. See original summary → .