WikiFormsBugs

Summary: Bug reports for the WikiForms recipe

Categories: Forms

Wikiform Bug Reports

Page for bug reports for the WikiForms recipe.

The ! qualifier to protect fields from being changed does not work correctly with (text) textarea.

When creating a form they are not editable like the plan text boxes

Navigation fails if I delete an intervening page

I am using the "next/previous" navigation capabilities when viewing via ViewTemplate. I just deleted page 00006. Now page 00005 looks just as if it was the very last page in the list (i.e., no "next" available) and page 00007 has no "previous" available. —Peter Bowers February 18, 2011, at 08:57 AM

Title markup is not stripped from title field when displaying the ViewTemplate

On line 854 $fv[$f[$i]['element']]) should be DeTitle($fv[$f[$i]['element']])) in order to get rid of the title, I think. I noticed it because in my ViewTemplate I tried to put [++'''...'''++] around the title display. Since the title markup is on a second line and the bold/large markups are single-line markups I ended up with a non-functional ViewTemplate. When I changed the wikiforms.php as above everything worked fine (including displaying the title appropriately). —Peter Bowers February 08, 2011, at 02:58 PM

Stating default text doesn't work with explicit two-dimensional field sizes (PmWiki 2.1.17, WikiForms 1.48) - NOT A BUG

I just found that when I supply default text, excplicit field sizes don't work.

If I specify:

Name: name ("Default"=1*50)

I get an erroneous form as the quotation is not correctly parsed.

This feature is not currently supported. You can specify (text=rows*columns) to make a scrolling text box, but cannot specify a default value at this time.

Thanks for the clarification!

Font changes in mid-form, affecting default field sizes (PmWiki 2.1.17, WikiForms 1.48)

If I specify

Name: name ("Default"=50)

the form is OK, but the size information is ignored.

As of 2006-09-02, I am unable to replicate this problem. It works for me; I get a field called name, containing Default, 50 characters wide.

Hm, upon closer investigation, I noticed that it was the first field on my form that is affected, and that I get a proportional font there (Arial or something), but a monotype font (Courier) in the rest of the fields. So the width probably is 50 characters indeed, but the character width differs. So it's a cosmetic problem only. --Henning September 05, 2006, at 09:53 AM

Suffix-defined FormTemplates "cannot be associated" (PmWiki 2.1.17, WikiForms 1.45) - FIXED IN 1.48

These two variants don't work for me:

$Suffix.FormTemplate where $Suffix is any text after a hyphen in the group name (eg PmWiki-Issues)
Forms.$Suffix

--Henning August 23, 2006, at 11:21 AM

Maybe I should try to describe what I'm doing: I've got set up a number of groups named like

 D300-Doks.D300-Doks

These groups work well if they have a template like D300-Doks.FormTemplate. However, if I delete that in-group template and instead create

 Doks.Doks and Doks.FormTemplate

 Forms.Forms and Forms.Doks

I get the following error message:

 PmWiki can't process your request
 cannot associate a form with 'D300-Doks.D300-Doks'
 We are sorry for any inconvenience.

Am I doing something wrong, or have I indeed found a bug? --Henning August 29, 2006, at 05:03 AM

I can confirm the issues as described above. Same here... -hfwang sep02/06

Looks like this broke at some point for some reason. I'll investigate -- currently, it isn't looking up the group suffix, so it isn't finding the template. (a couple of hours later...) Ah! It broke when PmWiki changed $FmtP to $FmtPV. I think I have fixed it -- try version 1.48 jr

Great! It seems that all is working fine with the latest fix hfwang

Thanks! It works as intended with 1.48! --Henning September 05, 2006, at 09:53 AM

CR in text field leads to text suppression in wikilist (PmWiki 2.1.17, WikiForms 1.45, 1.48)

I just noticed that the use of CR line breaks in text fields leads to the suppression of the lines after the first CR in the wikilist.

It would be preferable to reproduce all text up to the next field identifier instead of the next CR (as now).
If wikiform could automatically substitute all user-typed CRs with [[<<]] markup, that might also solve the problem.
Teaching the users to avoid CRs seems to be the most difficult solution :-/

