Multiple blocks on a page share settings

Created on 30 April 2020, about 5 years ago
Updated 6 March 2024, over 1 year ago

If you add the same block on a single page, all blocks change if you "change the settings of one block".
http://www.root.artwaves.de/sharex/30-04-20--11-56-53.jpg

Each block should have its own settings i guess as that makes blocks so powerful and reusable? What do you think.

🐛 Bug report
Status

Postponed: needs info

Version

1.0

Component

Code

Created by

🇩🇪Germany marcoka

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇪🇸Spain bmunslow

    The approach by @riyas_nr is to keep the static caching of the view and differentiate based upon the view name or display ID. It fixes the issue tot, although view name and display ID should BOTH match before returning the static object (since it's quite common to have views with different names but same display IDs, e.g. block_1, etc.).

    The attached patch improves on #9 by make sure both the view name and display ID match the static object or otherwise creating it from scratch.

    Important to bear in mind #3 though. IMHO removing static caching altogether would be best in this case, although patch #8 needs a re-roll...

  • First commit to issue fork.
  • Pipeline finished with Failed
    about 1 month ago
    Total: 314s
    #507879
  • 🇺🇸United States calebtr

    I agree that the static keyword is a problem here.

    In order for the same page to use the same view twice, we need the uncached object.

    Another way to duplicate this:

    1. make a view with two displays
    2. give each display distinct exposed filters
    3. create a content type with a viewsreference field that allows multiple values
    4. create content that references the two displays
    5. observe that the incorrect filter is available for the second value
  • 🇺🇸United States kmonahan

    Ran into an issue with the patch where I couldn't edit my viewsreference field once the exposed filters items was checked or add a new paragraph that used a viewsreference field to the page.

    The website encountered an unexpected error. Try again later.
    
    AssertionError: Cannot load the "view" entity with NULL ID. in assert() (line 261 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).

    Cause seems to be that when the `loadView()` method is called as part of the form field alter, since no view has been selected yet, view_id and display_name are NULL and so the `load()` of the view fails.

  • Pipeline finished with Success
    about 1 month ago
    Total: 147s
    #509534
  • 🇮🇹Italy pheudo

    I agree that the static in this context doesn't help a lot, there is not a real gain of performance using the caching of the view in that way.
    Even if I'm not sure that it resolves all the issues, especially if you have a view with exposed filters. I experienced strange behaviours.
    Anyway, I think that this PR could be mergable and it could also resolve the issue 3497737.

Production build 0.71.5 2024