How to redirect page after saving user info?

@ jegelstaff

I'm using Formulize + Reg Codes on Xoops 2.0.16, and they all work in harmony. I use them as an extended user profile which will help to contain extra information about the users - e.g. mobile numbers, etc.. But what I'm looking for after when a user has clicked-on the "Save" button after editing his/her profile; the "Saving" message-box will appear and then the page will be redirected to the "View Account" page.

Any ideas on how this can be done? I tried looking at the "/class/formdisplay.php" codes, but I can't seem to find nor know what to add-in ... Please help!

Many thanks in advance,
Jason :-)

Comments

RE: How to redirect page after saving user in

Hello, thanks for the good feedback about Formulize, Reg Codes and 2.0.16. :-)

You caught me at a good time, with a good question (ie: I'm online, not doing much important, and your question is interesting and has a clear answer [edit: well, it seemed clear at the time, but there's actually two different approaches])...

Disclaimer...I haven't tested any of this...let us know if you run into trouble, but I'm pretty sure it will all work, it's actually not that complicated, despite all the typing I've done below!

The first thing to figure out is whether you are using the option in Formulize that lets you turn off the "All Done" button? This is one of the preferences in Formulize, accessible through the admin side of the module. It affects all forms everywhere. If you have the "All Done" button turned off, then you can solve your issue pretty simply. When the "All Done" button is turned off, the "Save" button becomes a "Save+Done" button, ie: when the user clicks Save, the info will be saved, and then whatever the defined "leave-the-form" behaviour is, will happen right away. So you can just add some instructions for what you want the "leave-the-form" behaviour to be on the Edit Account page, and you're done. (There is no "leave-the-form" behaviour defined for the Edit Account page by default, and that means it will just reload the current page over and over when you click Save, which is exactly what is happening and what you don't want.)

If you do not currently have the "All Done" button turned off, then you could decide to turn it off now. You have to think about whether it will have a bad effect on your users or not -- maybe the way you're using Formulize in other situations means you really do want an "All Done" button (and you do not want the Save button to become a "Save+Done" button, which is what happens when you turn the "All Done" button off).

If all you're using Formulize for is the custom profile form in conjunction with Reg Codes, then just go and turn the "All Done" button off, you don't need it.

So, with the "All Done" button turned off, here's what you have to do.

Around line 166 of the edituser.php file in the root of your XOOPS installation, you should find a line similar to this:

displayform($fid, "", "", "", "{NOBUTTON}", "", "", "", "", "", "", $xoopsUser->getVar('uid'));

Replace the third "" in the displayForm line with XOOPS_URL . "/user.php". ie:

displayform($fid, "", "", XOOPS_URL . "/user.php", "{NOBUTTON}", "", "", "", "", "", "", $xoopsUser->getVar('uid'));

That will cause the form to redirect the visitor to the "user.php" page after they've saved their info, and the user.php page is the "View Account" page (or will redirect them there).

----------

If you do not want to turn the "All Done" button off, ie: you need it for some other situation you're using Formulize for in another form, then the fix is a little harder. You need a way to mimic the effect of turning the "All Done" button off, ie: you need to turn the "Save" button into a "Save+do something else" button. Fortunately, there is a way to do that which is not too complicated. Find that same line in the edituser.php file (around 166), and change it to this, and add another line below:

displayform($fid, "", "", "", "{NOBUTTON}", "{RETURNAFTERSAVE}", "", "", "", "", "", $xoopsUser->getVar('uid'));
header("Location: " . XOOPS_URL . "/user.php");

What that will do is interrupt the normal process of drawing the form, so that after the info is saved, instead of drawing the form again, it just ends the displayForm function. So, immediately after the displayForm function, you can then use the PHP "header" function to send the user to another page, ie: the View Account page.

The catch: I believe the header line will not work because higher up in the edituser.php file, some text has already been output to the screen. Around line 156 there is an "echo" statement. The easiest way around this problem would be to erase or comment out line 156. I think if you do that, then this approach would work.