This is not an easy problem to solve in a general way without creating undesirable side-effects. Consider the case of a text field that contains an itemised list. It would not be a good idea to apply any of the proposed solutions to such a field value. The design has to be robust across a wide range of usage scenarios. If the wiki list doesn't show what the user wants, it is surely easy enough to edit the page and change it.

With the amount of text we store in the forms, it would be beneficial to have a simple way of structuring it using by CRs.

Some of the data has been imported from MS Office software where it already had line breaks, so there are lots of pages affected, and an inexperienced user might introduce more unnoticed. To "sell" the WikiForm solution as replacement for the MS Office solution, I pointed out that if desired, it would be possible to copy and paste the complete data back into Excel anytime. The way CRs are handled blocks this route, which is a bit of a problem.

I'm not sure I understand the problem with the itemized list. It wouldn't be rendered as an itemized list in the table, but we'd get the asterisks and the full text if the [[<<]] markup were used as a CR substitute, wouldn't we? From my point of view, that appears better than dropping the lines entirely. --Henning September 05, 2006, at 09:53 AM

The wikilist directive is a compromise. It tries to do something "reasonable" for a wide range of usage situations. This meant making quite a few design trade-offs to get a solution that actually works reliably. In your situation, it's not doing the right thing. But if we change it to support your situation, then it will have undesirable consequences in other situations. For example, suppose a user has made use of the title option; currently, if that field is included, wikilist omits the title directive from the data it retrieves, which is a desirable result. So I think the best option is that rather than change wikilist, you need a new custom directive that emits the entire field value. You may even want it to emit an advanced table and actually process the markup from the source pages.

It may be time to consider creating a custom report writer that lets users build formatted reports from the data on form-based pages. If this is evaluated at the same time as include processing, then all markup will get processed in the display page. jr

You are right! The point about "all markup" is absolutely convincing - I was having problems with the "Attach:" markup, too, and now I see that it's all part of a higher-level issue. My problem is that I'm not PHP-literate, so I'm not capable of creating that custom report writer by myself. Maybe I should try to learn PHP, though I guess even if I take that route, it's going to take some time before I can contribute anything of value.

We are always happy to accept commissions to meet special requirements. Alternatively, you might be able to build close to what you want using the pagelist directive with an include-style format. It depends on what you want the resulting page to look like. jr

Commission is an interesting option, if I can get my employer to fund it. Multinational mega-corporation - no idea if the concept of supporting Open Source development will get accepted by the buereaucracy, but I'm always optimistic :-) I'll also look at the pagelist directive, I haven't checked it out yet but it seems to be a very powerful and universal tool. --Henning September 29, 2006, at 11:52 AM

