No configuration possible in UI for 301, 303, etc. HTTP responses

Sounds good.

Any developments on this front?

bump? I can help with testing & documentation if needs be. Used page manager extensively to do redirects in 7, would love to see this functionality!

I would also love to see this!

It seems odd that we can create a redirect but can't specify where it redirect to.

I wanna to save us!

Small fix for building redirect using current params.

Tested, redirect works, but there few issues:

1. When creating new variant with http_status_code using wizard, PHP notice appears about undefined redirect_location variable;
2. When creating new variant with http_status_code using wizard, and non redirect code chosen (404 etc.) - wizard doesn't go forward because of required redirect_location;
3. When redirecting path alias is not used.

Fix:

1. When creating new variant with http_status_code using wizard, PHP notice appears about undefined redirect_location variable;
2. When creating new variant with http_status_code using wizard, and non redirect code chosen (404 etc.) - wizard doesn't go forward because of required redirect_location;
3. When redirecting path alias is not used.

Update page_manager.schema: display_variant.plugin.http_status_code to accept redirect_location parameter.

@dstorozhuk please provide interdiff from #8 to make review easy https://www.drupal.org/documentation/git/interdiff

+++ b/src/Plugin/DisplayVariant/HttpStatusCodeDisplayVariant.php
@@ -35,10 +90,10 @@ class HttpStatusCodeDisplayVariant extends VariantBase {
-      '404' => $options['404'],
-      '403' => $options['403'],
-      '500' => $options['500'],
-    ] + $options;
+        '404' => $options['404'],
+        '403' => $options['403'],
+        '500' => $options['500'],
+      ] + $options;

no reason to change, see https://youtrack.jetbrains.com/issue/WI-26512

Fix the schema label for redirect_location property.
Add interdiff.

@dstorozhuk I see schema changed, what about supporting upgrade path?

There are new property added. Nothing changed, nothing removed.
@podarok what particular changes in upgrade path do you mean ?

I mean how the schema is going to get updated after module updated for existing site?
In our case we use http://dgo.to/confi to update configs within hook_update_N @dstorozhuk

Worked perfectly. Thanks. Our use case is a deprecated node whos content hasn't been fully migrated but we don't want shown. I applied the patch (clean), updated my page variant and added the path. No errors and works as expected.

As I don't believe I constitute a community I'm going to leave this as Needs Review :)

Works good on my side too

NW
- tests
- upgrade path (hook_update_N to add empty property to existing variants)

@andypost thanks for clear roadmap for that patch. I believe i can create the update path, i will be very appropriate for help with tests.

Add update path.

Strange, but I cant chose the page_manager 8.x-4.x-dev for testing. The patch can only apply to page_manager 8.x-4.x-dev, since 8.x-1.x-dev doesn't have function page_manager_update_8002().

#30 works for me on 8.x-4.0-beta2 version

#30 applied just fine on fresh pull of 8.x-4x branch. Works as expected as well.

Last patch needs fixes for doc-blocks for new functions, also some nits below

Also still require test coverage

1. +++ b/src/Plugin/DisplayVariant/HttpStatusCodeDisplayVariant.php
   @@ -20,7 +23,59 @@ use Symfony\Component\HttpKernel\Exception\HttpException;
   +    $this->aliasManager = \Drupal::service('path.alias_manager');
   

   It needs proper DI

2. +++ b/src/Plugin/DisplayVariant/HttpStatusCodeDisplayVariant.php
   @@ -69,19 +144,96 @@ class HttpStatusCodeDisplayVariant extends VariantBase {
   +      $response = new RedirectResponse($redirect_location, $status_code);
   

   this does not allow remote redirects, maybe use TrustedRedirectResponse...

3. +++ b/src/Plugin/DisplayVariant/HttpStatusCodeDisplayVariant.php
   @@ -69,19 +144,96 @@ class HttpStatusCodeDisplayVariant extends VariantBase {
   +  private function variableToString($var) {
   

   Better to make it protected

I am having the same problem, I think. I opened https://www.drupal.org/project/page_manager/issues/2932215#comment-12392787, but it looks like it may be a duplicate of this.

Whats the status? This seems to be core functionality for the module.

Applying the fixes suggested in #33 + some coding standard fixes

It seems like tests are failing because of https://www.drupal.org/project/page_manager/issues/2918564

thanks @piggito. What's the next step, simply waiting for that issue you linked to be resolved?

@xeM8VfDh I think we should focus on solving the linked issue first cause it is breaking Drupal CI tests for all issues in page_manager.

sounds reasonable to me @piggito. Hopefully that is resolved shortly, and this soon thereafter.

Looked good to me and passes tests. Fixed!