Add context from Layouts to be passed into to Views blocks.

[smaiorana]

Views blocks currently don't allow context to be passed in from a Layout. The only way to accomplish this now is to extract context from the URL based on position. This is less than ideal because it forces the block to be locked to a specific path structure that is separate from the Layout configuration.

Drupal 7 had the option to choose a data source "From context" in a View block. This code exists in Backdrop but has been commented out with a TODO. Perhaps this should be revisited to add context handling for Views blocks.

Update (April 3, 2023): The latest pull request for this issue adds context support to views blocks associated with layouts. There has been many revisions made to this pull request to address concerns from this wonderful Backdrop community. Some of these revisions have addressed improvements, efficiency changes, updated coding standards, etc. As of today, this PR has passed all the validation checks except one that seems to be some kind of external issue with that particular check.

Update (April 11, 2023): The latest pull request for this issue includes automated testing and is awaiting review. All validation tests have successfully passed.

---

Advocate for this feature: @rbargerhuff

TRANSLATION UPDATE:

Changed strings:

• old (d7 views): Which type of context to use.
• new: Select which type of context to use that best matches the contextual filter.

Removed strings:

• Context is optional
• This context need not be present for the block to function. If you plan to use this, ensure that the contextual filter handler can handle empty values gracefully.

[smaiorana]

A potential solution to this is forthcoming. We'll submit a PR sometime next week.

[klonos]

Welcome to Backdrop @smaiorana and thanks for opening this issue and working on a PR. Please let us know if you happen to hit any blockers or need any assistance.

For quick (usually almost real-time) answers to things that don't necessarily need to be documented as part of an issue thread, perhaps also consider joining us on our Zulip chat: https://backdrop.zulipchat.com 😉

[rbargerhuff]

@smaiorana and I have made the changes needed and will be creating a pull-request within the hour.

[rbargerhuff]

The pull request is ready to be reviewed/tested.

In resolving this issue, @smaiorana and I made a couple of decisions concerning the existing context support that was carried over from Drupal. In the current version of Backdrop CMS, the context support is left intact but commented out, presumably so it could be re-integrated later.

Due to the way we added our functionality, Drupal's context support and our context support are no longer compatible. The incompatibility stems from the fact Backdrop CMS requires context to be specified in hook_block_info whereas Drupal's codebase does not.

We thought it made more sense to eliminate the old context code completely and replace it with a new "From layout" argument input type. This way the incompatibility prevents breaking existing Views carried over from Drupal during a Backdrop migration.

An important note regarding our PR is that the context support we added only works with types that implerment or extend the following classes:

• EntityLayoutContext
• LayoutStringContext

We understand that this may appear to be a limitation, but we believe it covers the vast majority of use cases.

[klonos]

Thanks @smaiorana and @rbargerhuff 🙏🏼

Can one of our @backdrop/core-committers please approve the workflow in the PR, so we can get the tests going?

[quicksketch]

Looks like @BWPanda already approved the workflow. I've also added @smaiorana and @rbargerhuff to the docs/organization team so they can edit and label issues. Welcome to the Backdrop project!

[quicksketch]

I took a quick look at the PR. Wow, it's surprisingly compact! That doesn't mean it was easy though, so thanks to you both for putting in the effort to figure it out! I'll need to spend some time to process what the PR is doing. @docwilmot has worked a lot on Layout and contexts in the past, maybe he can help review too?

Two things we need here:

• How do we test this new functionality manually? What steps should be taken?
• We'll also need to test this functionality through new automated tests.

[rbargerhuff]

Thank you everyone for your responses. We could use some guidance on setting up the automated testing that you require for this PR. The only reason we did not include some kind of automated testing is because the other argument-inputs do not have test cases EXCEPT the argument-input type "Fixed."

Information regarding manually testing this PR will be coming shortly.

Cheers!

[smaiorana]

Thanks everyone for your input on this issue!

Here are steps to test this functionality manually:

