Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forms timeout with session #275

Closed
marshmn opened this issue Aug 18, 2018 · 21 comments
Closed

Forms timeout with session #275

marshmn opened this issue Aug 18, 2018 · 21 comments
Assignees

Comments

@marshmn
Copy link

marshmn commented Aug 18, 2018

If you view a page with a form on it, and then wait for the PHP session to time-out, the form will no longer work. Hitting the submit button will present an error such as: "Oops there was a problem, please check your input and submit the form again."

One suggestion on potentially how to fix this from @rhukster is that perhaps there should be an AJAX ping to keep the session alive.

@rhukster rhukster self-assigned this Aug 20, 2018
@marshmn
Copy link
Author

marshmn commented Nov 9, 2018

Having thought about this some more, I'm not convinced that an AJAX ping is necessarily the right way to go for all usage scenarios.

I would definitely fix some cases and be an improvement, but it does have a side effect of keeping more active PHP sessions open presumably - which might not be a good thing if you're wanting to keep some control on how long users are logged in for etc.

It will also fail to solve the problem in scenarios where, for example, you are using a laptop to view a page with a form on it, then suspend your laptop and wake it hours later. The AJAX ping clearly won't have been in effect during that time so now filling the form will fail.

I wonder if it would be better to have an option on a form-by-form basis to set whether or not it should care about whether there is an active session?

@rhukster
Copy link
Member

I need to think about this to see if there's a solution.

@mahagr mahagr self-assigned this Jan 29, 2019
@mahagr
Copy link
Member

mahagr commented Jan 29, 2019

This has been implemented (in a way) in Form 3.0, though it needs to be documented as it is not turned on by default.

Form submission will still fail, but everything inside the form will be kept, including your uploaded files.

@skyleo
Copy link

skyleo commented Feb 26, 2019

Is it possible to get the fix for that as a diff for the current stable version of Grav?
Or will we have to wait for Grav 3.0?
Any other kludges I can use meanwhile?

@Sogl
Copy link
Contributor

Sogl commented Apr 30, 2019

@mahagr This problem still exists in Form 3.0.2
Problem with modular form when form send I see "Oops, you have a problem"... cache_enable: false is set

@mahagr
Copy link
Member

mahagr commented May 6, 2019

For logged in users you can try:

form:
    name: my-form
    remember_state: user
    uniqueid: asdf1234
    id: my-form

@Sogl
Copy link
Contributor

Sogl commented May 6, 2019

I don't use auth mechanism, just contact form with name, email, phone.

@rhukster
Copy link
Member

rhukster commented May 6, 2019

Are you using:

form:
  keep_alive: true
...

???

@rhukster
Copy link
Member

rhukster commented May 6, 2019

I set my session timeout to 30 secs and reloaded my form, and keep alive seems to be working just fine.

Image 2019-05-06 at 5 45 19 PM

@Sogl
Copy link
Contributor

Sogl commented May 7, 2019

@rhukster Just added keep_alive: true to my form without success.
This is GH problem that it not add reference from CHANGELOG.md:
image

Ok, I give more info.
My filesystem:
image

Full home.md content:

---
title: Юрист Евгений Имангулов
body_classes: title-center title-h1h2
cache_enable: false
content:
    items: '@self.modular'
    order:
        by: default
        dir: asc
        custom:
            - _intro
            - _area
            - _digits
            #- _about
            - _advantages
            - _record
            - _contact

form:
    keep_alive: true
    name: send-form
    action: /home
    template: form-messages
    refresh_prevention: true

    fields:
        name:
            label: Имя
            display_label: false
            placeholder: Ваше имя
            classes: 'form-control form-control-lg'
            type: text
            validate:
                required: true

        phone:
            label: Телефон
            display_label: false
            type: text
            classes: 'phone form-control form-control-lg'
            placeholder: 'Ваш телефон'
            autocomplete: true
            validate:
                required: true
                pattern: '^((\+?7|8)[ \-]?)?((\(\d{3}\))|(\d{3}))?([ \-])?(\d{3}[\- ]?\d{2}[\- ]?\d{2})$'
                message: 'Формат: +7 (***) ***-**-**'

        question:
            label: Вопрос
            display_label: false
            placeholder: Ваш вопрос на консультацию
            classes: 'form-control form-control-lg'
            type: text
            validate:
                required: true


        honeypot:
            type: honeypot

    buttons:
        submit:
            type: submit
            classes: 'btn-one btn-square'
            value: Отправить

    process:
        email:
            from: "{{ config.plugins.email.from }}"
            to:
                - "{{ config.plugins.email.to }}"
            subject: "Заказ консультации от {{ form.value.name|e }} [imangulow.ru]"
            body: "{% include 'forms/data.html.twig' %}"
        message: 'Спасибо! Я обязательно свяжусь с вами.'
---

AJAX part in js file:

