#foswiki 2015-09-11,Fri

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

WhoWhatWhen
jomohi gac410. Did you checked the attached i.html file to the Item13696 ? [00:51]
FoswikiBothttp://foswiki.org/Tasks/Item13696 [ Item13696: Some attachments can be unreachable with non-UTF8 store encoding. ] [00:51]
..... (idle for 24mn)
gac410jomo, can't read the file. we block html attachments. But as diplomatically as possible, your statements about URLs must be utf-8 are completely wrong. You are reading the wrong paragraph of the RFC.
You are quoting paragraph that describes the encoding of the reg-name or hostname, and that MUST be utf-8 if non-ascii. You are correct in what you post.
But the component in question is not the reg-name. You keep quoting from section 3.2.2 ...
And I wrote all this up, and one of us used the backspace key and clobbered it. So I need to write it all again :(
The path is defined in paragraph 2.5, covered under "Identifying components" and is NOT as restrictive as the reg-name
There is no ASCII requirement, only that *if* characters are in the UCS (ie UNICODE) then they have to be utf-8 ecoded
It is perfectly acceptable to use other encodings in that component.
[01:15]
Anyway, once you get past the reg-name and into the path, in the case of the pub directory, the path identifies a location in the file system. If the file path uses iso-8859-1 high characters, then the URI representation of that path needs to use the same encoding. [01:25]
jomogac410: attached a zipped version. Just download a zip, unpack and open the browser. The file is an iso1 encoded html and contains only 1 iso1 encoded link. Click on the link and watch the result. (if you want also could use wireshark to see what happens...) [01:26]
see, my intention was help - not wrangle... do whatever do you think it is right.. :) 3.30 here - so goind to sleep... GN. [01:32]
gac410okay I see what it did.
thanks.
goodnight
[01:33]
jomocool
gn
[01:33]
....................................................... (idle for 4h31mn)
***ChanServ sets mode: +o CDot
ChanServ sets mode: +o MichaelDaum
[06:04]
.................................................................................. (idle for 6h49mn)
LavrI am trying out the conversion tool right now. It is hard to pick the errors because convertion text scrolls over the screen and even exceeds my terminal buffer. [12:57]
***ChanServ sets mode: +o Lynnwood [12:57]
LavrWhen I run quiet I have gotten 1 error
so far
Argument "" isn't numeric in numeric lt (<) at /var/www/foswikidev/core/lib/Foswiki/Store/Rcs/RcsLiteHandler.pm line 408.
How do I know now which topic this error happened in?
Why can't I divert the output with ./convert_charset.pl -i > out.txt
It still outputs to the terminal
[12:57]
***ChanServ sets mode: +o gac410 [13:03]
LavrWhy can't I do perl convert_charset.pl -i > out.txt The > out.txt is ignorred [13:05]
gac410Lavr: Prints to STDERR? [13:07]
LavrPrint in termal instead of file like I have not put the > out.txt I have never seen that before
I am trying this now. perl convert_charset.pl -i > output.txt 2>&1
[13:07]
gac410command > file-name 2>&1 [13:08]
LavrSo it seems the script outputs everything to STDERR instead of STDOUT
I only saw the error once so there is hope it is one topic that makes a mess of it
it seems to rename around 15 or so attachments in total. Not more than I can manually repair that if they don't work
[13:08]
gac410What are you renaming. Example of from / to ? [13:12]
LavrThe script renames e.g. [13:13]
gac410CDot .. We have an issue with non-UTF stores. We really need the name-filter to block topic and attachment names that can not be represneted in the store. [13:13]
LavrThe script starts by saying it has moved Move /var/www/foswikidev/core/data/NM/AarsmødeBroendby2010.txt
So that is a topic with in it.
And an attachment Move /var/www/foswikidev/core/pub/NM/D82PreM5Tests/odświeżanie_storage_pc_administration.png
[13:14]
CDotLavr: redirect STDERR as well as STDOUT [13:15]
LavrNo idea what that is in the real world. [13:15]
gac410CDot Topic *content* can be tolerated by converting to html entities for the non-supported characters. But changing a filename to &someentity; is not good. [13:15]
LavrCDot. Yes it worked when I used 2>&1
Still running trial with -i
[13:15]
CDotLavr: that filename looks (from experience) like a UTF8-encoded filename stored in a ISO-8859 store
the Å is codepoint C5 in ISO, but is also the introducer byte for a multi-byte char in UTF8
[13:15]
LavrYes. Counting the moves (they seem to happen first) I may have to repair manually 15 or so cases. It may work. I have not yet done it for real. Just saying that I had that few filenames with none plain ASCII. [13:17]
CDotgac410: afreed [13:17]
gac410So the Topic name ...Aarsmø... seems to be a valid rename from 8859 to utf. But the attachment is already utf8 probably and will be corrupted by the rename. [13:17]
LavrI had one instance where the script returns Argument "" isn't numeric in numeric lt (<) at /var/www/foswikidev/core/lib/Foswiki/Store/Rcs/RcsLiteHandler.pm line 408. [13:18]
gac410CDot ... I wasn't sure how to handle attachments. Add a encoding check in sanitizeAttachment and remove the offending characters? [13:19]
Lavrso did it miss a file or? [13:19]
gac410hm Lavr, could that be an illegal rev number in the history? I had to hack the script and report every file name before attempting the conversion to find some really difficult issues. [13:20]
LavrWell. Next step. Run the same for real without the -i. Yes. it is a copy I run on. [13:20]
CDotLavr: that "Argument "" isn't numeric " strongly suggests a corrupt ,v file
an illegal rev number would indeed have that effect
try running with the RcsWrap handler, if you can. It may give more info.
(or it may not. Caveat emptor)
[13:20]
LavrIt is a topic in our sandbox [13:22]
gac410CDot for atachment filenames, would you just filter-out any unsupported characters, or throw an error? I have not looked at topics yet.
Oh, and I have a working but rudimentary pub url fixup attached to Item13696
[13:23]
FoswikiBothttp://foswiki.org/Tasks/Item13696 [ Item13696: Some attachments can be unreachable with non-UTF8 store encoding. ] [13:24]
CDotpersonally I'd throw an error. I hate filter-out.
the risk of a duplicate filename resulting is significant.
[13:24]
gac410ah good point.
I think I want to prevent the store filename issues in 2.0.2 That can be nasty. Item13697 has interesting side effects.
[13:25]
FoswikiBothttp://foswiki.org/Tasks/Item13697 [ Item13697: With iso-8859-1 store, it's possible to create unreachable topics and attachments. ] [13:25]
gac410I'll probably "try" a call to Encode::encode( $Foswiki::cfg{Store}{Encoding} || 'utf-8', with the attachment name and throw an error if it's not clean.
Not sure where to do similar for Topic and Web names.
[13:27]
LavrThere is a problem in my pseudo-install around the sandbox. The problem is that pseudo-install creates the pub/Sandbox symlink the wrong way. It symlinks Sandbox instead of the Extension name. It happens because there is no empty pub/Sandbox directory when you pseudo-install the first time. [13:28]
gac410Ah. yeah that's a known issue ... though I thought someone had fixed it. Used to happen a lot in the Lib [13:29]
LavrSo all my Sandbox content ends up in the Extension Sandbox directory. And when I delete or move I delete the wrong thing. Really annoying. Need to restore DirectedGraphPlugin sandbox from git now [13:29]
gac410That issue has probably been in pseudoinstall for a very long time. [13:31]
........ (idle for 35mn)
andreli: I've attached a small "puburl fixup" plugin to Item13696. It finds any puburlpath URLs in the completed page, and changes them from uft-8 encoding back to iso-88 encoding. [14:06]
FoswikiBothttp://foswiki.org/Tasks/Item13696 [ Item13696: Some attachments can be unreachable with non-UTF8 store encoding. ] [14:06]
gac410Very rudimentary right now, just to prove the concept
It's just the PM module, so very manual installation ... sorry
[14:06]
andreliHello gac410. I've seen it. It somehow does not solve my root problem. I currently writing into the Taskitem more details. [14:07]
gac410Still wondering if it should be a plugin, or part of core only active for non-utf8 stores.
okay thanks. :(
[14:07]
andreliThe whole thing drives me crazy.
I see, that Foswiki 2 changes spaces into underscores where as Foswiki 1 leaves them untouched.
Is this configurable?
[14:13]
gac410CDot ... something really strange is going on. I added a try/catch to Sandbox::sanitizeAttachment ... but when it DOESN"T catch anything, for some reason it bubbles up to the higher caller skipping the rest of the code.
andreli: Foswiki always changes spaces to underscores. it's hardcoded in Foswiki::Sandbox::sanitizeAttachmentName
[14:14]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Sandbox [14:15]
gac410Could you be running with a modified system? [14:15]
andreliWhere would we have needed to modify the system? In Foswiki::Sandbox?
We are running Foswiki 1.1.5 from 2011
[14:16]
gac410Yes. hang on let me look at that code.
Line 311 of lib/Foswiki/Sandbox.pm on 1.1.5
[14:17]
andreliI see. our upload must bypass this line, because I definitively have spaces on the disk.
We are using TopicInteractionPlugin.
In both setups, 1.1.5 and 2.0.1
[14:24]
gac410Oh. It does it's own thing.
Plays outside of the sandbox
[14:24]
andreliOk, I repeat my trials without the Plugin to confirm some findings. Be back in a minute. [14:26]
GithubBot[distro] cdot pushed 1 new commit to master: http://git.io/vZzEK
distro/master 24a5f4d Crawford Currie: Item13570: cannot remove the %TABLE macro during table parse, as the TablePlugin depends on it. When we kill the TablePlugin we'll be able to remove this yuck.
[14:27]
***GithubBot has left [14:27]
FoswikiBothttp://foswiki.org/Tasks/Item13570 [ Item13570: EditRowPlugin does not work on page with TABLE macro ] [14:27]
CDotgac410: check you have enough semicolons. try...catch *looks* like a perl structure, but isn't, it's a pair of function calls. [14:28]
gac410Completely different issue. Found it. Encode::encode which I used in the try{} "consumes" the source string. So it was working but returning empty which happened to trigger the same error. [14:28]
CDotLavr: hopefully that checkin addresses all the relevant issues. If not, and I'm not here, there are a bunch of unit tests in the EditRowPlugin/EditRowPluginSuite, generically called things like "test_table_TABLE_table_EDITTABLE_table" and "test_TABLE_EDITTABLE_table" that are intended to test the parsing for different table/macro sequences, please feel free to add to the set if you need to. [14:33]
gac410To do this encoding issue right, I really need to add a new oops string :( [14:34]
CDotoops..... [14:36]
andreliIt's to confirm, TopicInteractionPlugin does it's own filename parsing. [14:37]
LavrMy site is busy converting. I will go home now and try there if the Table stuff works now [14:39]
gac410I'm going to throw an error "The filename (blah) you are uploading contains characters that are not supported by the system encoding (iso-8859-whatever). Please upload using a different file name. [14:42]
andreligac410: Some more tests show that this probably doesn't cut it. [14:49]
gac410What's going on? [14:50]
andreliI can now confidently confirm, that the name of the file on disk is identical to the string in the topic META string.
This includes encoding
So my topics are in ISO, so are the filenames on disk.
[14:50]
gac410If you Ctrl-u look at the html source of the link to the file, what is the link url? [14:52]
Lavrhome [14:52]
gac410The issue we've recreated any is indeed .. filenames on disk are ISO .. It's just when the UI generates the link it uses UTF-8 [14:53]
andreliThe html link is the simpler problem. I'm struggling with IMAGE, the thumbnails etc. [14:53]
gac410Oh... :( [14:53]
LavrThe table fix does not work well. [14:53]
gac410My plugin fixes the basic stuff. corrects the src=" " for img tags, and the href=" " for file links. [14:54]
LavrThe TABLE attributes work on the columns the wrong way so the extra left column with the EditRowPlugin buttons takes the role as column 1
So the columnwidths and initsort etc work on the wrong columns shiftet to the left
[14:54]
If you just look at TestCases/TestCaseEditTableWithTableInitSort then it jumps right into your eyes. You cannot miss it.
Use these test cases. They are easy to quickly look at and all the bugs reported are clearly visible.
[14:59]
andreligac410: I seem not able to get your plugin to work. [15:01]
gac410hm. Copy to lib/Foswiki/Plugins/PubUrlPlugin.pm and set {Plugins}{PubUrlPlugin}{Enabled}=1 and {Module}=Foswiki::Plugins::PubUrlPlugin [15:03]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Plugins::PubUrlPlugin [15:03]
LavrTestCases/TestCaseEditTableMacrosWithSettings fails just by looking at it [15:05]
andreligac410: That's what I did. I'll check. [15:05]
gac410Maybe I messed up the upload. :( [15:06]
LavrIf you edit a table on TestCases/TestCaseEditTableMacrosWithSettings and save it adds copies of the TABLE macro. So it destroys the topic.
TestCases/TestCaseEditTableMacrosInSettings same thing. Fails with the two macros on the same line
TestCases/TestCaseEditTableMacrosInMacros just looks at it and you see naked EDITTABLE macros.
TestCases/TestCaseEditTableAllFieldTypes still fails for the textarea fields
gac410 no release with this. It is totally broken
[15:06]
gac410okay. [15:09]
LavrIt takes 5 minutes to walk through these manual test cases. Unit tests will NEVER shows this type of bugs.
But on a webpage they poke you in the eyes
[15:10]
..... (idle for 21mn)
gac410andreli: Crap... I'm sorry... my hacked plugin name is "PubLinkPlugin" not PubUrlPlugin. You can either rename the module, or edit the Package statement in the code. [15:31]
andreliOh, I have seen that, sorry not telling you. But it don't get it to work. [15:33]
gac410Is it doing anything?
I should have left the debug print statements in handleHtmlLink routine
[15:34]
..... (idle for 22mn)
andreligac410: I try to understand the whole handling of images. If I link an external image, http://...umlauts...jpg the file gets copied to the pub folder too. So your approach of blocking upload might miss some usecases. [15:57]
gac410ah. is that the ImagePlugin mirroring function? [15:59]
andreliAt least, native wiki attachment handling as well as TopicInteractionPlugin can delete a file, so in worst case I could demand users to rename their files. But I'm not yet ready to default to this. [15:59]
gac410It will be up to TopicInteractionPlugin to make sure that only characters supported by the store are used for names in the store. [16:00]
andreliImagePlugin mirroring: possibly, even thought I disabled AutoAttachExternalImages and AutoAttachInlineImages. [16:01]
gac410Can't think of why else an external image would be copied to pub.
We have 3 separate problems with non-utf8 stores. 1) Upload can create a filename that uses non-supported characters. I'll fix that for core in Sandbox::sanitizeAttachmentName. If a plugin doesn't use it, that's the plugin author to fix.
2) Topic names can use characters that are not supported in store. Have not looked at that yet, but we also need to prevent that.
3) Filenames with "high characters" such as umlats, etc. create bad lnks to pub. That is the plugin that I've been tinkering with.
[16:01]
andreliAren't 1) und 3) somehow in contradiction. Meaning, if 1) does its job right, 3) should never occur.
But because of migration, we have to deal with 3). So, if we can deal with 3), we can let go of 1).
[16:08]
MichaelDaumgac410, have you upgraded FO with 2.0.2? CommentPlugin still misses the form.reset() ... thanks. [16:09]
gac410No. not true. 1) needs to stop characters that are not supported by the store. ie utf8 multibyte that do not map to the Store high character encoding.
MichaelDaum: CommentPlugin changes were not in 2.0.2 RC1 Have not tried another RC yet.
[16:09]
MichaelDaumay [16:10]
gac410#3 happens because when Foswiki generates a link to a file, it uses the utf-8 multibyte equivalent of the store's single byte high character. [16:11]
andreliMichaelDaum: Might I ask you about your 2 cents on TopicInteractionPlugin, umlauts in filenames, ImagePlugin on a ISO-8859-1 Store! [16:11]
MichaelDaumhi andreli [16:11]
andreliHello Micha [16:11]
MichaelDaumhope I can help you
MichaelDaum never looked back at iso-8859-1 for a looong time
[16:12]
gac410Andre, so continiung on #3. our UI and Core are utf-8. The character (é) in utf-8 is represented by %c3%a9 but in your iso-8859 store, it is saved as%e9
So all the links point to utf-8 URLs. ... %c3%a9 where as the filename is iso-8859 %e9
Something needs to make the transition back to the Store's encoding.
[16:14]
andreliI'm with you so far. But I see now, that in wiki attached files use ISO on the disk, where as AutoAttached files use utf-8. [16:18]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vZgOu
distro/master 8366b8a George Clark: Item13697: Prevent attach of unsupported filename...
[16:18]
***GithubBot has left [16:18]
FoswikiBothttp://foswiki.org/Tasks/Item13697 [ Item13697: With iso-8859-1 store, it's possible to create unreachable topics and attachments. ] [16:18]
andreliI see now iso encoded filenames next to utf8 [16:18]
gac410Eewww ... So you use AutoAttach as well ??? yikes I don't think we considered that case [16:18]
andreliHonestly, I was not aware of AutoAttach. [16:19]
gac410wait... AutoAttach doesn't actually write the files to disk. It just finds what's out there.
So how are these "autoattach" files getting written. Usually that's an external process dropping files into the directories.
[16:19]
andreliI'm talking about AutoAttach from ImagePlugin. [16:20]
gac410Oh. that's different. Sounds like a plugin bug then not considering the {Store}{Encoding}
CDot ... for your review. my commit http://git.io/vZgOu I think I need to do something very similar to Foswiki::isValidTopicName and isValidWebname ... ie reject any name not supported by the Store encoding.
[16:21]
andreliI guess I best start count the files with umlauts. Might be fastest just to rename them. Forbid umlauts be convention. Convert the store (later!). And the forget about the problem again. [16:24]
gac410andreli: The umlats should be fully supported.
It's probably a bug in ImagePlugin
though we stil have the link issue that PubLinkPlugin needs to resolve.
CDot, so another question. Add code to Foswiki.pm, or add a utility function like Store::supportedEncoding() that returns true if the string can be represented in the store natively.
[16:25]
Hm. or add a CROAK flag to Store::encode() If CROAK, then use FB_CROAK instead of the entity encoding. And we have Sandbox, and the isValid routines try Store::encode( name, 1) to test.
Store is really your baby, put I think that results in least duplication, and pushes the decision of supported or not down into Store.
[16:33]
CDot"reject any name not supported by the store encoding" - yes, I like that, I hadn't thought of it that way.
that API should be supported in Foswiki.pm, which in turn should call an API in the Store
[16:46]
gac410Most of the API is there. isValidTopic and isValidWeb just need to call Store::Encode with the "croak" bit.
and add a try/catch to the existing isValid*
So either need a isValidAttachment addition to the Foswiki.pm or do that one from Sandbox sanitizeAttachment for now.
[16:48]
CDotI'd prefer to rework that whole code path. The idea of "sanitising" an attachment name is bad. It should be a check, just like any of the other isValid validators [16:51]
gac410Agreed, but not for 2.0.2 I don't think. [16:51]
CDotbetter not to add more layers of complexity to sanitizeAttachment that are hard to reverse out of later [16:52]
gac410There are feature proposals for "reject don't sanitize" that have objections iirc. [16:52]
CDotp'haps [16:52]
.... (idle for 18mn)
andreliHe, I appreciate your effort, Thanks a lot.
I've to leave now
bye
[17:10]
gac410by andreli [17:10]
MichaelDaumI'm gonna finish a long week now [17:18]
gac410have a nice weekend MichaelDaum [17:19]
MichaelDaumgac410, weekend is family time so I won't be able to assist in publicity. when do you plan for the next rc or final? [17:19]
gac410Definitely an RC, and not before next week I'd guess. need to get the EditRowPlugin working. and the iso8859 store issues. [17:20]
MichaelDaumyea oh dear
got some release work ahead as well: new LikePlugin, updated MetaComment, SolrPlugin, NatSkin, LdapContrib, ClassificationPlugin, BlogPlugin, WikiWorkbench, ...
[17:21]
gac410Looks like ImagePlugin is going to have issues with iso stores and umlats according to andreli [17:22]
MichaelDaumyea
TopicInteractionPlug will get some updates as well
StringifierContrib needs unicode finxing
[17:23]
gac410Y. Woudl be nice if it could use the NameFilter, and sandbox to at least validate names. [17:23]
MichaelDaumprobably was a bad idea to use a name filter of its own...will revert that. though I'd like to have space in my attachment names ... which WysiwygPlugin does not support ....gosh [17:24]
gac410So for creating topics, isValidTopicName if it returns 0, due to the invalid iso-8859 characters, foswiki tries to create WebHome for some reason. [17:25]
MichaelDaumbig outch as people tend to have nice frontpages for their knowledge bases there ... [17:25]
gac410Hm. Spaces in attachment names. ... I think we are closer to supportin ghat. [17:25]
MichaelDaumthere was this now deprecated link syntax, wasnt there? [[foo bar]] [17:26]
gac410Any idea if there is a way for the javascript name checker to check if valid iso-8859 characters?
We removed the [[foo bar]] syntax I'm pretty sure.
[17:26]
MichaelDaumy, but it is still there on 1.1.x
legacy
javascript name checker? which one? jquery.wikiword?
[17:27]
LavrIt was deprecated already in Twiki 3 [17:27]
MichaelDauman equivalent to [^[:ascii:]] [17:27]
gac410I guess that's it. Whatever lets FľléxPápěŕPĺúgíň make it into webCreateNewTopic on an iso-8859 system.
Yes.
er..no no
[^[:ascii:]] but also permitting supported high characters for the configured encoding Umlats, etc.
[17:27]
MichaelDaumregex - shmegg-eggs [17:29]
gac410y. needs to know the configured {Store}{Encoding} and only support that set of characters [17:29]
MichaelDaumno clue so far [17:29]
gac410okay ... well at this point I'd just like to be sure that an iso-88 configured wiki doesn't let users pollute the filesystem with bad names. [17:30]
MichaelDaumalright leaving. see you. [17:31]
gac410cu
So CDot. For store. It was my change ages ago that allowed encode() to subsitiute entites. I've added the "CROAK" flag. And I think as a final check, any calls to encode for *names* not content, should set the CROAK flag. To avoid creating filenames with invalid characters.
Entities in content, Croak for bad names.
[17:31]
CDoty, sounds about right
I'm still puzzled by all the incorrectly encoded links spewed out when I view a complex UTF8 topic name. The fact that nothing seems to break kinda suggests that all those links are..... cruft
[17:34]
gac410Should be pretty straight forward. I'll get that done over the weekend.
I've not observied the incorrectly encoded links. But for bad names, that may be my encode() changes from early on.
Since I return entities from encode, you'll end up with entities in filenames as well. Not good.
Named entities, even worse.
This all might be related. to what seemed like a good idea to avoid the CROAK if a topic *content* included unsupported utf-8 characters
[17:35]
CDotmight be. I'm seeing UTF8 being output as bytes in several places.
sorry about that, my fault for not documenting *why* it was a croak in the first place :-(
[17:37]
LavrCDot you saw my feedback on EditRowPlugin checkin earlier? [17:39]
CDotnope [17:39]
gac410But that should not be outputting bytes, but on an iso-8859-1 system might end up with a filename A&Scaron;df.txt
[17:39]
LavrI must admit that I am a bit puzzled how these errors I see in 30 seconds can be undetected by you. [17:39]
CDotah, table attributes applying to the wrong column? yeah, that's a bitch, that one [17:39]
gac410I wonder as a quick fix, the pencils column should just be omitted when a TABLE macro controls the column layout. [17:40]
CDotLavr: don't be puzzled; I usually test for specific problems, via unit tests. You are providing a level of integration test that I don't always do.
gac410: or the pencils column can be moved to the end of the row
[17:40]
gac410ah. that might work too. [17:41]
CDotthough that creates horrible problems for the ERP javascript, which uses the first column to attach data() [17:41]
LavrAll the TestCases web topics I did years ago for EditTablePlugin apply very well for EditRowPlugin and it takes 1-2 minutes to at least just look at the test cases. There are 8 web pages and cliking through them takes only no time. [17:41]
gac410That would also fix the highlighting issue where the sort column highlights the column to the right of the sorted column. [17:41]
CDotthe reason the pencils are at the start of the row is because rows may be wider than the screen [17:42]
gac410hm though I would think it would highlight one to the left, not to the right. [17:42]
CDototherwise, there's no fixed reason for them to be there.
Lavr: I strongly recommend *not* using the pencils icon, but using cell-by-cell editing
if you do that, the pencils column goes away as an issue
[17:42]
gac410Can you just turn off the pencils column automatically if the columns are specified. [17:43]
CDotno. the ERP does not parse the t%TABLE attributes [17:44]
gac410to me a worse issue is the deleting of macros from some colimns [17:44]
CDotthe TABLE attributes are simply passed on to TablePlugin
my original intent was to blow away TablePlugin completely, and handle the formatting it does in JS
but events moved too fast for me :-(
[17:44]
LavrI never asked for any pencils. I just want to make sure the new plugin is compatible with the EditTablePlugin. [17:45]
gac410to me the most serious issue is Item13693 ... When you edit a row or the whole table, the %MACROS% in one column just magically disappear. [17:46]
FoswikiBothttp://foswiki.org/Tasks/Item13693 [ Item13693: EditRowPlugin deletes macros from text area fields ] [17:46]
LavrAs I said to George the other day, the initsort at HTML cannot be converted to JS based sorting without losing the ability to use sorted table data in other plugins such as ChartPlugin. I really like that I have control of the HTML. [17:47]
gac410That's a data-loss. Formatting is a concern, but data loss is poison. [17:47]
CDot* Set EDITROWPLUGIN_DISABLE = row
the initsort is still a perl sort, it's only the later interactive sorts that are done using JS
[17:47]
LavrThere were additional problems. EDITTABLE and TABLE on the same line is broken now. Several of the TestCases tests shows that. Just look at the topics and it pokes you in the eye [17:47]
CDotthe JS sorts do not, however, refer back to the server [17:48]
LavrJS sort is fine when you click the headers. No problem with that
On the contrary
The TestCases/TestCaseEditTableAllFieldTypes is a simple but powerful manual test case because it represents all field types. And it is not a coincidence that there is a Macro in the text area. That was been an old bug in EditTablePlugin.
I am just randomly trying some of the other manual tests. They fail. TestCases/TestCaseSpreadSheetPlugin fails.
You look at the topic. You click a button. You get the result. Fail.
[17:48]
GithubBot[distro] cdot pushed 1 new commit to master: http://git.io/vZgNT
distro/master 346900b Crawford Currie: Item13570: Idiot - only disable globally when the preference is 'full'
[18:02]
***GithubBot has left [18:02]
FoswikiBothttp://foswiki.org/Tasks/Item13570 [ Item13570: EditRowPlugin does not work on page with TABLE macro ] [18:02]
..................................... (idle for 3h4mn)
jmk0I managed to blow away some config data again by forgetting to completely localize Data::Dumper settings... I think it was a cookie/session file that gets munged but I can't find it nor recall details... can anyone remind me?
it was working/tmp/cgisess but that's apparently not all of it
[21:06]
yikes, our operational server has 42,525 cgisess files [21:16]
gac410Need to be running tick_foswiki script, or set an expires timer in the config.
(timer is slow because on every session it scans all existing cgisess files ... tic_foswiki is much better from a cronjob
afaik the only session files are in working/tmp/cgisess_*
[21:16]
jmk0are there any other files that might be written to using Data::Dumper?
ok I managed to get it working again... it failed the first time I removed the session file, not sure why
[21:18]
........... (idle for 52mn)
gac410Are you still on 1.1.9?
we changes 2.0.1 to use Storable for the session files.
[22:12]
jmk0ummmmmmm yeah. had to think cos I have an operational 1.1.9, a test 1.1.9 and a test 2.0.something [22:13]
gac410Otherwise they have utf-8 encoding issues. [22:13]
jmk0... and i'm using all of them :) [22:13]
gac410Anyway, 2.0.1 shouldn't have any session file encoding issues due to Data::Dumper. [22:14]
jmk0k [22:14]
gac410I meant to say, shouldn't have any file corruption due to non-localized data::Dumper changes, since it no longer uses it. [22:15]
jmk0I always thought of it as a debugging tool, was surprised to learn that foswiki used it for data storage [22:16]
gac410Actually Data::Dumper is the default storage mechanism for CGI::Session ... have to configure it to store any other way. [22:17]
jmk0huh.
jmk0 gives a little side-eye to CGI::Session
[22:17]
i think that's it for me for the week, have a good weekend [22:25]
............. (idle for 1h1mn)
gac410you too. g'night [23:26]

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