1. Create a new View called “Layout Context Test” and have it show "User accounts". Create a block from the view with a display format set to "Unformatted list" of "User accounts". Have it display only 1 item.
2. Within the view settings, add a contextual filter for “User account: Uid”.
3. Under block settings, click to edit the contextual filter input. Set “User account: Uid source” to “From layout” and set required context to “User”.
4. Save the view.
5. Add a new Layout called “Layout Context Test” and pick any layout template. Set the path to “context-test/%” and set the context of “Position 2: context-test/%" to "User”.
6. Add the block “View: Layout Context Test” to the content section of the layout. When configuring the block, set “User" to "User from path (position 2)” and save the layout.
7. Lastly, visit /context-test/1 and you should see your view appear with the information from User 1.

[docwilmot]

Had a quick look, and I think this looks good. I never even realised this functionality was commented out. Made a few comments on the PR. One immediate thought I had was the possibility of smoothing the match between the context types and the argument types: if you select for example contextual filter Content: NID, is there any way to limit the choice of required contexts in the Views block settings select list? It wouldn't really make sense to have the "source" for the NID be a String override or User for example. Haven't thought of how this could be done, but may be worth a thought.

We could use some guidance on setting up the automated testing that you require for this PR.

Did you mean ideas on how to write the tests or what to test?

[rbargerhuff]

One immediate thought I had was the possibility of smoothing the match between the context types and the argument types:

My colleague @smaiorana and I had the same exact thought but we were not sure how to go about implementing it.

It wouldn't really make sense to have the "source" for the NID be a String override or User for example.

We believe that String override should always be an option.

For example, there is a layout with 2 blocks. The first block is associated with a search form and requires context to be passed as String override. The search form can handle different entity types and searches on common properties.

Consequently, the layout must be configured to send the value as String override.

The second block, for example the View, would be configured to receive context as String override so that the search could behave properly.

We understand that this may be non-standard, however because String override passes the value verbatim, it does not hurt the user to make that an option and the view will work in either case.

Does this example make sense?

We could use some guidance on setting up the automated testing that you require for this PR.

Did you mean ideas on how to write the tests or what to test?

Our issue seems to be where to start. Is it appropriate for the view module to create layouts or vice versa? There are no existing tests for argument_input types other than Fixed available for us to reference.

[docwilmot]

We believe that String override should always be an option.

Just so I'm understanding you, in this image you've posted

it shows that the View requires a User UID and the block is being configured to expect that UID from the layout.

You could, I would agree, allow the user to select "string override" there, and set the layout path as for example mypath/% and configure in the layout the placeholder % as a "string override" but % would still have to be an integer value that maps to an existing UID for the View to work.

Also, if the View required a User UID, layout would then only make the block available if a USer context is provided, thus preventing confusion.

Finally, though, at the very least only User and String Override should be in the select list, not Node or File etc.

[docwilmot]

Our issue seems to be where to start. Is it appropriate for the view module to create layouts or vice versa? There are no existing tests for argument_input types other than Fixed available for us to reference.

Yes, the test would need to create a Views block with a required context, and test that it "works" in a layout that provides that context and doesnt work in one that doesnt provide that context. So the test should ideally need to create a layout to add contexts (fixed contexts, and/or relationship contexts and/or path contexts).

[smaiorana]

Just so I'm understanding you, in this image you've posted it shows that the View requires a User UID and the block is being configured to expect that UID from the layout.

You could, I would agree, allow the user to select "string override" there, and set the layout path as for example mypath/% and configure in the layout the placeholder % as a "string override" but % would still have to be an integer value that maps to an existing UID for the View to work.

Yes, this is the conclusion we reached as well.

Finally, though, at the very least only User and String Override should be in the select list, not Node or File etc.

We'll take a look later this week and see if we can figure out how to make this work.

[rbargerhuff]

@docwilmot We researched the idea where certain context types are not visible given the context chosen for the layout and this was not easy to implement.

First, in order to carry out what you asked for requires the definition for hook_layout_context_info to be changed to include an optional entity type. This must be specified for context types that will be used by the View. Without this definition change, there is no way to know what entity type corresponds to what context.

Second, there is no easy way to determine what context types should be available in the View. Meaning, if a contrib module introduces their own context, how do we determine if that context should be shown in the View or not?

We thought about hard-coding the contexts that are part of Backdrop Core, such as dashboard, that should be excluded from the View. However, there would be no way to exclude other irrelevant context types introduced by contrib modules.

So we gather there are 5 options available:

