Problem/Motivation

There are a lot of createBlockContentType() and createBlockContent() defined all over the place and this is not consistent with code reuse.

Proposed resolution

  • Centralize all createBlockContentType() and createBlockContent() methods in a new BlockContentCreationTrait.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

CommentFileSizeAuthor
#2 3046670-2.patch26.68 KBclaudiu.cristea

Issue fork drupal-3046670

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

claudiu.cristea created an issue. See original summary.

claudiu.cristea’s picture

Status: Active » Needs review
StatusFileSize
new26.68 KB

This patch decreases the locally test run from 9.0 to 1.8 seconds.

martin107’s picture

Status: Needs review » Reviewed & tested by the community

To my mind this looks like a good cleanup .. and makes things consistent.

Side note: after a visual scan of the patch

a) No extraneous changes.
b) All changes are implemented correctly.

larowlan’s picture

Status: Reviewed & tested by the community » Needs review
  1. +++ b/core/modules/block_content/tests/src/Functional/BlockContentTestBase.php
    @@ -54,62 +55,11 @@
    -  protected function createBlockContent($title = FALSE, $bundle = 'basic', $save = TRUE) {
    ...
    -  protected function createBlockContentType($label, $create_body = FALSE) {
    

    this is a base class so removing these is an api change, could we just translate them to use the trait logic and retain the signature, we'd have to use the trait methods with a different name of course

  2. +++ b/core/modules/block_content/tests/src/Functional/Views/BlockContentTestBase.php
    @@ -48,60 +48,4 @@ protected function setUp($import_test_views = TRUE) {
    -  protected function createBlockContent(array $settings = []) {
    ...
    -  protected function createBlockContentType(array $values = []) {
    

    same here

klausi’s picture

Status: Needs review » Needs work
Issue tags: +DevDaysTransylvania

Talked to alexpott and he agrees with larowlan to keep the base class backwards compatible. As I understand it:

* The new trait has different names for the methods. I suggest insertBlockContent() and insertBlockContentType(). Is that good?
* The base class imports the trait
* The base class keeps the old method implementation and its signature. The implementation simply forwards to the trait methods.
* Add a @deprecated + trigger_error() to the old methods on the base class saying the new method names
* Update all core code to use the new method names.
* Add a test case to the legacy tests that check that the trigger_error() works.

Quite a bit of work and I think we are going a bit too far with our backwards compatibility promise here. This is just a random test base class in a random module, I would be fine with the API break.

+++ b/core/modules/block_content/tests/src/Kernel/Views/FieldTypeTest.php
@@ -0,0 +1,62 @@
+    $view->preview();

Why are we using ->preview() here and not ->execute() as in the old test? Please add a comment.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Title: Convert FieldTypeTest into a Kernel test. Move block content creation methods in a trait » Move block content creation methods in a trait
Issue summary: View changes
Parent issue: #3041700: [META] Convert some tests into Kernel or Unit tests »
Related issues: +#3414259: Convert FieldTypeTest into a Kernel test

Converting FieldTypeTest was completed in 3414259. The remaining part here is to create a trait for the creation of blocks.

I am changing the title for that new goal and removing the parent.

quietone’s picture

Title: Move block content creation methods in a trait » Move block content creation methods to a trait

acbramley made their first commit to this issue’s fork.

acbramley’s picture

Status: Needs work » Needs review

Started this from scratch as much of the patch no longer applied. I've updated other tests that call something similar to createBlockContent with the trait where possible with aliases.

I've also added another optional $values parameter to createBlockContent to support tests which were passing these to their own functions, we can then deprecate the $title and $bundle params at a later date if required.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

This seems like a good refactor and have no objection to it as another sub-maintainer hat. Not sure if it needs a CR as a new test trait but we'll see!

catch made their first commit to this issue’s fork.

larowlan credited alexpott.

larowlan’s picture

Credits

  • larowlan committed 2bc52706 on 11.x
    Issue #3046670 by acbramley, claudiu.cristea, catch, larowlan, alexpott...
larowlan’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 11.x and published the change record.

Thanks all

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.