So not such a simple answer I guess, but assuming I've got this right, the fix is not hard to implement in either case, and would actually be an interesting option to add to the Reg Codes module: "Should the user be sent to the View Account page after editing their account? Yes/no".

Good luck, Let us know how it goes.

--Julian

RE: How to redirect page after saving user in

Hi Julian,

A BIG thank you in helping me out with my request ...

Anyway, I've tried your 1st option (there's no need to use the "All Done" button since I've incorporated Formulize with Reg Codes, as you've suggested too). However, the 'hack' which you've provided here isn't working, sad to speak :-( ... Apparently after clicking onto the "Save" button, the Edit Profile page still remains (not redirecting to user.php, but remains in edituser.php).

What could be missing in the 'hack' which could complete the redirect to user.php?

Many thanks in advance,
Jason :-)

RE: How to redirect page after saving user in

Hmm, interesting. You sure you uploaded the copy of the file you made the change in?

Are you sure you turned off the "All Done" button? It normally does not show up on the edituser.php page, regardless of the setting in Formulize, but that does not mean that you have it turned off. You have to specifically go into the Formulize preferences and turn it off, ie: turn it off throughout Formulize.

When you go to the Admin side of Formulize, there's two options at the top of the page, one for the menu and one for the preferences. Click the one for the preferences, and where it says something like "Should the "All Done" button appear at the bottom of forms?" say no (or yes, whatever makes sense given the way the question is worded).

With the "All Done" button turned off, then the Save button should save and then execute the "all done destination" automatically, and with the modification to edituser.php I suggested above, the "all done destination" would be the user.php file, which in turn should redirect the user to their "view account" page.

As a test, you could try this:

Make sure the "All Done" button preference is set to "on", ie: make sure the "All Done" button is supposed to appear, so the opposite of how it's supposed to be to make this hack work.

Then change that line in edituser.php again, so it looks like this:

displayform($fid, "", "", XOOPS_URL . "/user.php", "", "", "", "", "", "", "", $xoopsUser->getVar('uid'));

ie: remove the "{NOBUTTON}" part.

That should give you a Save and All Done button at the bottom of the edituser.php page. And if you click the All Done button, then you should get sent to the user.php page.

If you can get that working, then you just need to turn the "All Done" button preference off again, ie: set it to no "All Done" button for all forms. And that should be it (the "{NOBUTTON}" setting should actually be redundant).

Does that help at all?

--Julian

RE: How to redirect page after saving user info?

Hi Julian,

I've tested what you've suggested above, and it works! However, it'll be 2 steps to press the "Save" button to save the information, and then "All Done" to redirect to user.php. There should be a way to combine these 2 steps into one. I was wondering that by pressing the "Save" button, it can then save all the information and after that automatically redirect to user.php ... Any suggestions?

Please keep me informed soon.

Cheers,
Jason

RE: How to redirect page after saving user in

Hi there,

I'm glad to hear this worked. There is a way to turn off the "All Done" button, that's what the preference is for in Formulize. Go to the Formulize admin area, click on Modify the Preferences at the top of the screen, and enable the option to turn off the "All Done" button. That should do it for you.

--Julian

RE: How to redirect page after saving user info?

Hi Julian,

I've "bad news" for you. Apparently, even I set "Yes" or "No" to turn the "All Done" button on at Preferences, the "All Done" button on EditUser doesn't change. It only changes when I "hack" the edituser.php file, as you've described above.

To have the "All Done" button OFF:
displayform($fid, "", "", XOOPS_URL . "/user.php", "{NOBUTTON}", "", "", "", "", "", "", $xoopsUser->getVar('uid'));

and "All Done" button ON:
displayform($fid, "", "", XOOPS_URL . "/user.php", "", "", "", "", "", "", "", $xoopsUser->getVar('uid'));

By the way, the redirect XOOPS_URL . "/user.php" doesn't work, even with the "All Done" button is set NO, and after the "Save" button is pressed. It'll only save the information and still shows the edituser form again without redirecting to userinfo. Hmm ... isn't the redirect link XOOPS_URL . "/userinfo.php" ...???

Any suggestions?

Many thanks in advance,
Jason