1. No limitation. We show the user every context type and we rely on the user to choose the correct context type for the view.
2. We display all entity contexts and the string override. This is our current PR.
3. We only display relevant/correct entity contexts plus the string override. This requires modifying the definition of the hook above.
4. We only display relevant/correct entity contexts plus all other contexts except the ones we exclude via hard-coding. This requires the modifiying the definition of the hook above.
5. Same as Option 4 but we allow contrib modules to manually exclude via hook implementation. Again, requires modifying the definition of the hook above.

We have a prototype of Option 4. Even though it requires a hook definition change, we see no reason for it to break existing Backdrop CMS instances.

We have the View limited to the following context types:

• Dashboard
• User
• String-passthrough

However we would like to note that it would require changes to existing documentation.

https://docs.backdropcms.org/api/backdrop/core%21modules%21layout%21layout.api.php/function/hook_layout_context_info/1

We are confident that we can complete any one of these options, however we do not know what the community would prefer.

[docwilmot]

Thanks for considering this so carefully. I must say I was mostly curious as to if this could be done, but I don't think it is a blocker in any way. Looking at your explanation above I agree it would be difficult especially with contrib creating any number of argument types and context types. Arguments and context are also such quite distinct concepts. I think for the sake of not bikeshedding, we should go ahead with option 2, and simply add some help text to the description of the Required context select list: instead of just "Which type of context to use", maybe a brief "warning" to suggest the context type should ideally match the View argument type?

[rbargerhuff]

It was our pleasure! When we left the office on Friday we presumed that you would ultimately decide on Option 2 given the amount of changes that other options would require. We will get together soon and release a new PR. Also, we appreciated learning about the term bikshedding. That was new to us!! :)

[rbargerhuff]

Okay. The PR has been updated. The changes suggested here by @docwilmot have been included in this latest commit.

[docwilmot]

Okay. The PR has been updated. The changes suggested here by @docwilmot have been included in this latest commit.

I didnt see https://github.com/backdrop/backdrop/pull/4373/files#r1129759787 implemented though?

[quicksketch]

With all the activity on this issue and it nearing functional completion, I think this is a great candidate for the 1.25.0 (May 15, 2023) release. To be tagged for 1.25.0 we need an issue advocate. @smaiorana or @rbargerhuff would either of you be willing to shepherd this to completion? You're already doing everything we want/hope from an issue advocate so this is largely a formality.

[rbargerhuff]

I or @smaiorana will happily be the issue advocate but we both need to be aware of the expectations of this title before we can commit. Due to our current jobs and limitations, we are both not in a position where we can attend weekly meetings going forward.

[klonos]

@rbargerhuff you are not required to attend the weekly meetings, so long as you make sure that there is an up-to-date status summary for this issue:

• An advocate would ideally be able to attend most of our weekly meetings to report on the status of the issue. If that is not possible, then a short update/summary of the status of the issue they are advocating for should be left in a in a dedicated section of the top post in the thread.

[rbargerhuff]

Okay I will be the advocate for this issue. I will keep this issue's status up-to-date. As of right now, this issue is awaiting automated testing. I am unable to locate the dedicated section that you are referring to. Thank you.

The PR has been updated. The changes suggested here by @docwilmot have been included in this latest commit.

[docwilmot]

Looks good, but awaiting tests. Can we get a core committer to approve so tests can run please?

[klonos]

Okay I will be the advocate for this issue. ... I am unable to locate the dedicated section that you are referring to.

It's the first comment in the issue. I've added you as an advocate 😉

[klonos]

There are some coding standards failures in the PR. Setting to NW.

[smaiorana]

There are some coding standards failures in the PR. Setting to NW.

Curious. Some of the coding standards that failed are part of the original 1.x branch. For example:

Check warning on line 228 in core/modules/layout/plugins/context/layout_context.inc - Type hint "array" missing for $router_map Check failure on line 228 in core/modules/layout/plugins/context/layout_context.inc - Visibility must be declared on method "setDataFromRouterMap"

We didn't change visibility or type hinting on either of those. Is this to be expected?

[rbargerhuff]

There are some coding standards failures in the PR. Setting to NW.

I hightly suggest that the powers that be take the time to make it clear to developers of Backdrop Core, that if and when they modify lines of code that do not adhere to the updated standards set by the Backdrop Community leaders, that they are responsible for bringing the existing code up to those standards. Both @smaiorana and myself were not aware.

