Forums

Concrete5.7.5.6 - Form in Global Area doesn't work

Permalink
I have a form. It works perfectly anywhere but in a Global Area. I can't even pin point where the error is coming from. It seems my $_POST is empty when the form is submitted but I have no idea why because, as I said, it works fine anywhere else.

Has anyone come across anything like this before? I couldn't find much on the internet. I only found someone mentioned there might be a different way to call

$view->action('submit_form')

in a Global Area or the block's controller doesn't work in Global Areas. Any ideas? Thank you.
linuxoid
 
Mainio replied on at Permalink Reply
Mainio
This is an existing bug in the core:
https://github.com/concrete5/concrete5/issues/1854...

There are some workarounds presented in the issue thread but I think they haven't yet settled on the best way to solve this.
linuxoid replied on at Permalink Reply
linuxoid
I knew it!!! )))

Thanks for the link. Really appreciate it.

However, I couldn't understand what the actual working fix is. What exactly should I do until the bug is fixed?
Mainio replied on at Permalink Reply
Mainio
If you are just experiencing this problem with a global area, I would suggest do it the easier way and do this modification:
https://github.com/concrete5/concrete5/issues/1854#issuecomment-7746...

If you also have the same problem with stacks, you'll need to go a bit deeper and follow the instructions in the previous message above that.
linuxoid replied on at Permalink Reply
linuxoid
I've added the function into my form block's controller.php but the form still doesn't work. What are 'qsID' and '$this->questionSetId'?

Here's an extract from view.php:
<div class="row mfp-hide inquiry-form-block" id="inquiry-form">
    <?php
        $formAction = $view->action('submit_inquiry_form').'#inquiry-form'.$bID;
    ?>
    <form id="inquiry_form" 
        enctype="multipart/form-data" 
        action="<?php echo $formAction?>" 
        method="post" 
        accept-charset="utf-8">
    ...

and controller.php:
public function action_submit_inquiry_form() {
    ...
}
public function isValidControllerTask($method, $parameters = array()) {
    $valid = true;
    if ($method == 'action_submit_inquiry_form') {
        if ($this->post('qsID') != $this->questionSetId) {
            $valid = false;
        }
    }
    if ($valid) {
        return parent::isValidControllerTask($method, $parameters);
    }
}
Mainio replied on at Permalink Reply
Mainio
OK, I'm not quite sure on how to fix that if that doesn't work.

The letters "QS" here refer to "Question Set". Each block instance gets assigned to a single question set containing all the questions for the form.

The "qsID" is a parameter coming from the form view and it refers to this exact "question set" that is attached to the form that you are displaying at that time:
https://github.com/concrete5/concrete5/blob/develop/web/concrete/blo...

The "$this->questionSetId" is the question set ID for the instance of the block that you are handling in the controller. This method compares these together and assumes that if they match (i.e. the post parameter's ID matches the currently handled block's question set ID), we should handling the form action and storing the data.

Why this modification worked in our case was that there were possibly multiple forms on a page of which the first one got handled always, even if someone was trying to submit the second one (which was in the global area). So, the second one in the global area never stored its data properly because the controller thought it should be handling the first form always.

I'm not sure if it works in your case but it fixed the situation in our case. Also, I'm not sure if there have been any core changes regarding this. In the lately releases there seem to have been some architectural changes in most of the release updates.