RE: How to redirect page after saving user in

Hmm, I'm a little confused. I thought from a previous post that when the edituser.php file looks like this:

displayform($fid, "", "", XOOPS_URL . "/user.php", "", "", "", "", "", "", "", $xoopsUser->getVar('uid'));

Then everything works, except you've got the Save and All Done buttons at the bottom. And "All Done" *does* take you to the "View Account" page, the problem is simply that it's an extra click.

Is that true? In that case, turning off the "All Done" button in the preferences should work I think....but wait, a check of the code reveals that Formulize itself has a hard coded exception built in for the profile form that excludes this from working. Hmmm. Okay, sorry for all this hacking.

Around line 370 of formulize/include/formdisplay.php there is a line that looks like this:

$allDoneOverride = (!$formulizeConfig['all_done_singles'] AND !$profileForm AND ....

remove the part that says "AND !$profileForm".

Also, repeat that same modification a bit lower down on a similar line, around line 376 (these line numbers will not be exact since I'm looking at our development copy of the code, not the 2.2 version).

Okay, so if you have removed the profile form exception from that line, and you then make sure that the "All Done" button is turned off in the preferences, then does that all work okay?

I do not recall why that except exists in the code. Perhaps with a modification to the edituser.php file we will not need it at all, which would be nice and would save you having to hack the formdisplay.php file every time you have to upgrade Formulize (not that we release new versions too often anymore).

Does this help

--Julian

P.S. I believe the user.php file redirects to the userinfo.php page automatically if you are logged in.

RE: How to redirect page after saving user info?

Bravo ... Julian,

I've managed to get it working now, with the following steps (a mixture of your suggestions):

1. Under Xoops 2.0.16 Admin >> Formulize >> Preferences >>
Should the 'All Done' button appear at the bottom of the form when editing an entry, and creating a new entry in a 'one-entry-per-user' form? .. Set this to NO.

2. With the Reg Codes 2.2 RC1 - core patch files, on line 166 of the edituser.php file >>
Replace the third "" in the displayForm line with XOOPS_URL . "/user.php". ie:
displayform($fid, "", "", XOOPS_URL . "/user.php", "{NOBUTTON}", "", "", "", "", "", "", $xoopsUser->getVar('uid'));

3. Then, with the Formulize 2.2 RC1 - on lines 368 and 374 of the /includes/formdisplay.php file >>
Remove the part that says "AND !$profileForm".

With these modifications, after the user has/hasn't made any changes to his User Account details, the page will save, and automatically redirect to user.php (or userinfo.php?uid=xxx).

Many, many thanks Julian for all your help. I hope these steps will help someone else who needs it too ...

Best regards,
Jason

RE: How to redirect page after saving user in

Great, I'm glad to hear this worked. Thanks for your patience, good luck with the site.

--Julian

RE: How to redirect page after saving user in

Hi Julian -

I've been using Reg_Codes 2.2 for a couple of years now, and recently realised that newly registered users do not receive the User Activation emails. I wish only that the new users can verify and activate their accounts themselves, and not the job of the administrator.

The following are my settings:

1. Under Xoops 2.0.16 System Admin >> Preferences >> User Info Settings
Select activation type of newly registered users: Requires activation by user (recommended).
Select group to which activation mail will be sent: Administrator

2. Created registration code has:
Instant account creation: No
Approval by these groups: None - approval not required

I ran a test by changing the Approval by these groups: , and realised that the User Activation email is sent to both the user and administrator. What is wrong here? Strange.

Please advise soon. Thank you.

Cheers,
Jason

RE: How to redirect page after saving user in

Hello, you caught me at the FSOSS conference, and then a major deadline for a client right after, my apologies for the delay.

I am glad to hear you've been using Registration Codes happily for a little while. :-)

It is not really possible in Registration Codes to allow users to simply self-activate their accounts, unless they are using "nocode" and you have your XOOPS default account creation options (in the system module preferences) set to allow them to self-authorize through e-mail confirmation. That should work for users just creating plain accounts, not using any code, if you allow that.

For actual codes that assign membership in groups, there is a new option in Registration Codes 3 that may be attractive...

We realized that the admin approval feature had a problem. The admin users only knew what the candidate user had typed into the form, but they didn't know if anything that was typed was actually true.

So we added a user confirmation step to account creation.

So admins now only get approval messages after a user has confirmed their e-mail address by clicking a link in a message.

However, we also added a feature -- and this is what you might like -- where you can pre-approve e-mail addresses for certain users. So if you are accepting public registrations, this is not so good for you, you don't know the e-mail address of the people you want to accept. But if you are accepting accounts only from certain people you know, then you can specify their e-mail addresses when you create the code, and they will get their account as soon as they confirm their e-mail.

If that doesn't help, this would not be a difficult feature to hack into Registration Codes. If you don't mind messing around in the PHP code, I can provide some pointers.

So as far as your current site is concerned, because you are allowing user activation, then users are getting the message. And then when you required activation by an administrator group, they got the message too. We try to take a very broad interpretation of the XOOPS settings. ie: we don't want to conflict with them and have our settings override things you've set in the admin side. We want to do both what XOOPS says and what Reg Codes say, if possible.

That's probably what's going on here, but it's been a while since I fiddled with these kinds of settings.

Again, the best approach for you may be some PHP hacking. Let me know if you're comfortable with that and I can post details.

Take it easy,

--Julian

RE: How to redirect page after saving user in

Hi Julian,

Thank you for the quick response. Your explanation seemed too alien and difficult for me to comprehend, and I've decided to "skip" my own requirements. Sorry for troubling you.

Cheers,
Jason

RE: How to redirect page after saving user in

No trouble. If you can't get a solution working that meets your needs, please post back here. I'm sure there's something that can be done.

Good luck,

--Julian

RE: How to redirect page after saving user in

Hi Julian -

I returned to your last suggestion after I've successfully upgraded to Formulize 3.0 and RegCode 3.0. I managed to make use of some of the earlier hacks to meet some of my requirements - like the NOBUTTON save redirect to userinfo.php after editing and saving the user information.

However, I'm puzzled by some things, as listed below:

  1. When a new user is registered, two emails are sent to the new user - a) stating that his/her ID has been registered, and b) asking for an email confirmation. I would like the second email delivered only to the new user, but how do I prevent the first email from being delivered?
  2. On Formulize, I had disabled one of the fields, which detects the new user's IP address. I've used the following code to default the IP value:
    $default = isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : $_SERVER['REMOTE_ADDR'];

    Unfortunately, when the field is disabled, the value returns as '1'. Otherwise, it will return with a proper IP address. What could be wrong here?

  3. Upon upgrading from Formulize 2.2 to 3.0, I noticed that a new DB has been created, i.e., xoops_formulize_1. This is strange as why isn't Formulize 3.0 reusing the old DB, xoops_formulize_form instead. Could you please explain? ...

    Please ignore this as I ran some a sub-domain to test the differences between an upgrade and a fresh install. Found out that the DB xoops_formulize_1 is automatically formed when a new form is created. An upgrade migrates the info from xoops_formulize_form to xoops_formulize_1. Therefore, one can delete xoops_formulize_form after the upgrade is completed, which I did. The DB xoops_formulize_1 is neater. Great thinking. Thank you.

  4. Is there a way to customise the email(s) sent out to the new user, just after registration? Please help.

I sincerely hope that these aren't overwhelming you. I look forward to your reply soon.

Many thanks in advance,

Jason

Hello, thanks for posting,

Hello, thanks for posting, interesting questions.

For number 1, you would probably have to modify the include/functions.php file in Reg Codes to stop that message from being sent. But it's not totally obvious where in that file that message is being sent. You could try commenting line 251, but I'm not sure that's the right place (ie: if that's the right message to turn off). As the comment there says, where and how it's sent can vary quite a bit depending on settings in XOOPS and Reg Codes.

For number 2, I'm not sure where the code is that you've modified. Formulize does not pay any attention to IP addresses, I don't think. The code could be returning 1 because perhaps HTTP_X_FORWARDED_FOR is always set even if it's not a valid IP, and so in those cases it returns its current value which is 1. Let me know where you've made the change and all the changed code at that point and I can probably figure it out.

For number 3, yes you're right, the upgrade process creates the new tables and new forms create new tables. I'm glad you like the approach, it is fundamental to so many of the changes in Formulize 3, and lets us do proper SQL statements when gathering data from more than one form at once. The current development branch includes some significant optimizations to the display of data which are only possible with the new data structure. It took quite some time to refactor the code to use the new structure, as you might imagine. :-) One other benefit is it makes the data pretty transparent for manipulating with third party apps. So if you want to point a separate report generator at your data, you can.