All that being said, we submitted a PR that complies with the latest standards.

Cheers!

[bugfolder]

make it clear to developers of Backdrop Core, that if and when they modify lines of code that do not adhere to the updated standards set by the Backdrop Community leaders, that they are responsible for bringing the existing code up to those standards.

Yeah, that would be a good thing to mention in the docs. For a new bug-fixer, it's kind of a harsh surprise to get dinged for code issues that were already present! The addition of PHPCS testing was relatively recent, so all of us are experiencing this. We see the test fail, sigh, and go back and update the PR. But the first time it happens to you, it's "whoa, what's this?"

[bugfolder]

Documentation added:

https://docs.backdropcms.org/documentation/how-to-use-the-core-issue-queue#automated-tests

[rbargerhuff]

Okay I will be the advocate for this issue. ... I am unable to locate the dedicated section that you are referring to.

It's the first comment in the issue. I've added you as an advocate 😉

I am unable to edit the first comment since that comment's creator is my colleague :P

[smaiorana]

So we jumped the gun a bit and tried updating all the method declarations within layout_context.inc to be brought up-to-date with PHPCS standards (considering we touched a few lines in that file). But that caused other PHPCS errors. Let's see if this goes through. Worst case, we'll roll back and update only the lines we need to modify, but we figured we'd try to be helpful.

[klonos]

I am unable to edit the first comment since that comment's creator is my colleague :P

No worries @rbargerhuff, I have "superpowers" here, so I edited that on your behalf 😉 ...if you find yourselves not being able to edit the issue summary (because another person is the author), or add/remove issue labels and other metadata, then simply add a comment, and someone that can will do that for you.

So we jumped the gun a bit and tried updating all the ...

Thanks for doing that @smaiorana 🙏🏼 ...and as @bugfolder said, sorry about the less-than-ideal first PR experience - we've only added PHPCS recently, so all the code from previous years + everything we have inherited from D7 needs to be fixed. This will happen over time, and there eventually be less of these annoyances, or none at all.

[klonos]

Can one of our @backdrop/core-committers please approve the PR so that tests run again?

[ghost]

Done.

[klonos]

Thanks @BWPanda 🙏🏼

@smaiorana and @rbargerhuff there's failures with PHP version 5.6 (v7.4 and 8.1 tests are passing). Can you please look into it?

[smaiorana]

So we have a dilemma here. Our PR requires that we update the method signature for LayoutContext->setDataFromRouterMap by adding a new (optional) argument.

We need to update the following:

/**
 * Set the context data from the router item map.
 *
 * @param array $router_map
 *   A router item map array.
 */