I just received a discouraging response from within the company :-( I was able to create a useful overview using a customized searchbox directive (hadn't properly understood what it was about before), which I have described in WikiFormsRecipes#pagelist. I couldn't think of a way of providing absolute links in my recipe, though, as this would require manipulation of the field content. (I'm not even sure it's possible at all.) --Henning October 19, 2006, at 10:30 AM

The CR issue is conceptually an important one because once data was entered that way, it's sort of "trapped" in PmWiki because it's not possible to simply copy & paste it back into an MS Office table (as I had promised naively). Fortunately, no-one has asked for that one yet. I guess I could improvise on file level then. --Henning September 22, 2006, at 08:34 AM

"Attach:" markup does not work as text field default (PmWiki 2.1.21, WikiForms 1.48)

I tried to use the following text as default for the first field in the form:

 [[Attach:

The idea was to use this to enter links like the following one:

 [[Attach:Test.txt|Test Document]]

However, after pressing submit to go to the standard edit page, the data entered previously has vanished completely (including the default text).

If I do not provide a default text, everything works an normal. --Henning September 14, 2006, at 09:34 AM

Perhaps the best solution would be to provide an "attach" field type, that automatically wraps the contents in suitable attach markup. jr

Good idea. I guess it would have to have two components, filename and link text. (I also thought about having link text only and provide a clickable symbol for uploading, like for the "?update=y" action, but while convenient, that would have some disadvantages if the filename already exists etc.) --Henning September 29, 2006, at 11:52 AM

Here is a suitably modified file (wikiform-attach.php Δ) that adds an (attach) field type as described, which inserts the markup: Attach: before the field text. It does not provide an alternative link text option. (I couldn't work out the reg expressions syntax to adapt the function DeLink, so I added a new one DeAttach.) Francis March 05, 2007, at 05:03 AM

PHP error message upon editing password-protected pages, date field related (PmWiki 2.1.21, WikiForms 1.48, 1.50)

This one took me unaware, but it's sort of a biggie.

If I edit a page that is protected by a write password and I have not entered that write password yet, I get the following error messages:

: Warning: implode() [function.implode]: Bad arguments. in C:\Programme\Apache Group\Apache2\htdocs\pmwiki\cookbook\wikiform.php on line 444
: Warning: Cannot modify header information - headers already sent by (output started at C:\Programme\Apache Group\Apache2\htdocs\pmwiki\cookbook\wikiform.php:444) in C:\Programme\Apache Group\Apache2\htdocs\pmwiki\pmwiki.php on line 884

The error occurrs in the line that implodes the date field:

 implode('-',$_REQUEST[$f[$i]['element']]));

The result is the loss of the data entered in the date field.

The sequence is as follows:

System displays form
User presses "Edit Form" button
System displays password prompt
User enters password
System displays PHP error message with edit page missing the data for the date field
User makes changes and presses "Save" button
System displays password prompt again
User enter password again
System displays changed page

(I have set up numerous WikiForm instances in my Wiki, but they are either not password-protected at all, or they are protected by a read password that simultaneously serves as write password, so the password prompt never came up precisely after pressing "Edit Form" before.) --Henning September 15, 2006, at 09:36 AM

Version 1.50 may fix this problem. I changed the code to open forms for editing with $auth='edit', so now PmWiki should prompt for a password before loading the form for editing, not after. jr 27 Sep 2006

Unfortunately, the problem remains the same (but the warning occurs in line 449 now, confirming that I'm using the new version). Should I use a specific version of PmWiki? I have not upgraded to 2.2.x yet. --Henning September 29, 2006, at 11:52 AM

I seem to have a solution to this issue using wikiforms 1.77 (where the FormValues function calls RetrieveAuthPage instead of ReadPage like it did in 1.71). When the page already exists the password is asked for before the form is displayed and everything works fine. If the page doesn't already exist you get the problem. So I added code to do a RetrieveAuthPage to a page that has the attr appropriately set. I don't do anything with the page but it causes the password entry page to come up before the form is displayed.

  function EntryForm($pagename,$action,$method,$FormPageFmt,$opt=NULL)
  ...
            $fve = $FormValuesFunction($pagename,$f,'edit');
			foreach ($fve as $k => $v) $$k = $v;
        } 
		else 
		{
			$g = FmtPageName('$Group',$pagename);  //{MSB} get the group for the form
			RetrieveAuthPage($g . ".Form", 'edit', true, READPAGE_CURRENT); //{MSB} causes login when the user hasn't logged in with the edit password.  page ".Form" needs to be have attr edit set appropriately.
			$FmtP['/\\$LastModified/e'] = '$GLOBALS[\'CurrentTime\']';
		}

I believe the real issue is that $_POST['text'] = FormData($pagename,$WikiFormPageFmt) needs to be called after the password login as this modified $_POST is lost. --MSB

Layout problem with ?update=y (PmWiki 2.1.21, WikiForms 1.50)

I've found a layout problem with the ?update=y action: If an updatable link is displayed in a table field and the link text is close to the maximum size of the field, the update symbol vanishes (MS Internet Explorer) or moves to the left side, graphically overlapping the attach link (Opera). I'm not using any special CSS files.

I suspect that the upload symbol is not figured in when determining table row height, and the apparently vanished symbol is actually moved to the (invisible) second line in a table field if it's wrapped around. (I'm using the default upload symbol which appears to be a superscript Delta.) --Henning October 23, 2006, at 10:18 AM

PITS

00726 Coding error in wikiform.php version 1.45
- I think this was fixed some time before 1.52, although I don't remember doing so. jr March 22, 2007, at 07:17 PM