penguin359, on my wiki we use different webs for different access control scenarios too. So what you're doing sounds normal. Our Main web has some general content trying to describe a general overview of our whole wiki, with some cheatsheet/help topics too. I really wish we had used a dedicated Home web instead, and I've lacked the time to bother cleaning it up. hello, everyone. I am trying to install foswiki under Nginx, everything looks fine. But when I navigate in my browser to http://mydomain/bin/configure, the HTML output by the configure script is not rendered, rather, it is downloaded as a file? what's wrong with my configuration? hello, anyone there? Have you looked at http://foswiki.org/Support/FoswikiOnNginx Unfortunately we don't have many people here using nginx. [foswiki] foswiki pushed 2 new commits to master: http://git.io/qqfjNA [foswiki/master] Item11591: Sanitize requested rev. - GeorgeClark [foswiki/master] Item11554: Document logger changes - GeorgeClark http://foswiki.org/Tasks/Item11591 [ Item11591: Don't try to view invalid rev ] http://foswiki.org/Tasks/Item11554 [ Item11554: Logs are not rolling on first of months. ] neevek: Off the top of my head, that sounds like your HTTP server isn't configured to run Perl scripts. neevek: (i.e. to run Perl CGI scripts). I have successfully configured nginx for running foswiki, because when I tried to open http://mydomain/bin/view, it was able to output HTML rendered by the browser(which says Foswiki Configuration Error, because foswiki is not yet configured) flexibeast: nginx is a bit of a different environment. It only runs fcgi natively. configure will not run under fcgi. That reference topic has a attachment DaveHayes wrote to get contifure working. not it looks it cannot get the output of bin/configure rendered. neevek: Overall, when an HTTP server doesn't know that it needs to run something, it just serves it up as an ordinary file. gac410: Ah okay, interesting. when I say curl http://mydomain/bin/configure > test.html, and open test.html in a browser, it is rendered as a usual HTML. neevek: i had the same issue as you when i first set up Foswiki - but i'm running it on Apache. neevek: have you followed the instructions on http://foswiki.org/Support/FoswikiOnNginx - configure will not run natively under ngnix because it is a CGI application. neevek: Oh okay. neevek I don't have ngnix set up, and have never tried it, so I can't be much help. ): it looks the configure script is executed successfully, cause it is not the source code of the perl script that is output, it is the HTML generated by the configure script that is output. it is just not rendered by the browser, and through "curl -I http://mydomain/bin/configure", I can see the Content-Type header is "text/html; charset=ios-8859-1", what could be the problem? hm That is strange. Does it have and tags generated? So other HTML pages - i.e. non-Foswiki ones - served up by nginx render fine? neevek: You might be able to get a start by following instructions at http://foswiki.org/System/InstallationGuide#Configuring_Foswiki_manually_40without_using_the_61configure_61_page_41 Not recommended - there are a lot of things configure does & checks for you. But it would probably get you started. the output is a normal HTML, CSS, javascript, everything looks correct. other HTML files are served fine by nginx, I can see them from the browser. ok, I'll take a look at it. neevek: Is their charset 8859-1 also? Another conversation about nginx is at http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2010-11-03,Wed&sel=378#l374 yes, as the HEADER says so. Do you have a different browser you could try - just fishing now, I have no idea why it won't render if the headers look correct. What browser are you using? damit..now I can see the configure page on Firefox. I was trying on Chrome hm strange. chrome works for me. ( chromium 16.0.912.77 ) i am using the latest version, 17.0.963.54 I have not bothered to compile it yet - Gentoo has 17.0.963.56 available oh, there's still a problem. now i can see the main page through "http://mydomain/bin/view", but all the links on this page do not exist, like "http://mydomain/bin/view/System/WelcomeGuest" You mean you get 404 not found? or the links are actually missing from the page i think it is 404, my fastcgi-wrapper.pl complained it cannot find the file pointed to by view/System/WelcomeGuest Hm. Sounds like it's not running the view script. view should be handled by foswiki.fcgi, System/WelcomGuest is passed in the url, not a file. the System/WelcomeGuest is the file data/System/WelcomeGuest.txt under the covers. but rendered through view. it means I have to do some URL mappings? like those in a Django app? tbh I have no idea. On apache, view gets mapped to foswiki.fcgi and /System/WelcomeGuest passed to it. [foswiki] foswiki pushed 2 new commits to Release01x01: http://git.io/ops3Yg [foswiki/Release01x01] Item11591: Sanitize requested rev. - GeorgeClark [foswiki/Release01x01] Item11554: Document logger changes - GeorgeClark http://foswiki.org/Tasks/Item11591 [ Item11591: Don't try to view invalid rev ] http://foswiki.org/Tasks/Item11554 [ Item11554: Logs are not rolling on first of months. ] Hey, I am back. now I still have problems. except for bin/configure and the main page(bin/view), I cannot access any other pages. neevek, on apache it's something like: RewriteRule ^/+(.*)$ /var/www/foswiki/bin/foswiki.fcgi/view/$1 [L,NS,H=fastcgi-script] That tells the server to pass view/ to foswiki.fcgi and handle it as a fastcgi-script but i don't have this file: "foswiki/bin/foswiki.fcgi" Ah... in bin/configure. Use the Install Extensions to install the FastCGIEngineContrib or from shell in root of foswiki, perl tools/extensions_installer FastCGIEngineContrib thank you, i have successfully installed foswiki.fcgi. but where do i put that URL rewrite rule? I have no idea. That's apache specific. Probably sometihing in nginx config. unfortunately with nginx you are mostly on your own. We don't do any testing with it at all that I've heard of. DaveHayes was successful, but I have not seen him around in a while. ok, I think I am near being successful on this, it should be just a rewrite rule issue. ^_^ Could you help me understand why bin/view worked even though I didn't install FastCGIEngineContrib? while other pages didn't work. I have no idea - did you try it on apache previously and the browser had it cached? no, I only tried it on nginx. cool, I get it work on nginx now. great. BTW compile of latest chromium just finished. Configure is working fine. Not sure why it displays html for you. I didn't follow the instructions on the foswiki site. i didn't need the foswiki.fcgi, and it just worked. hm. strange. Maybe ngnix has added cgi support then. i am using the fastcgi-wrapper.pl script downloaded from here: http://www.ruby-forum.com/attachment/1583/fastcgi-wrapper.pl the most important config in nginx.conf is this line: fastcgi_split_path_info ^(/bin/\w+)(.*); that's probably running foswiki as standard cgi then. foswiki.fcgi and the FastCGIEngineContrib are needed to get the full acceleration .. I assume. which comes from the link you posted this morning. but I still don't understand what that line does. without that line, i can only open the main page, are pages are not available. other pages .. no idea - and it's almost 1 am here - so I'm leaving shortly. g'night all good night. but it is afternoon here. Good morning folks! Just read about http://twiki.org/cgi-bin/view/Blog/BlogEntry201203x1 Iam really shocked that that guy cant stop lieing even after leaving twiki.inc … "rock solid releases". He should rather stated "rock solid releases ripped from foswiki in 95% of the cases" hi Eugen There release notes have been looking like "what foswiki did + new icons + some theme changes" ever since Hey pharvey! - I just actually wanted to state, that statement / blog is actually rather a compliment to you guys, you did a very good job - thanks :) how's drupalwiki going? "This brought more focus to the project (some contributors who disagreed departed), and brought professionalism to the community." that one ( Adnre found that quote ) fits the picture perfectly [foswiki] foswiki pushed 2 new commits to master: http://git.io/bb9m8w [foswiki/master] Item8402: removed dependency on GluePlugin - MichaelDaum [foswiki/master] Item9978: removed dependency on GluePlugin and ZonePlugin - MichaelDaum http://foswiki.org/Tasks/Item8402 [ Item8402: port BlogPlugin ] http://foswiki.org/Tasks/Item9978 [ Item9978: initial checkin of WikiWorkbench ] [foswiki] foswiki pushed 2 new commits to master: http://git.io/Pj0aJQ [foswiki/master] Item8402: updating list of dependencies - MichaelDaum [foswiki/master] Item9978: updating list of dependencies - MichaelDaum MichaelDaum: nice one :-) which one both# all eugenmayer: I don't think that's fair. I have kept an eye on t.o's checkins (not that there's been much to see) and I think they've been pretty separated from work done on Foswiki. Mind you, just catching up with Foswiki would be a major challenge for them now. They have even had some ideas that we missed, and we have taken on board (though the Foswiki implementation is generally a lot better IMHO) CDot: well, i cant argue against you, you have a lot more insight, no doubt. I was just reading the changelog more then the checkins sure. From the outside it looks the way you say. and they looked, for me, very similar I haven't actually seen much more than "new icons + some theme changes", though. CDot: but you really think, that its true, that this state "This brought more focus to the project (some contributors who disagreed departed), and brought professionalism to the community." really stands? I don't see much evidence of it. but then, I don't pay it that much attention. CDot: why should you :) right :-) now what will happen to twiki.inc? what will be pths rel to them? dunno. Maybe they will start packaging Foswiki. they are more probably packaging confluence with a twiki skin Maybe thats the "split" behind the scenes. TWiki.inc told Pth, that from a b-perspective it makes sense to jump on the Foswiki train. dont think so. it more looks like twiki.inc going downhill. He couldnt stand the descision to much and could not give up "his" child, so they might split on the long run MichaelDaum: +1 they simply ran out of money yup we are guessing. Could be anything. Jap my well best guess is: no fresh money for twiki.inc, and a "sorry peter lets refocus" MichaelDaum: tbh, i think their marketing worked out pretty well and i expect them to make some serious money in the US how long could you not live up to your marketing promises. The did not glance with the best system, but they had their own market and they could reach the market i suggest. I think they are facing serious troubles against confluence and sharepoint now and maybe their forecast dont look as good as they might want CDot: well, in germany and US, it is :) both are vital competition, even more jive does anyone know what they were charging? CDot: but those customers dont want a "wiki", they want to "collaborative office solution" … or lets say "we had some network share all over the place, we want to have that better organize, work more with vision and interlinking features" there are a lot of other systems though worth learning from, and competing against. foswiki too has long past the "just a wiki" phase CDot: for that kind of serious integration, sharepoint is pretty good, actually without any competitors. Sharepoint has a wiki also, its not the same as Foswiki is, but people always rather join "oh i can use office documents as i was used to" wagon, then "what syntax? whiteboard? new content?" CDot: so i see sharepoint having this big plus, this "office docs works" thingy .. + the political aspect of "its MS and fits our architecture" it really depends on the budget of the company. i had the impression that t.n were targeting the lower end, below sharepoint (and jive)'s horizon head to head, they wouldn't stand a chance, IMHO the majority deployments of sharepoint arent going beyond "files and directories on the web" out of the box sharepoint doesnt add more to remote file shares Well, sharepoint gives you a LOT of PM features, a lot of consultancys use that Michael, Sharepoint evolved. you really have to tweak a lot the big plus is the ms office plugin to access documents right from within the office suite. not from the browser. They did a lot of work on it. Iam not a sharepoint lover, but they got a serious standing and they have some serious feature worth trying it for a customer. You wont easily win a pitch against it as it maybe was possible in the past true And its much "easier" to setup i used easier, because i admit that you are right, you will need tuning directly but deployment works very easy OOTB. you get first results after minutes. thats what people do most of the time: use it OOTB and thats what consultants complain about That is, for the IT, for the PM, for the deciders sometime "that argument". It works first, it can do docs, i can use office - lets but it sharepint is better than what it does OOTB, cus OOTB it sux at information management The company behind it is know, large and maybe already part of the infrastructure. right. for the rest of the world M$ is a save bet. and betting save is important for IT MichaelDaum: sometimes its not only about the features-argument :) the only lesson to be learned from sharepoint is: office integration rulez ... in a certain requirement looking at other products in this market, competitors have a lot more exciting products thats where to learn even more from, besides office integration. IMO wrong - there a lot more to learn. But i wont argue, no need for fighting okay at least it is _me_ being a lot more excited by others You wont, at all, being able to argue with a customer, what an alternative to Offer for Visio Visio is completly integrated into sharepoint, including workflow. That is serious buissiness, e.g. SOPs and stuff. or Project MS has good sotware, we have to deal with it. And this software adds value to sharepoint - and thats the point of sharepoint yea maybe sharepoint is more a connection point - but one for good software - and they scale and envolve very fast, as each department works on its own part. Hard to scale that way for others does anyone know what they were charging? - I think we paid ~ $30k for 2 years danger is you get paralyzed by and driven in front of microsoft. there simply is more to innovate on than what microsoft does or says. I guess the "wiki" word rings no bell for business users, so they were squeeze by the competition with confluence and sharepoint ColasHome, no more, true. or worse, 'wiki" means "wikipedia" here I heard last week: "why are you calling this a wiki? a wiki is like wikipedia,. just to write docs, not to colaborate" Confluence is not a Wiki ? :) ColasHome: ^^ tee hee eugenmayer: confluence is not marketed heavily with a wiki bias, and also it is part of a great suite of ttols (JIRA for instance) ColasHome: you are really serious about this statement? which one? (i fully ack the Jira argument for the developers / documenters of software-developers) well jira is not perfect But to be honest, if you have to compete on the Wiki market for compenies, you got to stand against Confluence - and nothing else. IMPOV Confluence is, by margin, ahead of every Wiki iam being aware of. Thats a sad story, also for us, but well, i think thats simply the reality. Confluence is not so great their strength is that they guide a lot the usage: users are told what to do Heh, you telling that as being a "small side point" which is a good feature for most buisness users that do not want to understand and feel confortable with an open system For a compony, sorry, thats that one key for establishing a system for that kind of collaboration but I see plenty of bugs with their wysiwyg yes, but still, their WYSIWYG is doing extremly well (compared to ours :) ) I am not sure from what I see here but you are right, from a buisness user point of view confluence is a very attractive ofering, price is also very nice. but the best "wysiwyg wiki" is still Google sites. yes, for that particular feature - they are awesome but overall, C is doing a very decent job. I have that fact ,-) s/have/hate What a typo! In my opinion foswiki do not really compete with C what could be competing is somebody (consultants?) offering a "packaged" foswiki, with a set of "approved" plugins, skins, and connectors to other tools ;) currently foswiki is really a good multipurpose engine I didnt look into the code for a while, but I did recently for fixing links in WYSIWYG, and I am really impressed by the work done "under the hood" PeterThoeny: first i'd like to state that i did a few mistakes as a community leader, one was to introduce the ubuntu style governance model too quickly, which resulted in the departure of many contributors who disagreed, it was my fault not to involve some key people while preparing the move to the new model starshine: do you agree, with some of the reasons they stated for leaving? - PeterThoeny: yes with some of the moderate voices ColasHome, where do you have that from? http://twiki.org/p/pub/Codev/JerusalemReleaseMeeting2012x03x02/JerusalemMeetingLog2012x03x02.txt I never look at T anymore, but eugen mention of Pth blog post made me have a look PeterThoeny: starshine: i like to idea of interviewing some people who left it seems he still does not get the point: at that time he wasnt the community leader anymore. he was officially deposed by a community vote. there already was a newly ellected twiki board. Also, he kept successfully his "community" really unaware of the reasons of the fork they do not seem to realize that we were forbidden to comment on the T site... so now they wonder why we left without an explanation... lol :( they = 3 people GeorgeTrubisky: the wikiring folks? - PeterThoeny: i do not think it is fruitful to interview people who worked very consistently against the twiki project for many years ahhh, he hasn't actually changed views :-) he is just fooling himself again... I can't stand reading these logs good grief; I didn't realise he was still beating that drum. He really did get the wrong end of the stick! it brings back all the bad memories However it appears that Foswiki devs are invited to submit their CVs for interview encrypted and shredded for security reasons buried for 50 million years and recycled as coal ho hum. Water under the bridge. Back to the coal face; I found a good seam of Cobol developer CVs....... some people need a friendly clap ... with a chair ... in the face. MichaelDaum: ah you are following the French pseidential campaign too? :-) Hehe ColasHome: i though he was about Putin! Wikiring is working against TWiki in the past ( before Foswiki ). Interesting statement, of course. In that kind of situatian i always accuse specific people for drug-abusing wiki systems store all data in flat files? neevek: which wiki systems? There are many. Foswiki does, right? I just started to use a wiki system, and, Foswiki is really great! Thank you all nice people creating such an excellent software. foswiki stores data in flat files by default, yes. cool. oh boy would anyone like to take on re-writing all our error messages? http://uxmag.com/articles/are-you-saying-no-when-you-could-be-saying-yes-in-your-web-forms boo "PC LOAD LETTER", classic SvenDowideit: that's fundamentally wrong. If we allow users to feel empowered, they will rise up and crush us! PC LOAD LETTER is *far* too informative, it should have been "WRONG SIZE" it's not just the messages, it's how you present them e.g. offering help and alternatives. We do have a few that work that way, but most are dev-authored "WTF" style messages. error recovery is *hard* to do well. indeed SvenDowideit: just reading twiki IRC log, seems they like the idea of doing mongo DB :P SvenDowideit: Well maybe not /all/ of them, but perhaps i could look at a few .... ? flexibeast, ever error message is scared :) pharvey, which is good really - I've not touched it for a long time :/ SvenDowideit: Sorry, i don't follow? i'm actually most curious/concerned by something else I guess the "wiki" word rings no bell for business users, so they were squeeze by the competition with confluence and sharepoint between store2, TypedData, ... there's a few things in core which need addressing to make DBI/Mongo sing properly. flexibeast, sorry - thats a yes, every error message that gets improved and de-developered is a really really positive thing pharvey, y.. that was what i was going to bug you about :p typed data! SvenDowideit: Okay. :-) Any suggestions for a particularly good place to start? awesome! Except this weekend is WYSIWYG emergencies :P yes - ish with the first or most common error message you get or possibly - the most common __non__ error message i get cheesed off by my incorrect syntax rendering with no warning :) pharvey, whereas i have about 4 days of docco to write atm, plus some more debugging luckily, I'm too busy to do any of that in the next 2 days ooh, that reminds me: people middle-clicking the same edit link more than once, resulting in editing an old copy of a topic oh boy thats nifty i want the 'page being edited by someone else screen to use ajax to tell me when they've stopped and I __really__ want Forms.pm re-written oh dear, typed data again :p shall I add some icons to the 1.2 release? SvenDowideit: Okay, will keep an eye out for such (non-)messages. :-) flexibeast, grin I guess this means I should push my Foswiki::Datum code somewhere http://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Datum pharvey: what would you think of committing yourself my Wysiwyg patches? they seem to run OK, but I will have no time to get up to speed on the svn commit process this week-end even though it's less interesting than Foswiki::DOM http://trunk.foswiki.org/System/PerlDoc?module=Foswiki::DOM ColasHome: my initial thoughts were "I'm going to be doing a lot of work in the unit tests", but my first quick glance didn't catch anything horribly wrong oh dear, i wonder what re-donig documentGraphics using css sprites would be like especially using ADDTOZONE to add only the ones that are used, and to mmmm, oh well, too much work that will probly hurt the cache SvenDowideit, is it worth it? most of our HTTP requests seem to be <1KiB CSS files :P no, we should then aggregate, but that then won't cache nm y http://projects.opengeo.org/geosilk it should be possible to use binning to group certain static files together, based on access stats ok, next big feature for 1.2.0 metacpan uses something like an aditional.... er.... set of icons which pretty much looks like md5(names-of-all-js-in-there) yup mmm, time for bed :/ nite all maybe it is too easy using a completePageHandler ColasHome: realistically, I think this weekend I should concentrate on getting Release01x01 & trunk merged as far as possible, and knocking down the ReleaseBlockers - I think my spare time will be taken just doing that problem is there are nondeterministic permutations while ordering underconstraint js in the page head. these result in functionally the same blob but generate different md5s so rendering the zone needs to fallback to something alphabetically sorting equivalence classes perhaps there's a way to normalize the ordering snap perhaps even just normalize the ordering used to generate the md5 just reloading the same page again and again: files keep shifting around in the header indeed when collecting all css (js) top down to write them into an md5-named cache file, requires them to be ordered deterministically. the rest is a matter of post processing the html page imho this stage could also clean up the code a bit: remove everything after a closing , remove all one-line html comments , maybe take care of properly nested

s ^code^html markup collapse all (

)+ into a single

all cheap, but downsizes the document length besides making the html code look not too silly I still think you don't want one big fat .js or .css file, though cus of browser caching? to avoid regenerating a different big-fat-everything file when you encounter a different page with a new requirement ya incrememntally creating Eg. 10KiB files might work how would you optimize that? like: find out which js go together on almost all pages I don't know. 1... 2 ??? 3: profit :) yeah, it might need some advanced log analysis stuff. But, it should be possible to learn what files are in close proximity of each other jquery.foo.init.js + jquery.foo.js + jquery.foo.css etc. Perhaps even just taking the pub path into account MichaelDaum, good point 32 out of 62 static files on our homepage are < 1KiB using the Makefiles would be trivial...though (our = mine, not foswiki.org) CDot, what do you think about being able to concatentate js files during build, a build target that specifies a set of js files to go together. Example: minitfy jquery.foo.init.uncompressed.js+jquery.foo.uncompresesd.js > jquery.foo.js that's pretty much what I had in mind. The issue that arises is that different pages load different sets of JS (dep. on addtozone calls). Also stylesheets. the asset tracker has to keep track of all these well there are some files that *always* go together and this is known during packaging time "this is known" - who knows it? the author of the package ach, too simplistic have a look at JQueryPlugin often have a dozen plugins, each with some JS I know how JQueryplugin works - but unfortunately several plugins don't. JQREQUIRE{somethirdpartystuff} ... loads somethirdparty.js and a somethirdparty.init.js ... always I thought about adding an approriate Makefile target to do just that and halfen the number of js files coming from JQueryPlugin. alas, this would throw off BuildContrib asset tracker...sounds big first we need to collect some real data: how much differ js and css per page? my guess 90% of the pages have identical assets if that is the case, then we can afford the simple approach which is: post process html, gather all js, concatenate the files, have an md5 of their names, cache it on the server. well, we use asset packaging in rails, where upwards of 200 small files are loaded for each page. Compressing and concatenating makes a big difference. We're using both scss and less in the packaging process (don't ask) which complicates things a bit. the basic approach there is to have a single manifest of assets greouped into difference "classes" - for example, an edit page has a different class to a view page that gives the asset packager a huge head-start ah ok. but thats because all assets are broken up a lot more. it's made easier by being able to pre-classify assets because it's not a dynamic application. In foswiki, it's much harder, because it depends what plugins etc are loaded which assets get brought in though there *is* an argument for - say - an "editors" zone and a "viewers" zone to contextify certain assets actually we can already do that, using Foswiki::inContext [foswiki] foswiki pushed 1 new commit to master: http://git.io/AHtR2Q [foswiki/master] Item11591: More validations - GeorgeClark http://foswiki.org/Tasks/Item11591 [ Item11591: Don't try to view invalid rev ]