For number 4, I believe all the mails have their text in either a mail template, which would be in [root]/language/english/mail_template/ I think, or some mail contents appear to be in language constants. If you customize the templates, then that will change the contents of the messages.

I hope that helps, let us know. Good luck,

--Julian

After clicking "Save" I redirected into a white blank page

Dear Julian
I work with xoops 2.3.1 - 2.3.2 and 2.3.3 and I have some problems :

on "one entry per user " option

- After clicking "Save" botton I redirected in to a white blank page .
- With same PC (maybe same IP) only one entry can be done.
- When you go on to the form for the second time ,you recieve a white blank page again
- suppose you want to give access to guests , after filling the form for the first time as a guest another guest can not fill the form

- A form element for uploading a file looks necessary

Excuse me for my elemantry questions

Not sure about the white screen

Hello, thank you for your interest in Formulize. I am sorry to hear you have run into trouble.

I am not sure what is causing the white screen you are getting. If you can turn on PHP debug information and post any error messages, that would help identify the problem. You may need to check an error log on your server to find the important messages, since some errors are not printed to the screen, depending on how your web server is configured.

As for the other issues, here is how the one entry per user setting works:

If you are logged in, then you can fill in the form once, and when you return to the form, you get update that entry, but you cannot make another. This is because that one entry is tied to your user ID number.

If you are not logged in, then things are a little different...this is because all users get an ID number, and if you are not logged in, then XOOPS treats that ID number as a zero, basically. So everyone who is not logged in essentially shares the same entry, ie: the entry that is associated with user zero.

So if you intend the form to be used by non-logged in people, you probably want it to be set to more than one entry per user. In that case though, people will no be able to return to the site to update their entry, because, afterall, they have no way of identifying themself to the site (no username and password) so you don't know which entry belongs to them.

If you want all "guest" users to use the same username and password, you have basically the same situation: they will all use the same account, therefore they will all share one entry that is associated with the one user ID number.

There are some more advanced tricks you can do with the displayForm function if you want to manually create a pageworks page. You can use that function to control whether a form behaves as one entry per user or more than one entry per user, and switch the behaviour based on whether a user is logged in or not, or whether the logged in user is the special "guest" user or not. And cookies can also be used in some situations.

Alternatively, instead of letting all your guests use a single account, or letting them be anonymous and not logged in at all, you could use the Registration Codes module and create a code that uses the "instant account creation" feature. That feature is designed for a "guest" situation, where you want people to have real accounts in the database, so that they can have their own entries, etc, but you don't actually want them to have to create accounts, and you don't expect them to come back to the site later. So with the "instant account creation" code, the visitor just types in the code, or even clicks a special link, and an account is created for them behind the scenes, but they don't have to fill in a form, create a password, nothing. Maybe that is more in line with what you want to do?

If you can post a description of what you are trying to do in your website, then we could provide some more specific advice.

Lastly, a file upload element is a much requested feature. We have never had a need for it in any of our projects, that's why it's not done yet. But if you have developers available, it would probably not be difficult to add. I have made a short outline of what is required here:

http://www.freeformsolutions.ca/en/node/566#comment-1759

I would be happy to provide more details to anyone who is going to work on this.

I hope this info helps, let us know how it goes.

--Julian

Blank page Error

Dear Julian

Thank you for your favour

Suppose you want thousands of people to fill your form for some purpose and you don't need them to be registered or membered in your site .
Suppose different people go to the same PC ( in a caffeeNet for example)
So you want any new comer to fill his/her entry and each one shouldn't see the other's information .
Now if we set "One Entry Per user" and set access to "view th form" and "Add his/her own entry" only and not "Edit own entry" , when the same ID (as you said) goes to fill , he/she receives white blank page especially guests .

if we set "More than one entry per user " we don't recieve white blank page but in the situation of the Same ID for guests you have differnt bottons and a list of records for that ID , and as I said before (....each one shouldn't see the other's information ) this is no good .

thank for your information in previous post but as a shame I know nothing about the PHP and HTML codes and so ashamed to ask you explain in more details . Sorry I couldn't get the point with ""instant account creation" code""
Anyhow so usefull module for me if I can use it this way .

I wish you health and success

Setting up anonymous access

Anonymous access does cause some problems. There are two basic options that you should consider:

1. Make a form that is "more than one entry per user" and use the default interface. Then when anonymous people in a cafe visit the form, they will get an empty form, they can fill it in and save the information. But, they cannot go back and edit the information. They are anonymous, they have no way to identify themselves to the website, no username. So we do not know which entry is their entry. They can go back to the form and make two or three or four more entries. You have no way to control that.

2. Make a form that is "one entry per user" and make a special interface to that form in a Pageworks page. This will require some PHP coding. So maybe it's not an option. But if you do this, then you could just use the displayForm function in a Pageworks page that you create in the Pageworks module. You can set this up in such a way that the people in the cafe will have their entries tracked by cookies, and if they come back to the form, it will show them what they submitted. But, for people in a cafe, that is not good. The next person who sits down in the cafe and uses the same computer, they can see the first person's information!

In both cases, you want to let people view form, add entries and update their own entries. You need to set all those permissions.

So really, the problem is that you want to let people fill in the form, and you don't want them to register. That is a problem. It means that either 1 -- no one can go back and see/edit their entries, or 2 -- you have to create a special interface to the form.

If option 1 is not good for you, and you want to try option 2, I can post some PHP code that might help.

--Julian

Access to the form for all for unlimited times

I think it would be better for the case that anybody who filled the form , received a chase code ( an auto made code by the module when submitted a record ) for later editting . So no need to save the IP or ... for editting and no necessity for logging in .
Ofcourse the module is so usefull for the membered , but I think having the above mentioned point as an option is so good .
dear Julian I want new students enrole in our college and I want have some information of them and decide which ones to choose . So no need them to be membered in our site and different anonymous entries with different imformation looks natural and if anyone if anybody wanna enrole for himself/herself and also for one or more of his/her friends by the same PC what should the module do .

Anyhow help me in the way you prefer better for me .

Thank you very very much

Good idea about showing them the code

Hello,

That's a good idea to show them a code after, and they can type in the code later to see their entry again. That would take some fancy work. The interface where they typed in the code again would need to be custom built, but it could be done. The basic idea would be to have a textbox in the form that is disabled for all users. So it's visible, just disabled. Make a special PHP-based default value for the element that would generate your unique code. Make sure each code is unique, base it on the timestamp or something like that.

I haven't tried using that feature much myself, so I am not sure exactly how it would work in this situation, but I think it would be the right thing to use. If it didn't work, for example if it didn't save, it would surely be a small fix to make it work.

Then you would need to make a Pageworks page that showed the user a box where they could type in a code. And when they submit the code, then the page would do a getData call on the form and look for that code, and then get the ID number of the entry in the form that it finds. And then show the form for that entry so people can edit the information.

The form should be setup as more than one entry per user, and anonymous users should have view, add and edit permission.

One problem with this approach is that if your codes are guessable, people could type in another person's code and make changes to an entry that doesn't belong to them.

If you don't care about people being able to edit the entries, then it all becomes much simpler. Just setup the form for more than one entry per users, and allow anonymous users to have view, add and edit permission. Then make a Pageworks page that shows just the form, it would simply have this code:

displayForm(1); // displays form number 1

And they could then go to that page to fill in the form as many times as they want. There are some other parameters in the displayForm function that you can use if you want to have the form reload with the entry they just made. By default it would reload blank, since the form allows "more than one entry per user".

