I also had this issue. Just creating a view setting it to a monthly calendar and then adding the date as a contextual filter and it breaks. This could be a documentation issue as I don't see it anywhere described how to set this up. I get this error when trying to view the page with the block defined - \Drupal\calendar\Plugin\views\style\CalendarStyle: The calendar row plugin is required when using the calendar style, but it is missing.
Yeah sorry about the confusion. I discovered/remembered after a fair amount of troubleshooting that I had overwritten the twig template for the view in order to add some markup. So that was what was causing the issue on my part. Thanks and sorry for the confusion.
I think I found part of the problem. A newer commit - https://git.drupalcode.org/project/views_bootstrap/-/commit/cf14a0ac12fc... - seems to have reverted the twig file templates/views-bootstrap-grid.html.twig that was modified in the previous MR - https://git.drupalcode.org/project/views_bootstrap/-/commit/e2144b8546f1...
So I'll see if I can come up with a working MR based upon the latest branch.
Thanks for the quick response. I pulled the latest dev code and it was still providing me with the errors and not quite working as intended.
User error: "attributes" is an invalid render array key in Drupal\Core\Render\Element::children() (line 98 of core/lib/Drupal/Core/Render/Element.php).
And it isn't applying the row classes from Grid row custom class to the row div but instead it is now adding the row class to the top wrapper div that contains the view id vs. the next nested div (which is the row div).
Also now the columns aren't receiving the custom class from the Custom column class field under the bootstrap grid settings (which they were before this latest commit).
So I think additional work is needed. I'm not sure where the render array key errors is coming in but maybe attributes doesn't exist in the render key according to the error.
I'm trying this code and it doesn't appear to work to provide the class to the row. I'll be testing when I applied to a test server I get an error - User error: "attributes" is an invalid render array key in Drupal\Core\Render\Element::children() (line 98 of core/lib/Drupal/Core/Render/Element.php).
And it looks like the row class code is applied to the columns and the new form is also applied to the column.
I see it added Custom column class which is added to every column as one would want and what was missing from my contribution but Grid row custom class also gets applied to the individual column divs and not to the entire row as was the intended behavior that my MR added.
I'll tinker around with it further but thought I'd share my feedback thus far.
Also noticed that the dark.css line 665 #layout-builder-modal textarea,
- height: auto; causes the textarea to shrink to only 78px tall when viewing source with CKEditor 5 so I'll try to submit a patch to fix this as well.
I think that testing the sort is a good idea. I haven't written any tests for a Drupal core contribution yet but I'm willing to give it a shot.
In looking at the code it appears that web/core/modules/views/tests/src/Functional/Handler/FieldWebTest.php has a test for testing click sorting that could be used as the basis for a new test of this functionality.
Also I see web/core/modules/views/tests/src/FunctionalJavascript/ClickSortingAJAXTest.php which tests the same thing via AJAX.
In theory I think it would make sense to also test the functionality of sorting based upon the title (if it is enabled) and also based upon the uri (the default). I'm not sure how to mock this test up exactly but I'll be digging into other tests and reading the documentation to try to figure it out but any help or pointers in the right direction would be appreciated.
From a UI/UX perspective I would think that if a link field uses a title/display that would be the default sort chosen since that is what usually displays but that would require further changes to this code and probably views (beyond updating the description). I also don't know what sorting by the options would mean and if this even makes sense to include.
The patch in #27 was failing drupal coding standard tests so I've added a new one that should at least pass the issue it was failing on (a lack of a <?php tag.
Otherwise if this passes the automated tests it should be ready for review.
So I was able to get this to patch to apply. I realized I needed to set patch level to 2 as described here - https://www.drupal.org/docs/develop/using-composer/manage-dependencies#s... → in order to apply a patch to core using composer-patches.
With that working I do think it makes sense to alter the description to say Used by Format: Table rather than Used by Style: Table which I think was from a previous version of Views.
I've created a new patch based upon 11.x that makes this change as well, so if anyone can test and review it then I think we can change it to RTBC as @akhil_babu suggests. My change merely updates the description and is based otherwise entirely on the patch on #16
I attempted to apply this patch using composer and the file wasn't created.
When I manually created the file based upon the patch I could indeed click sortable and sort the table based upon the link.
But one issue I noticed is that it sorts based upon the URL rather than the display name which probably isn't ideal for everyone.
I'm also not sure if the best way to accomplish this fix is through using a hook_alter for views rather than fixing the links module directly, but that's going to require more research on my part to determine how other fields tell views they are sortable.
I did some sleuthing and for me the issue that is happening occurs due to the dark.css inside of the bootstrap_styles module at /modules/contrib/bootstrap_styles/css/themes/dark.css and line 375
#layout-builder-modal form {
color: #ffffff;
font-family: inherit;
}
Changing the theme for the bootstrap styles module to light vs. dark was the fix for me. I suppose this could also be overridden somewhere in the CSS.
Not sure if the bug/fix here doesn't involve fixing the CSS in the bootstrap styles module so that it doesn't target the CKEditor 5 form.
I tested this and it works. I'd recommend committing it.
The work around for this was to create a new view mode for the content and then select that view mode for the ones that weren't swipers. I'm not sure if this is caused by a bug in Drupal View's caching or if it's in swiper formatter at this point.
Ok, I'm no longer sure that this is a problem with the swiper_formatter or a problem with how Drupal caches full content nodes in the views cache. I realized that essentially the "cards" which are being rendered as a full node are getting wrapped in the slider or not wrapped in the slider based upon whether they have been rendered on a page. So far this is happening with different displays under the same view using different formatters.
Say view_1 which is a list of cards has A B C D rendered with the bootstrap_views_grid formatter - if I then load a page that has
a view with swiper_formatter (displayed with the cards) E D F G - D will be rendered without the swiper_slider as it was cached without it.
If I then loaded a grid which should be rendered without a swiper_slider after this that has C D E F G - E, F & G will still have the swiper_slider div included in their rendered values.
I'm going to see if I separate the displays using different formatters into different views if I still have the problem or if this is a workaround. Otherwise it seems like this might require digging deeper into drupal render caching than I had planned.
So I'm just providing an update, there appears to be an error in the way that the twig cache is interacting with swiper_formatter module.
Essentially these issues existed only in the render cache, by disabling Disables render cache, dynamic page cache, and page cache. on /admin/config/development/settings the issue is fixed.
Sometimes clearing the cache for the whole site fixes it as well but other errors seem to be introduced, so it seems like there is a bug here where the render array isn't always being generated with the right markup but it's still intermittent and I'm not sure what the exact cause is or where to dive deeper in order to troubleshoot it.
Ok so I figured out the issue is that in Views a row seems to be every column/item. Whereas in bootstrap a row is essentially a wrapper for a number of columns. So I just disabled the utilization of the built-in row class for the Bootstrap Grid and it appears to work and will allow you to utilize row-column classes to supercede the built-in columns.
The only reason I could think of not merging this is that it would remove the ability to apply classes to columns via the UI, but doing that would require overriding the built-in views code and language so that it says column vs. row because the terminology is confusing and contradictory.
Happy to have people review this.
robbt → created an issue. See original summary → .
My first MR attempt where I cherry picked code from the other issue above is not working yet. I'll have to dive deeper into the code to determine what further changes are necessary. I'll update here when it's ready for testing.
The additional components of row classes on patch #4 solve the issue reported here - https://www.drupal.org/project/views_bootstrap/issues/3324207 🐛 Row class added to all columns Active for 5.5.x -
Also I tested this and it applied on 5.5.x but I'm not really sure that changing the grids works correctly. I think that it would make sense to take the additional code jienckebd provided and make it into a patch that could solve the other issue. I may put together a patch if I get a chance.
I think that a better way to make columns more responsive would be to support - Row Columns - see https://getbootstrap.com/docs/5.3/layout/grid/#row-columns
It was evidently introduced into Bootstrap with version 4.4 - https://blog.getbootstrap.com/2019/11/26/bootstrap-4-4-0/
This is a lot cleaner in my mind for Views since it allows you to set the number of columns for each breakpoint while also providing a default aka mobile breakpoint of 1. This is what I've been using for cards - class="row row-cols-1 row-cols-md-3 row-cols-lg-5" - this would be impossible to implement with the current grid options because everything has to be divisible by 12.
Also this should in theory work pretty well with views since all of the items will likely be of uniform width and so relying upon the row to set the number of columns is cleaner in my opinion.
I'm not sure if this would be the best approach for the 5.4.x branch as I'm not sure if we want to impose a requirement to use 4.4.x and above but I do think it would make sense to roll out this approach for 5.5.x
In the meantime with the row class fix patched in this approach can be done via applying a row class which is nice.
I can confirm that this indeed is a problem with the current 5.5.alpha code.
I found that applying the patch to allow the customization of the number of columns here - https://www.drupal.org/project/views_bootstrap/issues/3120960 → fixed this problem.
I haven't delved deeper into why yet.
I realized that the approach I have taken utilizes row columns to make the grid responsive rather than changing the width of the individual columns and the overall container.
I'll try to compare the code with the patch and the default code and see if I can provide a simpler patch to fix this behavior but wanted to share my findings.
I agree that this issue should probably be closed. Any good code should be merged with the 5.5.x (currently alpha) and individual issues should be opened up for specific functionality that is lacking.
This could be utilized as a meta-issue tracking specific features that need to be modified for Bootstrap 5 compatibility but I think logically that specific patches and MR would be best done in separate issues for specific features so that they can be better tracked and tested.
I am interested in contributing code to get the Bootstrap 5 branch working as that is what is useful for the work I am doing and I think this is a pretty useful module in general so I'm interested in hearing what the maintainers think.
I was able to get this working but I ran into a weird bug that it took a lot of troubleshooting to figure out.
In my use case their should be one slidePerView by default but when I set slidesPerView: 1 it would break the responsiveness. I tried digging into the code but couldn't determine what was causing this.
If I changed my default config to slidesPerView: auto it worked and the slides were responsive above the breakpoints and I still got the 1 slide on mobile that I was looking for.
Just wanted to share this in case anyone else was running into a similar problem.
I'd love for this functionality to be added to the module but I can imagine that it isn't a super easy task as it would require making the form somewhat dynamic to be able to add new breakpoints but I could also see having a number of predefined breakpoints that could be enabled and changed via the form would be another option.
Here is a simple patch that adds the option to slidesPerGroup - might be worth adding slidesPerGroupAuto and hiding this option unless SlidesPerView is larger than 1 but as a simple way to add the option this seems to work.
Here is my suggested fix as a patch. I limited the max-height of the drop down to half of the window height and/or height of the number of elements.
robbt → created an issue.
I am not sure, that was the release I started using it with. For what it's worth I think that only a few libraries from boostraps javascript were being loaded by my Radix theme. I didn't look into the code to see what specifically is checked by this module but if it's checking for the whole library then that could have been the issue.
I just wanted to share my issue so that it is out there in case someone else runs into it and is scratching their head.
So the site has been running fine with open_basedir set. I did not set the file_private_path and the public path is just sites/default/files
It appears to want to check the directory above the directory where composer.json etc. is installed.
I asked about this on the #d10-readiness slack channel. It would be a simple fix, hoping the maintainers can chime in and patch this or otherwise explain their rational for not putting out a D10 compatible version. I suspect they're just busy and hopefully will become aware of this and make the D10 release.
Has anyone worked on this for the 3.0.1 version ? In looking at the code it appears that the language variables are hard-coded in each of the javascript files making adding this a big more complex.
I'm interested in determining the best way to replace this module with Media + responsive image styles. Relying upon inline images even after migrating from Drupal 7. I can't seem to find an easy way to convert existing inline images to media images. This module File to Media → provides a way to create media items from existing files but it doesn't in-turn replace the existing files with media tokens.
The media migration module → appears to be able to do this based upon this issue → . But I'm not sure how one would go about using a migration module like this for a site that has already been migrated to Drupal 9/10. Perhaps that is the best approach.
The way that makes the most sense to me would be to do the conversion inside of CKEditor 4/5 where you could edit a text area such as the Body field containing inline images and select the images and click "convert to media" and it would convert them into media. Going in and editing the HTML or attempting to delete the image and then insert it again as a media would be somewhat painful for large sites but it is the only apparent solution I've found while searching for a solution for existing sites.
Thanks for reporting this I have ran into the same issue and just discovered why this was occurring.
I think that it would be helpful to include some information on this page explaining to developers how they can override the templates for specific view modes - such as how to override a new display mode called card could be overridden by creating node--card.html.twig to override the card view. Without this knowledge the ability to select which fields you want to display has a limited impact upon customizing a specific display view mode. Does this sound like a reasonable addition to this page or is it specifically geared towards only site builders ?
It looks like this PR from the CKEditor5 team has this issue fixed as of 5 days ago - https://github.com/ckeditor/ckeditor5/pull/14406 - I haven't tested the latest version and I'm not sure if the latest version of CKEditor5 will now be bundled with Drupal or if something else needs to happen, but I thought I'd bring it to the attention of everyone here that we may be able to proceed with a solid fix for this.
I looked at this at the DrupalCon usability review event and I don't think there has been an agreed upon solution even if everyone recognizes that this is a usability issue with Layout Builder.
My suggestion would be to differentiate between Content Fields and Content Metadata Fields
This seems like a cleaner distinction than hiding certain fields under "More" which was rejected as a solution.
I think if we differentiated them into Content Fields and Content Metadata Fields
Content Fields
Body
Image
Title
Content Metadata Fields
Authored by
Authored on
Changed
Comments
Comments
Content type
Default revision
Default translation
ID
Language
Links
Menu link
Promoted to front page
Published
Revision create time
Revision ID
Revision log message
Revision translation affected
Revision user
Sticky at top of lists
Tags
Maybe Tags and Comments and Links could be considered Content fields vs. Metadata but certainly most of these aren't typical things that someone would want add to a layout display and so hiding them would reduce cognitive load and overwhelm that was identified by testing.
I think that this could definitely be improved because using View Mode for content displays is easy to confuse with the Views module. It also makes it harder for people to find documentation for how to use custom view modes because of the language similarity in terms of search.
On the main admin page we have Display modes
Configure what displays are available for your content and forms.
So we utilize the term content on the top link but inside it shows
Form modes
Manage custom form modes.
View modes
Manage custom view modes.
Which requires a leap of logic to go from content to View Modes
The more consistent terminology I'd suggest would be to change the language to
Form Display modes - Manage custom form display modes
and
Content Display modes
Manage custom display modes for content.
The other issue is that if someone isn't completely familiar with Drupal there is no obvious way to utilize the display modes once they're created. Instead you have to know that you have to go to Admin -> Content Types -> Select a Content Type on the list -> Manage Fields then scroll to the Manage display tab or click the drop down and select Manage Display and then expand the Custom Display settings and you can get a checkbox for the various view modes.
Then all the UI provides is an ability to select different fields that could be displayed and you still I would assume need to create a custom twig template for this view mode (or use a module like display mode) if you want to customize how it's displayed. As far as I can find there is no documentation for how to do this on Drupal.org -> https://www.drupal.org/docs/drupal-apis/entity-api/display-modes-view-mo... →
Display and View are synonymous to someone who doesn't know Drupal where as View and Views are two core Drupal concepts and it is very easy for someone to get the two confused if they're searching documentation.
There are very few Custom Form Display Modes whereas a lot of View Modes are provided by default.
So I think that even as #18 suggests that there is a problem with showing Display Modes and then Form Display Modes and View Display Modes - just substituting either Content Display modes or just having the default Display Mode be content and then Form be a specialized type of Display mode does not seem like a problem to me.
The biggest challenge at this point would be confusion from eliminating "view modes" and using "display modes" instead for existing developers but I think that lowering the cognitive load and overloading of the word view would be worth it.