How to to redirect a form to a certain node for anonymous users?
In a custom module, I have a form that is triggered by an option in a menu.
I'd want this form to be redirected automatically (without action of the user) to a certain node (/node/2) when the user is not authenticated.
In the public function buildForm(array $form, FormStateInterface $form_state) {
, I know how to not display the fields of the form for the anonymous user:
$oCurrentUser = Drupal::currentUser();
if ($oCurrentUser->isAnonymous()) {
} else {
some fields...
$form['submit'] = [
'#type' => 'submit',
'#value' => $this->t('Submit'),
];
return $form;
}
I guess that redirection might be done with $form_state->setRedirect('entity.node.canonical', ['node' => 2]);
but I don't know how to make it work...
Any idea?
8 forms
add a comment |
In a custom module, I have a form that is triggered by an option in a menu.
I'd want this form to be redirected automatically (without action of the user) to a certain node (/node/2) when the user is not authenticated.
In the public function buildForm(array $form, FormStateInterface $form_state) {
, I know how to not display the fields of the form for the anonymous user:
$oCurrentUser = Drupal::currentUser();
if ($oCurrentUser->isAnonymous()) {
} else {
some fields...
$form['submit'] = [
'#type' => 'submit',
'#value' => $this->t('Submit'),
];
return $form;
}
I guess that redirection might be done with $form_state->setRedirect('entity.node.canonical', ['node' => 2]);
but I don't know how to make it work...
Any idea?
8 forms
add a comment |
In a custom module, I have a form that is triggered by an option in a menu.
I'd want this form to be redirected automatically (without action of the user) to a certain node (/node/2) when the user is not authenticated.
In the public function buildForm(array $form, FormStateInterface $form_state) {
, I know how to not display the fields of the form for the anonymous user:
$oCurrentUser = Drupal::currentUser();
if ($oCurrentUser->isAnonymous()) {
} else {
some fields...
$form['submit'] = [
'#type' => 'submit',
'#value' => $this->t('Submit'),
];
return $form;
}
I guess that redirection might be done with $form_state->setRedirect('entity.node.canonical', ['node' => 2]);
but I don't know how to make it work...
Any idea?
8 forms
In a custom module, I have a form that is triggered by an option in a menu.
I'd want this form to be redirected automatically (without action of the user) to a certain node (/node/2) when the user is not authenticated.
In the public function buildForm(array $form, FormStateInterface $form_state) {
, I know how to not display the fields of the form for the anonymous user:
$oCurrentUser = Drupal::currentUser();
if ($oCurrentUser->isAnonymous()) {
} else {
some fields...
$form['submit'] = [
'#type' => 'submit',
'#value' => $this->t('Submit'),
];
return $form;
}
I guess that redirection might be done with $form_state->setRedirect('entity.node.canonical', ['node' => 2]);
but I don't know how to make it work...
Any idea?
8 forms
8 forms
asked 14 hours ago
gbmapogbmapo
369315
369315
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
In buildForm() you can return a redirect response the same way as in a controller:
public function buildForm(array $form, FormStateInterface $form_state) {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
// build $form for authenticated users
return $form;
}
Use $form_state->setRedirect()
if you want to redirect in a form submit handler.
1
Is there any core module that does that?FormInterface::buildForm()
is documented to return an array.
– kiamlaluno♦
13 hours ago
@kiamlaluno, FormBuilder::retrieveForm "... the Form API currently allows any form builder functions to return a response."
– 4k4
12 hours ago
@kiamlaluno, example ModulesListConfirmForm::buildForm
– 4k4
12 hours ago
add a comment |
The class implementing FormInterface
is allowed to return an instance of a class extending the Response
class, despite FormInterface::buildForm()
not documenting it. See what a comment in the FormBuilder::retrieveForm()
code says.
Exceptions should not be used for code flow control. However, the Form API currently allows any form builder functions to return a response.
This means that code similar to the following one would actually work.
public function buildForm(array $form, FormStateInterface $form_state) {
// Verify the currently logged in user is an anonymous user and redirect.
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
}
Although, since Do not allow form builder functions to return Response objects is open for Drupal 8.8.x, that code could not work anymore, in future.
A module that works also after the change described in that issue is implemented would:
- Associate a controller to the route, not a form builder
In the controller method associated with the route, redirect the anonymous users to the node page, or render the form for authenticated users
class RedirectOrFormController extends ControllerBase {
public function showForm() {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
return $this->formBuilder()->getForm('Drupal\locale\Form\TranslateEditForm');
}
}
Replace 'Drupal\locale\Form\TranslateEditForm'
with the fully qualified name of the form builder.
This is a good point, but this is the same forFormAjaxException
. I think if core succeeds to control the code flow of the Form API without exceptions (which is very unlikely to happen before Drupal 9), it wouldn't affect much of custom code.
– 4k4
8 hours ago
Actually, the patch for that issue removes the part handling an instance of a class extending theResponse
class and it forces form builders to return an array from theirbuildForm()
method.
– kiamlaluno♦
7 hours ago
This patch is from 2015 when core maintainers were more ambitious to remove exceptions for code flow control. We don't know what they will decide if this issue is picked up again and they might consider a replacement for redirecting in form builders directly.
– 4k4
7 hours ago
The point is not removing an exception. In fact, the code would still throw an exception, if that patch would be committed to Drupal core.
– kiamlaluno♦
6 hours ago
Why should the patch be committed after four years when there is no reason for it anymore since the introduction of EnforcedResponseException? There is of course the point "Exceptions should not be used for code flow control." If this is resolved the patch might be revisited, but probably in a different form and by having a solution to rewrite existing code if necessary.
– 4k4
5 hours ago
|
show 1 more comment
yes, you are right. you can redirect to the node using the code that you have mentioned. There is another way to set the redirection check the below code.
use the name space :
use SymfonyComponentHttpFoundationRedirectResponse;
$response = new RedirectResponse(node url);
$response->send();
exit(0);
I don't know what you are trying to achieve hope this code may help you.
1
exits should not be needed
– Kevin
10 hours ago
@Kevin is correct:exit()
should not be used.
– kiamlaluno♦
9 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "220"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdrupal.stackexchange.com%2fquestions%2f277594%2fhow-to-to-redirect-a-form-to-a-certain-node-for-anonymous-users%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
In buildForm() you can return a redirect response the same way as in a controller:
public function buildForm(array $form, FormStateInterface $form_state) {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
// build $form for authenticated users
return $form;
}
Use $form_state->setRedirect()
if you want to redirect in a form submit handler.
1
Is there any core module that does that?FormInterface::buildForm()
is documented to return an array.
– kiamlaluno♦
13 hours ago
@kiamlaluno, FormBuilder::retrieveForm "... the Form API currently allows any form builder functions to return a response."
– 4k4
12 hours ago
@kiamlaluno, example ModulesListConfirmForm::buildForm
– 4k4
12 hours ago
add a comment |
In buildForm() you can return a redirect response the same way as in a controller:
public function buildForm(array $form, FormStateInterface $form_state) {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
// build $form for authenticated users
return $form;
}
Use $form_state->setRedirect()
if you want to redirect in a form submit handler.
1
Is there any core module that does that?FormInterface::buildForm()
is documented to return an array.
– kiamlaluno♦
13 hours ago
@kiamlaluno, FormBuilder::retrieveForm "... the Form API currently allows any form builder functions to return a response."
– 4k4
12 hours ago
@kiamlaluno, example ModulesListConfirmForm::buildForm
– 4k4
12 hours ago
add a comment |
In buildForm() you can return a redirect response the same way as in a controller:
public function buildForm(array $form, FormStateInterface $form_state) {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
// build $form for authenticated users
return $form;
}
Use $form_state->setRedirect()
if you want to redirect in a form submit handler.
In buildForm() you can return a redirect response the same way as in a controller:
public function buildForm(array $form, FormStateInterface $form_state) {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
// build $form for authenticated users
return $form;
}
Use $form_state->setRedirect()
if you want to redirect in a form submit handler.
edited 13 hours ago
answered 13 hours ago
4k44k4
52.1k561104
52.1k561104
1
Is there any core module that does that?FormInterface::buildForm()
is documented to return an array.
– kiamlaluno♦
13 hours ago
@kiamlaluno, FormBuilder::retrieveForm "... the Form API currently allows any form builder functions to return a response."
– 4k4
12 hours ago
@kiamlaluno, example ModulesListConfirmForm::buildForm
– 4k4
12 hours ago
add a comment |
1
Is there any core module that does that?FormInterface::buildForm()
is documented to return an array.
– kiamlaluno♦
13 hours ago
@kiamlaluno, FormBuilder::retrieveForm "... the Form API currently allows any form builder functions to return a response."
– 4k4
12 hours ago
@kiamlaluno, example ModulesListConfirmForm::buildForm
– 4k4
12 hours ago
1
1
Is there any core module that does that?
FormInterface::buildForm()
is documented to return an array.– kiamlaluno♦
13 hours ago
Is there any core module that does that?
FormInterface::buildForm()
is documented to return an array.– kiamlaluno♦
13 hours ago
@kiamlaluno, FormBuilder::retrieveForm "... the Form API currently allows any form builder functions to return a response."
– 4k4
12 hours ago
@kiamlaluno, FormBuilder::retrieveForm "... the Form API currently allows any form builder functions to return a response."
– 4k4
12 hours ago
@kiamlaluno, example ModulesListConfirmForm::buildForm
– 4k4
12 hours ago
@kiamlaluno, example ModulesListConfirmForm::buildForm
– 4k4
12 hours ago
add a comment |
The class implementing FormInterface
is allowed to return an instance of a class extending the Response
class, despite FormInterface::buildForm()
not documenting it. See what a comment in the FormBuilder::retrieveForm()
code says.
Exceptions should not be used for code flow control. However, the Form API currently allows any form builder functions to return a response.
This means that code similar to the following one would actually work.
public function buildForm(array $form, FormStateInterface $form_state) {
// Verify the currently logged in user is an anonymous user and redirect.
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
}
Although, since Do not allow form builder functions to return Response objects is open for Drupal 8.8.x, that code could not work anymore, in future.
A module that works also after the change described in that issue is implemented would:
- Associate a controller to the route, not a form builder
In the controller method associated with the route, redirect the anonymous users to the node page, or render the form for authenticated users
class RedirectOrFormController extends ControllerBase {
public function showForm() {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
return $this->formBuilder()->getForm('Drupal\locale\Form\TranslateEditForm');
}
}
Replace 'Drupal\locale\Form\TranslateEditForm'
with the fully qualified name of the form builder.
This is a good point, but this is the same forFormAjaxException
. I think if core succeeds to control the code flow of the Form API without exceptions (which is very unlikely to happen before Drupal 9), it wouldn't affect much of custom code.
– 4k4
8 hours ago
Actually, the patch for that issue removes the part handling an instance of a class extending theResponse
class and it forces form builders to return an array from theirbuildForm()
method.
– kiamlaluno♦
7 hours ago
This patch is from 2015 when core maintainers were more ambitious to remove exceptions for code flow control. We don't know what they will decide if this issue is picked up again and they might consider a replacement for redirecting in form builders directly.
– 4k4
7 hours ago
The point is not removing an exception. In fact, the code would still throw an exception, if that patch would be committed to Drupal core.
– kiamlaluno♦
6 hours ago
Why should the patch be committed after four years when there is no reason for it anymore since the introduction of EnforcedResponseException? There is of course the point "Exceptions should not be used for code flow control." If this is resolved the patch might be revisited, but probably in a different form and by having a solution to rewrite existing code if necessary.
– 4k4
5 hours ago
|
show 1 more comment
The class implementing FormInterface
is allowed to return an instance of a class extending the Response
class, despite FormInterface::buildForm()
not documenting it. See what a comment in the FormBuilder::retrieveForm()
code says.
Exceptions should not be used for code flow control. However, the Form API currently allows any form builder functions to return a response.
This means that code similar to the following one would actually work.
public function buildForm(array $form, FormStateInterface $form_state) {
// Verify the currently logged in user is an anonymous user and redirect.
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
}
Although, since Do not allow form builder functions to return Response objects is open for Drupal 8.8.x, that code could not work anymore, in future.
A module that works also after the change described in that issue is implemented would:
- Associate a controller to the route, not a form builder
In the controller method associated with the route, redirect the anonymous users to the node page, or render the form for authenticated users
class RedirectOrFormController extends ControllerBase {
public function showForm() {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
return $this->formBuilder()->getForm('Drupal\locale\Form\TranslateEditForm');
}
}
Replace 'Drupal\locale\Form\TranslateEditForm'
with the fully qualified name of the form builder.
This is a good point, but this is the same forFormAjaxException
. I think if core succeeds to control the code flow of the Form API without exceptions (which is very unlikely to happen before Drupal 9), it wouldn't affect much of custom code.
– 4k4
8 hours ago
Actually, the patch for that issue removes the part handling an instance of a class extending theResponse
class and it forces form builders to return an array from theirbuildForm()
method.
– kiamlaluno♦
7 hours ago
This patch is from 2015 when core maintainers were more ambitious to remove exceptions for code flow control. We don't know what they will decide if this issue is picked up again and they might consider a replacement for redirecting in form builders directly.
– 4k4
7 hours ago
The point is not removing an exception. In fact, the code would still throw an exception, if that patch would be committed to Drupal core.
– kiamlaluno♦
6 hours ago
Why should the patch be committed after four years when there is no reason for it anymore since the introduction of EnforcedResponseException? There is of course the point "Exceptions should not be used for code flow control." If this is resolved the patch might be revisited, but probably in a different form and by having a solution to rewrite existing code if necessary.
– 4k4
5 hours ago
|
show 1 more comment
The class implementing FormInterface
is allowed to return an instance of a class extending the Response
class, despite FormInterface::buildForm()
not documenting it. See what a comment in the FormBuilder::retrieveForm()
code says.
Exceptions should not be used for code flow control. However, the Form API currently allows any form builder functions to return a response.
This means that code similar to the following one would actually work.
public function buildForm(array $form, FormStateInterface $form_state) {
// Verify the currently logged in user is an anonymous user and redirect.
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
}
Although, since Do not allow form builder functions to return Response objects is open for Drupal 8.8.x, that code could not work anymore, in future.
A module that works also after the change described in that issue is implemented would:
- Associate a controller to the route, not a form builder
In the controller method associated with the route, redirect the anonymous users to the node page, or render the form for authenticated users
class RedirectOrFormController extends ControllerBase {
public function showForm() {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
return $this->formBuilder()->getForm('Drupal\locale\Form\TranslateEditForm');
}
}
Replace 'Drupal\locale\Form\TranslateEditForm'
with the fully qualified name of the form builder.
The class implementing FormInterface
is allowed to return an instance of a class extending the Response
class, despite FormInterface::buildForm()
not documenting it. See what a comment in the FormBuilder::retrieveForm()
code says.
Exceptions should not be used for code flow control. However, the Form API currently allows any form builder functions to return a response.
This means that code similar to the following one would actually work.
public function buildForm(array $form, FormStateInterface $form_state) {
// Verify the currently logged in user is an anonymous user and redirect.
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
}
Although, since Do not allow form builder functions to return Response objects is open for Drupal 8.8.x, that code could not work anymore, in future.
A module that works also after the change described in that issue is implemented would:
- Associate a controller to the route, not a form builder
In the controller method associated with the route, redirect the anonymous users to the node page, or render the form for authenticated users
class RedirectOrFormController extends ControllerBase {
public function showForm() {
if ($this->currentUser()->isAnonymous()) {
return $this->redirect('entity.node.canonical', ['node' => 2]);
}
return $this->formBuilder()->getForm('Drupal\locale\Form\TranslateEditForm');
}
}
Replace 'Drupal\locale\Form\TranslateEditForm'
with the fully qualified name of the form builder.
edited 3 hours ago
answered 9 hours ago
kiamlaluno♦kiamlaluno
80.6k9132249
80.6k9132249
This is a good point, but this is the same forFormAjaxException
. I think if core succeeds to control the code flow of the Form API without exceptions (which is very unlikely to happen before Drupal 9), it wouldn't affect much of custom code.
– 4k4
8 hours ago
Actually, the patch for that issue removes the part handling an instance of a class extending theResponse
class and it forces form builders to return an array from theirbuildForm()
method.
– kiamlaluno♦
7 hours ago
This patch is from 2015 when core maintainers were more ambitious to remove exceptions for code flow control. We don't know what they will decide if this issue is picked up again and they might consider a replacement for redirecting in form builders directly.
– 4k4
7 hours ago
The point is not removing an exception. In fact, the code would still throw an exception, if that patch would be committed to Drupal core.
– kiamlaluno♦
6 hours ago
Why should the patch be committed after four years when there is no reason for it anymore since the introduction of EnforcedResponseException? There is of course the point "Exceptions should not be used for code flow control." If this is resolved the patch might be revisited, but probably in a different form and by having a solution to rewrite existing code if necessary.
– 4k4
5 hours ago
|
show 1 more comment
This is a good point, but this is the same forFormAjaxException
. I think if core succeeds to control the code flow of the Form API without exceptions (which is very unlikely to happen before Drupal 9), it wouldn't affect much of custom code.
– 4k4
8 hours ago
Actually, the patch for that issue removes the part handling an instance of a class extending theResponse
class and it forces form builders to return an array from theirbuildForm()
method.
– kiamlaluno♦
7 hours ago
This patch is from 2015 when core maintainers were more ambitious to remove exceptions for code flow control. We don't know what they will decide if this issue is picked up again and they might consider a replacement for redirecting in form builders directly.
– 4k4
7 hours ago
The point is not removing an exception. In fact, the code would still throw an exception, if that patch would be committed to Drupal core.
– kiamlaluno♦
6 hours ago
Why should the patch be committed after four years when there is no reason for it anymore since the introduction of EnforcedResponseException? There is of course the point "Exceptions should not be used for code flow control." If this is resolved the patch might be revisited, but probably in a different form and by having a solution to rewrite existing code if necessary.
– 4k4
5 hours ago
This is a good point, but this is the same for
FormAjaxException
. I think if core succeeds to control the code flow of the Form API without exceptions (which is very unlikely to happen before Drupal 9), it wouldn't affect much of custom code.– 4k4
8 hours ago
This is a good point, but this is the same for
FormAjaxException
. I think if core succeeds to control the code flow of the Form API without exceptions (which is very unlikely to happen before Drupal 9), it wouldn't affect much of custom code.– 4k4
8 hours ago
Actually, the patch for that issue removes the part handling an instance of a class extending the
Response
class and it forces form builders to return an array from their buildForm()
method.– kiamlaluno♦
7 hours ago
Actually, the patch for that issue removes the part handling an instance of a class extending the
Response
class and it forces form builders to return an array from their buildForm()
method.– kiamlaluno♦
7 hours ago
This patch is from 2015 when core maintainers were more ambitious to remove exceptions for code flow control. We don't know what they will decide if this issue is picked up again and they might consider a replacement for redirecting in form builders directly.
– 4k4
7 hours ago
This patch is from 2015 when core maintainers were more ambitious to remove exceptions for code flow control. We don't know what they will decide if this issue is picked up again and they might consider a replacement for redirecting in form builders directly.
– 4k4
7 hours ago
The point is not removing an exception. In fact, the code would still throw an exception, if that patch would be committed to Drupal core.
– kiamlaluno♦
6 hours ago
The point is not removing an exception. In fact, the code would still throw an exception, if that patch would be committed to Drupal core.
– kiamlaluno♦
6 hours ago
Why should the patch be committed after four years when there is no reason for it anymore since the introduction of EnforcedResponseException? There is of course the point "Exceptions should not be used for code flow control." If this is resolved the patch might be revisited, but probably in a different form and by having a solution to rewrite existing code if necessary.
– 4k4
5 hours ago
Why should the patch be committed after four years when there is no reason for it anymore since the introduction of EnforcedResponseException? There is of course the point "Exceptions should not be used for code flow control." If this is resolved the patch might be revisited, but probably in a different form and by having a solution to rewrite existing code if necessary.
– 4k4
5 hours ago
|
show 1 more comment
yes, you are right. you can redirect to the node using the code that you have mentioned. There is another way to set the redirection check the below code.
use the name space :
use SymfonyComponentHttpFoundationRedirectResponse;
$response = new RedirectResponse(node url);
$response->send();
exit(0);
I don't know what you are trying to achieve hope this code may help you.
1
exits should not be needed
– Kevin
10 hours ago
@Kevin is correct:exit()
should not be used.
– kiamlaluno♦
9 hours ago
add a comment |
yes, you are right. you can redirect to the node using the code that you have mentioned. There is another way to set the redirection check the below code.
use the name space :
use SymfonyComponentHttpFoundationRedirectResponse;
$response = new RedirectResponse(node url);
$response->send();
exit(0);
I don't know what you are trying to achieve hope this code may help you.
1
exits should not be needed
– Kevin
10 hours ago
@Kevin is correct:exit()
should not be used.
– kiamlaluno♦
9 hours ago
add a comment |
yes, you are right. you can redirect to the node using the code that you have mentioned. There is another way to set the redirection check the below code.
use the name space :
use SymfonyComponentHttpFoundationRedirectResponse;
$response = new RedirectResponse(node url);
$response->send();
exit(0);
I don't know what you are trying to achieve hope this code may help you.
yes, you are right. you can redirect to the node using the code that you have mentioned. There is another way to set the redirection check the below code.
use the name space :
use SymfonyComponentHttpFoundationRedirectResponse;
$response = new RedirectResponse(node url);
$response->send();
exit(0);
I don't know what you are trying to achieve hope this code may help you.
answered 13 hours ago
sekharctcsekharctc
214
214
1
exits should not be needed
– Kevin
10 hours ago
@Kevin is correct:exit()
should not be used.
– kiamlaluno♦
9 hours ago
add a comment |
1
exits should not be needed
– Kevin
10 hours ago
@Kevin is correct:exit()
should not be used.
– kiamlaluno♦
9 hours ago
1
1
exits should not be needed
– Kevin
10 hours ago
exits should not be needed
– Kevin
10 hours ago
@Kevin is correct:
exit()
should not be used.– kiamlaluno♦
9 hours ago
@Kevin is correct:
exit()
should not be used.– kiamlaluno♦
9 hours ago
add a comment |
Thanks for contributing an answer to Drupal Answers!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdrupal.stackexchange.com%2fquestions%2f277594%2fhow-to-to-redirect-a-form-to-a-certain-node-for-anonymous-users%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown