Posted by wpanssi on April 18, 2008 at 5:49am
| Project: | Webform |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | sgabe |
| Status: | closed (fixed) |
Issue Summary
Is it possible to somehow show webform as a content of another node? I would want to show my webform as a book page in my book. InsertNode -module allows me to show the title and the description of the webform but the form itself won't be seen.
Comments
#1
If you have php in the node, you should just be able to use:
<?php$node = node_load($nid);
print node_view($node);
?>
Also, what's probably happening is insertnode module is only showing the teaser. If there's an option to show the full node, use that instead and the full webform should appear.
One more option: in Webform 2.x, there is an option to show the entire form in the teaser.
#2
You can also use the nodereference cck type to load a specific webform.
#3
I'll try those. Thanks!
#4
Ok, using php snippet was easy! What if I would like to leave out the title of this node? A slick way to do that? I looked up the node_view function from API, but couldn't figure out how to leave out the title.
#5
If you are taking an API route, check out hook_nodeapi and use the $op for view.
#6
<?php$node = node_load($nid);
$node->title = NULL;
print node_view($node);
?>
#7
Where? I can't find it.
#8
Under "Webform advanced settings" on each node form, there is a checkbox labeled "Show complete form in teaser".
#9
Code snippet in comment #1 doesn't seem to work in a block for Drupal 6. How should that snippet get modified?
#10
Ignore last. I did not have php filter module turned on.
#11
Using the snippet given above in #1 to create a block containing my webform, I get the following error on pages displaying the block (and the block doesn't show up):
**EDIT: Scratch that - I'm a total dumbass. I forgot to replace $nid in the snippet with the actual node id of my webform. I'm going to leave this question here in case it helps future dumbasses who have made the same mistake.
#12
This is great, thanks.
It was posted that to have webform in node, just type the following with php selected as input format for that node:
<?php$node = node_load($nid);
$node->title = NULL;
print node_view($node);
?>
This is probably trivial, but I don't know exactly how to enter node id in there. Say my webform node id is: ?q=node/15 what would I put:
<?php$node = node_load($15);
$node->title = NULL;
print node_view($node);
?>
This does not work for me, so how would I do this is node id is node/15?
#13
A little more guess work, and simply, it is as follows:
<?php$node = node_load(1);
$node->title = NULL;
print node_view($node);
?>
#14
The attached patch adds a "Expose as Block" to the Webform Advanced fieldset in the webform edit page.
Once checking that, the webform will appear as an available block on admin/build/block.
Note that it's useful in this case to add a "thank you" message to the webform or redirect to an url.
(update.. just reuploaded the patch)
#15
This looks pretty good. I think a lot of users would find the functionality helpful so I'd like to be able to commit this feature improvement. However this expose a problem that the block is still displayed, even if the user is not allowed to fill out the form because of submission limits or access controls. The block should be hidden entirely, or continue to show but display one of the standard messages explaining why the form is no longer available.
Implementation-wise, can we not create a "block_id" counter, and instead just use the NID as the delta for blocks. This avoids adding another auto-increment column that will differentiate between the Drupal 5 and 6 version. Instead we add a column for just "block" that is a tiny (for mySQL, small for pgSQL) unsigned int of either 0 or 1.
If we can make those changes, please please port to Drupal 6 also to speed up the process for getting this into Webform.
#16
patching file webform.install
Hunk #1 FAILED at 23.
Hunk #2 succeeded at 955 with fuzz 1 (offset 173 lines).
1 out of 2 hunks FAILED -- saving rejects to file webform.install.rej
patching file webform.module
Hunk #1 succeeded at 336 (offset 95 lines).
Hunk #2 FAILED at 427.
Hunk #3 FAILED at 746.
2 out of 3 hunks FAILED -- saving rejects to file webform.module.rej
#17
Subscribing, this patch is for drupal 5 right?
greetings,
Martijn
#18
Hi you @ll,
there is a "Node as block" module quite useful for that purpose and for many other things:
http://drupal.org/project/nodeasblock
Basically it allows on "Content types" decide if such content type could have nodes to be shown as blocks and you activate it or not for each content type. The on node edition there is a textfield with several parameters.
#19
Interesting... testing on D6
#20
Moving to a feature request. I'm still open to including this as feature directly in Webform, since it requires special considerations when dealing with submission limits. The current patch in #14 doesn't really seem to have any advantage over the nodeasblock module JordiTR recommended in #18.
#21
I'm using webform in a block and validating the form with the snippet below. This gets the errors and posts them on the redirect page and clears the form once submitted, but is there a way to extract and display a user defined message (i.e "Thank You") in the same node after the form is submitted?
<?phpif (form_get_errors()){
drupal_set_message();
drupal_goto('node/19');
}
?>
Note:
I'm using this to display the webform in a block:
<?php$node = node_load(20);
print node_view($node, false, true, true);
?>
#22
#23
This can be done cleanly using views.
Add a "node type" view
Add a "block" display
Settings for the view: (I copy my settings below marking with *** the modified ones)
Display: Block
Basic settings
Name: Defaults
Title: None
Change settings for this styleStyle: Unformatted
Change settings for this styleRow style: Node *******
Use AJAX: No
Use pager: No
Items to display: 10
More link: No
Distinct: No
Access: Unrestricted
Exposed form in block: No
Header: None
Footer: None
Empty text: None
Theme: Information
Relationships: None defined
Arguments: None defined
Fields: The style selected does not utilize fields.
Sort criteria: None defined
Filters
Node: Type = Webform ********
Node: Nid = Your webform node ID ********
Do not forget to enable the block display in admin/build/block/list/your_theme_name
#24
when you click the submit button of you forgot to fill in an obligatory field, the form displays the webform-node instead of displaying the error/confirmation messages in the block-area. Ne1 knows a solution for that?
#25
Didn't see this thread previously and mad a module last November to do just this thing. Also addresses the issue in comment 24. Available now for download from http://drupal.org/project/webformblock
I've not tested it with the form submission limiter mentioned in comment 15.
#26
Excellent thanks budda! I'll feature the new module on the Webform project page. It'll be great to find any remaining problems with the approach. I'm still open to including it in the webform.module directly, but now we can work out all the kinks and decide if it's best left as a separate module or included in Webform. Thanks!
I'm moving this issue to fixed. Please report any issues with the webformblock.module in the issue queue for that project: http://drupal.org/project/issues/webformblock
#27
What's the correct PHP snippet or easiest way to insert a webform in a node now?
I tried the snippet above in D6 and it doesn't work.
Thanks.
#28
The snippet in #1 still works in both Drupal 5 and Drupal 6.
#29
That didn't work. I have PHP filter enabled and "show webform in teaser" checked, too.
For this particular case, I just entered the main content in the description field, but I'd still like to insert forms in nodes in the future.
I've inserted forms in nodes using the PHP code above in Drupal 5.7, but it just doesn't work in Drupal 6.11 with the 6.x-2.6 Webform version for me.
Thank you for your work.
#30
Automatically closed -- issue fixed for 2 weeks with no activity.
#31
Hi folk,
A very special thanks to www.ixis.co.uk.
This is what I was looking for.I just wanted to show contact-us like form in block of each page so that visitors of website do not need to go to contact us page.
Is "Node as block" module work same as "webformblock" module? I mean, can I get same functionality by use of "Node as block" module too?
Thanks,
Web-Farmer
@letsnurture.com
#32
You can override the validate and submit functions in form_alter and do a redirect.
To have this working, you will need clear the custom URL path of the webform.
Some code sample:
function MODULENAME_form_alter( $form_id, &$form )
{
if( $form_id == 'webform_client_form_998' )
{
$form['#submit']['MODULENAME_webform_998_submit'] = array();
$form['#validate']['MODULENAME_webform_998_validate_fix'] = array();
}
}
function MODULENAME_webform_998_submit( $form_id, $form_values )
{
return 'PATH/THAT/YOU/WANTED';
}
function MODULENAME_webform_998_validate_fix( $form_id, $form_values )
{
return 'PATH/THAT/YOU/WANTED';
}
I hope this helps someone.
If it doesn't work.. go to edit the webform and make sure URL path settings is empty.
cheers,
#33
The Webform block module now does the work.
#34
Does anyone know how I might display a list of Webforms for a user to click on (a title) and load the respective form? Is there a way for this to load dynamically once a Webform is created? Thanks for you time!
#35
I would like to have something similar.
Show a dropdown with all the webform titles, when you select one, the specific webform is loaded onto the page (preferably without an entire page refresh)
Default the first webform should be shown and selected in the dropdown list. (or a specific form, if set through a url parameter for example)
#36
Subscribing
#37
I know the Webform Block module can do this and the development snapshot works with the 3.x branch of Webform but that module seems to be kinda fuzzy for me. Since I needed this feature for a current project, first I started to rework that module but I ended up with a patch for Webform instead. IMHO this functionality should be available in Webform itself instead of another module. I am attaching patches for the 6.x.3.0-beta6 version and for the 3.x branch. I hope they will be useful for you. Let me know if you are interested so I can keep you up-to-date with changes and fixes.
#38
I'm not sure about including this functionality directly in Webform, though I will agree that the Webform Block module has in the past been lacking in keeping up-to-date and including frequently requested features.
#39
Revised patch for dev.
#40
I was going to suggest this could be a submodule within Webform but looking at how it works, so nicely integrated, and looking at the code, i really think it should be part of Webform.
If code weight is a concern the functionality within the hook_block implementation could go in a conditional include and this feature would add next to nothing for anyone who doesn't use the functionality.
One insignificant code note: This can go within the if statement for block enabled:
+++ includes/webform.pages.inc 9 Aug 2010 21:17:29 -0000@@ -179,6 +185,7 @@
+ global $theme_key;
Doesn't matter much but that's the only place it's used.
Anyhow i consider this RTBC but i understand the reluctance to add the feature to Webform. I do think it belongs, though.
#41
Awesome i didn't realize this was on the table... Webforms in blocks is essential for sooo many sites. Plus the maintainer of Webform Block is MIA...
#42
Rerolled the patch for latest 3.x release of webform. Should we keep going this route, or will this only get in as a separate module, whether a submodule or a separate project?
#43
I'm not entirely convinced this belongs in Webform. Clearly the main reason for including in Webform is because of the lack of proper maintenance by the Webform Block maintainer, rather than this being integral functionality that most Webform users need. Of the ~6,500 users that use Webform 2.x, about 10% have Webform Block installed (based on usage statistics). So it's sort of on the border of what's expected and what's considered additional functionality.
The biggest obstacle to inclusion is long-term maintenance. Webform is already a massive module and this furthers code that I need to maintain and test for. That said, I'm open to this possibility if:
In addition, this patch needs the following:
+ // Create the block if enabled.+ if ($form_state['values']['block']) {
+ db_query("REPLACE INTO {blocks} (module, delta, theme, cache) VALUES ('%s', %d, '%s', %d)", 'webform', $node->nid, $theme_key, -1);
+ }
+ // Or delete it if disabled.
+ else {
+ db_query("DELETE FROM {blocks} WHERE module = '%s' AND delta = %d", 'webform', $node->nid);
+ }
- $allowed_roles = array();- foreach ($node->webform['roles'] as $rid) {
- $allowed_roles[$rid] = isset($user->roles[$rid]) ? TRUE : FALSE;
- }
- if (array_search(TRUE, $allowed_roles) === FALSE && $user->uid != 1) {
- $enabled = FALSE;
+ if (!empty($node->webform['roles'])) {
+ $allowed_roles = array();
+ foreach ($node->webform['roles'] as $rid) {
+ $allowed_roles[$rid] = isset($user->roles[$rid]) ? TRUE : FALSE;
+ }
+ if (array_search(TRUE, $allowed_roles) === FALSE && $user->uid != 1) {
+ $enabled = FALSE;
+ }
url(drupal_get_path_alias($_GET['q'])).+ // Set the form action to the current URL.+ if (isset($node->webform_block) && $node->webform_block == TRUE) {
+ $form['#action'] = url(drupal_get_path_alias($_GET['q']));
+ }
// Set the form action to the node ID in case this is being displayed on the
// teaser, subsequent pages should be on the node page directly.
- if (empty($submission)) {
+ elseif (empty($submission)) {
$form['#action'] = url('node/' . $node->nid);
}
- $node = node_load($form_state['values']['details']['nid']);+ $node = $form['#node'];
#44
I am attaching an updated patch according to your notices.
#45
I've committed #698494: HTML Email Template Functionality (MIME mail support) which will require this patch to make a few changes:
- Change the update function one higher
- We shouldn't need to update the insert/update queries any more since we're now using drupal_write_record() instead of manual queries.
This patch looks really good overall. I'd like to see the use of manual SQL queries reduced and using drupal_write_record()) instead. PostGres does not support "REPLACE" commands, so we won't be able to use it.
To clean up our hook_block() function, I'd like to see it broke into separate pieces (similar to hook_nodeapi), this makes code more consistent between Drupal 6 and Drupal 7. I'd suggest using all the names of hooks in Drupal 7 and call them manually as needed from hook_block() in Drupal 6. See the Example block module for Drupal 7.
After reading this segment, I found that it makes a huge change to existing functionality:
- $allowed_roles = array();- foreach ($node->webform['roles'] as $rid) {
- $allowed_roles[$rid] = isset($user->roles[$rid]) ? TRUE : FALSE;
- }
- if (array_search(TRUE, $allowed_roles) === FALSE && $user->uid != 1) {
- $enabled = FALSE;
+ if (!empty($node->webform['roles'])) {
+ $allowed_roles = array();
+ foreach ($node->webform['roles'] as $rid) {
+ $allowed_roles[$rid] = isset($user->roles[$rid]) ? TRUE : FALSE;
+ }
+ if (array_search(TRUE, $allowed_roles) === FALSE && $user->uid != 1) {
+ $enabled = FALSE;
+ }
This makes it so that unchecking all roles allows ALL users to submit a Webform, rather than allowing NO users to submit a Webform. This change is completely unrelated to this patch and definitely needs to be removed.
#46
Thanks quicksketch for your constructive reviews.
#47
Ehh...please ignore the previous patch.
#48
Thanks to you for the continued rerolls. This looks really good. I've updated the patch with a few changes:
- Small indentation fix on a switch statement
- Switched to drupal_write_record() for updating webform records (I thought we were doing this already).
- Changed configuration options to use strings instead of integers (full, content, form; instead of 0, 1, 2).
- Renamed webform_block_list() to webform_block_info().
- Changed the default value of the "block" column to be 0 instead of '0'.
#49
I also meant to ask, what's the value of the "redirect" options? Isn't a little strange that you would want to redirect a user to a confirmation page if they filled out the page-based webform but you'd show a message if they filled out the block-based webform? It seems like you'd likely just not set a confirmation URL in either place.
#50
Fantastic work sgabe and quick turnaround! A few nitpick notes:
+ case 'list':+ return webform_block_list();
This call and the function itself could use
webform_block_info()and the function would be Drupal 7 ready.+ $blocks[$data->nid] = array(I don't think webforms have any machine name or alpha identification for exportables that we could reuse here (which is understandable as webforms are nodes) but block deltas should still at least be prefaced with the module name, not be just a number: 'webform_' . $data->nid
I think this makes all the prefacing of settings with block_ unnecessary, if it ever were necessary, such as
$new_settings['block_'. $delta]and$webform_blocks['block_'. $delta];. The delta would already be a proper string.The inserts could be drupal_write_record(), i think? Though that's combining other improvements in this patch. However given the quicksketch's and your comments i am confused that i don't see a replace function nor any drupal_write_record...
#51
Do I download the latest version of webform (3.2) or the latest dev release before applying this patch?
#52
The latest dev.
#53
quicksketch: Sorry, I didn't know that you meant to replace the webform queries too, I thought for only the block queries which I removed completely. What do you mean by the value of the redirect options? I think default and none are fine. :) Actually setting the $redirect_url to
$_GET['q'];is like doing$form['#redirect'] = FALSE;but the former is easier here I think. Or do I misunderstood you?Benjamin Melançon: Thanks, that is a good idea about the delta.
#54
When would you ever use these options? They seem superfluous. If you're showing a Webform in a block, you'll probably just configure the Webform with a message and it's the same as no redirect(?) I think that we need to figure out what to do about setting the #action property permanently here, like we shouldn't set #action unless the form is multiple pages. It seems like most people don't appreciate being taken to the form page when a validation error occurs.
#55
I am using this on a site that I am currently building. The default behavior gets the user to the webform node displaying the confirmation message after submission.
<?phpif ($is_draft) {
...
}
elseif (!empty($form_state['values']['details']['finished'])) {
...
}
elseif (valid_url($redirect_url, TRUE)) {
...
}
elseif ($redirect_url && strpos($redirect_url, 'http') !== 0) {
...
}
else {
$redirect = array('node/' . $node->nid . '/done', 'sid=' . $sid);
}
?>
Either we need to set the $redirect_url to the current URL or set redirection to NULL/FALSE to avoid this and keep the user on the same page where he filled out the form. Since we are speaking about a block and the user can be anywhere on the site this is important. Setting the $redirect_url is easier than set the #redirect element for the $form in webform_client_form_submit(). To do that we should check if the webform is being displayed in a block, than load the block settings and check if it needs "NO" redirection and set the #redirect element to NULL or FALSE.
The patch changes the currently behavior to only set the #action if it is neither a block or a submission. Do you refer to something else?
<?phpif (!isset($node->webform_block) && empty($submission)) {
$form['#action'] = url('node/' . $node->nid);
}
?>
#56
My point is setting up the redirect on the block instead of as a property on the node is awkward. This requires you to set up a message on the node that you would expect to be shown as a page sometimes and other times as a message. Either that or you set up a redirect on the webform node that is node/[nid], to make it so that the confirmation message is always a message and never a page.
Perhaps we need to use the same radio-button choices that we've used for other e-mail settings and create something like this (on the webform form settings page):
Redirect location:(•) Confirmation page
( ) No redirect (reload current page)
( ) Custom URL: [ ]
Ah, okay that works for me.
#57
Okay, I think I got your point. I will do this first thing tomorrow.
Note that using webform-$nid for block delta results CSS ids like block-webform-webform-$nid. Perhaps we should think of a unique identifier that could be used for $delta and $mailkey, see #899948: Use more descriptive mailkey and let me know what you think.?
#58
Hmm...I saw your reply about the unique identifier. Then lets change the $delta to form-$nid for now, so the block ID will be like webform-form-$nid.
#59
Even though the form itself is given a class of "webform-client-form-[nid]", I think it'd make more sense if the block were given an ID that indicated it was a block, not a form. Though giving a block delta a name like "block-[nid]" doesn't really seem right, it would generate an ID of "webform-block-[nid]". What do you think?
#60
In the end I came up with something else. The original idea did not look good enough when I started to rework the redirection part, so I did this instead:
Redirect:[X] Redirect to confirmation page or custom URL: [ ]
Basically this is a yes/no question, with some plus in case yes (confirmation page or URL), doesn't it?
Furthermore I changed the block delta to "client-form-[nid]", which results in "#block-webform-client-form-[nid]".
I think I have discovered some bugs, I will search the queue or open new issues for them.
#61
This approach doesn't make it clear that a confirmation page will be provided for you automatically if you check the box but don't enter in a URL (that is the behavior right)?
#62
+++ includes/webform.pages.inc 2 Sep 2010 17:08:53 -0000@@ -40,11 +41,20 @@
+ '#description' => t('If enabled the user will be redirected to the confirmation page or the given URL (optional). Enabled by default, uncheck to reload the current page.'),
This is what the description for, I think its pretty clear. I see no reason in using radios and provide three options.
#63
Hmm, I don't know. I don't like it when unchecking has one behavior and checking has another. Radio buttons provide clarity on what action will take place without any additional help text. It seems to me that checking the box really means I should fill out a URL. Saying the URL is optional doesn't mean that it's optional when the box is checked. I might think that it's only optional if you don't check the box. Finally, what happens when you don't check the box but you do fill in a URL? We've already set this UI pattern when configuring e-mail settings, I don't see why this should take on a different appearance.
#64
I added a JS function to webform-admin.js which disables and clears out the URL field and I changed the redirect checking to avoid what you refer to.
Do you reject this idea for sure? I wanted to give it a shot, but if you insist...
#65
Hm, let me try it out and I'll post back when I get time to functionally review the patch. Thanks for your patience on this, I appreciate the continued rerolls.
#66
Okay, I had some time so I made a patch according to your original idea just in case. I don't know how much time will I have to work on this in the next weeks, so I wanted to do it now.
I changed only the order of the options like this:
Redirect location:(•) Confirmation page
( ) Custom URL: [ ]
( ) No redirect (reload current page)
Additional changes:
Note that though I removed the redirection setting from the block configure page, but in order to add settings with ease in the future I didn't change anything else.
#67
Heh...Please ignore the previous patch.
#68
subscribing
#69
I think we can avoid the addition of a column just for "redirect", instead we can infer whether a redirect will be used based on the value of "redirect_url", similar to how we do not have dedicated columns for each of the from, e-mail, and subject properties for e-mails. I'm doing a minor reroll/review, which I'll post shortly.
#70
I thought of that too, but IMHO at least rename the "redirect_url" to "redirect", the original name would be misleading in this case.
#71
Here's a reroll with the following changes:
- Consolidated 'redirect' and 'redirect_url' into just reusing the existing 'redirect_url'. I like the column name 'redirect_url' because it doesn't sound like a boolean flag like some of our other columns: i.e. teaser, block, or allow_draft. I used
<confirmation>and<none>as special values, with<confirmation>being the default.- Regarding access control on the block, the node_access() check should be sufficient I think. If the user doesn't have access to submit the form, Webform doesn't return anything. If they're using the default "form" display mode, then the block will be hidden entirely. I made it so that status messages are not shown if form access is not allowed for a webform block so you don't get "You may not submit another submission at this time" on every page where the block tries to display.
- Modified a few help texts.
A few concerns left:
- I'm not sure about the benefit of the auto-loading translated versions of the Webform node. When most people translate content I imagine they'll end up with multiple blocks (one for each translation). Then again, it doesn't hurt so I'm fine with it.
- I'd still really like tests.
- We need to port to D7.
#72
Looks pretty neat. :) I will test it out and port to Drupal 7 ASAP.
One little thing, isn't the usage of non-existent hook comments misleading in D6? Should we at least add a @see and provide the address of the corresponding D7 API page?
#73
It's a little misleading but I think it's a fine trade-off for greater patch-compatibility between Drupal 6 and Drupal 7. Since I maintain both at the same time anything that helps consistency between the two versions is always preferable for me.
#74
@@ -2034,34 +2183,36 @@+ elseif ($redirect_url == '<none>') {
+ $redirect = NULL;
+ }
These lines are unnecessary, as this is the default. Maybe clearer to keep them though?
Something cool that i'd just like to note here: the
$node->webform_block = TRUE;setting can be seen in implementations of hook_form_alter() to identify when a webform is being displayed as a block.#75
It actually is necessary because
<none>apparently passes valid_url(). However I like it for clarity too. I thought about just having an empty string be no redirect, but then I found<none>to be more explicit.Yes, I've found $node->webform_block to be useful already. Very handy!
#76
subscribe
#77
is this patch is ready to a production website ? or must i do waiting for a future release of webform 3.0 ?
#78
i think you need to use the dev version of the module and then apply the patch?
#79
@aiphes: It needs testing. You can help to get it in the next release if you try it out and report back.
@bkosborne: Exactly.
#80
ok i will try..
#81
I'm using webform load in lightbox code below. This gets the validation errors and posts them on the webform creation page when form is submitted, but is there a way to extract and display a validation error message in the same page i.e on lightbox after the form is submitted?
Load Webform in Lightbox...
<?php$contact_node = node_load(42);
print node_view($contact_node, false, true, true);
?>
#82
Hi Sandipmkhairnar– that's not really related to this issue. You can try http://drupal.org/project/ajax which has/had integration with Thickbox for this sort of thing, and asking in http://groups.drupal.org/ajaxmodule or other group, forums or IRC for help.
#83
on website test :
after applying patch ( a little hard for me) :
this message after enabling block in webform settings
"user warning: Unknown column 'w.block' in 'where clause' query: SELECT n.title, n.nid FROM d6mt_webform w LEFT JOIN d6mt_node n ON w.nid = n.nid WHERE w.block = 1 AND n.type IN (0) in C:\wamp\www\Modules-test\sites\all\modules\webform\webform.module on line 1362."
i go to try an update.php..no block appear
after update.php : it's working !! i had to re-enabled the webform as a bloc, and then it's presently in the blocks list and displayed in the right region.
after trying a submission : 403 error : You don't have permission to access /Modules-test/ on this server.But email is well sended on my mail box...
#84
The patch in #71 worked great for me as an alternate to the webform_block module, thanks!
With webform_block, I encountered an issue where the form's action attribute would be fixed to the url of any visited node if a webform_block block was active there and the caches cleared. The action attribute in the form's own node was also locked to the same url until the cache was cleared on that page. Because of this, submits were simply ignored due to being POSTed at the wrong url.
I'm not having any such problems with this patch! =)
One minor thing though. I applied this to the 6.x-3.x-dev branch (DRUPAL-6--3), but this part failed as it was already in there.
+++ includes/webform.pages.inc 4 Sep 2010 17:45:27 -0000@@ -13,7 +13,9 @@
- drupal_add_css(drupal_get_path('module', 'webform') . '/css/webform-admin.css');
+ // Add CSS and JS. Don't preprocess because these files are used rarely.
+ drupal_add_css(drupal_get_path('module', 'webform') . '/css/webform-admin.css', 'theme', 'all', FALSE);
+ drupal_add_js(drupal_get_path('module', 'webform') . '/js/webform-admin.js', 'module', 'header', FALSE, TRUE, FALSE);
Powered by Dreditor.
#85
author of webform block just has updated his module to work with webform 3.xx...so there is a choice between two ways..
#86
Tried appying the patch to 6-x.3-2 which failed, please confirm which version of the module this patch applies to as tere is no dev version? 6-x.3-dev?
patch < webform_block.patch
patching file webform.module
Hunk #1 succeeded at 856 (offset 3 lines).
Hunk #2 succeeded at 899 (offset 3 lines).
Hunk #3 succeeded at 995 (offset 3 lines).
Hunk #6 succeeded at 2010 (offset -1 lines).
patching file webform.install
Hunk #2 succeeded at 364 with fuzz 2 (offset -17 lines).
Hunk #3 succeeded at 1190 (offset -29 lines).
can't find file to patch at input line 255
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: includes/webform.pages.inc
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/webform/includes/webform.pages.inc,v
|retrieving revision 1.10.2.2
|diff -u -r1.10.2.2 webform.pages.inc
|--- includes/webform.pages.inc 19 Aug 2010 03:00:45 -0000 1.10.2.2
|+++ includes/webform.pages.inc 31 Aug 2010 23:28:33 -0000
--------------------------
#87
@hixster: There is a development version. Though it isn't available on the project page, you can find it on the releases listing page, see here. Furthermore you can check it out from CVS. However the patch still applies fine.
@aiphes: It is up to quicksketch then. Personally I would stick with this patch since it got pretty neat by the end and I even started porting to Drupal 7... :)
#88
subscribe
#89
@hixtser: which tool do you use to apply the patch automatically ? i do thata with my"hand" and notepad++ :)
@sgabe: i think too its better having this include in webform module instead of adding another module (update delay..)
#90
I just used the command line: patch < filename.
In the end I installed the new dev version of the webform_block module and that fixes the issue.
#91
@sgabe - I just saw these warning messages, so thought the patch didnt apply properly.
can't find file to patch at input line 255
Perhaps you should have used the -p or --strip option?
I didn't get the ability to expose the form as a block after the patch, so assumed it didn't apply properly
#92
ok i believed you used a specific software..
#93
@aiphes, patch is a standard command line tool on Linux and OSX machines, not sure about windows.
See here: http://drupal.org/patch/apply
or http://linux.about.com/od/commands/l/blcmdl1_patch.htm
#94
Ok, so I installed the webform 6.x-3.2 and applied the patch given in #71 . Patch installed fine.
But it doesn't seem to work. I have tried with both "webformblock" being enabled and disabled.
I get this error:
user warning: Unknown column 'block' in 'field list' query: INSERT INTO webform (nid, confirmation, confirmation_format, redirect_url, block, teaser, allow_draft, submit_notice, submit_text, submit_limit, submit_interval) VALUES (35, '', 0, '', 0, 0, 0, 0, '', -1, -1) in C:\wamp\www\bentexdp\includes\common.inc on line 3528.
Any clue?
#95
You need to run update.php...don't forget!
#96
Ah good catch. Thanks.
Works now.
It was one of the better replies I have got on the forums :)
#97
A general comment: Block names generated by code are quite funny. Maybe a feature to creator itself the name of the block could work.
#98
Define funny, please. :)
#99
Sorry, I didn't intend to offend, if it appeared so.
So right now the block name comes like "client-block-nid" . I think that is not quite informative, because "client" is a generic term. Instead of this if the block name comes like "formname-webform-block-nid", then that would be more informative.
Also, as I said, we could give the option to user also as to what name he wants to give to the block.
Also, probably the "nid" can be removed from block name, as otherwise the code gets coupled with the admin interface. If somehow user feels that he should delete an existing form and recreate it (for whatever reason), then he cannot simply create a new form with the same name, and be happy with it. Since the node no. will change, he will also have to go and change the code wherever its name appears. This may not work right at once also, as it is very tough to find all instances, and very easy to miss one.
But I guess there might be some reason behind adding the nid in the name. I remember some other module also doing the same.
Please let me know if I misunderstood something.
#100
There's another issue around about specifying "machine" names for each Webform node but I couldn't find it. All your concerns about using NID in the block name should go there instead of this issue. Webform currently is extremely tied to using NIDs as unique identifiers in many places, like in theming template names, function names, form identifiers, e-mail headers, e-mail templates, and other places. It would be very, very difficult to change this to a machine name through out Webform.
So, since we're already using NIDs in so many places, I think that will continue to have to be the case for this patch and we can save the more difficult problem for Webform 4.x when we can break existing APIs.
So for now I think this patch is still pretty good to go, I haven't had time to review it recently but I'll get to it eventually. Any further reviews of the patch will help move it along.
#101
It will be easy to review, it didn't change since you posted it. :)
#102
quicksketch, sgabe,
I found one error with the patch from comment #71:
1. Install Webform 6.x-3.2
2. Create webform with redirection to "<front>"
3. Apply patch from #71
4. Run update.php
5. Visit the "Form Settings" tab of the webform
BUG: The "Redirection location" form item has no default option selected and my previous redirection location is not in the "Custom URL" textfield.
I consider this a bug because data is not being preserved. I imagine this probably happens with URLs other than <front> as well. Other than that, the patch works great! Thanks for the work being put into this patch.
Cheers,
Antoine
#103
Update:
The bug from comment #102 also applies to the October 1st 6.x-3.x-dev install.
Cheers,
Antoine
#104
I applied this patch to the dev release but can't find anywhere to create a block from the form...?
#105
I am attaching a new patch according to the bug reported by Antoine. Another minor bug fixed, the
tfunction name was missing before('Confirmation page'). Besides that still looks good.@bkosborne: First run the update.php, then check the form settings page.
#106
sgabe,
Excellent! You fixed both my issue and the issue described in comment #84. Marking as RTBC!
Cheers,
Antoine
#107
@bkosborne: I had no option in the form settings either, so I just created a view..
don't no if this may help:
when I tried to apply the patch from #71 on webform 6.x-3.2 I got several errors. one of them was that the file to patch couldn't be found and I was asked for the filename, so I typed in "webform.module". I did this 2-3 times, ran update.php and got it running.
#108
I downloaded latest: webformblock 6.x-3.x-dev and I now get a "generate block" button, but it doesn't generate a block.
I running Drupal 6.19, and Webform 6.x-3.2.
Also webform block module loaded into 'core-required' modules area??? does this mean I will not be able to remove it now?!!!
Any ideas guys?
Frank
#109
This patch has nothing to do with the Webform Block module!
Usage:
#110
I've ported sgabe's excellent update from #105 to Drupal 7. I also made one more additional change to only show the block option if the user has either "administer blocks" or "administer site configuration" permission (the latter being used by Context module, which provides similar functionality to the blocks admin page). Doing the same thing for Panels might be a good idea, but I think nearly all users that have access to Panels will already have "administer site configuration" also. There's no point in showing options about making a block if the user can't turn on that block anywhere (or doesn't know what a block is to begin with).
Thanks for all the rerolls and effort guys, I expect a 3.3 version of Webform should be out shortly, including these changes. Thanks!
#111
Thank you quicksketch! I wanted to help with the D7 port but I didn't have the time to finish and post it, sorry about that.
#112
Automatically closed -- issue fixed for 2 weeks with no activity.
#113
Yes, this code doesn't work for me either. I've tried:
<?php$contact_node = node_load(637);
print(node_view($contact_node,false,true,true));
?>
and also this code:
<?php$contact_node = node_load(637);
$contact_node->title = NULL;
print($contact_node);
?>
Neither of which work for me anymore, although they have worked in the past. I just did the security update to Webform 6.x-3.x although I haven't done the Security Update to Drupal core yet.
When I do this, I get the webform printed out in the page correctly, with field labels and everything, but NO actual components show up. The spot for them is there, but they've been stripped out of the HTML. I attached a screenshot of what the form looks like:
#114
This is a closed feature request. If you encounter any bugs, you should open a new issue. Furthermore your problem seems to be irrelevant to this feature.
Please, open a new issue, but first search in the queue, maybe you can find a solution.