I have a custom multi-step form that I add to certain node type content via hook_nodeapi. It is working great, with one exception.
During testing, I've found that when I am in mid-form (say, step 2 of 6) and update the node in another browser tab, my form reverts to step 1 when I try to proceed to the next step. Similarly, when an AHAH event occurs, I get an error and the form disappears altogether. The error suggests there is a problem with retrieving the form from cache after a node update, as it's not able to retrieve the form parameters.
Have you encountered this behaviour before, and/or do you have any suggestions on how I might go about fixing it? It isn't a huge problem as these nodes likely won't be updated too often on the production side, but it would still be a significant nuisance to those it does affect.
Edit: Thanks for your response. Unfortunately I can't contain this form within a block. It must be within the node content itself. Upon further testing I noted that other users thankfully aren't affected. It is only the user that updates the node while in mid-form that is affected. As this is extremely unlikely to happen on the production site, the impact of such an occurrence would be minor, and I have no time at the moment to explore this further, I'm going to move on with this behaviour unexplained for now. But if anyone can point out why this is occurring, I'd appreciate it.
Well, have just tried your situation based on multistep form described here - http://zgadzaj.com/basic-drupal-multipart-form-example-with-previous-and-next-buttons - but put in the block and displayed on node page, and even if I edit this node in a different tab, I still can navigate between all form steps on the original tab, keeping all already submitted values. So I'd say it all probably depends how your form is being built...
Related
I started block development recently and I just came across a problem. Let say I create one block twice on a page. I edit that block. As soon as I click the second block it takes the over the same data as the first. On preview the behaviour is the same but if I now refresh the editor page both blocks are treated seperatly. What am I missing out?
I added unique ID's but that did not help. I rewrote my data structure aswell.
Sadly there are no error messages. All I know that updating one value will trigger the callbacks of all the blocks of the same type. The state is only updated for the selected one.
I recently took over a site from someone else at a new company. Having never used Drupal before, updating things has been a bit cumbersome. There were some outstanding security updates that I applied(but I haven't updated the core yet). Anyway, after doing this, the calls to views_embeded_view have not been working. For example:
print views_embed_view('news_block');
Will break the links(by using the title, rather than alias for the link), or it will link correctly, but not follow the paging rules I have set(show 1 page, 6 items per page) instead it shows 10 items and has links for other pages.
I am not sure if the update has anything to do with it, but it seems likely. Would updating the core resolve this issue potentially?
The first argument of views_embed_view is view name, the second one is display id. If display_id is not provided, 'default' is used. Make sure that you are displaying the correct display. (i.e. default can be configured differently than some other display which you actually wish to see)
Currently, I have an asp.net web application that links to another page. The enduser clicks on a link which response.redirects to a validation page. This works correctly they finish with the validation page and this response.redirects them back to the initial page that they started on. The specific problem is that when the user is brought back to the initial page any work that they had previously completed is now gone (aka filling in textboxes/dropdowns etc.). I have been reviewing the best way of making sure this doesn't continue to occur and everything seems to be pointing to saving the view state of the page prior to redirecting to the validation page, and then reloading this view state upon coming back to the initial page. Although, I fell like using response.redirects will not allow this to occur. Now if the end user was just clicking the back button then this would work. Basically, my problem is keeping the data that my enduser input present on the initial page. Any thoughts/ideas/suggestions will be greatly appreciated. Please go easy as it is my first post here. Thanks.
I am not sure whether or not this will solve your issues but long time ago there was an idea to store the ViewState on the server and restore it on demand.
http://www.codeproject.com/KB/applications/persistentstatepage.aspx
This came at a price of turning of the validation. I remember I tweaked it a little bit:
http://netpl.blogspot.com/2007/11/persistentstatepage-with-event.html
I hope you'll find it useful.
I will suggest looking at this article: 9 ways to persist user stat
Which state choice is really up to you and what your application requires. Its a little old (2003) but a good guide to user state.
(Sorry this is rather a vague question. My attempts to be clearer [and indeed to be more code-oriented] have failed...) :-/
//
I've installed the Firebug for Drupal module, and I notice that it shows I'm apparently loading the same eight node objects on every page for no apparent reason. These are all of the same content type (the site uses many other content types).
It seems they are actually all the nodes of this one content type, excepting those produced as dummy content by the developer module.
I've flushed the cache multiple times.
Is there a way to work out where these nodes are being loaded from???
Install devel.module, add ddebug_backtrace(); inside the node_load() function. Reload the site. Now you should see 8 browsable backtraces which will tell you which function calls node_load().
At a guess, you probably have a block (from a view or module) which is querying those nodes on every request.
http://heydon.com.au/node/1044 has a short writeup on this behaviour. If so, the fix is to remove that block from the regions which are rendered, or configure it to only be displayed (and therefore rendered) on pages where you want it to be run.
Drupal caching should prevent those queries being run for anonymous users (depending on the caching and block settings, of course).
I've had this happen with 3rd party modules that were repeatedly calling node_load() needlessly. What I would suggest is for you to disable all 3rd party modules, retry you node loads and re-enable them one by one until you catch the misbehaving module.
Good-luck!
I have a grid with several thousand rows that can be filtered and sorted. On each row you can click a details button, which will bring you a new page with detailed information about the page. Because this is a button, you can't middle click or right click and open in a new tab. In addition, when clicking back you lose your filters and search results.
To solve this problem, I considered the following: Switch the buttons to links, and when filtering and searching, use get instead of post requests. This way, you could switch to new pages with a right click or middle click, and if you did follow a link normally, back would work properly.
This change was not made however. We were asked add a 'next result / previous result' set of buttons on the details page, that would allow you to navigate. While not an elegant solution, it would at least work.
I proposed adding querystring parameters to the details page, that would regenerate the search query based on filter, and allow you to get the next and previous results in code.
A team member took issue with this solution. He believes that it is a waste of server resources to re-query the database. Instead, a solution was proposed to add session variable that included a list of results. You could then use that to navigate.
I took issue with that because you can't have multiple tabs open without breaking navigation, and new results aren't appended to the list in real time. Also, if you worried about optimization, session would be the last thing to use since it eats memory and prevents server replication... unless you store the results back in the database.
What's the best solution?
Session doesn't sound like a winner, won't scale with lots of users.
Hitting the database repeatedly does seem unnecessary, but it depends on the cost - how many users, how often would they refresh/filter and what is the cost of that query?
If you do use querystrings you could cache the pages by parameter.
What about some AJAX code on that button to retrieve details - leave the underlying grid in place and display details in a div/panel or a new window/tab.