#foswiki 2015-06-26,Fri

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
gac410Yeah. 1.2 means that a lot of stuff like that goes away. Rest is always utf8, as is foswiki core, so no decoding needed.
Unfortunately MichaelDaum has been committed on other stuff and has not had time to work on his extensions.
[00:00]
jesuisseHmm, so I can just throw out the whole decode call? [00:01]
gac410hang on ... I'll look at it.
Some of this is discussed here: http://foswiki.org/Support/Utf8MigrationConsiderations#Extensions
[00:01]
jesuisseJust tried to make urlDecode into a noop but this breaks when the Topic Name contains special characters... [00:03]
gac410I think you just want to get rid of the two lines:
my $downgradedValue = $session->UTF82SiteCharSet($value);
 $value = $downgradedValue if defined $downgradedValue;
[00:05]
jesuisseNo, that doesn't help... [00:06]
gac410hm. They guys that know this stuff better are in Europe. so sleeping [00:06]
jesuisse:-) So should I open a task for this and let them fix it? [00:06]
gac410What happens when you eliminated the two lines? [00:07]
jesuisseThe same as when I didn't touch any of the code - HTTP error.
And when I make the urlDecode a No-op, the topic name gets decoded into something really strange (or more likely it doesn't get correctly decoded)
Do you know if UTF82SiteCharSet was renamed to something else? Or removed completely?
[00:07]
gac410There is no site charset any more. That code is all gone I think. [00:09]
jesuisseok...
Oh, so maybe removing those two lines actually works but I have to remove more code somewhere else in the plugin.
[00:09]
gac410yeah I don't really know.
I just in stalled TopicInteractionPlugin, but I've got nothing set up to test it with.
[00:10]
jesuisseProbably just NatSkin uses it :-(
I'm not so sure about urlDecode not being needed any more, though. Aren't special characters in URLs encoded in some percent digit digit encoding? This would have to be decoded into perl's representation of utf 8, right?
[00:11]
gac410Yes you need urlDecode, it's just the utf8 part you don't need.
my $downgradedValue = $session->UTF82SiteCharSet($value);
[00:14]
jesuisseI see... [00:14]
gac410$value is already in utf-8 if it came from rest, [00:14]
jesuisseWell if I take out that line, I get another error: "Topic Main.DünenRöcke does not exist"
The Topic name was DünenRöcke.
But at least that's better than Internal Server Error :-)
[00:16]
gac410okay, yeah something isn't being correctly encoded.
It's hard to say, since I really don't know much about that extension.
[00:17]
jesuisseI opened a question in the support section on Foswiki a while back, but it now seems this is a genuine bug. Are you one of the Developers? Should I file a bug report in the Task section? [00:21]
gac410Yes. I'm release manager for 1.2. But I don't do anything with MichaelDaum's "Nat" ecosystem ;)
I'm guessing that $value needs to be passed through either Foswiki::encode_utf8($value) or Foswiki::decode_utf8($value)
[00:22]
jesuisseWell, let me try that real quick. [00:23]
gac410I think it's going to be encode_utf8.
It may be that the extension dips into the CGI parameters directly, in which case it might need to encode. I'm afraid I still get pretty confused by all this. Sorry...
[00:23]
jesuisseTell me about it. I've been using Foswiki since it forked and character encodings have been a nightmare ever since...
(and before that with Twiki too, I guess)
[00:25]
gac410yeah. This should be a huge step forward. All the special encoding are gone. Word from others using i18n characters is that it "just works" [00:26]
jesuisseThat's what I noticed with 1.2.0, except hat uploading using NatSkin produces the error I mentioned. All the other stuff seems to work just fine without any tweaking in bin/configure. [00:27]
gac410The only thing messed up in 1.2, and will ship that way :( are sorting, and Backlinks [00:27]
jesuisseWhat's wrong with Backlinks? [00:28]
gac410Unfortunately it will take some time for extensions to "catch up".
Backlinks uses hardcoded A-Za-z type regexes. don't work well with international names
[00:28]
jesuisseah. ok. [00:28]
gac410We need to rewrite it, and I don't want to delay 1.2 for this.
It also gets badly broken if a topic name contains "regex" characters. Some+Name as a topic name and backlinks falls apart
[00:29]
jesuisseWell, I have a 1.1.9 in production which has a lot more problems with Umlauts etc, so I might switch to 1.2.0 despite backlink problems if I can fix the upload problem. Umlauts are a huge thing for German users, so this seems like a big step forward to me.
when do you release 1.2.0?
[00:30]
gac410I want to build the RC on Monday, and if all goes well, we'll release on the 4th of July ;) [00:32]
jesuisseLook at all the fireworks for the release :-) [00:33]
gac410For an example of some utf8 "acid tests" see http://trunk.foswiki.org/TestCases/TestCaseUtf8Errors and http://trunk.foswiki.org/TestCases/TestCaseUtf8Rendering
It was a big risk moving ahead with the utf-8 / unicode core. But it solves so many issues, we took a risk and went for it.
[00:33]
jesuisseI think it was the right decision. It had to be tackled. BTW, tried both encode_utf8 and decode_utf8 and no joy... I think I'll open a new task and let the experts handle it. Thanks for the support effort. [00:34]
gac410okay. yeah I was afraid of that. Thanks. We are hoping MichaelDaum will get some time soon. He's been out straight on some other work. [00:35]
jesuisseYeah. If I have some time tomorrow, I might tinker with it some more, otherwise I'll just wait for Michael to get around to it. [00:36]
gac410Okay. I've got it installed. The issue is that the extension is dipping into the CGI object and processing the parameters directly. They all need to be encoded. I'll tinker a bit. [00:45]
jesuisseThanks. I opened Item13477 for the problem, just in case you fix it :-) [00:46]
FoswikiBothttp://foswiki.org/Tasks/Item13477 [ Item13477: Using TopicInteractionPlugin to Upload an attachment produces an Internal Server Error ] [00:46]
gac410I/m sure there are more. But in Core.pm, it needs at line 200
$topic = Foswiki::decode_utf8($topic);
It will probably need to do that for each parameter it accesses directly.
It successfully uploaded a ascii named attachment to a utf-8 named topic.
[00:47]
jesuisseJust a sec [00:48]
gac410Probably line 220 for decoding the filename [00:48]
jesuisseHmmm, doesn't work right yet, at least not for topic names with umlauts in them. [00:49]
gac410I uploaded to TestTöpic umlat over the o [00:50]
jesuisseStrange. Did you just commend out the two lines in urlDecode and add the decode_utf8 at line 200? [00:50]
gac410Yes [00:51]
jesuisseCan't reproduce it. It still says "Topic Main.D%C3%BCnenR%C3%B6cke does not exist" for my DünenRöcke topic. [00:53]
gac410Well it definitely needs some work. Uploaded a filename with a umlat and it corrupted the filename. [00:54]
jesuisse:-( Well, it's 3 a.m. over here. I need to get some sleep. Thank you for your help. I'll tinker some more tomorrow. [00:54]
gac410okay goodnight.
Are you running on a macintosh osx as your client?
[00:54]
jesuisseUbuntu Linux 14.04
Both Server and client.
[00:55]
gac410okay. just checking, osx does some strange stuff with unicode normalization.
I'm on ubuntu 15.04 both client & server
(same laptop ;)
[00:55]
jesuisseOk, time to go catch some sleep. Thx & till other time, hopefully. [00:58]
***jesuisse has left [00:58]
..... (idle for 21mn)
jomogac410: could you try? 1.) press create new topic 2.) unchek only wikiword 3.) enter (__) and click create a topic. Try other combinations, like _{}_ and so on.. also try enter only one backshlash ... this is probably a bug? [01:19]
gac410you want a topic named only with an underscore? [01:20]
jomo(__)
not want - only trying what the FW does for some "strange" topic names...
after the create, check the WebIndex ;)
[01:21]
gac410Yikes Topic name became /(<strong><em>) [01:23]
jomoit also creates a topic with a name \ (one backshsah) but not editable ... [01:24]
gac410gac410 needs to try on 1.1.9
Well 1.1.9 does the same thing. So definitely not a 1.2 blocker.
[01:25]
jomook, good.
for the normalisation bed-time theme added some points to thinks about - http://trunk.foswiki.org/Sandbox/UnicodeNormalisationOutpourings :)
[01:26]
gac410Even if we eventually go with NFD by default, I still like the idea of calling NFKD() for each sort comparison. I've added it to Store, Attach and TablePlugin and it all behaves very nicely.
But that's for after 1.2
if at all
[01:29]
jomokk [01:30]
........................................................ (idle for 4h39mn)
***ChanServ sets mode: +o MichaelDaum [06:09]
.... (idle for 16mn)
ChanServ sets mode: +o CDot [06:25]
............................................................................... (idle for 6h33mn)
ChanServ sets mode: +o gac410 [12:58]
.... (idle for 18mn)
gac410Hi MichaelDaum Did you see Item13477 :( I tried a bit to fix it but will all the direct cgi param processing, I got a bit lost. [13:16]
FoswikiBothttp://foswiki.org/Tasks/Item13477 [ Item13477: Using TopicInteractionPlugin to Upload an attachment produces an Internal Server Error ] [13:16]
MichaelDaumhey gac410 [13:17]
gac410The internal server error was easy to fix. But it also needs some decode_utf8 calls [13:17]
MichaelDaumthat's the kind of trouble I was expecting :(
whatever patch you come up: backwards compatibility is mandatory.
[13:17]
gac410I got to the point that it was handling utf8 topic names correctly, but I'd still get the attachment uploaded names messed up.
Well I wanted to get it working first, then it's easy to add the if $Foswiki::UNICODE
[13:18]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::UNICODE [13:18]
gac410Since I don't really use NatSkin, I don't know much about the plugin. [13:19]
MichaelDaumyear or $session->can(non-standard-api)
TopicInteractionPlugin isn't NatSkin specific
[13:19]
gac410I installed it and enabled topicinteraction skin but it really messed the attachments tables, so I suspect I'm missing something. [13:20]
MichaelDaum1.1.9er PatternSkin? [13:21]
gac410No 1.2.0 ... pseudo-installed on trunk [13:22]
MichaelDaumjust fine over here using ?skin=topicinteraction,pattern [13:22]
gac410I get stuff like %RENDERFORDISPLAY{ topic="Usersweb.WebHome" revision="" excludeattr="[hH]" header="$percntTAB{\"Data form\" id=\"dataform\"}$percnt $percntBUTTON{\"Help\" title=\"Read more about Data Forms\
Ah darn. Never mind.
pseudo-install doesn't do dependencies. :P
That's why I said I was missing something. I am
We really need to rewrite pseduo-install and Package, so that we have one and only one extension installer.
[13:23]
Ah. okay now with all the dependencies installed, things look visually okay :) [13:35]
........... (idle for 52mn)
CDotgac410: I'd kinda like FW to work without *any* skin (i.e. no PatternSkin) installed
I'm a minimalist
[14:27]
gac410;) [14:27]
CDot"But it also needs some decode_utf8 calls" - that sounds unlikely [14:28]
gac410If I try to attach a file to TestTöpic, it corrupts the topic name and claims not found. Calling decode on the topic name fixes it.
The plugin reads the topic name directly from the CGI params: my $topic = $params->{topic}
It's doing the same thing when trying to attach a utf8 filename, but that one seems more difficult to fix :(
It uploads/attaches a filename as TestT�picAttachment
It does some stuff I'm not sure how to handle. It processes the CGI parameters, and then updates them back into the cgi params to "pass to delegates"
So I'm not sure where / how to fix the encoding
[14:30]
CDotthis is TopicInteractionPlugin? [14:38]
gac410Yes [14:38]
CDotCDot reviews the code [14:38]
gac410It calls UTF82SiteCharSet ... I removed that call. [14:39]
CDotok, problem 1) is: $message = JSON::to_json($message, {pretty=>1}); $response->print($message);
JSON::to_json generates UTF-8, which is then being passed to $response->print, which expects Perl characters. So It'll end up double-encoding
[14:41]
gac410Ah... [14:41]
CDotcall ->body( instead, it'll work the same on 1.1.9 and be portable to 1.2.0
$message = JSON::to_json($message, {pretty=>1}); $response->body($message)
[14:42]
gac410So my decode_utf8 was reversing the double-encoding [14:42]
CDotdon't see anything else obviously wrong
"sanitizeAttachmentName" looks a bit questionable
but the core code is questionable in that area as well (really there's no justification for "sanitising" attachment names any more)
[14:43]
gac410And this stmt: my $downgradedValue = $session->UTF82SiteCharSet($value); just goes away, or is that needed on 1.1.9 [14:47]
hm. Still having some issues: Topic Litterbox.TestTöpic does not exist (when I try to attach)
That was one I had to fix with the decode. But before, it was corrupted. now the topic name looks fine. hm
[14:52]
CDotCDot doesn't see where that is
yes, that need to be iffed out
unless ($Foswiki::UNICODE) {
[14:53]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::UNICODE [14:54]
CDotmy $downgradedValue = $session->UTF82SiteCharSet($value);
$value = $downgradedValue if defined $downgradedValue;
}
[14:54]
gac410yeah for now I just commented it [14:54]
CDotsure [14:54]
jastIIRC to_json doesn't actually change the value. if it generates incorrect things, the source data is probably wrong. *encode_json* does another encoding cycle. [14:54]
CDotuse JSON; # imports encode_json, decode_json, to_json and from_json.
# simple and fast interfaces (expect/generate UTF-8)
from "perldoc JSON"
ah, the "expect UTF-8" might be a problem in that :-(
no, sorry, it's not. It means the decode expects utf-8, which is reasonable
not that internal data must be utf8-encoded bytes
[14:55]
gac410The upload attempts to upload TopicInteractionPlugin - param topic=Litterbox.TestT%C3%B6pi [14:57]
CDotthat looks ok (ish)
except for the missing 'c' at the end
CDot doesn't know how to use the plugin, so can't really comment
[14:57]
gac410c/p error :D
yeah I'm sortta in the same boat. But it's a drag/drop uploader. kinda cool actually
[14:58]
CDotFailed to open pub/System/TopicInteractionPlugin/browserplus.init.js to read: No such file or directory at ./pseudo-install.pl line 1060.
huh?
[14:59]
gac410pseudo-install gets all messed up. But it does install a workable extension.
Have to manually patch in the {Module} names :( I thought I didn't need to do that. Totally confused I no-actioned a task I need to reopen
Also need to install deps: ./pseudo-install.pl FilterPlugin FlexFormPlugin MimeIconPlugin RenderPlugin
[14:59]
CDotCDot gives up [15:01]
gac410:)
Okay. This comes back to needing to decode the CGi parameters.
printed input to topic_exists web='Litterbox', topic='TestTöpic'
[15:01]
CDotso long as the params are coming from the Foswiki::Response, they *are* decoded [15:03]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Response [15:04]
gac410No it's coming from the CGI query
my $request = Foswiki::Func::getCgiQuery();
my $params = getRequestParams($request);
[15:04]
CDotsorry, Foswiki::Request [15:04]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func
http://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Request
[15:04]
CDotFoswiki::Func::getCgiQuery returns a Foswiki::Request (which is a subclass of CGI, when using the CGI engine) [15:05]
gac410So the very next two lines:  ($web, $topic) = Foswiki::Func::normalizeWebTopicName($web, $topic);
 print STDERR "web='$web', topic='$topic'\n";
caused the print: web='Litterbox', topic='TestTöpic'
$topic = Foswiki::decode_utf8($topic); fixes the problem. LIne 200 Core.pm
[15:06]
CDotwrong, wrong, wrong
there should never be a need to decode in a plugin
[15:09]
gac410I'm not saying it's right ... I'm saying it makes the plugin work So it's a symtom of something else wrong [15:09]
CDoty. Well, the Foswiki::Request is deffo decoding the CGI params, otherwise nothing else would work [15:10]
gac410So except for needing that extra (wrong wrong wrong) decode_utf8 ... the plugin is now working. Uploading utf8 attachments to utf8 topics.
I can't explain why it's needed, but it won't work without it. hm This is a REST request. Are we somehow failing to do the decode in rest requests?
[15:13]
jastin unicode mode things are always decoded when they enter your perl code
except if you're maybe getting your data from a perl XS module
[15:17]
gac410gac410 has no idea. Dipping down into "it's magic" :D [15:17]
CDotgac410: unless $request is not (for some reason) a Foswiki::Request [15:20]
gac410Looking at Func, it should be a Foswiki::Request. I'll data::Dumper it. [15:20]
CDotoh, crap, no, I'm wrong
sorry, I *did* fully decode ->param for a while, but i found several plugins that wouldn't work that way
Foswiki::Request->unicode_param() (same params) will take care of the decode for you
same problem as multi_param :-(
[15:21]
gac410Hm So advise on making that backwards compatible? [15:22]
CDot$Foswiki::UNICODE [15:22]
gac410Okay
hm so $params->{topic} changes to $request->unicode_param('topic') ???
[15:22]
CDotthe original code should be OK
i.e. param is still UTF-8 encoded
[15:25]
gac410Well it doesn't work unless I decode it [15:25]
CDothmmm
ah yes, it won't
so how did the original code get it to {Site}{CharSet}
[15:25]
gac410called UTF82SiteCharset [15:26]
CDotok [15:26]
gac410but not there. ... later [15:26]
CDotyeech [15:26]
gac410That was not decoded. But maybe it didn't work with utf8 topic names. [15:26]
CDotUTF82SiteCharSet was effectively a NOP if {Site}{CharSet}=='utf-8' [15:27]
gac410yeah. [15:27]
CDotyou are right, though, if ($Foswiki::UNICODE) then a simple decode_utf8() is appropriate [15:28]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::UNICODE [15:28]
CDotso my "wrong, wrong, wrong" was "wrong" [15:28]
gac410Ah. good. so a quadruple negative not a triple negative :D [15:28]
CDotwrong wrong wrong was wrong, so right.
ugh. Just spotted another nasty in JsonRpcContrib
damn, I'd forgotten about this decode problem
tends not to show up until you explicitly play with wide-byte topic names
[15:29]
gac410MichaelDaum: I have a fix then for TopicInteractionPlugin. ... Want me to check it in? I did the checks so it *should* be backwards compatible. [15:31]
MichaelDaumcould you paste the patch to the task item before please? [15:31]
gac410Yes will do. [15:32]
MichaelDaumthanks a lot
http://dev.atomikos.com/Blog/TCCForTransactionManagementAcrossMicroservices
sorry
[15:32]
CDotargh, JsonRpcContrib handles username and password too, both of which may contain wide-byte characters :-/ [15:32]
gac410So is the call to decode_utf8 still valid or are you addressing it in JsonRpcContrib ? [15:33]
CDotIt can't be addressed there [15:33]
gac410okay. I'll post my fix then. ty [15:33]
CDotyou need to call it, if $Foswiki::UNICODE [15:33]
gac410yes that's what I did
MichaelDaum: Patch posted to Item13477
[15:33]
FoswikiBothttp://foswiki.org/Tasks/Item13477 [ Item13477: Using TopicInteractionPlugin to Upload an attachment produces an Internal Server Error ] [15:36]
gac410Damn. Now the problem moves. Can't click / view an attachment with utf8 characters [15:40]
CDothmmm, just noticed that JsonRpcContrib decodes the POSTDATA to the site charset before passing it to JSON for parsing. But JSON expects input data to be encoded using UTF8
gac410: I just unocvered a problem passing a UTF8 topic name in the -topic= parameter, if that helps....
[15:40]
gac410Works fine with pattern skin, so something else
I think that's part of the issue that the decode_utf8 fixed maybe??
[15:41]
CDotno [15:42]
gac410Okay, so when viewing an attachment, I get the url: .../pub/Litterbox/TestT%C3%B6pic/TestT%F6pic.txt
The Topic and Attachment names should be identical. The attachment is indeed the topic txt file. (Lazy, and it gave me a utf8 filename :D )
If I view the attachments with PatternSkin, I get ...pub/Litterbox/TestT%c3%b6pic/TestT%c3%b6pic.txt
MichaelDaum: What's rendering the Attachments table?
[15:43]
MichaelDaumMichaelDaum on a call [15:47]
gac410Issue seems to be in TopicInteractionPlugin/Attachments.pm
It's the urlencode routine in Attachments
urlencode TestTöpic.txt returns TestT%F6pic.txt
[15:51]
CDotthat's encoding a unicode codepoint, I suspect [15:56]
gac410$text =~ s/([^0-9a-zA-Z-_.:~!*\/])/'%'.sprintf('%02X',ord($1))/ge;
yup
[15:56]
CDotit probably needs to be put through encode_utf8 first [15:56]
gac410okay ... I'll try it. [15:56]
CDothum, should urlEncode *always* put things through encode_utf8?
it already does :-/
[15:56]
jastit probably should, yes [15:57]
CDotFoswiki::urlEncode automatically encodes to utf8 [15:57]
gac410Plugin provides it's own urlEncode [15:57]
CDotthere you go, then
why?
[15:57]
gac410No idea
gac410 doesn't do why questions :P
Especially on someone elses code
[15:57]
CDotCDot always tries to comment his dubious decisions
of which I'm currently finding more and more :-(
[15:58]
gac410My guess... is urlEncode backwards compatible to Foswiki 1.0 ? [15:58]
CDotAFAIK, yes [15:59]
jastyes, just checked [15:59]
gac410Anyway calling $text = Foswiki::encode_utf8($text) if ( $Foswiki::UNICODE ); fixes it. Need to defer to MichaelDaum about the "Why" questions [16:00]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::UNICODE [16:00]
CDotnah, he'll just give some entirely plausible reason that ultimately boils down to "because". [16:01]
gac410Hm core also urlencodes # Michael's version does not. [16:03]
CDotperhaps he's passing it a string that has a fragment identifier in it?
erm. Do we want to be able to give skins names with unicode chars in them?
[16:04]
gac410CDot just went over my head :) [16:05]
CDotcurrently we're restricted to ASCII in skin names [16:05]
gac410I don't see why that is important to support. Users seldom directly interact with skin names. [16:05]
CDotglad you agree [16:06]
gac410That would be a mess down in template handling I bet. [16:06]
CDotdon't think so; I'm pretty sure I catered for it down there
it's more an issue when interpreting ?cover= and ?skin=
[16:06]
gac410Anyway for 1.2, unless something is seriously broke, don't fix it :D [16:07]
CDotBTW a fragment identifier is just a #GoHere at the end of a URL [16:07]
gac410Same as an anchor?
Or is that the rfc terminology
[16:07]
CDotsame thing. the proper name is a "fragment identifier" [16:07]
gac410Ah. okay [16:07]
.... (idle for 17mn)
So CDot .. out of all that did you find a "nasty" we need to address for RC1 Or is it just some docs needed in the UTF8Migration topic [16:24]
CDotsadly more than docs [16:24]
gac410:( [16:24]
CDottrying to minimise the impact [16:24]
gac410okeydokey [16:25]
CDotonly affects a very limited set of cases, all involving multi-byte chars in topic/web/attachment names
but important
[16:25]
MichaelDaumgac410, thanks again fir the patch. Nothing too seriously broken I guess other than the plugin creating garbage on an unicod-ified Foswiki core [16:35]
gac410yeah. with CDot's help it was a pretty easy fix. And should be backwards compatible. [16:36]
MichaelDaumfeel free to checkin this patch and I'll take care of merging it with my local stuff. [16:36]
gac410One "why" question :D Why not encode # in urlEncode ... that way you could use the Core urlEncode
Seems to be the only difference
[16:36]
MichaelDaumsimple miss out I guess [16:36]
gac410okay. Any objection if I just call Foswiki::urlEncode. One less UNICODE specific test. [16:37]
MichaelDaumurlEncode never is/was part of the official (Func) api so I tend to use a local one. [16:37]
gac410Ah. hm maybe we ought to elevate that one. someday good point.
I'll leave well enough alone.
[16:37]
MichaelDaumthere are some other goodies in Foswiki.pm that would be great to stabilize via Func [16:38]
gac410yeah I agree. [16:38]
MichaelDaumsuch as takeoutBlocks [16:38]
gac410yup I've cheated and used that too. [16:38]
MichaelDaumputBackBlocks
all the different encoding/decoding stuff
problem - again - is backwards compatibility. we probably would need a PatchItemContrib to forward those APIs
[16:38]
GithubBot[TopicInteractionPlugin] gac410 pushed 1 new commit to master: http://git.io/vtWyH
TopicInteractionPlugin/master 52ea281 George Clark: Item13477: Compatibility with UTF-8 core on Foswiki 1.2
[16:40]
***GithubBot has left [16:40]
FoswikiBothttp://foswiki.org/Tasks/Item13477 [ Item13477: Using TopicInteractionPlugin to Upload an attachment produces an Internal Server Error ] [16:40]
MichaelDaumhey I am leaving into my weekend now. kids are waiting for dinner and movie time. back on Monday. see you. [16:41]
gac410see you.
need to think about releaseing TopicInteract ... or 1.2 users of NatSkin will be left behind
RC1 coming on Monday hopefully
[16:41]
CDotthe original reason I didn't export more of those functions was a desire to keep their specs from getting too locked down [16:42]
MichaelDaumthere are tons of changes in loads of plugins that I could push. but I simply run out of hands and arms atm. [16:42]
gac410At least this one wasn't too complex. CDot makes it look simple :) [16:43]
CDotpffft..... /me is in the process of tripping over his own underwear :-( [16:43]
gac410There has generally been very good feedback on Beta2 ... I think there are even some sites who have gone live. [16:45]
CDotcrap..... CommentPlugin uses CGI::hidden, which doesn't utf-8 encode Perl strings passed to it [16:46]
gac410Yeah the sooner we dump CGI:: methods, the better off we'll be. [16:47]
CDot<input type="hidden" name="topic" value="MꟸltiByte" />
should be MꟸltiByte
almost looks like it's been *double* encoded
[16:48]
gac410gac410 still has trouble recognizing when encode / decode / or double encoding has happened. [16:49]
CDotit can be tricky, esp with multi-byte chars [16:51]
......... (idle for 44mn)
ah shit, this is more complex than I'd bargained for :-( [17:35]
....... (idle for 31mn)
"wrong, wrong, wrong" was right after all.
gac410: I need you to revisit the TopicInteractionPlugin
no, forget it. I can see what is wrong. The plugin is doing it's own parse of the query string to extract parameters
so really it's shooting itself in the foot (and the head, if you ask me, but hey)
my $queryString = $ENV{QUERY_STRING} || '';
foreach my $item (split(/[&;]/, $queryString)) {
nothing like making life hard for yourself (and us)
CDot gives up and goes to the pub
[18:06]
................... (idle for 1h30mn)
gac410The parse of QUERY_STRING seems to be used in a non-POST situation. Not sure why it's needed. In my testing so far, it doesn't come into play.
But there is definitely some double-encoding going on. :(
In some cases the topic name seems to get encoded a 2nd time, no idea where.
If I don't encode it, Attach fails. If I DO encode it, changing a comment fails
[19:39]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)