Create an interface to share the definition of the overridable methods on DefaultsSectionStorageInterface and LayoutEntityDisplayInterface

Created on 12 July 2018, over 6 years ago
Updated 27 March 2024, 8 months ago

Problem/Motivation

\Drupal\layout_builder\Entity\LayoutEntityDisplayInterface::isOverridable()
\Drupal\layout_builder\Entity\LayoutEntityDisplayInterface::setOverridable()
\Drupal\layout_builder\DefaultsSectionStorageInterface::isOverridable()
\Drupal\layout_builder\DefaultsSectionStorageInterface::setOverridable()

Proposed resolution

Make a shared OverridableInterface

Remaining tasks

User interface changes

API changes

Data model changes

πŸ“Œ Task
Status

Fixed

Version

10.3 ✨

Component
Layout builderΒ  β†’

Last updated about 12 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States tim.plunkett Philadelphia

Live updates comments and jobs are added and updated live.
  • Blocks-Layouts

    Blocks and Layouts Initiative. See the #2811175 Add layouts to Drupal issue.

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.

  • First commit to issue fork.
  • πŸ‡³πŸ‡ΏNew Zealand danielveza Brisbane, AU

    Opened a MR for this change

    • Adds a new Interface LayoutBuilderOverridableInterface
    • Adds this new interface to DefaultsSectionStorageInterface & LayoutEntityDisplayInterface
    • Removes the overridable functions from DefaultsSectionStorageInterface & LayoutEntityDisplayInterface as they're now part of the interface
  • Pipeline finished with Success
    10 months ago
    Total: 1232s
    #86537
  • Status changed to RTBC 10 months ago
  • πŸ‡¦πŸ‡ΊAustralia mstrelan

    This is straight forward and does as described. Only thing I'd say is we can just call it OverridableInterface instead of LayoutBuilderOverridableInterface as per the proposed resolution, but this is consistent with LayoutBuilderEnabledInterface so I'm not going to hold it up.

    I also wondered if we need a change record, but if you're implementing one of the existing interfaces you'll automatically be implementing the new interface already, so you don't need to declare the implementation in your class.

  • πŸ‡³πŸ‡ΏNew Zealand danielveza Brisbane, AU

    Only thing I'd say is we can just call it OverridableInterface instead of LayoutBuilderOverridableInterface as per the proposed resolution, but this is consistent with LayoutBuilderEnabledInterface

    Yup - I had the same thoughts while developing this. I figured keeping it consistent with LayoutBuilderEnabledInterface was the right call, but I don't feel strongly either way

  • Status changed to Needs work 9 months ago
  • πŸ‡³πŸ‡ΏNew Zealand quietone

    I'm triaging RTBC issues β†’ . I read the IS, the comments ant the MR. I didn't find any unanswered questions.

    Regarding the name, there are no existing interfaces in core using the word 'overridable' plus 'overridable' is not in the American English dictionaries recommended by Drupal.org, and it is in the list of misspelled words used by cspell. I think it we should conform to current patterns and change it.

    There are existing interfaces in core using the word 'override';

    $ find . -iname \*override\*interface\*  -not -path '*tests/*' -not -path '*vendor*'
    ./core/lib/Drupal/Core/Config/ConfigFactoryOverrideInterface.php
    ./core/lib/Drupal/Core/Menu/StaticMenuLinkOverridesInterface.php
    ./core/modules/layout_builder/src/OverridesSectionStorageInterface.php
    ./core/modules/language/src/Config/LanguageConfigFactoryOverrideInterface.php

    Will LayoutBuilderOverrideInterface convey the same meaning?

    Setting to NW for naming. At least, we should not be using, 'overridable'

  • πŸ‡¦πŸ‡ΊAustralia mstrelan

    In that case we need to rename isOverridable method to canBeOverridden. I'd have to disagree with this. We have things like Stringable, I think this is fine as is.

  • Status changed to RTBC 9 months ago
  • πŸ‡¦πŸ‡ΊAustralia acbramley

    The word already has precedent in the method name isOverridable so I'm not sure how it could be against cspell? It definitely is a word in the english language, do we need to expand the dictionary?

    Changing the semantics of this and having to do BC for changing the method name seems like unnecessary busy work.

  • πŸ‡¦πŸ‡ΊAustralia kim.pepper πŸ„β€β™‚οΈπŸ‡¦πŸ‡ΊSydney, Australia

    I agree with #19 and #20. There is a strong precedent in Symfony and the PHP language itself of appending the "-able" suffix to an interface name. I don't think it needs to be in the dictionary.

  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Agree that renaming the existing methods is out of scope here, we just want to add a shared interface to the hierarchy.

    Committed and pushed a99e0b5763 to 11.x and 277cf4a8bb to 10.3.x. Thanks!

    • longwave β†’ committed 277cf4a8 on 10.3.x
      Issue #2985362 by DanielVeza, tim.plunkett, mstrelan, quietone, kim....
  • Status changed to Fixed 8 months ago
    • longwave β†’ committed a99e0b57 on 11.x
      Issue #2985362 by DanielVeza, tim.plunkett, mstrelan, quietone, kim....
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024