#foswiki 2015-09-17,Thu

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

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood [00:16]
.................................................................. (idle for 5h26mn)
ChanServ sets mode: +o CDot [05:42]
...... (idle for 29mn)
ChanServ sets mode: +o MichaelDaum [06:11]
MichaelDaumhttp://irclogs.foswiki.org/ is down? [06:21]
......................... (idle for 2h1mn)
jastseems so. hosted by ColasNahaboo from what I can tell... [08:22]
........... (idle for 51mn)
LavrLavr is again trying a conversion from old to UTF-8. This time I hope to have remembered everything.
What is so critical this time is that once you have converted from 1.1.9 to 2.0 on a production site there is in practical no turning back.
All previous updates could be reverted by changing a symlink
Finally what looked like a clean conversion. So now on with the testing again.
[09:13]
.... (idle for 18mn)
GithubBot[distro] KennethLavrsen pushed 1 new commit to master: http://git.io/vnvWY
distro/master 6785eb6 KennethLavrsen: Item13504: Someone probably wanted to remove cruft but instead created yet...
[09:35]
***GithubBot has left [09:35]
FoswikiBothttp://foswiki.org/Tasks/Item13504 [ Item13504: Documentation changes Foswiki 2.0.x / 2.1.0 ] [09:35]
.... (idle for 18mn)
JulianLevensAre the logs down? [09:53]
andreliLavr: How did you convert your store now successfully? You were talking yesterday about Windows encoding and this sort of stuff. Is there a topic on foswiki.org that I can follow? [09:53]
.... (idle for 15mn)
MichaelDaumYouAreHere.txt doesnt make much sense to me
I can't see where it is included
Lavr, your commit message doesnt enlight me either
[10:08]
LavrIt is not included anywhere in a new fresh Foswiki. But an upgraded Foswiki is full of them because we used to have this per default in the tools section of WebHome
I have around 20 webs with this included. Maybe more
It just needs to be there for the upgraders. I am not encouraging anyone to start adding it to WebHome again
[10:10]
MichaelDaumit would still be best to remove it from the Foswiki-2.x distro [10:11]
LavrWhy? Do add yet another problem for the upgrader? [10:11]
MichaelDaumotherwise we never get rid of any legacy
please have it in some contrib or so
[10:11]
LavrIt does not cost anything to be nice to the upgraders [10:12]
MichaelDaumit does cost anybody else not upgrading wondering what this is for [10:12]
LavrNoone will notice or care. it is just one of many topics in System web. They care when it is missing. [10:13]
MichaelDaumremoving stuff was probably not the best way to offer a better upgrade path. moving it out into a LegacySystemWebContrib makes more sense
the System web is full of cruft. it is in constant need of love & care
[10:13]
LavrWhy create such a geek solution to a simple problem? I'd rather copy over the missing topic from the old install than having to install misc contribs. Try and put yourself in the upgraders mind please. There are so many things you need to do when you upgrade to 2.0. I have worked on it for 2 weeks now and I am not even getting near [10:15]
MichaelDaumrequiring to carve current status quo into stone is not in the best sense of the project. however, I agree, any changes whereever they happen, need a sensible upgrade path, easy to apply for upgraders.
we need two things: (1) easy upgrade (2) remain flexible to improve
in parts they contradict each other ... as for YouAreHere.txt
good example
[10:15]
LavrYes. and having a few old System topics is not going to hinder 2 and it will for sure aid 1 [10:17]
MichaelDaumimho System web is not well structured. and if people keep reverting cleanup for the sake of easy upgrade, then we get nowhere with that docu task
just keep that in the back of your mind, Lavr
and then decide yourself what you do
[10:18]
LavrI believe I did the right thing. I am not putting back any croft. And I have not seen any additional cruft to add so the problem is not so large
meeting time
[10:19]
MichaelDaumHey, your new name from now on is: Lavr Croft ;) [10:20]
Lavrbbl [10:20]
***Lavr is now known as LavrCroft [10:20]
jastI can provide an unofficial logfile temporarily... the only downside would be that [off] messages won't get filtered [10:22]
okay, I've added filtering. get the full log for this month here: http://jk.gs/fw09.cgi
I suppose I should filter hostmasks, too...
okay, done
[10:30]
foswiki_irc6hello [10:38]
jasthi [10:38]
foswiki_irc6It says I shall not asked for permission so I am just asking my question [10:39]
jastvery good :) [10:39]
foswiki_irc6actually I already did but no one answered it yet: http://foswiki.org/Support/Question1662 [10:39]
jastthat's strange... the same thing works fine for me. do you have a FastCGI-based setup? /bin/ is handled specially with that. [10:42]
foswiki_irc6Is it maybe because my scripts are in /bin/custom and not /bin/ ?
the webserver setup is the one on the foswiki VM image
[10:43]
jastokay... I haven't looked at the VM image myself, truth be told
are you using Foswiki 1 or 2?
[10:44]
foswiki_irc62
2.0.0 to be exact
the exact errors look like this:
Failed to include URL http://192.168.56.102/bin/custom/dbfitrtab.pl Not Found
but it is definetley in at that exactl location I double checked
[10:46]
jast"Failed to include" doesn't look like a simple link... that's what I'd expect if you used %INCLUDE{...}%
I'm downloading the VM image to have a quick look at the config
[10:51]
foswiki_irc6This is the source: %INCLUDE{"%SCRIPTURL%/custom/dbfitrtab.pl"}% thats how it worked in TWiki
that is really kind of you
[10:52]
jastit's _probably_ due to FastCGI (which significantly improves performance), but I'll find out for sure in a moment [10:52]
foswiki_irc6thanks a lot [10:53]
jastlet's hope my VM software can read these disk image files... [10:53]
foswiki_irc6works fine in VirtualBox [10:54]
jastyeah, I can see that now :)
okay, that's what I thought. the VM is set up for FastCGI.
we can add an exemption for your custom scripts
do you know how to get root access and edit files within the VM?
[10:55]
foswiki_irc6I know how to get root and all but not where the edit files are located [10:58]
jastI can tell you that part :) [10:58]
foswiki_irc6and yes I know how to use vim or nano [10:58]
jastthe file in question is at /etc/apache2/sites-enabled/000-foswiki.conf
in line 19 there's an "Alias /bin ..." that makes Apache use Foswiki's FastCGI handler instead of the actual scripts in the bin dir
which is good for the standard foswiki scripts, but breaks any custom scripts placed there
we can probably fix that by adding another line immediately before that:
Alias /bin/custom "var/www/foswiki/bin/custom"
insert that, then save and quit, and run "service apache2 reload"
and of course I meant "/var/www/foswiki/bin/custom" (leading slash_)
this *should* change the behaviour. we might still run into other issues, e.g. getting the source code of the script instead of having executed, but first let's find out what happens with just this one change
[10:58]
foswiki_irc6mhm I am afraid that did not change anything
I did exactly how you said
checked it again. it did save the file and I restarted the server
[11:02]
jastand the new line comes first, i.e. before the existing "Alias /bin", right? [11:07]
foswiki_irc6http://pastebin.com/7MvZcxqh [11:07]
jastyeah, that looks fine
not entirely sure where it's getting hung up
[11:07]
***LavrCroft is now known as Lavr [11:09]
foswiki_irc6how about trying to deactivate fastCGI interly? just to find out if thats where the problem is [11:10]
jastyou mentioned a /twiki/ in the URL in your support question. is that what you're using in this VM, too? [11:10]
foswiki_irc6no TWiki is running on a life server I just copied the content and users over
the server foswiki is running on will be a clean install of the image with nothing else but foswiki on it
[11:10]
jastI'm assuming you get a normal 404 error page if you try to access http://foswiki.local/bin/custom/dbfitrtab.pl -- right? [11:11]
foswiki_irc6oh it works now. I swear I restarted the service like you said. tried a reboot now and it works [11:11]
jasthmm, sometimes these things happen in confusing ways :) [11:11]
foswiki_irc6thank you very much [11:11]
jastyou're welcome
I'm going to put an answer in your question topic, too, so everyone else can refer to it
[11:11]
foswiki_irc6only problem left is that the scripts itself use direct links to the twiki server but thats easy to fix
yes that would be perfect
The thing I struggled most with actually was the recoding to utf8 (TWiki was windows-1252) and installing all the perl dependancies
[11:12]
jastyeah, that can be tricky [11:14]
foswiki_irc6ah and is it save to just continue using the RCSLite store or should I change this?
because that could be a bit of work to and it works fine now with RCSLite
[11:14]
jastthere's a script for conversion in CharsetConverterContrib which has received a number of fixes in the past days... and the bulk_copy.pl script shipped with foswiki 2 to convert to PlainFileStore at the same time (which has received important fixes in 2.0.1)
RCSLite still works, sure... PlainFileStore performs better and is somewhat less susceptible to corruption, which is why it's the new default
[11:15]
foswiki_irc6I think I'll just leave it how it is now. thanks a lot for your help now I can finally copy over the image to a real server
(and do some more testing)
[11:17]
favioflamingohello
i have not been here a while. wanted to ask about DBISQLCOntrib status?
[11:19]
jastyou mean DBIStoreContrib, I guess? [11:20]
favioflamingoyes, how is that coming? [11:21]
jastI haven't looked into it myself yet... all I know is Crawford and a few others have done quite a bit of work on it [11:21]
favioflamingohttp://foswiki.org/Development/DBIStoreContrib
I did some work about 4 years ago
[11:22]
jastthe change history suggests that there is no official support for Foswiki 2 yet... [11:22]
favioflamingoand so my wiki installation is about 3-4 years out of date
i have a 100% postgres back end
[11:22]
jastanyway, there have been a LOT of changes in 2014
from what I can see, Crawford has basically built full support for SEARCH and QUERY into it
(probably minus a few perl-specific extensions to regular expressions...)
[11:22]
favioflamingothat pretty cool. i wish i had uploaded my work
muuuch earlier
[11:24]
jastwell, hindsight is 20:20 :) [11:24]
favioflamingoi have been trying to do a kind of block chain bitcoin verification scheme on foswiki for 3 years now
but i only work on this part time
[11:24]
jastthat sounds... exotic ;) [11:25]
favioflamingowell, the reason i wanted to use postgres was so that i could use a relational database, abstract topic objects, which would allow me to boil the entire wiki database down to a single sha256 hash
im mostly there, but i messed up something in the schema 4 years ago
[11:25]
jastthat doesn't seem like something that would become _that_ much easier by involving a relational database
obviously you've looked into this more than I have
my intuition says if you go with a similar scheme as in git, you'd still have to rebuild the toplevel hash each time anything changes, and probably create a hash out of the hashes of the individual webs, or something like that
[11:26]
favioflamingowell, at the time, i was told topics are tracked by a webname, topicname. but that made it difficult to track topics over time. [11:27]
jastwhich I guess isn't actually that big a deal unless you have several thousand webs [11:27]
favioflamingoAlso, another issue was by using NoSQL stuff and text files, it was impossible to separate the structure of the data from the content. Hence, i could not run any encryption schemes [11:27]
jastencrypting things you need fast lookups on is tricky with relational data, too... [11:28]
favioflamingoim a math guy, so i just generate a random guid to represent each topic
i did research on encrypted indexes
[11:28]
jastI've only seen that such a thing exists :) [11:29]
favioflamingothe most important priority for me had been getting each topic save down to a single sha256 hash. with that, many things become possible.
http://r.duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fwww.isi.edu%2Fdivisions%2Fdiv7%2Fseminar%2Fpast_seminar%2Fslides%2Fbloom-encrypt.pdf
[11:30]
jastin principle even one of the modern filesystems can give you that
bloom filters are one of things I find pretty ingenious but I've never actually used them
[11:30]
favioflamingowell, the other theory i had was to make foswiki more peer to peer [11:31]
jastsame for heapsort. I liked that algorithm so much when I first learned about it that I got myself a domain name for it :) [11:31]
favioflamingoi think for full text search, you have to use bloom filters [11:31]
jastwell, you sure like the complex stuff [11:31]
favioflamingowell, going for complex stuff means never getting that product to sell ;( [11:32]
jastunless you're a superhero...
(which I'm not)
[11:32]
favioflamingome either
now that i live deep in the country side, i have tasked myself with publishing as much as my code as possible for people without giving away my aws keys.....
[11:32]
jastmy intuition would be that doing full text search on encrypted data would either make phrase queries (let alone sparse phrase queries) significantly more difficult or it would weaken the encryption
I suppose you could add encrypted sparse n-grams to the index, too
but I don't have enough time to actually look into any of this\
[11:33]
favioflamingoi think it is a tough problem, because by possessing the index, you can glean a lot of information about the content
but at least, with a wiki with structure and content separated, you can keep the indexes in your office, and store the meaty content on amazon, etc
[11:35]
jastvery tough, yes [11:36]
JulianLevensColas the logs are down :( [11:49]
ColasThanks for the notice JulianLevens , checking... [11:49]
favioflamingowhat about having a json data back end?
via the mongo db contrib. that way, everything is just jsonrpc
[11:57]
ColasJulianLevens, fixed [11:59]
JulianLevensExcellent [12:00]
..... (idle for 21mn)
LavrI have been going through all the TestCases web tests for EditTable. They all apply to EditRow except in edit row you also have to test in row and cell mode.
And as you will notice I raised MANY urgent new bug items. That plugin is disfunctional. It should not be shipped with Foswiki in the state it is now.
[12:21]
***ChanServ sets mode: +o gac410 [12:23]
Lavrgac410 I am not sure there are logs available for IRC [12:32]
gac410yes they are back I've been reading [12:32]
LavrBut you may want to just check out the changes in Items web on f.o. [12:32]
gac410Already saw. I use ff live bookmarks for tasks, and support [12:32]
LavrI cannot for the living daylights understand how anyone can miss all these bugs. That plugin is totally broken.
The good news is that I have done ALL the same tests in EditTablePlugin and I did not raise one single bug item during that test
I also finally got the site translated to utf-8 without severe issues so that no longer seems to prevent me from upgrading.
I will continue testing some of the more rarely used plugins now that we have installed.
[12:33]
gac410Lavr, are you actually running live now on 2.0, or just have a successful migration for testing? [12:36]
LavrI now have a complete copy of my production site from yesterday to test on and that helps me test everything [12:37]
jasttesting [12:37]
gac410okay... great. [12:37]
..... (idle for 22mn)
***ChanServ sets mode: +o Lynnwood [12:59]
gac410MichaelDaum: Did you see Item13710 [12:59]
FoswikiBothttp://foswiki.org/Tasks/Item13710 [ Item13710: JQueryPlugin (6.13) version of jquery.foswiki.js fails in 1.1.9 installation ] [12:59]
gac410Lynnwood reported it yesterday. I installed the new plugins on an old 1.1.9 test site and ended up with the same issue.
I'm also running into a "unable to find FoswikiTiny ... that one sounds familiar and I suspect it's self inflicted. But the encoding issue maybe is a compression or build issue?
I did test all the extensions on 1.1.9 so not sure why it's happening now.
[13:00]
Lavr, I opened Item13721 Still wavering on which one to leave enabled. Probably ERP, so that bugs get reported & fixed. [13:10]
FoswikiBothttp://foswiki.org/Tasks/Item13721 [ Item13721: Return EditTablePlugin to the 2.0.2 MANIFEST. ] [13:10]
LavrLeaving the current ERP enabled is pissing on the users. It does not work. It needs to get either fixed or ditched.
some of the cases I just reported were without TABLE tags!
[13:12]
MichaelDaumgac410, Item13710 ... try the attached files, please. [13:13]
gac410Regarding restoring unused topics. I'm really tempted to create a System/Obsolete web and move stuff there. That way they are readily available for upgraders, to copy into system web, but we have some way to remove cruft. [13:13]
MichaelDaumthere was a release blocker due to a javascript error on IE [13:14]
gac410MichaelDaum: okay I'll try them. Line number was not reportable. Always line 1. (minified file). I restored uncompressed, and problem goes away [13:15]
MichaelDaumcould be that compression was broken. but I basically need more info on browsers etc [13:15]
gac410I'm on firefox. 40.0.3 [13:15]
LavrThen may as well not do anything. The problem is that upgrading from 1.1 to 2.0 is a NIGHTMARE already. And each step you add to the problems for the upgrader is bad. If this was the only problem then a little note in the upgrade guide would be fine. But that is not the case. Upgrading to 2.0 is really difficult. [13:15]
MichaelDaumgac410, how did you build the new JQueryPlugin that you then installed on a 1.1.9er [13:16]
LavrAnd we are talking about 1 file [13:17]
MichaelDaumit is important NOT to use the yui compressor or the perl one [13:17]
gac410I just let the extension installer download from Extensions. I use the node.js compressor for all of the prod. builds.
Lavr, that's the 2nd file you restored.
[13:17]
MichaelDaumdo you have uglifyjs [13:17]
gac410yes. [13:17]
LavrOK 2 files. [13:17]
gac410The system web has gotten utterly out of control. Documentation is duplicated all over the place. If the new rule is we cannot delete anything that might be needed because of includes on an old system, lets just give up. [13:18]
jastmove off old stuff into a Contrib, that way it's one click to get it back [13:19]
MichaelDaumgac410, yep
a LegacySystemWebContrib
[13:19]
LavrA contrub. You think an upgrader wants to install a contrib to restore two fucking topics? Be reasonable! Actually what was the other topic I restored? [13:20]
gac410Lavr, I don't recall. But CDot deleted maybe 10 or so topics in a big cleanup. I already made one big pass fixing %INCLUDES ... there were a bunch of them but were used in still shipping topics. [13:22]
LavrI added a topic to list Macros. That was not for upgraders. That is for new installs as well. [13:22]
jastI haven't been involved in System web cleanup and don't know how much cruft we're talking about [13:22]
gac410Lavr, It was StatisticsTrigger or something innane like that... Oh... I restored it. you opened the task. [13:23]
MichaelDaum_: Those replacement files seem to have fixed the error. I'm still getting Error: ReferenceError: FoswikiTiny is not defined but I think that's something unrelated. [13:31]
LavrGeorge you fixed the problenm behind http://foswiki.org/Tasks/Item13316 completely - didn't you? [13:31]
gac410Between CDot and me... yes Module and Enabled settings should be in good shape [13:32]
LavrI will close it then. It is covered by a generic bug item so I will not put it in WaitingForRelease [13:34]
gac410Okay thanks. [13:34]
MichaelDaumgac410, okay: will check in [13:34]
gac410Any recollection on the "FoswikiTiny is not defined" I'm searching Tasks and Support, ... I know I've seen it before I just can't remember why [13:35]
GithubBot[distro] MichaelDaum pushed 1 new commit to master: http://git.io/vnf4t
distro/master 7754989 MichaelDaum: Item13710: fixed javascript error on IE...
[13:36]
***GithubBot has left [13:36]
FoswikiBothttp://foswiki.org/Tasks/Item13710 [ Item13710: JQueryPlugin (6.13) version of jquery.foswiki.js fails in 1.1.9 installation ] [13:36]
gac410Damn. Went to another 1.1.9 site, Wysiwyg edit. works fine. Search page source Same exact reference for FoswikiTiny. So wtf can't 1.1.9 find it after plugin updates.
MichaelDaum: curious. Do we still need to ship yuicompressor with JQuery Plugin if that compressor is broken?
[13:39]
MichaelDaumgac410, it really should go away. as well as any perl based js and css minifier
we are depending on node.js' toolchain for that as these are the only ones making sense nowadays
[13:44]
gac410okay. I'll open a task to remove cruft from JQueryPlugin. I wonder if we also should start pruning some of the older jquery versions. [13:45]
MichaelDaumdefinitely [13:46]
gac410Removing old jquery ... is that a 2.1 level change, or one okay for a patch. lavr... any reason to keep old mostly non-working queries in the distribution? [13:47]
LavrI do not think you need to worry about legacy with respect to jquery revisions. Just keep the major one from 1.1.9 and the latest and greatest
There is no legacy on 2.0. You can tell from the lack of bug reports that not many are using it. probably because they still fight upgrading - like I do.
[13:48]
gac410MichaelDaum: Created Item13722 No release designated yet. Maybe for 2.0.3? [13:54]
FoswikiBothttp://foswiki.org/Tasks/Item13722 [ Item13722: Clean JQueryPlugin of obsolete material ] [13:54]
MichaelDaum2.0.3 or 2.1.0 whatever is next [13:56]
gac410okay. [13:56]
on foswiki.org ... is TinyMCE working for anyone? I always get NatEdit now. On Trunk I'll get TinyMCE, but not on f.o. Trying in Sandbox.
Damn... Someone added * Set NOWYSIWYG = on as a hidden security setting in Main.SitePreferences wtf?
Probably should be a Local, not a site-wide setting???
[14:05]
LavrI have not caught that but that must be because I had to tweak it for misc things
I did not CATCH that ... darn grammer
I do not see that setting on my copy
[14:08]
gac410Topic revision: r55 - 07 Jul 2015, MichaelDaum Disabled TinyMCE Globally for foswiki.org ... Michael??? why?
no it's specifc to foswiki.org
[14:10]
LavrAh. ON f.o [14:10]
gac410I'm going to guess it was meant to be " * Local NOWYSIWYG = on" to prevent SitePreference itself from being munged up by Wysiwyg
And make it that way :P
And then wait forever as the cache invalidates every page.
[14:13]
Lavrf.o is an important test bed for us and Wysiwyg is important - even if most of us always hit Edit wikitext [14:14]
gac410The new natedit is so much better, it just didn't register that I was not getting tinymce.
Crap. I bet the cache invalidations are going to time out fcgi and leave us with a stale db lock.
gac410 fires up ssh
[14:15]
LavrNatEdit is a killer feature [14:17]
gac410MichaelDaum: before I blow a bigger hole in my foot. I's safe to just "rm -rf sqllite.db* cache" to wipe out the cache ... and not worry about "in-flight" transactions, or should i stop apache? [14:23]
MichaelDaumjust rm [14:25]
gac410cache is reset. Btw, after I deleted, no new files were created. ... until I restarted apache. Maybe a fcgi side-effect? [14:28]
.... (idle for 17mn)
jomo posted a really superb presentation on unicode http://foswiki.org/Sandbox/UnicodeBasics?slideshow=on;cover=slideshow#GoSlide1 [14:45]
LavrNext upgrade annoyance. SmiliesPlugin.
Not complaining. Just explaining.
We have a defined our customized SmiliesPlugin topic and added additional Smilies which are actually more business minded icons like red, yellow and green flags
[14:52]
gac410Any chance you are capturing these for maybe a "Experiences" chapter in the UpgradeGuide? [14:53]
LavrBut sizes have been increased and a css file added that sets them to a slightly larger size. Result. They look bad!
I have already spent way too much time on this. I am getting a bit tired of it all now. I cannot understand why upgrading from 1.1.9 to 2.0 has to be THIS difficult.
[14:54]
gac410Trunk (on svn) spent 4 -5 years gathering commits from developers, many who have left the project. There was a lot of extremely important work. Trying to do a line-by-line yeay / nay review of 1000's of checkins was impossible.
We had a practical choice. 1) Cherry pick changes into 1.1.x and most likely miss a LOT of good stuff. or 2) Try to go forward.
we had a very long beta / RC cycle to try to address this stuff. Very little feedback.
For better or worse, we decided to move ahead .. the big changes were too important to keep hidden.
It's a "2.0" for a reason. we fully expected upgrade to be hard.
[15:00]
LavrNoone could test a beta when the upgrade to the beta was a 2-3 weeks effort. Think about how many weeks I have been working on this. The change no SmiliesPlugin is that Michael has replaced the old ugly icons with newer nicer icons. But forgotten to ask himself - how will this work when someone upgrades?
Increasing all the smilies in size and renaming all the picture files. It has consequences. Could it have been done so upgrading the plugin would still work fine?
The change that makes the upgrade a pain is small. It is ONE number in a css file. It is even needed? Can I delete the value and my old icons will works again?
I will try that now
it is just. That is another hour of upgrade work that I'd would have liked to avoid. I notice because I was going to test ActionTrackerPlugin and notice that the icons on the meeting minutes are massive big and not sharp. When you scale a 15x15 to 17x17 the result is not pretty
It must also mean that people that just upgrade the plugin in 1.1.9 must get a bit of a surprise.
[15:03]
gac410You deleted the value, or just changed it to 15x15? [15:09]
LavrRight now I get no change. Probably because I edit the wrong place [15:11]
gac410Maybe need to change the compressed / minified version?
Lavr, what did you change? max-height?
or the height 1.5em ?
[15:11]
LavrJust changed the 19 to 15 to see the effect on my old icons. But that is a bad fix because the new nice icons should be shown in their native format
Removing the 15 = very big and ugly
Removing the 1.5 em - old = OK
[15:18]
gac410Right. The 1.5em allows the icon to scale to 1.5 time the text size if I understand that, but the max-height then sets a limit. So you get hopefully better scaling of icons as a user zooms the page. [15:20]
LavrYes. The max height does not make the old icons ugly [15:21]
gac410We are trying to move a lot of the rendering control into CSS. Foswiki 2.1 will probably ditch CGI::blah rendering and move the whole html generation into templates.
CGI has deprecated all of the rendering functions, and will remove them from a future CGI release.
[15:21]
HanumaanI am using foswiki latest and I get following error in apache : http://apaste.info/x1w as need to have mod_perl .. do any of you have same problem? [15:23]
jmk0whoa. nope, never seen that [15:24]
gac410Hanumaan: I have not seen that either, and we have definitely tested on mod_perl [15:24]
jastmy guess would be that that can only be caused by native code extensions [15:25]
gac410Or an issue in perl, or compatibilty between mod_perl and perl version [15:25]
jastso chances are that one of the dependencies has faulty native code that the versions Foswiki developers tested didn't have
or that, yes
[15:25]
LavrIf I remove the 1.5 em and look at the new icons - they look as fine as they do with the 1.5 em. And they scale up and down just fine when I zoom in and out in the browser. [15:25]
HanumaanI have perl in the following version : perl 5, version 20, subversion 2 (v5.20.2) [15:26]
gac410Lavr, In that case, I'd suggest opening a task, and either removing it, or we ask MichaelDaum Looks like he added that particular CSS, and I am not all that css savvy.
Hanumaan: Quick search found http://stackoverflow.com/questions/24618243/can-attempt-to-free-unreferenced-scalar-errors-be-safely-ignored
Obviously you can't ignore it. But we don't ship any XS code at all, and don't really have expertise here to debug internal perl issues.
[15:29]
LavrNo. This is not a release blocker thing. But it would be good if the upgrader with custom icon page (documented feature ni the plugin) can upgrade to same icons as he has. And then when all is in production you can play with all the little improvements. In this case it is to make a copy of the new SmiliesPlugin topic to Main web, and add the custom icons to it and change the setting in SitePreferences. And if
people don't like it you change back. And it is all done from the browser.
[15:31]
gac410Lavr, I'm not following that. Are you saying kill off the css file? How do you change the css from the browser.
It sounds like we can safely remove the height: 1.5em from the css definition.
[15:33]
LavrIf you remove the 1.5 em from the css it seems to work just fine both with new and old icon set. [15:34]
gac410right. So let's review that with Michael and slot it for 2.0.2 [15:34]
LavrBut all the icons are defined in the SmiliesPlugin topic. And you can change to an alternative with Set SMILIESPLUGIN_TOPIC = SmiliesMotorola in our case [15:35]
gac410yes? [15:35]
LavrThat is better than adding new icons to the plugin page because you lose them when you upgrade the plugin [15:35]
gac410what's that got to do with the CSS?
gac410 is very confused.
[15:35]
LavrThe problem is that when you have such a custom SmiliesMotorola with all the old icons and new icons made in 15x15 and you scale them up they look blury.
The new icons are 19x19
[15:36]
gac410Okay.... but removing the 1.5em from the css fixes that ... righ?
t
[15:36]
Lavryes. I cannot see any visible effect on the new icons when I remove the 1.5 em. But the old icons look much better withouut it as they are not scaled. [15:37]
gac410Okay so good. Task to remove height: 1.5em from the CSS, That is completely orthogonal to SMILIESPLUGIN_TOPIC isn't it?
I don't get what you want to do with SMILIESPLUGIN_TOPIOC
[15:38]
LavrI am writing the task. I am just explaining how an upgrader can safely get the new icons later [15:40]
gac410The only reason I'm saying review with Michael is that I don't really understand why he added that height to the css. Maybe he needs it for NatSkin [15:40]
LavrYep. [15:40]
gac410But in that case it should be a css override.
in a smilies.nat.tmpl or something.
[15:40]
LavrIf you want to mix icons of different sizes it is best to not try and set the height. The old plugin did not spit out any size info so you could add larger pictures.
I write the Item and set priority low and we see what Michael has to say
[15:41]
gac410agreed. Only reason to set an explicit height on an <img is to improve browser rendering performance. but that has nothing to do with the css height.
Lavr, I'm going to release / upload CharsetConverter with fix for the -r repair option ... but later. Need to get stuff done around house.
[15:43]
LavrSure. You may want to suggest in the docu that upgrading from a Foswiki that had users on Windows machine should convert a 1.1.9 site using -encoding=cp-1252 and not -r
That was the ONLY combination that has given me a satisfactory result.
[15:46]
gac410Yes. I started trying to update the docs a bit.
So even with the fix, -r doesn't help?
[15:47]
LavrNo. I got conversions I did not want. None of my topics are utf-8 even if there is a utf-8 char in it.
it is more likely that there are cp-1252 text that must be converted to utf-8 and a single garbage utf-8 char that can be ignorred.
[15:48]
gac410I've been hunting all over for a LoremIpsum generator that would generate using a variety of codepages. We really need a strong test corpus to validate the converters. bulk_copy and convert_charset [15:49]
LavrI believe that the reason why I see so little valid UTF-8 in topics is that the Apache set the charset to iso. So the browser showed the page as ISO making any utf-8 char garbage when displayed.
So people have very naturally just edited the garbage they pasted in so it looked nice.
[15:50]
gac410Maybe -r could: if utf-8 detected, do a manual fixup of smart-quotes, bullets, etc .to utf-8 ... but probably not worth it. [15:51]
LavrContrary to the cp-1252 chars that actually were displayed very nicely by the browsers [15:51]
gac410The bigger issue is the entity-encoded high ascii characters in links. Once I get 2.0.2 out, I'll probably think about that one a bit more. [15:52]
LavrI do not think it is worth it. It would be better to focus on how we can help people semiautomatically fix all the broken links [15:52]
gac410I don't understand why we entity encode links anyway. If Wysiwyg inserts a link it does not. But Foswiki/Attach does.
So sites have a mix of encoded and not-encoded depending upon what created the link.
[15:52]
LavrMaybe very old legacy. Browser have become better over the years to understand URLs with international chars [15:53]
gac410y true. Maybe we should remove encoding of the utf-8 now.
So that wysiwyg and attach create the same style.
[15:54]
LavrSounds like a good idea. At least to try it and see if that makes anything fail. [15:56]
When I upgrade I will need to keep my old Smily setting topic. I have tons of direct image links like <img alt="smile" border="0" src="%PUBURL%/Main/SmiliesMotorola/smile.gif" title="smile" />
And I can guess why. People copy and paste text from view mode into the editor and then you get the HMTL link and not the icon. Oh. There will be many of those in any wiki. And they will not work at all if they used the standard out of the box SmiliesPlugin because all the icon files are renamed. Buh!
end of my day
Lessons learned. Do not rename anything!!!!!!
[16:06]
....... (idle for 34mn)
gac410Lavr: Could you give an example of a rename. ... so I don' t have to pour through the commits? [16:42]
LavrHi Again. Home now. In this case the SmiliesPlugin file names should have been preserved even though the icons were replaced by newer nicer icons [16:45]
gac410Could you give an example of a rename? [16:46]
LavrLet me get to a computer. I am on an ipad [16:46]
gac410okay. just one example is plenty. Just saves me scanning through commits.
I did find *missing* icons in the refresh and did restore them Some of the Foswiki topics used them. But didn't detect renames, probably as we don't use explicit links.
[16:46]
LavrWith SmiliesPlugin the changes are from 2014. I do not know if Michael released it to f.o then. Otherwise renaming back creates problem also. [16:48]
gac410Renaming back is probably not a good idea. There is a Foswiki:System.OriginalDocumentGraphics ... is that them? [16:50]
FoswikiBothttp://foswiki.org/System.OriginalDocumentGraphics [ OriginalDocumentGraphics ] [16:50]
LavrSimple example. In the old SmiliesPlugin the :-) was translated into an img link to .../pub/System/SmiliesPlugin/smile.gif
After the update of all the icons smile.gif is now emoticon-0100-smile.gif
[16:51]
gac410Okay. hm. So simply restoring the legacy files would make it easier for anyone who cut/pasted the html links.
No collisions / conflicts
[16:52]
LavrSo anyone that copied text from the browser in normal view mode and pasted it into another windows in edit mode will have pasted in the smile.gif link. And now they are all broken. [16:52]
gac410I don't think that's an objectionable restore for 2.0.2 [16:53]
LavrYes. Adding all the old smile gifs to the pub dir would work. You would not need to attachment them to the SmiliesPlugin dir. They just need to reside in the pub dir as files. [16:53]
gac410Best to attach them Store is getting very fussy about inconsistent meta vs. disk
The one missing one I added back was skull.gif which had no counterpart in the new icon set.
[16:54]
LavrI am lucky that in my Motorola installation I have always had a custom Smilies dir so all my links point to a Main web topic that I can just leave present. But for most this little change will for sure mean missing icon files in existing topics because normal users just copy and paste without know what they do [16:55]
gac410But I won't add them to the tables that define them. [16:55]
LavrI bet that 99% of all legacy links are to :-) and :-( [16:56]
gac410I'll have to revert a checkout. I removed them all from the git repo, as they showed up as manifest errors in check_manifest. [16:56]
LavrIn our meeting minutes people used these to mark present or not present. Or done and not done.
Some funny guy added a 32x32 icon with an island with a palm. Used on some pages that track vacation. They will be flattened by the new plugin. I can live with that. A silly icon to have anyway.
The other icons we added are all very business oriented. red/yellow/green flags. And red/yellow/green 16x16 colour blocks used in status tables
[16:56]
gac410Do you have a task to get back the lost icons? [17:02]
LavrNo. I was sure you and Michael would burn my underwear if I had suggested to add back the files >:-) [17:02]
***Lavr is now known as LavrCroft
LavrCroft is now known as Lavr
[17:03]
gac410I'm less concerned about cluttering attachments, which are relatively hidden, vs. System web topics which are a cluttered mess. [17:03]
LavrWell. I have not found more missing System stuff. I searched very hard to see if I had missed something. Adding back two files in total is not THAT bad I think. I remember now the other one. It was actually a file that had been renamed by Arthur.
I think it was used in old WebNotify topics.
A help text
[17:05]
gac410Yes.
Okay. I'll agree, not worth a contrib for 2 files. There was a lot of cruft removal. EditingShorthand is gone, iirc.
[17:06]
LavrThat was only included in one place and not all over the place so that was not a problem to change [17:07]
gac410consolidation of help texts, some of which disagreed with each other. [17:07]
..... (idle for 24mn)
GithubBot[distro] MichaelDaum pushed 1 new commit to master: http://git.io/vnJ7p
distro/master 350c995 MichaelDaum: Item13723: Add next slide navigation with spacebar
[17:31]
***GithubBot has left [17:31]
FoswikiBothttp://foswiki.org/Tasks/Item13723 [ Item13723: Add "next slide" navigation with spacebar ] [17:31]
gac410Lavr, I have a checkin ready to go that adds back the old smiliey icons, just as attachments, with comment "Legacy", no configuration to actually access them except by direct links. [17:33]
LavrI am sure that will help upgraders. Great [17:34]
gac410Just need a task ;) [17:35]
LavrEating. I can make one later [17:35]
gac410okay sounds good. [17:35]
Guest63063so if I have a few questions about foswiki, you guys might be able to help? [17:39]
....... (idle for 31mn)
gac410jomo ... excellent presentation on unicode [18:10]
jomogac410: far from finished - no excessive energy for now ;) use it as you wish in your topic... [18:10]
gac410I was going to suggest that we include it right into the Support web as a presentation, ... maybe with a bit of grammar cleanup
Maybe add a couple of slides at the end about implications for Foswiki.
[18:11]
jomogrammar cleanup + need aslo many checks for the number values - it is not ready for "real" presentation imho...
i wrote it because i saw your topic - just take it, cleanup, modify - just do whatever want ;) :)
[18:12]
in the logger i saw youre looking for the lorem-ipsum for the different codepages - what do you expect (want)? [18:18]
gac410I was just thinking of some way to thoroughly check out the CharsetConverter including the -r repair option. Not really certain yet what I want. Just looking at stuff
Obviously needs to also include "bad" data - topics with windows codepoints inserted. etc.
[18:19]
jomoe.g. single-byte codepages only?
iconv -l - show many different codepages...
ech - encodings.. ;)
[18:20]
gac410okay ... yeah. I think that's what we want. And turn it into a "set" of topics with links, forms, etc. Hit it with CharsetConverter and review the results.
er... no... way way overkill. And that just list the encodings.
[18:22]
jomoso workflow. 1) generate such pages 2.) convert them with iconv to utf8, 3.) let foswiki test to convert them 4.) compare the result with the iconv? [18:24]
gac410Is there some way to actually test charsetConverterContrib with a corpus of likely encoded topics, rather than having to wait for people to report bah.. this didn't work.
For now this is lower priority for me. I really need to work on some sort of 2.0.2 we are very overdue from release plan.
[18:24]
jomookay :) just wondered about ;) :)
CU for now - if you think i could help with something - just say my name in chat - i monitoring the irclog at least once a day :)
[18:26]
Lavrgac410. Food is eaten. A bottle of redwine is empty (yummie) and http://foswiki.org/Tasks/Item13726 is ready for you [18:27]
jomoergh mean convince [18:29]
FoswikiBothttp://foswiki.org/Tasks/Item13725 [ Item13725: SmiliesPlugin can be made a little easier to upgrade with simple css change ] http://foswiki.org/Tasks/Item13726 [ Item13726: SmiliesPlugin icon files have all changed file name and that causes broken links for legacy sites ] [18:31]
jomo[off] ah yes, different task - going to study - will come back later - CU [18:32]
LavrMichael updated the SmiliesPlugin in 2014 but it was never released on foswiki.org.
And I doubt the 2.0 legacy is a problem to consider (people copying raw links the past few weeks on production sites)
So gac410 an alternative fix is to rename the new icons to the old names for those that are direct replacements.
This way you do not add new files. Just rename them.
Less cruft for the future
[18:33]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vnUE6
distro/master a5a92c8 George Clark: Item13726: Restore legacy smilies...
[18:35]
***GithubBot has left [18:35]
gac410Already done :( [18:36]
LavrIt is up to you if you want to spend more time on it :-)
I should have checked f.o earlier. I saw MDs checkin was in 2014 so I assumed wrongly that it had been released.
[18:37]
gac410The icons came from an external source, so probably easier to leave the new names for future integration / updates ?? [18:38]
LavrMaybe. If MD tomorrow feels strongly that rename is better than the extra cruft I will be happy to assist with removing them and renaming the existing.
It is within my skillset :_)
I wish I was able to fix the EditRowPlugin problems. I have the feeling it is the same code root cause that creates most of the bugs I raised today
I have looked at the code and I understand nothing
[18:39]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vnUg7
distro/master ef44d8f George Clark: Item13725: Remove height for better compatibility.
[18:42]
***GithubBot has left [18:42]
LavrI do think CDot needs help on it besides me frying his balls with a BIC lighter
Thanks for the Item13725 checkin George
[18:42]
gac410The challenge is he (very rightly) made the 2.0 core able to represent table objects rather than requiring everyone to parse the | | tables.
It lays groundwork for future api for extensions to easily request row info without writing their own parser.
[18:43]
LavrYes. That has great potential. [18:44]
gac410But trying to link together the new TABLE object with the old Macros is hell. And not very gratifying works. [18:44]
LavrI already have ideas for that for my TimeCalcPlugin so I could put the plugin in a table and it would pick up values from another column in same row
The thing is - it is almost there. The main problem is related to how the ERP gets rid of TABLE tag and reinserts it. And at the moment it goes totally wrong.
[18:44]
gac410I think it needs a "step back" and look at the overall design of the API with view toward implementing augmentation of table parsing and rendering. [18:46]
LavrThe first step is a accept that TablePlugin is not a bad plugin and that it is widely used and needed. I cannot understand the resistance again its existance.
You need to be able to control basic things like columnswidths and data allignment
And legacy has it - it is a TABLE macro in front of the table that defines this
[18:49]
gac410The table parser does support TABLE ... that's not the issue.
Also the new Tables API is back-ported to 1.1.9, by the TablesContrib. Real challenge here is that the fixes for ERP are changing Tables, which means they are not backwards compatible to Foswiki 2.0.0 or 2.0.1
[18:50]
LavrThe two issues I see is that the ERP tried to remove and reinsert the TABLE tag AND it screws up the column numbers when it adds the pencil column [18:53]
gac4101.1.9 won't be an issue . just update TablesContrib. But it's not a contrib on 2.0 :( [18:54]
LavrI do not even want to look at TablesContrib. Let us get the ERP and TP working on 2.0. And put FAT WARNINGs about not upgrading ETP and TP on 1.1.9. And ERP never worked in 1.1.X either.
I have been saying that for years.
[18:55]
gac410TablesContrib is *unmodified* Foswiki::Tables modules from 2.0. nothing special. [18:56]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Tables [18:56]
gac410Guest98824: you had some questions earlier? [18:58]
Guest98824yep [18:58]
gac410ask away [18:58]
Guest98824ok, so if i have to create a plugin to change formfields in the Form "attached" to the current topic, how would i do this?
a bit similar to the CommentPlugin, you have two fields where one can enter new Dates, click the submit button and the Formfields "Date" and "EndDate" would change accordingly, without having to undergo the edit/save cycle
[19:00]
LavrI can help with that. [19:02]
gac410The Foswiki::Meta API has functions to change formfield values. Lavr has more experience though ;) [19:02]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Meta [19:02]
gac410And with that ... Gotta head out for a while. [19:03]
LavrGuest. Let me get a few more details and I may be able either directly or give a link to a plugin that is already there [19:03]
Guest98824ok [19:03]
LavrYou want some fields inside the topic itself?
Look at http://foswiki.org/Extensions/MultiTopicSavePlugin
[19:04]
Guest988242 input fields, where a user can write the new dates in, so the dataForm gets changed after the submit-click [19:05]
LavrIt is originally made to be able to do a SEARCH - display certain formfields for each topic in edit mode - and save them all. [19:06]
Guest98824great, thanks i'll have a look at it [19:06]
LavrBut I have also found use for it inside a single topic to create some editable fields inside the topic text that saves to the same topic as form field updates
It looks complicated at first but it is actually very simple.
The complicated macro is %MULTITOPICSAVEINPUT{"Field name" type="field type" multiple="on|off" size="field size" web="webname" topic="topicname" value="desplayed value in field" options="list of options"}%
If topic="%TOPIC%" then the field works in the topic itself.
editmode="on" will make the field permanently in edit mode.
[19:06]
Guest98824and type/size/etc just has to be exactly as it is defined in the DataForm? [19:11]
Lavreditmode can also be controlled by a URLPARAM so it only goes in edit mode when clicking on a link that adds the URLPARAM
Actually. It does not have to be
But it is usually smart if they match :-)
It does not (yet) support the date mode where it pops up the calendar. But it would be a nice enhancement to it ;-)
If the dates you set are TODAY then also consider http://foswiki.org/Extensions/SetFormValuesPlugin
It is a plugin where you can define a rule so when a field (example a Status field) changes to a certain value (Closed) a date field is set to now.
It is also a good plugin to see how to change formfield values
[19:11]
gac410jomo, re your comment to missing icons. Yes, could be done in apache rules, and/or symlinks. But these are beyond most web admins. And in this case it's only a small number of very small files. [19:17]
Guest98824so instead of the date type I should use type="text" and size=10? hm nope the 2nd one, wont work, our people never manage to book their worked time exactly the day they actually worked. even worse with the aprentices [19:18]
LavrYeah. I use it in a bug reporting tool to set date fields when a bug report state field changes from New -> Assigned -> Performed -> Closed
New gets set when created. Assigned get assigned the first time the item is assigned but not when re-assigned (reopened). And I have performed and closed date fields that get updated when the bug gets performed/closed. The nice thing is that if people jump over the state performed, the plugin rules are smart enough to both set performed and closed dates
Guest there is one more more direct way
If you just want form field that submits to a formfield then it can be done without any plugins
[19:19]
Guest98824how? [19:25]
LavrLook at these few lines (flood alert)
<form method="POST" action="%SCRIPTURL{save}%/%WEB%/%TOPIC%">
<input type="submit" value="Update Resolution/Status Summary" class="foswikiButton" /><br />
<textarea name="ResolutionSummary" wrap="virtual" rows="8" cols="80" class="foswikiInputField">%FORMFIELD{"ResolutionSummary"}%</textarea><br />
Fixed in revision <input name="RevisionFixed" size="6" type="text" class="foswikiInputField" value="%FORMFIELD{"RevisionFixed"}%"/><br />
</f
Last line is
</form>
So you can put a HTML form in the topic with one or more fields and the submit changes the form fields.
The example I just gave is for a text area field. And the form shows the current value of the field so you can modify it and submit it again and again
And that you can make a real date field.
I guess that is all you need. No need for a plugin.
[19:25]
Guest98824great, i really like that [19:29]
LavrIt is incredible what you can do with Foswiki - from the browser :-)
BE PROUD! Foswiki devs :-)))
Hey wife has cake!!
[19:32]
Guest98824pretty great, yeah. but for a foswiki-noob who is just starting its still pretty complicated [19:33]
LavrGuest. Yes. But soon you will be a God at the office :-) [19:39]
Guest98824I'm just a trainee student, but nobody at the office exept from my boss knows how to use foswiki, so i get these tasks :D [19:44]
.... (idle for 15mn)
still have a question: can I somehow disply thatt caendar thingy next to the input fields, so people can choose directtly from the calendar and dont have to type the date manually? its also a bit "ungood" that it is posible to enter just random not "date" formated stuff and i still gets saved, even if its longer than 10 signs [19:59]
gac410See if http://foswiki.org/System/JSCalendarContrib#Using_the_Calendar_in_forms helps [20:01]
LavrI do not have a fixed and ready code for you but look at http://foswiki.org/System/JSCalendarContrib (or your own local copy of System/JSCalendarContrib). It shows how to do it [20:01]
gac410:) [20:01]
Lavr:-) [20:02]
Guest98824you guys are great [20:05]
gac410Lavr, any ideas on how to deal with the unmaintained plugin. New support task about HijaxPlugin, which is broken, out of sync with git, and dev has disappeared.
All of DavidPatterson's extensions are now in pretty tough shape, and he marked them CoordinateWithAuthor :(
[20:10]
LavrWe cannot save the world. Unless the plugin has strategic value for the project [20:11]
gac410Should we start moving broken stuff in to Extensions/Archives? [20:12]
LavrIf people left them unmaintaind for years, and someone wants to take over than I would ignore it
It is not like MDs plugs where he constantly attand to them
[20:12]
gac410problem is finding someone interested. I'm rather maxed out. [20:13]
LavrAttend. Darn ipad
Ignore it then.
[20:13]
gac410We should answer the questions. Otherwise it reflects badly on the overall project. :( [20:13]
LavrIf you have time tell the truth. Plugin lost maintainer. Looking for someone to take over
But we cannot save the world. And we have to focus on the important
[20:15]

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