• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Form Sessions being created on multipage forms even if "Save part edited recor" is No

bggann

Active Member
I have a site with multipage form - one of those pages is a repeating group.

We've had repeated problems with validation errors on the repeating group - for group repeats that are gone (have been deleted).
This seems to be related to temporary form sessions that are saved during editing on next/prev page.

We turned off the "save part edited records" to No in the "Form Processing" tab to prevent temporary sessions from being created (in fabrik_form_sessions)

For most uses, this seems to work. But for one (some?) users, we see the same "validation errors" after they delete a repeated group record, and there is a fabrik_form_session entry created for that user.

I'm looking at the fabrik_form_sessions table and it has a handful of sessions, but if it was being created for every users, it would be much bigger.

What can be causing this?
Current Joomla, Current Fabrik
I have caching (system) off.
I have Caching set to Off for the form (trying to figure this out).

When I log in and edit the same record, I do not see the issue - I can deleted repeated group items.
When my user logs in, even after I deleted their fabrik_form_session, it works 1 time, but on the second time we get the validation error and the fabrik_form_session is created anew.

The is the crrf site in mysites profile

Bob
 
Hmmm. I hate these intermittent / hard to reliably replicate issues.

I'll see if I can provoke this issue here on my test site.

So this is when editing existing records?

-- hugh
 
Yes - specifically I have a user (which happens to be the primary admin). He is opening an existing record, and trying to delete some of the repeated groups. He can do 1 edit - then press next/prev or save, but the 2nd time, he gets the validation error. I don't seem to get them when I edit the same record. I think if this were common, we'd have a lot of people screaming, cause it is pretty common to go in and edit records (delete repeated groups).
But I know it is happening sometimes cause I see "fabrik_form_sessions" appearing when I have deleted all of them (in phpadmin).

I can give you access to the site, but it is production, so we need to be careful. I could create a backup clone an tell you the login/record that is exhibiting it if that would help.

- yeah - I hate these to...
The validation here is a simple "not empty" validation. It seems like we get a 'validation failed' on a record (group) that has been deleted. It seems like the validation is still running.

Bob
 
So to try and replicate, I should have a not empty validation on a field in a repeat group. Edit a record, go to Next page, delete a group, save. Then edit again, Next, save, and it (may) toss an error.

-- hugh
 
OK, I forgot that we do use the formSession table to store data after a failed validation, even for non multi-page forms, or if session storing is turned off. They get deleted when that form is successfully saved.

But I still can't construct a scenario where the issue you describe can occur, where a "ghosts" of removed groups wind up causing failed validation.

I'll keep trying, though.

-- hugh
 
Ah. Well that kind of fits.
I wonder if the validation failure is on another page, and we are getting stuck where it wont advance.

I've got an idea but I can't look at till morning.

Why don't you hold and I'll investigate
 
OK, looking at that code, I think the only time we need to save the form session on a validation failure is if the submission is happening in a content plugin or module. In a normal component view, we just run the view's display() method at the end of processing, so we still have all the data from the form that failed validation, to stock it with again when redisplaying it. It's only in "mambot" mode (module, content plugin, etc) where we'll wind up doing a redirect, and losing that submitted data, that we need to stuff it away in the session table, to read after the redirect.

So try this. Edit ./components/com_fabrik/controllers/form.php, around line 494, in the handleError() method, find this ...

Code:
      if (!$validated)
        {
            $this->savepage();

            if ($this->isMambot)
            {
                $this->setRedirect($this->getRedirectURL($model, false));
            }

... and move that savepage() line into the isMambot block ...

Code:
        if (!$validated)
        {
            if ($this->isMambot)
            {
                $this->savepage();
                $this->setRedirect($this->getRedirectURL($model, false));
            }

That should prevent those failed validation sessions from saving into the form_session table. And hopefully, if that's what it causing these funky issue, they might go away.

Well, assuming you aren't displaying this form in a content plugin. If you are, don't. Just use a simple component menu link.

Let me know. If this works, and you don't find any other side effects, I'll commit the change.

-- hugh
 
Thanks Hugh - I'll put this code in and let you know later today. Booked all morning. No - I'm not using a content plugin, but a direct component menu link.

Bob
 
Sorry, No. It has been crazy at work and while this is part of work it has been below the line. I wanted to do there change this morning but my network was down. It is on the list for first thing in the morning. My user is also pushing.

Bob
 
Hugh,

I made the changes in the code and did some preliminary testing. I was able to introduce validation errors and confirm the temporary session was not created. I was also able to make the 'kind' of changes that was causing the problem, without seeing the problem.

However, my primary user that was having this is out on fire assignment and was not able to test for me. He may do it tomorrow. Until he can verify that he is not seeing it, I can't a-b-a it yet.

Bob
 
Hugh,

Update on this. My user was able to log in and test today, and had validation errors.
I verified that no fab_form_session entry was created - so the change you had me make achieved it's purpose (not creating fab_form_session).

But - he still had the validation error problem. He would try to remove a repeating group, press "next" and get a validation error on a repeating group record that appeared valid.

So - I logged in using HIS login information to try to replicate. I could not. I was able to repeatedly remove repeating group entries and validate either using the Save button or by pressing "Next".
Basically, I could recreate his error either using my login, or his, when editing the exact same record.

Baffled, I called him back and he tried logging into the site in 'incognito' mode so see if there was a local cache or cookie or something that was causing the problem.
On his '1st' attempt, he deleted a repeated group entry, pressed Next and it created a new, empty, record which failed validation.
He deleted that empty record, and it worked (no validation error).
He was able to delete other repeated records with no issue, and save the submission.
BTW - this user is very computer savy user.

--
So -
- The change you (had me) make had it's intended consequence.
- The change did not resolve the issue.
- I could not replicate his issue using his login information and editing the same record.
- He logged in in incognito mode to try to bypass any local cache.
- After one error, which he could clear, he was able to make the edits (repeatedly).
- That seems to indicate that this is a local cache issue. He'll clear his caches.
- He will continue working - he has several other records he needs to make the same (type of) changes on. He'll let me know of problems

I'm not sure, at this point, if you want to commit the change. I've not seen any negative consequences of the change, but it appears the problem may have been related to a local cache? (Is that even possible).

I'll update this if anything changes.

Bob
 
Well - here is the update.

I'm really not sure where to go with this.
When he logs in and does the following it breaks

- Open a record
- Deleted more than one repeated group
- Hit's Next

He gets validation errors on a valid remaining repeated group.

When I do the SAME thing using HIS login, it works. I get no errors.

Note:
- He is using a completely different computer than previously.
- He cleared caches (Chrome)
- He tried FireFox (which probably had never been run on this computer).

No joy. He gets the error.
I do not.

Since I can't replicate it..... I'm not sure where to go...

-Bob
 
Man, I hate these issues. As you say, without being able to replicate, it's essentially impossible to fix. And I was never able to replicate this issues at all, I just noticed why those form sessions were being created when they didn't need to be, and that might conceivably cause a problem like this.

The only other candidate for this kind of issue with repeat groups is Javascript getting the group numbering jacked up when deleting groups. But I would expect that to be replicatable (is that a word?).

So I'm kind of at a loss with this as well.

-- hugh
 
I'm right with you. For most users I would assume some type of user error. But this one is very computer savvy. He is actually the first level support for the site. He handles most user issues with no help from me.

I'd say we leave well enough alone for now. Your choice on committing the change you made. The site has been running normally with people using it since I made the change you suggested with no apparent side effects.
Bob
 
K. I think the change is the right way to do it. Only need to store the form data in the session on validation fail if it's a module or content plugin.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top