2100h here in Old Europe. Helllo everybody. :) Hi Oliver Hi Kenneth Will be a short meeting, I guess. Yes again * xoimai has quit ("http://www.mibbit.com ajax IRC Client") Maybe we have some time to talk about ways, I can improve my contributions to twiki then. :) :-) Well. You can always start looking at some urgent bugs uebera|| and gnc are you here and need to get registered as being here in the minutes? The problem I have in general is, I /feel/ I dont have enough overview about twiki to work on most of the bugs. No I think that is a generic problem for most. It has become too complex in some areas and those areas are tangent to almost everything. ;) I guess, I sometimes just need somebody saying "its ok, to do so"... :) Yes. Which is why it would be good if the key developers would be here to help with questions like we used to in the good old days. I will look at Bugs:Item5382 (shorter urls / https) later, since I always wanted to try shorter urls. Should I continue to try and have these release meetings any longer? I feel some of the main contributors are just laughing at me. Dunno. We can ask for RSVP with the invitation and only do a meeting, if X Y Z is there. I have tried that. They just ignore it. I would suspend the meetings then. Basically that means the whole release process is down the toilet. They are all so keen on getting governance issues resolved but the one place where we have governance - the feature requests - people don't care to participate. This makes no sense. So, the problems are deeper, I guess. But what are they??? I will probably pull back the invitation to Berlin in September. There is no point any more. I have no idea, since I did not speak to the key players in this plot. for a very long time Maybe we should take the step and kick them out of the project then? Or branch away Who? We are so many people that get along well. It is 3 people that create all the trouble. Peter, Sven, Crawford. Its 3 people who "are" twiki (to some big extend). They are currently 3 people preventing TWiki from developing. * ktwilight (n=ktwiligh@33.78-66-87.adsl-dyn.isp.belgacom.be) has joined #twiki_release As you can see I do not choose side here. I am so angry at both sides that they cannot pick up the phone and get an agreement hi Hi ktwilight Hi. You are no 3 here. oh? wait, what time is the meeting? hi OliverKrueger The release process is dead ...?! It was 21:00 central European but none of the key developers show up so we are just here to be laughed at. :/ not even peter is around? that's...unheard of... Peter had said he would not come. The rest just stay away without a word as usual. what was peter's reason? Meeting with an investor :/ am sure he could have adjusted his schedule... Sure he would if he could But where is Crawford? dunno but shouldn't we reschedule the meeting too? would be more interesting and fruitful to hear what peter has to say about this important investor It wont be an .org investor. ;) oh, priorities ;) Reschedule it for which timezone? Are there any potential participants (execpt Sven)? good question, let's vote. not here and now, btw. Yes. We moved it to 21:00 CET / 20:00 UK to fit the European developers better. But that did not help because that is not the problem. The developers choose not to be here. I just do not understand why????? oh * EugenMayer (n=Miranda@dslb-088-066-128-163.pools.arcor-ip.net) has joined #twiki_release Maybe the ones that are not here are in reality not interested in a democratic process? (good evening, morning, afternoon) * ktwilight didn't even know the time moved. all i saw in #twiki was that the meeting would start soon evenin' EugenMayer Hello Eugen Hi Eugen Hello together EugenMayer, how's the pdf thing coming along? iam fixed serveral bugs this days, not committed yet. I worked on supporting images ( done ) and some performance / configuration issues *i awesome :) Is performance an issue for a printer view? ;) in the current version are several bugs on the local fetcher, so a lot of things accessed localy are not working, thats what i fixed OliverKrueger: : for some of us ( SvenDowideit ) haha My monitor does 60 pages / sec, my printer does 10 pages / min. ;) i thinkk it's more about rendering? sure. :) Yeah but it seems like big time topics are timing out / memory exceeding rendering/parsing speed? just joking. :) how big is big? I think we will need to replace the dom parser, maybe by a perl one and keep the CSS stuff as is speaking of big topics, i'm gettin' quite frustrated with large topics and the lack of sectional edits. though i know there's a plugin for it ktwilight: : for me i did not face any problems yet, you must ask SvenDowideit hm there are some approaches to sec edits... OliverKrueger, which works best atm? one for each twiki version. ;) dunno, but tell me, if you find out. :) ( lovely i dont need all this edit things ) sure will * ktwilight just hopes it works on 4.2 as well You have a read only wiki? * ktwilight still haven't complete his upgrade yet :( if there will ever be a 4.2 the office editor is working that well, that its the "standard" way at the moment, i dont have a WYSWYG editor available Lavr, 4.2.1 you mean? what are its release blockers? got a link? oh yeah ktwilight, iam 0% done with porting to twiki 4.2, this will be my next move :) http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x05x12#1_Review_Urgent_Bugs_with_4_2_1 i think i'm about 20% done http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/ReleaseBlocker * ktwilight actually is scripting a bash for an easy upgrade next time Especially Item5118 is bad. It has been open since last year. http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5118 Are there any specs for Svens new user backend? Lavr: Thats one of "those areas". :-( OliverKrueger, not that i heard of except the source k I keep on saying that the user mapping code should be reverted back to 4.1.2. Problem is that even that is difficult without also rolling back all other bug fixes. But it would be the right thing to do. I "feel" that would not be possible without lots of work. When I think about how many hours I have spent testing and bug reporting the new user mapping code - so Crawford and Sven could make money on a client - and then when I get trouble from it I am without a fix for 5 months. i guess not much thought was put into user mapping code on the wider area of twiki itself :-( but let's concentrate on finding a solution? ;) what do you guys which yourself from user-mapping? loginname<->wikiname? s/which/wish/ ? OliverKrueger : yes, sorry yep, some sort of abstraction. We always had a mapping between a login name and wikiname. What was done in 4.2.0 was a major code refactoring that enabled pluggable user mapping so TWiki could be integrated with a 3rd party application. EugenMayer, not sure about the details, but TracOnTWikiContrib depends on 4.2 user mapping, and not even to mention any other webapp integration at the user level. LoginManagers are interwoven with it, right? when i started with twiki, that loginname/wikiname diffrence really did a great job confusing me. Until know, i do not really see any use of it, except confusion and extra-developer time EugenMayer, totally agreed I use the login name feature so that we can use a global single signon. This way users use same password as everything else. in many SSO environments using a different login name is not an option. Lavr: : you dont need user mapping for that? i also have a single-signon and do not need the user-mapping thing No When you use Apachelogin you just let Apache modules take care of authentication. Eugen: Probably you are not forced to user "emayer" as your login. ;) That has worked fine since Beijing, Cairo, 4.0 and 4.1 OliverKrueger: : my user are name like firstname.secondname there were some patches in the topic, how do they fair so far? For ApacheLogin 4.2.0 has not changed anything in a positive direction. Only difference is that the access control feature broke and still has not been repaired. I have not tried the patches because it is clear that they are not a complete fix. from the looks of it, they are expecting some tests on whether it works or not. Lavr: : for me that sounds like a really sensitive place for beeing not working. I dont undestand why they are still no fixes. Also i dont get, why even you did not fix it, when you need that so much. It seems to be a lot of work / its too complex? http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5118 michael did have a fix, somewhat. I have tried to fix it but I do not understand the new user mapping code. Even Crawford has told me he does not understand the new code. Wasnt sven writing the new user backend ? Yes SvenDowideit is the coder for that I fear i cant help to much with 4.2 bugfixing right now, iam still with 4.1.2 and doing my work there. There are still stings in 4.1.2 which arent to great and costs me a lot of work. But iam about to finish and will port all the plugins to 4.2 then and hopefully then, i cant help with fixing common bugs What is really sad is that there is a loooong list of good fixes ready for 4.2.1 :) Is someone using LDAP with 4.2? It was the only reason i did not move to 4.2 early But the one bug that causes me most trouble is still open. 5118? And the new Wysiwyg is also broken with one bug that was introduced AFTER 4.2.0 which makes it destroy topics with bullet points. well, lots of problems happen for wysiwyg since 4.2 michael is working on ldap for 4.2 iirc Well. Also a lot of good things happened to the Wysiwyg so do not be too hard on that. wysiwyg is a hard problem.... always. no offense, i don't use wysiwyg, so i don't quite see the good things (yet?) but i do see lots of issues For people using non Latin charsets the 4.2.1 has a potential to be much better. If we get the last very few open bugs closed. true, unfortunately one person can't handle such a large piece of pie ;) CDot is really doing a lot of work on the WYSIWYG editor, i dont think its right to critisize to much, because he is a one-man-army in that point yet. And all that encoding problems are extremly time consuming work, so that really a problem of us getting more devs on the WYSIWYG thing i still believe twiki lacks key devs in key areas you open twiki to a much bigger userspace with wysiwyg... but I dont like it, too. ;) EugenMayer, 'xactly and i don't think crawford is being paid for his work on this, so he needs to of course work on projects to sustain his income The only critique I have against CDot is that he and other core developers do not participate in the release meetings so we can give the feature proposals a fair treatment. again, twiki lacks key devs, which i seriously thought peter was bringing in due to twiki.net iam not using tinyMCE anymore, but iam doing the same thing using an office editor. And thinking about all the bus and time i investigated, i can really undestadt CDot, that he aint able to run after all the problems.. hm ktwilight: : how is twiki.net suppose to help t.o ? who is tinymce targetted to? new twiki users or existing twiki users who have been using it for years? The amazing thing is that the Wysiwyg is currently quite great - if it did not eat the newline after the last bullet in a bullet list. It is actually a pretty good editor now. is it supposed to? Lavr : i think its not to hard to fix that. EugenMayer, the picture that was painted to me in the beginning when and before twiki.net was born was to help t.o in development and in many other sense. i.e. for the good of the community at large. Lavr: and in 4.1.2 it does not Correct. But in 4.1.2 the Wysiwyg has 20 other bad bugs that have since been fixed. Who is involved in twiki.net? I mean, except of Peter, i think i did not meat anyone yet EugenMayer, it'd be challenging 'cuz of tml translations TWiki.net is still an early day thing with very few paying customers. Lavr: I use the 4.2 version of WYSIWYG i 4.1.2, so there are not diffrences EugenMayer, heh fair point. to me, or rather the community, t.net is behind the shadows most of the times The roundtrip tml-html-tml is the problem. unlike other OSS communities where various levels of organisations and such participate OliverKrueger, yup, that's it :) I worked into the WYSIWYG thingy to fix a bug with iso-8859-1 and for me, the current 4.2 WYWIWYG version works for bullets and all the things. But iam not sure why you face problems Lavr i dont think at all, that tml<->html is a problem here (except the Link-Issue) Eugen it is http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5664 that currently blocks the use with iso-8859-1 Which was introduced very recently. The 4.2.0 version has a very annoying problem with putting

and

round bullets. But at least the 4.2.0 version will not destroy the bullets once they are there. The current SVN version destroys topics with bullets when editing in FF Lavr: : i cant see how this bug is 8859-1 related ? It is not 8859 related. It is just the only Wysiwyg release blocker I know of that is not UTF-8 specific and I do not use utf-8. So I would personally upgrade the Wysiwyg now if Item5664 was not there I was travelling this weekend. Otherwise I would have spent all weekend trying to fix it. Lavr: : iam not sure you can use 8859 with the current version of tinyMCE. Sure you can. I have not seen other issues recently except this one. http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5626 there have been more issues with iso than utf8 from my personal observation... oh there is a fixed but its not closed? ktwilight: : iam sure you arent to wrong "Waiting for Release" is closed except it is waiting for 4.2.1 to be released. "Waiting for Release" is used to make a list of fixed bugs for the release note. I get it, thank you And just to clarify. Item5664 is not an iso-8859-1 bug. It is also visible with utf-8. It is just a wysiwyg bug which is NOT a utf-8 bug. It is a Firefox only bug. Firefox is adding some damaging space all browsers do when you come to the wysiwyg realm unfortunately, wysiwyg is a rather big beast Yes. But currently we are very close to having something "good enough". We have some utf-8 issues which is more in the heart of TWiki core itself. And we have the bullet error which is new. let's just hope a bug doesn't trigger another bug ;) but can we guarantee that without our not-so-expert-knowledge in character encoding? s/without/with The reason we started attacking the utf-8 problem was because Chinese/Japanese/Korean users could not use the 4.2.0 with Wysiwyg. which i'm VERY sure the user base isn't 51% or more ;) my (bold) question is this, twiki surived for YEARS without a compatible wysiwyg, why now? and especially in an abrupt time frame? s/surived/survived I run a TWiki in Motorola which is used both by Danish, Polish, and Chinese users - but in English. And the Chinese colleages have really adopted the wiki idea the past 4-5 months. i don't believe twiki users are average nutters who can't handle simple text formatting syntax. Wysiwyg is something all other major Wikis get now. If TWiki does not get it we are DEAD. My users main reason against TWIki is lack of Wysiwyg ktwilight: : for my cases, you believe wrong :) well, we have it now, and we aren't making much progress to the media at large EugenMayer, how many active users? wysiwyg is not a USP anymore, but a req... at least on the papers. to me is, the intention is great, i fully support it. but hte approach is somewhat...not fine-tuned. and due to the approach, we have a bigger problem than before ktwilight: : getting close to 70 now, in the end should be arround the double and possibly deter key decision makers and users away from twiki for something substandard like wikipedia EugenMayer, and are your users complaining about wysiwyg? and if yes, what have you done to help eradicate issues? s/possibly/potentially Iam not complaining about WYSIWYG editor, what i said is, that my users would not even think about touching the computer and use twiki without WYSIWYG or similar The problem is the users you never get because of lack of Wysiwyg. And to be honest. Try and add a column in a large table in Raw Edit. Even I use Wysiwyg more and more because it is much more user friendly. But I also use raw edit. We should never loose raw edit. For me, i had contact with WYSIWYG much earlier before i touched with twiki, i used in on moinmoin and other systems and i always got some problems, so when starting with TWiki, i moved away from it TWiki has from the beginning been a tool for computer geeks. If you want non technical users to use TWiki you need something that looks like Word and Excel and Powerpoint. sure, it's all good. but to gain that results that we want, we must ensure the steps we take are conforming to our dream. to me the steps are vital just as the goal Lavr: : exactly thats my point. And that was exactly my approach. Instead of investigating time into the WYSIWYG editor doint things the way Office-Tools do and build them just like a "word" i just simply use word, and only care about the converting thing am sure companies like google have dedicated teams just to get wysiwyg working close to perfection, yet still have to spend not weeks, but months to ensure its usability. i just make 'em upload docs, xls, and ppt to the topic, while the topic itself has a summary of what's happening. works well so far sure, you don't get the luxury of in-browser-editing, but hey, the browser isn't made for lots of things to work nicely And really, on my test, when a non technical user can work with an office tool, he there is not fear at all, it feals familiar and they really use it. Even a WYSIWYG editor "in a browser" which does the work for all of us, does frighten them away "i cant work in that small window, and that strange buttons and and and Again I want to remind that we already have a well working Wysiwyg. We just need to fix a few more bugs, make it work with utf-8, and maybe hide a few very advanced TCME features we do not support in reality in TML. with the assumption that it doesn't bring up more bugs ;) the bottom line is, i hope crawford is given more time rather than being pressured even a general needs rest What Crawford needs is HELP. here's a thought, Lavr, with Motorola's large userbase, is there any likelihood of bringin one or two people somewhat dedicated into the twiki project? well, that too of course. that goes without saying. s/userbase/resource I have tried to get more from my user base involved. But the users I have are coding DSP code and embedded code in C. I have no Perl or even Javascript experts among the programmers. since twiki has been a large part of motorola's success for development and whatever, am sure you guys can afford to help out somehow? ah i see I run a TWiki used by only 300-400 developers. I do not run the big global TWiki. We should port TWiki to DSPs. ;) Which is not such a great success by the way because of performance issues. It is so dead slow that people give on on it just by browsing it. If TWiki was written in C I could get much more help. C and C++ And some raw assembler. if they are good, they can pick up a language easily? That is also whay I keep on saying. And the one that IS involved in TWiki - me - is a hardware engineer. Lavr: : where do i get the current WYSIWYG / TinyMCE editor with the current fixes? From SVN. And if that is not to easy for you I'll be glad to do a quick and dirty build I am not sure what state the current twiki.org released version is in. hmm good point in starting to use the d.t.o svn, i could import ToPDFAddOn EugenMayer: You havent so far? Do you already have write access to svn? OliverKrueger: no, just the tar/zip yet oic http://svn.twiki.org/svn/twiki/trunk/ thats where i put my plugin into, or ? Eugen I will gladly guide you through making a pseudo-install from SVN TinyMCE on t.o. is dated 28 may. Eugen we currently have TWO active branches on SVN. Lavr: : which one should i use? depends... trunk is for the upcoming 5.0 branches/TWikiRelease04x02 is the current release branch. This is used only for 4.2.X release of core and default plugins. sorry, on phoone. :) and then there is trunk which will later be branced out to 5.0 and the trunk holds ALL plugins. Lavr: soi for WYSIWYG, i start there i guess, for ToPDFAdd i use trunk ? i think i only have write-access to trunk anway, so there arent to much options there. There are also plugins in TWikiRelease04x02 branch because the whole branch was copyed from the old MAIN branch (now dead). But all the TW....02 plugins are not maintained. If you havent asked yet, you only have read access. But lets not mix to things, let do the WYSIWYG part first, i can import the plugin myself later OliverKrueger : i have asked, times ago You have a ... WouldLikeToCheckin topic? OliverKrueger : i had yes, i did some work on the subscription plugin and stuff ok, great. SvenDowideit : gave me access, so it should be ok The WysiwygPlugin and TinyMCEPlugin are developed in trunk AND all fixed merged to TWikiRelease04x02 branch because those two are among the default plugins that are released with TWiki but i can remember, t.o login is not d.t.o login ? They are synced. I can check if you have svn access Lavr : so using the TinyMCE /WYSIWYG of the 04x02 branch should be the current one, yes? With a 10min delay for updates, afaik. Eugen. Yes OliverKrueger: : ok, then i just test it Eugen You have access as MayerEugen and you have only access to the twikiplugins great, this is all i need thank you for the confirmation http://twiki.org/cgi-bin/view/Codev/DeveloperResponsibilities and http://twiki.org/cgi-bin/view/Codev/SubversionReadme is a good starting point. This means you have write access to everything in trunk except trunk/core I hope, they are uptodate. Lavr: Do you have shell access to t.o.? yes ok, great... Just in case I need an admin and Sven is sleeping. :) I rarely use it. Mainly I look. Too many cooks you know. But I can kill a process or help a blacklisted person out of his misery. sudo ftw :) uh, and and logs -and Yep. too bad it's unix/solaris, am not familiar with it at all speaking of which, what's the update on the new t.o servers? Lavr: can you do a "cd .../data/Codev; ls -1 *txt | wc -l" for me? ;) I think the update is that the hardware they got is not the right to run an app like TWiki. haha why's that? Oliver - OK will take a while. I can never remember where /data is. The directory structure on t.o is a bit strange LSB I guess. ;) (although is solaris) ;) Just wanna know, how many topics are in Codev. :) OliverKrueger, "too many to count" :) 5388 thanks. :) ok so i can import. I use trunk/ToPDFAddOn, this would be correct or ? Yes. Eugen. Yes. And if you want to run TWiki directly from a twiki SVN checkout then it is actually quite easy to do. * OliverKrueger will leave for 20min now. (fetching some cola from ARAL...) :) What would computer geeks do without Cola? I would sleep, sleep looooong loooong Says a guy that never drinks Cola. dunno... probably I would go out into the sun. But drinks buckets of coffee all day coffee would be cold when I arrive back at home. ;) Eugen to checkout the entire trunk and run as pseudo install use this little script. #!/bin/sh cd /var/www/trunk/core rm -f `find . -type l -print` cd .. svn update cd core perl pseudo-install.pl -link default perl pseudo-install.pl -link BuildContrib perl pseudo-install.pl -link TestFixturePlugin perl pseudo-install.pl -link UnitTestContrib cd ../.. chown -R apache:apache trunk with the directory names adjusted. one second Lavr That script is actually an update script I run on a test server once an hour. i just finished the ToPDFAddOn checkin, no i run for the WYSIWYG i will only need the editor no the core, as mine is still 4.1.2 OK. i will just test, wheather i have your sumbmitted bugs and maybe fix some of them if its possible for me There is actually some newer bugs where people claim that latest Wysiwyg does not work in 4.1.2. I have not confirmed this because my test server at home runs TWikiRelease04x02 code and trunk code. if it does not run, i fix it I like that attitude :-))) I mean, nobody will do this for me :) And i think there are people waiting man, how slow is the SVN server ath d.t.o? I will assist by testing anything you need confirmed right away. The d.t.o is normally not too bad but it can be slow at times when people are doing a full branch checkout or the d.t.o bugs web is being updated. oh GREAT it canceled, i had no bug item posted do i have to create a "dummy" bug ? And the d.t.o webserver has a problem often when people save a bug item. Then it can time out again and again until you try from a different IP address. Some network problem at the host. Yes. You always have to make a Bug item when you check in stuff. The bug item must be open, confirmed or being worked on. Not Waiting for Release or Closed. And the checkin message must have the format... Item1234: Some text Then a script automatically adds the SVN checkin number to the bug item. Gives very good tracking. When you are done with the checkin you put the bug item "Closed". Except if it is a core bug or one of the default extensions. THen we put it in "Waiting for release". *next try* Still no luck? I am keeping an eye on the SVN. no new rev. The bug item looks good. done bug closed, ok Wait how do i link the topic with the SVN rep ?ยด oh no. You missed a level. yeah, sorry svn import ToPDFAddOn http://svn.twiki.org/svn/twiki/trunk/ You know how to revert? hate SVN for that.. Lavr: : why revert? i would jsut delete all that 4 directories. Would not differ from delete from *revert I guess the revert is easier. reverting is just setting a new head version or? i have no clue how i do this with the command line THis is the syntax from my own little reminder notes. For another SVN. svn merge -r 47:46 http://www.lavrsen.dk/svn/motion/trunk (revering change done between 46 and 47) So I guess this one would be svn merge -r 16884:16883 http://svn.twiki.org/svn/twiki/trunk :/ i need to checkout the whole trunk first do you have a wc of trunk ? yes You want me to revert? could you update/ rever? That would be great, checking out that thing would take 10 minutes Lavr: would be grat *great Reverted No it is not wait Powered by Subversion version 1.4.6 (r28521). is what the svn browser tells me. why do we have diffrent revisions ? That is odd. We are not at 28521 http://svn.twiki.org/svn/twiki/trunk/ take a look at this I have committed the revert now. in the bottom. thank you ( importing ) Revision 16885: /twiki/trunk at the top. I think the bottom is the SVN rev of Subversion itself. oh <- only using the trac browser, so no exp. with the davsvn one ok so for the WYSIWYG i take http://svn.twiki.org/svn/twiki/trunk/WysiwygPlugin/ and http://svn.twiki.org/svn/twiki/trunk/TinyMCEPlugin/ or ? yes * xoimai (i=4e1b21f2@gateway/web/ajax/mibbit.com/x-1d250e9d5012c76e) has joined #twiki_release I work only with the command line version of svn from a Linux box. Lavr: : thank you for the hand with the import, its done now Lavr: i used Eclipses SVN for a long time, but now starting the command line Eugen there is one thing that scares me a little. That ToPDFAddOn. It contains an awful lot of .php files in the pub directory. Is it the idea that you run these .php files as .php programs running from pub? hmm, i still did not add the .htaccess file did i ? How do you make sure noone can upload or replace one of these .php files with an evil one? the php script are only run by command line and therefore should not be accessable through the browser, which would be the case in some setup using not the viewfile alias Lavr : its not an attachment ? and its not under RCS And .htaccess files may not work at all. On my servers I have disabled all use of .htaccess files. Lavr: : in my initial setup, the whole html2pdf dir was not in the docroot. But for the release, i though it might to get to complicated for the most to configure it, when html2pdf can be placed "everywhere" I would consider placing all the php stuff outside the pub directory which is generally totally blocked for anything that smells like script Lavr: where should i put it? i mean, generaly, i do not care at all, and your point makes sense There are two places I can think of. lib i guess lib/TWiki/Contrib/ToPDF/html2pdf *ToPDFAddOn Either in lib/TWiki/Plugins/ToPDFAddOn..... or in working/work_areas/ToPDFAddOn with an instruction how to enable PHP scripts in this subdirectory. Lavr : not needed, as i stated before no need to have scripts enabled in any directory ( php ) as only php-cli is used OK. That helps. But it is still best not to have even CLI running something that potentially someone could find a way to hack. If someone can create subwebs and topics they can potentially replace the .php attachments with evil code. But the workarea should be a safe place. Sounds all good to me Note that the work areas changed place between 4.1 and 4.2 just to make things more complicated. Before the _work_areas was inside pub. It was moved out because of security thoughts. Another possibility is the tools directory which was both in 4.1 and in 4.2. tools/ToPDFAddOn/.... could be an option also. Some plugins put small scripts here already. Scripts that cannot be run from browser. I filed a bug, if there will be no arguments against workarea i will put them there In the work_area the plugin author rules. This is e.g. also where the BlackListPlugin keeps it list of banned sites etc. It is meant to be where Plugins store data out of reach of the browser. so ok, i installed the current WYSIWYG / TinyMCE on a 4.1.2 installation wooohooo my FF crashed with a win32 expection on pickaxe "ok", adding a umlaut in 8859 crashes FF when "pickaxing * peterthoeny (n=PeterTho@63.146.69.17) has joined #twiki_release Lavr: : ok there are still some non documented bugs you will get with 8859 and links with umlauts Pickaxe is not working anymore Sounds like the current Wysiwyg is not at all compatible with 4.1.2 anymore then. Maybe I should create a similar environment on my test server. On the other hand. I need to focus on 4.2.1 release. At work I run 4.2.0. It is with 4.2.0 I tried to upgrade to the current SVN version of wysiwyg. * xored (n=Miranda@dslb-088-066-139-185.pools.arcor-ip.net) has joined #twiki_release *crashed* Lavr : i dont think its and 4.1.2 <-> 4.2 issue at all http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5695 Hmm. Is this only with Wysiwyg? i think its more WYSIWYG, because the link is not converted correctly to HTML ( not recognised as internal link ) I know the Wysiwyg itself is wrongly codes with respect to A-Za-z instead of upper case. I will talk to CDot if he has a hint, otherwise i start debugging it on my own I am changing my Merlin test server back to iso * peterthoeny has quit (Read error: 110 (Connection timed out)) Hmm. Internal server error now because my topic contains utf-8 chars. 4.2 ? Hmmm. Now I cannot even raw edit Danish anymore. This is the current 4.2 branch. hhm * peterthoeny (n=PeterTho@63.146.69.17) has joined #twiki_release and you just changed the encoding to utf( I changed from utf and back to iso And I had just a few Danish chars in the topic. Now I cannot get back to iso in the doc In FF. In IE it looks OK. Grrr Yes. IE and FF see the same topic differently Diffrently means ? FF shows ? marks instead of Danish chars check the endoding used in FF while you are editing I am just viewing the same topic Works OK in IE. And like shit in FF http://merlin.lavrsen.dk/twiki42/bin/view/Myweb/WebHome Same in older topics also. This worked just a few days ago :-( for me WebHome looks the same in IE / FF ? * EugenMayer has quit (Read error: 110 (Connection timed out)) Ha. Something is goofed up in the meta generation. oh ye i bet you just did a copy paste error in configure Exactly Now it works But I do not understand the 5695 problem now To me 5695 is no longer there unless I misunderstand the issue Unless this is only in 4.1.2 this is the case Bedtime goodnight * xoimai has quit ("http://www.mibbit.com ajax IRC Client")