Closed (works as designed)
Project:
Multistep (D7)
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
21 Oct 2009 at 18:07 UTC
Updated:
20 Dec 2011 at 02:09 UTC
Jump to comment: Most recent file
Comments
Comment #1
vkareh commentedNot really. The idea of multistep is to allow you to continue the form at a later time without losing your progress. Deferring the creation of the node until the form is complete is not part of the current design, although patches are always welcome ;)
However, in the administrative settings you can configure the behavior so that the node is not published until the form is complete. Will that work for you? What you are asking for sounds like a good feature to add to the code.
Comment #2
baldwinlouie commentedThanks for the quick reply. Unfortunately unpublished nodes won't work here. Regardless of node status, uc node checkout will add the node to the cart upon creation.
If I were to write a patch, not sure where to begin with this one. Seems like you have to somehow store the form status of each step.
Comment #3
vkareh commentedThere are two ways that come to mind:
$_SESSIONvariable$form_state['storage']The first one will persist throughout the session, allowing the user to browse around, make some more changes, etc. The second one, I think, will persist only throughout the node creation process. If I had to write a patch for Multistep, I would go with the
$form_state['storage']since it's already part of the FormAPI and you just have to handle the redirects and form rendering at each step.I will see what I can come up with. In the meantime, I will mark this again as active to keep it on the issue queue; maybe someone else will jump in and help.
Comment #4
vkareh commentedThe way multistep saves nodes before completing them is by design. You might want to look into Chaos tool suite. It has an API to simplify building multi-step forms that will be submitted at the last step.
Comment #5
baldwinlouie commentedI was able to solve my problem by turning a regular node form into a multi-step node form. I did look at c-tools, but I didn't find a way to make it work with node forms. So, I ended up researching and researching multi-step node forms and implemented it.
Comment #6
yogesh1110 commentedcan you provide me how you have achieved this? I need the same functionality i.e. uc node checkout with multistep form.
Comment #7
doublejosh commentedME TOO!
Maybe you meant, you used Multistep Nodeform?
Comment #8
doublejosh commentedTested using Multistep Node Form with UC Node Checkout.
The problem with saving too early is gone, but you the form continues to the next step on the same page.
Also, the user is not redirected to the cart. Now looking for what allows this to still happen.
Comment #9
doublejosh commentedNot sure what I did, but now I don't get continued onto the cart at all.When logged out, the user is redirected directly to the cart, when logged in the process is followed but the cart is never reached.
Even when giving anonymous users the "toggle multistep" permission this still happens.
It's the "edit node_type content" permission that matters. Explicitly says so on the Redirect checkbox here: admin/store/settings/node-checkout/settings
However, even after turning off this redirect it still happens!Comment #10
baldwinlouie commentedI am very late to the game, but I wanted to reply with an attachment that shows how I created a multi-step node form.
I'm attaching the code I used for my multi-step node form. I built my solution before the Multi-Step Form module came ou.
The project was for creating a wizard to create a uc_node_checkout node at the end of the process.
There are some template files to make the module work, which I am not attaching. You'll want to look at the hook_form_alter, which is the meat of multi-step.
The module was written for Drupal 6. Basically, the idea is to setup a step variable, and when you reach each step, you store that. You then use the step variable to distinguish each step of the wizard and do your custom logic, or processing, or whatever else is needed.
For my case, I switch out the title, the theme function, and some extra stuff. Each step is rendered using a tpl.php file, instead of a theme function. This was to give the front end developer extra control.
The same step logic applies to the validate form function.
It's been a couple of years since I worked on this module, but it should give you an idea of how I did it.
Hope it helps.
Comment #11
doublejosh commentedAccomplished this with a rule.
Key thing to get right is that the final save is actually a node update (that's the trigger action).
Also you'll need to let anonymous users have the permission to edit their own content as they progress through the multistep.