function setDataFromRouterMap($router_map) {

to:

/**
 * Set the context data from the router item map.
 *
 * @param array $router_map
 *   A router item map array.
 * @param array $router_original_map
 *   (optional) A router item original map array.
 */
function setDataFromRouterMap($router_map, $router_original_map = array()) {

We have no reason to believe this change would break existing implementations of Backdrop or the LayoutContext class.

Here's the dilemma:

• When we update the signature above, PHPCS flags us for not using type hinting array on both $router_map and $router_original_map. When we add type hinting to the above method, it potentially breaks on PHP 5.6 because it expects any class extending LayoutContext to have the same exact signature. This means that any contrib modules could potentially break in PHP 5.6 if they happen to extend that method. So adding type hinting seems like a dead end.
• We considered removing the array type declarations completely from the @param tags so as not to get flagged for type hinting by PHPCS, but that results in another PHPCS flag, as type declarations are required in Backdrop 1.x. I suppose we could declare these arguments as mixed, but that would be inaccurate.
• The only other alternative we can think to do is remove the @param tags completely from the Doxygen comments, but this seems like a step backwards (removing recommended coding standards rather than enhancing them).

We are unsure of how to proceed and need some feedback regarding this change.

[smaiorana]

Sorry, I just had another thought. If we update the signature of LayoutContext->setDataFromRouterMap to add an optional variable, it'll break any class that already inherits that function anyway. So this might be a moot point. Would it be better for us to just create a new method with our preferred signature? We can do something like LayoutContext->setDataFromOriginalRouterMap that just runs what we need it to run. I think that would work, and no existing implementations of LayoutContext would break.

We're going to submit a PR with this change and roll back our "jump-the-gun" type hinting updates.

[smaiorana]

@rbargerhuff submitted a new PR for this issue.

I will submit to the community though that our dilemma in https://github.com/backdrop/backdrop-issues/issues/5995#issuecomment-1476389192 would potentially still occur if, for example, we had simply added explicit public visibility to the LayoutContext->setDataFromRouterMap method - a change that would itself conform to updated standards and not have been a breaking change (methods are public by default) but would nonetheless have caused PHPCS to flag in a way that would force us to revert the change and leave it as-is. It doesn't really matter to us, and there may be no way around it, but it does make it hard to bring existing code up-to-standard without getting flagged for things outside our control.

[docwilmot]

Would it be better for us to just create a new method with our preferred signature?

My original thought was similar. Perhaps deprecate setDataFromRouterMap () and add a setDataFromRouter() and just pass the whole router item; Could get both maps from that then. Contrib would still work, since we're not removing the old function.

[rbargerhuff]

Would it be better for us to just create a new method with our preferred signature?

My original thought was similar. Perhaps deprecate setDataFromRouterMap () and add a setDataFromRouter() and just pass the whole router item; Could get both maps from that then. Contrib would still work, since we're not removing the old function.

@smaiorana I updated the PR with @docwilmot's welcomed suggestion of deprecating the existing function. Hoping this level of change is accepted by the community.

/**
   * Set the context data from the router item map.
   *
   * @param array $router_map
   *   A router item map array.
   *
   * @deprecated Please use setDataFromRouter() instead.
   */
  function setDataFromRouterMap($router_map) {
    if (isset($this->position) && !empty($router_map[$this->position])) {
      // If the menu router set the data for a context object or a client did
      // so via hook_layout_load_by_router_item_alter(), we don't need to do
      // any setting here. But if $this->data is not an object, then it is
      // either a raw string that must be converted to an object by a load
      // callback, or it is a string pass-through.
      if (!is_object($this->data)) {
        // If clients replaced any layout with one whose placeholders are in a
        // new position, they need to have altered $context->position so that
        // it points to the right place in the router item to get the data
        // object.
        $context_data = $router_map[$this->position];
        // If the router item contains the context object in the right
        // position, then we can just set the data from that.
        if (is_object($context_data)) {
          $this->setData($context_data);
        }
        else {
          // If the context data was not an object, then we can try to set
          // it using the plugin's load callback. If there is no callback,
          // then it must be a string pass-through, so we leave it as is.
          $context_info = layout_get_context_info($this->plugin);

          // CHECK: the following 3 lines don't seem to be needed. By this point
          // of the page request all context data is already loaded onto
          // $router_item['map'].
          // if (isset($context_info['load callback'])) {
          //   $context_data = call_user_func_array($context_info['load callback'], array($router_item['original_map'][$this->position]));
          // }

          $this->setData($context_data);
        }
      }
    }
  }

  /**
   * Set the context data from the router item.
   *
   * @param array $router_item A router item
   */
  public function setDataFromRouter(array $router_item) {
    $router_map = $router_item['map'];

    if (isset($this->position) && !empty($router_map[$this->position])) {
      // If the menu router set the data for a context object or a client did
      // so via hook_layout_load_by_router_item_alter(), we don't need to do
      // any setting here. But if $this->data is not an object, then it is
      // either a raw string that must be converted to an object by a load
      // callback, or it is a string pass-through.
      if (!is_object($this->data)) {
        // If clients replaced any layout with one whose placeholders are in a
        // new position, they need to have altered $context->position so that
        // it points to the right place in the router item to get the data
        // object.
        $context_data = $router_map[$this->position];
        // If the router item contains the context object in the right
        // position, then we can just set the data from that.
        if (is_object($context_data)) {
          $this->setData($context_data);
        }
        else {
          // If the context data was not an object, then we can try to set
          // it using the plugin's load callback. If there is no callback,
          // then it must be a string pass-through, so we leave it as is.
          $context_info = layout_get_context_info($this->plugin);

          // CHECK: the following 3 lines don't seem to be needed. By this point
          // of the page request all context data is already loaded onto
          // $router_item['map'].
          // if (isset($context_info['load callback'])) {
          //   $context_data = call_user_func_array($context_info['load callback'], array($router_item['original_map'][$this->position]));
          // }

          $this->setData($context_data);
        }
      }

      // Set the raw argument in the context if router_original_map.
      $router_original_map = $router_item['original_map'];

      if (!empty($router_original_map[$this->position])) {
        $this->argument = $router_original_map[$this->position];
      }
    }
  }

[rbargerhuff]

We submitted an updated PR early this week. We want to make sure everything works as intended and that we resolved every PHPCS validation error associated with the previous PR.

Would someone please approve the PR so that tests run again? Thank you!

[rbargerhuff]

@smaiorana @bugfolder @quicksketch @jenlampton @docwilmot

Hello gang,

So getting this issue fully supported has been quite a task. Our latest PR failed the PHPCS checks and validation that have recently been set in place.

I have some things that I feel need to be expressed concerning this process and the hoops I've been jumping through.

Our latest PR failed because of strict standards being enforced by PHPCS. I would like those following this thread and those that I tagged to be aware of just what exactly failed.

Error: <error line="81" column="7" severity="error" message="Array indentation error, expected 4 spaces but found 6" source="Backdrop.Arrays.Array.ArrayIndentation"/>
Error: Array indentation error, expected 4 spaces but found 6

This was on almost every line of a function of the layout.module. Unfortunately, because the IDE we use, PhpStorm, interprets array concatenation as a binary operator, it managed to indent the body of the array further than PHPCS is allowing for. For example:

$items['admin/structure/layouts'] = array(
      'title' => 'Layouts',
      'description' => 'Create new landing pages or modify the layout of existing pages on your site.',
      'page callback' => 'layout_list_page',
      'type' => MENU_NORMAL_ITEM,
      'file' => 'layout.admin.inc',
    ) + $base;

This was reported to the PhpStorm bug tracker in 2015: https://youtrack.jetbrains.com/issue/WI-26512/Array-indentation-is-incorrect-when-concatenating-arrays-Drupal-coding-style

Unfortunately, if using PhpStorm, there is no fix for this issue and it is a non-issue depending on which way you lean with PhpStorm's interpretation.

Because there is no fix, the indentation that PHPCS expects would be lost if the file was ever reformatted to enforce Drupal's coding standards. So this work around was needed:

  $items['admin/structure/layouts'] = array(
    'title' => 'Layouts',
    'description' => 'Create new landing pages or modify the layout of existing pages on your site.',
    'page callback' => 'layout_list_page',
    'type' => MENU_NORMAL_ITEM,
    'file' => 'layout.admin.inc',
  );
  $items['admin/structure/layouts'] += $base;

Here are a few errors that failed related to the code below:

Error: <error line="300" column="11" severity="error" message="Line exceeds maximum limit of 120 characters; contains 138 characters" source="Backdrop.Files.LineLength.MaxExceeded"/>
Error: Line exceeds maximum limit of 120 characters; contains 138 characters
Error: <error line="300" column="11" severity="error" message="Comment indentation error, expected only 1 spaces" source="Backdrop.Commenting.InlineComment.SpacingBefore"/>
Error: Comment indentation error, expected only 1 spaces
Warning: <error line="301" column="11" severity="warning" message="There must be no blank line following an inline comment" source="Backdrop.Commenting.InlineComment.SpacingAfter"/>
Error: <error line="301" column="11" severity="error" message="Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses" source="Backdrop.Commenting.InlineComment.InvalidEndChar"/>
Error: Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses

These errors are because there is PHP code commented out and now PHPCS is checking if the lines follow the standards that comments that do not contain PHP code must adhere too.

          // If the context data was not an object, then we can try to set
          // it using the plugin's load callback. If there is no callback,
          // then it must be a string pass-through, so we leave it as is.
          $context_info = layout_get_context_info($this->plugin);

          // CHECK: the following 3 lines don't seem to be needed. By this point
          // of the page request all context data is already loaded onto
          // $router_item['map'].
          // if (isset($context_info['load callback'])) {
          //   $context_data = call_user_func_array($context_info['load callback'], array($router_item['original_map'][$this->position]));
          // }

          $this->setData($context_data);

Because of this check and enforcement, I removed the code in my upcoming PR because the following would not be good if the code was uncommented out.

          // CHECK: the following 3 lines don't seem to be needed. By this point
          // of the page request all context data is already loaded onto
          // $router_item['map'].
          // if (isset($context_info['load callback'])) {
          // $context_data = call_user_func_array($context_info['load callback'], array($router_item['original_map'][$this->position]));
          // }.

My colleague @smaiorana and I are in agreement that trying to enforce such strict standards on a codebase that was very loose in its standards is severly going to slow down the development process of Backdrop. Right now, there is no way to for the person that is submitting the pull request to run these validation checks without it being approved by someone with those privileges.

I really feel a discussion is needed concerning the realization of developers and contributors updating code that they were not responsible for, so that the PHPCS validation passes.

If at the least, please allow the owner of the PR request to execute these PHPCS checks.

[herbdool]

@rbargerhuff thank you for your feedback. It may be that we'll need to tweak this. Though I'm not most knowledgeable on this matter.

Though I do know that PHPCS annoyingly does a check on all commits that were merged after your PR was created. Even if those files don't appear in the PR. But it does look like you've got a bunch of files in your PR that probably shouldn't be there. I think you may need to rebase your branch from backdrop 1.x and do a force push. I'll state the steps here, though apologies if you already know.

From your local fork, add backdrop as a remote (if it's not already there). git remote add upstream git@github.com:backdrop/backdrop.git. Then git fetch upstream. And then from your branch for this issue rebase git rebase --pull upstream 1.x. And then finally force this: git push -f rbargerhuff 5995/views-layout-context-integration. Or something like that.

[herbdool]

I just noticed Drupal 10 added some new standards:

Drupal.Array.Array.ArrayClosingIndentation Drupal.Array.Array.ArrayIndentation Drupal.Commenting.FunctionComment.MissingReturnType

Maybe the first two are relevant to the issue raised here?

[rbargerhuff]

@rbargerhuff thank you for your feedback. It may be that we'll need to tweak this. Though I'm not most knowledgeable on this matter.

Though I do know that PHPCS annoyingly does a check on all commits that were merged after your PR was created. Even if those files don't appear in the PR. But it does look like you've got a bunch of files in your PR that probably shouldn't be there. I think you may need to rebase your branch from backdrop 1.x and do a force push. I'll state the steps here, though apologies if you already know.

From your local fork, add backdrop as a remote (if it's not already there). git remote add upstream git@github.com:backdrop/backdrop.git. Then git fetch upstream. And then from your branch for this issue rebase git rebase --pull upstream 1.x. And then finally force this: git push -f rbargerhuff 5995/views-layout-context-integration. Or something like that.

Thank you for your guidance. Unfortunately I had to start over from scratch as far as my branch is concerned. I really managed to make a mess up out of local fork. However, I realized what I did yesterday and now understand how to prevent it.

That all being said, thank you for your suggestions and your response. I look forward to other's weighing in on this.

Cheers!

[rbargerhuff]

Could someone please approve the PR so the validation tests would run? Thank you very much!!

[rbargerhuff]

Just committed an update to our PR. Sorry we are trying to get this PR updated so all the checks pass as expected.

Could someone please approve the PR so the validation tests would run? Thank you very much!!

[rbargerhuff]

Thank you. All the tests were successful except one test that is reporting the following:

Run shivammathur/setup-php@v2
/usr/bin/bash /home/runner/work/_actions/shivammathur/setup-php/v2/src/scripts/run.sh

==> Setup PHP
✗ PHP Could not setup PHP 5.6
Error: The process '/usr/bin/bash' failed with exit code 1

Can anyone offer assistance with this?

[rbargerhuff]

@klonos or anyone with "super powers" Could you please update the first comment of this issue with the following:

• Update: The latest pull request for this issue adds context support to views blocks associated with layouts. There has been many revisions made to this pull request to address concerns from this wonderful Backdrop community. Some of these revisions have addressed improvements, efficiency changes, updted coding standards, etc. As of today, this PR has passed all the validation checks except one that seems to be some kind of external issue with that particular check.

TODO: We are still working on the automated testing and we hope to have that ready by the end of the week.