I hope this makes sense, I'm not sure if this is the kind of information you want?

--Julian

Trow Pop Up "Print View" after saving.

After scratching the code for some time, id relized how to throw the Print View automatically after saving a form .

Just change formdislpay.php on the line that says:

$saveButton->setExtra("onclick=javascript:validateAndSubmit();"); (around 871 on Formulize 3.1 =)

And change it to

$saveButton->setExtra("onclick=javascript:validateAndSubmit(),PrintPop();");

You can actually do whatever you want after saving a form by writing a javascript function and calling it on this line =). The validateAndSubmit() is the function that saves the forms data and redirect you to the previous screen.

Regardz.

Cool, but is the data saved?

Hello,

That's a neat hack...I'm not sure the popup will show the saved information though...the save routine will run at the same time that the print view popup will appear, and depending which thread happens first, the print popup might contain the previous state of the data? Or do you find it always has the latest data from after saving?

What is the situation you're dealing with, that makes you want to have the printable view displayed after saving?

--Julian

Workaround to delay the popup.

You are right. I was only testing with previously saved entries, but when i update or add a new entry the printview values goes empty.

What i did was to add some code after line that says $ele_allowed = $_POST['elements_allowed'];
on printview.php:

// Get last entry loaded on DB and show it. By MedievalSpawn!
sleep(1); //Just for securing the last record is loaded to DB
if (empty($_POST['lastentry'])) { //If im adding a new entry the $_POST['lastentry'] will be empty
include_once XOOPS_ROOT_PATH."/modules/formulize/include/functions.php";
global $xoopsDB;
// Get the last entry saved to DB wich will be the one i just saved.
$result = q("SELECT MAX(entry_id) FROM " . $xoopsDB->prefix('formulize_'.$formframe));
// Assing the value to $ventry wich will be passed on the function that populates the form's data.
$ventry = $result[0]['MAX(entry_id)'];
}

Thank you very much for sharing your point =)

Neat solution

Getting the printview page to wait is clever...though timing based fixes are not guaranteed to work on all servers of course. What is the situation that you have, that makes you want to show the printview right after saving? Why is that useful to your users? I'm not saying that it's a bad idea, I just want to know more about the use-case, so I can think about whether there's a stronger feature-based way to make Formulize do the right thing here.

Thanks,

--Julian

Its a reception/delivery note.

This form, is used to receive and deliver Computers and Computers Parts for reparation. Why is this useful? because i need to simplify the reception/delivery process and show automatically a printview right after saving information. The Receptionist, has to create an user, load all the information about the machine, and give the account and reparation information to the clients, so i need to print all of this information and make the user and the company to sign this as a Reception Note.

Also, the reception note can be a delivery note, so i have modified printview and displayForm code to show other titles, fields (like User instead of User Name), and footer.

In example, the title of the printview is conditioned. If there is specified a delivery date, the title would be "Delivery Note" instead of "Reception Note" this is done by adding something like

if (empty($result[0]['deliverydate'])) { //If delivery date is empty then
print "
NOTA DE RECEPCION

";
} else {
print "
NOTA DE ENTREGA

";
}

It could be handy to be able to add predifined functions to the Submmit button, like popup another form, show printview, or go to the next entry for example... =)

Thanks for your interest julian... long time no see btw.

Interesting

There are plans for a "regular form" type of screen, and I think these kinds of features make sense to be part of that. You would be able to customize the look and behaviour of a plain form so you could add this other info, and perhaps add other actions that happen when the form is submitted. Unfortunately, I don't see a good way to integrate these kind of changes/features without the full screen type for regular forms. But we're aiming for version 4.0 with that feature...4.0 has a lot of stuff planned, we'll see how it goes. Anyway, until then you're stuck maintaining a hack it seems. :-(

I was away for a while on a big family trip...I thought I might get to answering some posts while I was away, but it never happened. That was probably for the best though. :-)

--Julian

Huge roadmap and aspirations.

Plz Read http://www.freeformsolutions.ca/en/node/639 =) or remove this answer.