$(document).ready(function() {
...
   var form = $('#send-form');
   form.submit(function(e) {
        // prevent form submission
        e.preventDefault();

        var record = $('#record');

        // submit the form via Ajax
        $.ajax({
            url: form.attr('action'),
            type: form.attr('method'),
            dataType: 'html',
            data: form.serialize(),
            success: function(result, status, jqXHR) {

                console.log(result);
                console.log(status);
                console.log(jqXHR);

                if ( $( result ).hasClass( "alert-success" ) ) {
                    form.addClass('d-none');
                }

                record.find(".alertbox").html(result);
                record.find(".alertbox").removeClass("d-none");
           }
       });
   });
...
});

Grav 1.6.8 and all plugins is up to date:
image

You can also check the problem here on my site:
https://imangulow.ru/#record

The form does not work until I clear the cache.

@rhukster
Copy link
Member

rhukster commented May 7, 2019

It might well be related to the form being a modular page. I'll take a look.

@rhukster
Copy link
Member

rhukster commented May 7, 2019

Do you have a bottom JS assets block and is form.min.js being loaded?

Image 2019-05-07 at 12 41 31 PM

@rhukster
Copy link
Member

rhukster commented May 7, 2019

BTW Read this for recommended structure: https://getgrav.org/blog/important-theme-updates

@Sogl
Copy link
Contributor

Sogl commented May 7, 2019

@rhukster

Do you have a bottom JS assets block and is form.min.js being loaded?

I forget to clear-cache after keep_alive: true add. Now it shows properly:
image
and with cache enable ONLY after 1st page load after clear-cache manually. No files after 2nd refresh etc:
image

My base.html.twig (excluding some parts):

<!DOCTYPE html>
<html lang="{{ grav.language.getLanguage ?: 'en' }}">
    <head>
        {% block head %}
            <meta charset="utf-8" />
            <title>{% if header.title %}{{ header.title }}{% endif %}</title>
            {% include 'partials/metadata.html.twig' %}
            <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
            <link rel="icon" type="image/x-icon" href="{{ theme_url }}/images/favicon.ico" />

            {% block stylesheets %}
                {% do assets.addCss('theme://dist/css/app.css', 10) %}
            {% endblock %}
            {{ assets.css() }}

            {% block javascripts %}
                {% do assets.addJs('theme://dist/js/app.js', {group: 'bottom'}) %}
            {% endblock %}
            {{ assets.js() }}

        {% endblock head%}
    </head>

    <body data-spy="scroll" data-target="#navbar-example2" data-offset="50">
        {% block icons_svg %}{% endblock %}

        <div id="preloader">
            <div id="status">
                <img src="{{ theme_url }}/images/preloader.gif" height="64" width="64" alt="">
            </div>
        </div>

        {% block header %}
             {% include 'partials/navigation.html.twig' %}
        {% endblock %}

        {% block body %}
            {% block content %}{% endblock %}
        {% endblock %}

        {% block footer %}
             {% include 'partials/footer.html.twig' %}
        {% endblock %}


        {% block bottom %}
	        {{ assets.js('bottom') }}
	    {% endblock %}
    </body>
</html>

All my js assets including jQuery:

window.$ = window.jQuery = require('jquery');
require('bootstrap');
require('jquery-mask-plugin');
//FontAwesome
require('./fontawesome');

//my js
require('./custom');

become one big minifiead app.js.

Sometimes I have jQ duplicates and other problems. See also my old issue about: getgrav/grav#2119

@rhukster
Copy link
Member

rhukster commented May 9, 2019

You should really update your base to use the format recommended in the blog article i linked above. Probably is not going to 'fix' your issue, but it's going to be more reliable.

Other than that, i'm not sure, I don't see anything that sticks out as an obvious issue, but i'm unable to replicate your problem. :(

@Sogl
Copy link
Contributor

Sogl commented May 9, 2019

I can provide more info, files, site access etc

@rhukster
Copy link
Member

rhukster commented May 9, 2019

email me the access information for both frontend and admin, and i'll take a look.

@Sogl
Copy link
Contributor

Sogl commented May 10, 2019

@rhukster I could not find your email anywhere, so I sent it to the Trilby Media inbox.

@rhukster
Copy link
Member

rhukster commented May 10, 2019

Ok, it's the usual issue. Twig output is cached in modular pages, so when using modular forms, you should always have:

never_cache_twig: true

Now we have logic to automatically set this option if you have your form in the actual modular page, but you have the form in the parent page, so this was not being automatically set. I set this manually on your modular page and it seems to be working.

More info: https://learn.getgrav.org/16/content/headers#never-cache-twig

Rule of thumb is if you have anything 'dynamic' in the Twig, like forms, but could be anything that needs to run, you should set this option.

@Sogl
Copy link
Contributor

Sogl commented May 12, 2019

Thank you Andy, it works on 1st try. I'll test more later.

@Sogl
Copy link
Contributor

Sogl commented Jun 2, 2019

@rhukster I tried to use form after some time and it works. I think you can close this issue because no activity from other participants.

@rhukster rhukster closed this as completed Jun 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants