When I tried to use Twiki, I found that documents containing long topics would not be saved correctly. When digging deeper I saw that my netscape (but, as I found later, also IE) does not allow reading more than (approx) 1K of text in a hidden variable, thus challenging the preview script. I found nowhere in the documentation a statement about there being a limit to the amount of data in a hidden variable, but I presume that this did not show up in other installations, since no BugReport exists about this.

I currently don't know whether this is actually a faulty installation in my setup (Debian Linux/apache/Netscape 4.5x) or a feature. I found a workarround by modifying preview.tmpl to include a little JavaScript function that changes the hidden variable value, and calling it by an onClick() before submitting.

-- EnriqueMelendez - 26 Sep 2000

I am just shooting arrows in the dark here but webservers (and of course the CGIs) let you limit the size of POSTs. You should check to see if there is any such limit configured in your apache installation as I can't understand from your description what magic your JavaScript is doing to make it work. I don't if the limit can be configured to be per variable.

-- ManpreetSingh - 26 Sep 2000

Posting Enrique's email to me - ManpreetSingh 27 Sep 2000

The problem does not lie en the POST limits. I have checked these (in CGI.pm), and are not further modified by wiki.pm. Moreove, the preview goes OK, so that the first POST poses no problems. The problem comes when saving. The current mechanism goes by setting a hide variable (text) in the form. It is this variable that gets cut (at arround 1k of text), so that for example, whatever the text I insert in the page, the following is displayed in by the view/source menu of Netscape (don't play attention to line breaks):

-------------------------------------------------------------------
<INPUT type="hidden" name="text" value="When I tried to use Twiki, I found that documents containing long topics would not be saved correctly. When digging deeper I saw that my netscape (but, as I found later, also IE) does not allow reading more than (approx) 1K of text in a hidden variable, thus challenging the preview script. I found nowhere in the documentation a statement about there being a limit to the amount of data in a hidden variable, but I presume that this did not show up in other installations, since no BugReport exists about this.

I currently don't know whether this is actually a faulty installation in my setup (Debian Linux/apache/Netscape 4.5x) or a feature. I found a workarround by modifying preview.tmpl to include a little JavaScript function that changes the hidden variable value, and calling it by an onClick() before submitting.

-- EnriqueMelendez - 26 Sep 2000 <br>

I am just shooting arrows in the dark here but webservers (and of course the CGIs) let you limit the size of POSTs. You sh">
----------------------------------------------------------------------

The INPUT tag ends just like that, with the ">.

The JavaScript overrides the problem because it sets the variable after the page has been read (actually, as I said, onClick()). I tried with an HTML page (not one generated from the perl scripts, but a real one with a lot of text in a hidden variable and the same thing happened. I also checked that the information was sent to the client, by writing $tmpl to a file.

---

If you can see this: I don't seem to have the same problem, and I'm writing this from pretty much the same setup. Debian 2.2/netscape 4.75.

The question what is the difference to make your setup not work.

-- NicholasLee - 27 Sep 2000

Transferring the same text twice is not very efficient when editing through a slow modem line (As i'm doing now). Why not storing the text in a unique temporary file and pass the name of this file in the hidden variable? This could be a file per topic (overwritten at each new "edit", and possibly removed when "unlocking" the topic, in this way one does not even need to pass the name of the file), or a file removed by cron.

-- FrancoBagnoli - 01 Oct 2000

Actually the twiki-cvs hack I wrote a while back had the potential to do something like this. Best way to do store in based on username. ie. some key like username.web.topic. You'd also need some reaper to delete old unsaved topics.

-- NicholasLee - 01 Oct 2000

I'll have a look to your hack. But I wonder: why do I need username.web.topic? since only one person at a time can edit a given topic, isn't simpler just to have a topic.tmp file, companion to topic.txt ? No needs to delete anything.

Moreover, it has the further advantage that an interrupted editing (due to netscape crashing, for instance) can be recovered (if one "previews" the topic often).

-- FrancoBagnoli - 02 Oct 2000

Hello, I'm here again. I think that the problem came from netscape, for this is now 4.72 and works. As I said previously, I also experienced the problem with IE 4 (didn't try IE5). Some sort of warning for the installation would be of use, since it took me some time to find out what was on.

As to the solutions proposed, I think I would be happier with the code as it stands, with no more temporary files. The problem of twice transferring the text (which I also find excessive) could perhaps be overcome by modifying the javascript function to both supply the hidden variable and the text for the page (some sort of post-processing would then be necessary, of course, but no more than what is now done to put the text in).

In any case, thank you for your interest in my problem, and for the too, which I find very useful.

-- EnriqueMelendez - 11 Nov 2000

I am closing this bug report since it is not directly related to the TWiki engine.

-- PeterThoeny - 25 Nov 2000

TopicClassification:

BugResolved