#foswiki 2015-04-22,Wed

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

WhoWhatWhen
***gac410 changes topic to: Channel logs: http://tinyurl.com/7atzrpz ... Next Release Meeting: Monday, 4 May, 1300Z in the #foswiki-release channel. [00:10]
........ (idle for 36mn)
Lynnwoodgac410 - I did a draft rewrite of InstallationGuidePart2 this afternoon: http://foswiki.org/Sandbox/InstallationGuidePart201x02Rewrite
I cut some intro verbage that I thought added next to nothing for the folks that would read this.
I also removed some details that i also thought were not valuable for this document and would be natually found later as uses got into foswiki.
But really that was not much. I reorganized to give some semblance of logical priority after installing (from users perspective)
Some other details:
I got rid of many of the explicit System web links on assumption that this page _will_ be viewed from within the system itself.
Don't think i've completed reviewing those. In a very few places it makes sense.
Got rid of the 1 TWiki reference (and associated trademark comment) as un-necessary at this point.
I Moved configuring by command line to main install page.
It really didn't fit here (I had it under Misc at first) but then my thinking was that it really should be part of the main installation notes (under the supplemental matericals)
One last thought that I didn't fully research was the section about plugins. I'm wondering if these need to be their own topic? Is this same material covered all togethere elsewhere? I haven't looked yet.
I'll revisit tomorrow. Heading to bed now.
[00:46]
timlegg3Lynnwood: the PageCaching link goes nowhere - looks good up to there, I wil fininsh reading ti [00:57]
gac410timlegg3: A lot of the links are broken because the topic has been copied to sandbox ... the link would hopefully be okay in a live system. Try http://trunk.foswiki.org/System/PageCaching
Sorry Lynnwood ... my speaker was muted and I didn't see your responses. I like what you've done. Spotted a couple of things to tweak which I'll edit in.
There are now 3 editors for one. Wysiwyg, Natural, and PlainText (which is rather unreachable by default).
[01:11]
........................................ (idle for 3h17mn)
***gac410 has left [04:30]
....................... (idle for 1h54mn)
ChanServ sets mode: +o CDot [06:24]
.......... (idle for 45mn)
ChanServ sets mode: +o MichaelDaum [07:09]
........................................................ (idle for 4h39mn)
BenjaminMartinhi all
I have one question / problem: we turned on caching on foswiki 1.1.9 -> now if we edit and save a topic, the changes are not visible as long as the cache is not refreshed on the server -> is there a way to tell foswiki to refresh the cache for a topic on save/quiet save?
[11:48]
jastthe cache in 1.1.9 has some issues. it's been completely rewritten for the upcoming 1.2 series. in the meantime, some problems may be unsolvable... [11:52]
BenjaminMartinok [11:53]
jast1.2 is in beta stadium right now [11:53]
BenjaminMartini know and plan to set up a test server with 1.2 [11:54]
jastgreat
we've found a bunch of bugs already. there'll be at least one more beta, I think. :)
[11:56]
....... (idle for 33mn)
***ChanServ sets mode: +o Lynnwood [12:30]
...... (idle for 25mn)
ChanServ sets mode: +o gac410 [12:55]
gac410Hi MichaelDaum ... I don't understand the solution on http://foswiki.org/Tasks/Item13378 that you and jomo found yesterday. It seem that if it was really a regex problem that the úů would link in both the topic text as well as the formfields. [12:59]
MichaelDaumgac410, hi. yea me neither. feels like magic.
even worse. enabling this switch doesn't let me repro the encoding problem.
[12:59]
gac410The same regex finds wikiwords in both locations. So something is internally changing the formfields. That disable of LocaleRegexes seems pretty draconian. [13:00]
MichaelDaumhave you been able to repro the fix on your install? [13:00]
gac410yes.
I spent hours last night printing every place I could find that the textbox string was touched during render. I can't find where it's getting modified.
By the looks of it something is "decoding" or "encoding" that string first, and changes it to a 2-byte ú U+FFFD and its that combination that links
[13:00]
CDotgac410: before, or after, it hits CGI? [13:15]
gac410This is during normal rendering for display, it doesn't use CGI I don't think.
Ohhhhh this is reaaalllly strange.
[13:16]
CDotlocales on or off? [13:17]
gac410The problem just went away for me.
Until I logged in.
UseLocale is NOT enabled, SiteCharset is utf8
As jomo reports in the task, its a completely default install, which is charset utf8, and locales disabled.
So Michael, to recreate the issue, I need to be logged in as admin. (Have not tried any other ids' yet)
[13:17]
MichaelDaumwot [13:21]
gac410Yeah Must be logged in. So far any ID, not just admin
So. Create a topic, attach a file, comment containing 2 characters: úů Then view the topic with attachment table expanded. The Comment appears as ú��
Where the ú� is a link to a missing topic.
log out and it displays as úů no linking.
[13:21]
CDotCDot confirms the behaviour gac410 reports, with a non-admin user [13:26]
gac410The same behavior happens in data forms as well, [13:26]
CDotextraordinary. A UTF8 poltergeist..... [13:27]
gac410yes indeed. And the strangest yet, I put debug print statement in Render.pm. Attachment comments I caught the render of wikiword, but not the formfield. I can't find where that gets rendered.
So the issues seem slightly different.
[13:29]
TarboxSorry to interrupt, I'm having trouble getting SolrPlugin to index the System web in full. Is there a gotcha I should know about? It's the only web it happens to. [13:30]
gac410What is it missing?
A lot of the System web files are not actually attachments.
Ie jquery, Tinymce, etc. they are all in subdirectories beneath attachments and Store / Foswiki doesn't really know about them.
[13:30]
TarboxHrm. It seems it's everything after the first Committing Index, which is every topic after ChangePassword alphabetically.
when I try to index from the commandline.
[13:31]
jastdoes it output anything unusual after that? is there a "committing index" at the end? [13:32]
TarboxYes, there's c ommitting index
and then it just gives up. No error message.
Summary is Indexing topic System.ChangeEmailAddress
Summary is Indexing topic System.ChangePassword
Summary is Committing index
Ah "Summary is" is my debug from a different thing.
[13:32]
jaststrange [13:32]
Tarboxhah okay. Errors had to be turned on. [13:37]
CDotgac410: ok, I think I can guess what is happening [13:49]
gac410great. I've been totally at a loss [13:49]
CDotit's happening in the renderTML, as you had probably observed [13:50]
gac410yeah. But why only in formfields / attachments. Same string inline text doesn't get corrupted [13:50]
CDothmmm, no, just had to abandon that theory :-( [13:51]
gac410which leads me to think that it's not the regex, its that the string in META has been transformed somehow. [13:51]
CDotI thought perhaps the unicode code point corresponded to one of the text markers used during rendering
but I was smarter than that
the text fed into the renderTML call at UI.pm:525 is fine
[13:51]
gac410Ah... yeah that would do it. Hm. generally the use of hex markers then is a bad thing. I've been doing similar as places, maybe not as smartly. :( [13:52]
CDotthe form rendering is doing its job OK [13:52]
jastthe hex markers don't conflict with utf-8 [13:53]
CDotjast: that's why I had to abandon that theory ;-) [13:53]
jastof course hex markers still are a bad thing, but that's neither here nor there
and who wants to rewrite all of that code...
[13:53]
CDotif you can think of a better approach, you're welcome to try it..... :-) [13:53]
jastyeah, let me just commit a few experiments to the master branch [13:54]
CDotanyways, it uses HTML comment strings, not just unprintables [13:54]
gac410gac410 sharpens his revert pen for jast [13:54]
jastI get the impression it's more of a revert axe
to be used on heads
[13:54]
gac410I've reverted very little. Lavr carries an axe, Me a scalpel [13:55]
CDotgac410: scalpel? more like bamboo slivers and a length of lead pipe [13:55]
gac410Aw... really :( [13:56]
CDotAha! between lines 526 and 537 of Render.pm [13:58]
BenjaminMartinone more question: which part of foswiki, or where are those buttons created which you get at the bottom of the page when editing a topic (?) (e.g. "Save", "Quiet Save", ... , "Cancel" buttons) [13:58]
CDotline 530, to be precise [13:58]
gac410takeOutBlocks is corrupting the string? [13:59]
CDotnope
_handleWikiWord
[13:59]
gac410Ah... But the same string when entered into plain topic text, does NOT link. So why is the formfield different [14:00]
CDotshhhhhh [14:01]
gac410:) [14:01]
jastis this with locale regexes enabled? [14:01]
gac410Yes.
That setting should never be disabled.
It's an emergency "my system has broken locales" flag which changes the regex to use [A-Za-z] style matching
[14:01]
jastis the rest of locale enabled, too? [14:02]
gac410No. Default config. CharSet utf-8, UseLocale disabled.
If it was a bad regex, then I'd expect the string to link in regular topic text as well and not just formfields
[14:03]
MichaelDaumthe LocaleRegexes only uses different regexpressions for upper and lower case.... as in WikiWords .... properly distinguishing upper and lower case isn't possible in all locales anyway .... so pft [14:04]
gac410By the time you hit RenderTML, it's one big blob of topic text [14:04]
MichaelDaumfor those locales that dont really distinguish upper and lower case you better disable autolinking of WikiWords all together [14:04]
CDotyup, \xc3\xba\xc3 is being matched by $STARTWW
(?:($Foswiki::regex{webNameRegex})\.)?
($Foswiki::regex{wikiWordRegex}|
$Foswiki::regex{abbrevRegex})
($Foswiki::regex{anchorRegex})?
which you probably already knew
that only happens when NOAUTOLINk is not set
[14:05]
gac410Right. We are running with NOAUTOLINK disabled. both in topic text and in formfields. [14:05]
MichaelDaumand if autolinking is disabled ... LocaleRegexes doesnt play a role anymore [14:05]
CDotCDot is checking which part of the regex is matching [14:06]
gac410CDot: Try putting that úů string in the plain old wikitext too. It should link there as well. [14:06]
CDotthe test string I am using is \xc3\xba\xc3
Šúá
I have it in text and in the form
[14:06]
gac410And it links in both places? [14:07]
CDotit should *not* match a wikiword, AFAICT, but I'm checking that
CDot will worry about the "both places" issues later
[14:07]
gac410okay [14:07]
CDotwhen he understands why it is failing *here* [14:07]
gac410MichaelDaum: on Register, Utf8User would be a valid wikiword, but the Registration wikiword javascript rejects it. :(
gac410 still believes that it is not the regex. :P Login/Logout does not change the regex, and location of the string does not change the regex
[14:10]
CDotit *is* the regex
"Šúá" =~ /^$Foswiki::regex{wikiWordRegex}$/ is true
[14:15]
gac410One more tidbit. Edit a user Set Šúá as the Address in the UserForm. and insert %QUERY{"Address"}% It does NOT link. But the formfield does. [14:17]
CDotok, so, the regex matches, but the string returned by the $2 contains different characters to those in the input string [14:30]
gac410strange [14:30]
CDotvery [14:31]
***BenjaminMartin has left [14:31]
gac410Does it have to do with the internal perl type of the input string?
isUTF8, ...
[14:31]
CDotCDot will check
both have the utf8 flag set
the input string is "195 186 195"
this matches wikiWordRegex
sorry, the input string is "197 160 195 186 195 161" and the match string is "195 186 195"
which is (notable) a subsctring of the input string
[14:32]
gac410hm. I tried checking the utf8 flag down in Form.renderForDisplay and it was not set. It was also not set for the Meta::text()
But I might have been checking incorreclty.
[14:35]
CDotneed to break down the wikiWordRegex - it's /[[:upper:]]+[[:lower:][:digit:]]+[[:upper:]]+[[:alpha:][:digit:]]*/
no idea which bit is matching what :-/
[14:36]
gac410That sounds suspicious that are $STARTWW lookbehind is actually wrong. [14:36]
CDotmay come back to that [14:36]
gac410picking up the 160 as a valid delimiter. [14:37]
CDot160 is a unicode  
but anyway, the string *is* validly delimted
in a form value, it is couched in spaces
so I doubt it's STARTWW at fault
[14:37]
gac410And in the case of the matching úů it appears to match a single character as a wikiword [14:38]
CDoty [14:38]
ok, so, the problem is that [[:alpha:][:digit:]] is matching the 195 character that introduces the utf8 tuple "195 161" [14:48]
gac410hm so it's matching it as bytes rather than characters? [14:49]
CDotsorry, it's matching [[:upper:]] [14:50]
timlegg3MichaelDaum: I'm still trying to make Solr WebSearch and Changes Web Specific - If I edit SolrSearchBaseTemplate.txt and replace all with %BASEWEB% Search works but not Changes [14:50]
CDotit's not matching as bytes, because 195 is not uppercase in bytes, either [14:50]
MichaelDaumsolrized WebChanges are always per web
except SiteChanges
[14:50]
timlegg3Also, I would rather not change the System delivered scripts but I can't seem to figure out how to do it otherwise [14:50]
CDotI would say this is a perl bug [14:50]
MichaelDaumtimlegg3, create a skin overlay. do you know how to do that? [14:51]
gac410CDot I'm testing on perl 5.20.1 [14:52]
CDotCDot is writing a tiny test script [14:52]
gac410So regarding the topic text vs. formfield, my guess is that the text does not have utf8 flag set? But since it's presented to the browser as utf8, it still renders correctly? [14:53]
CDotright [14:54]
MichaelDaumtimlegg3, would you like to get a short intro on how to create a skin overlay for SolrSearchViewTemplate? [14:54]
gac410And the logged in vs. not logged in ... no clue :) [14:54]
timlegg3MichaelDaum: I have AutoTemplatePlugin: 'WebChanges' => 'WebChangesView', and mine shows all webs in the changes [14:55]
MichaelDaumit should look like this: https://demo.michaeldaumconsulting.com/bin/view/Knowledge/WebChanges [14:55]
gac410CDot: Same failure on Perl 5.18.2 [14:56]
CDotCDot can't get it to fail in a test script
CDot is using utf8::upgrade to set the utf8 flag
[14:56]
timlegg3I would have to say at the point I don't know how to create a skin overlay [14:57]
MichaelDaumokay here you go [14:57]
timlegg3My changes looks exacly like that except that the changes listed are from all webs [14:58]
MichaelDaum(1) edit Main.SitePreferences and look for Set SKIN = ... ; add one if there is none
* Set SKIN = myorg, pattern
or myorg, nat
or myorg, natedit, pattern
[14:58]
timlegg3The loading comes up and appears to be Solr presenting the changes [14:58]
MichaelDaumdepending on what it is currently set. important point is to add the myorg prefix to the SKIN setting
(2) create the topic System.MyorgSkinSolrSearchViewTemplate
[14:58]
timlegg3Case Sensitive? I thought it would be but some of the filenames leads me to think not [14:59]
MichaelDaumcontent: %TMPL:INCLUDE{"SolrSearchView"}% %TMPL:DEF{"solr::defaultweb"}%%BASEWEB%%TMPL:END%
from there on the new MyorgSkinSolrSearchViewTemplate should be in charge
thats it basically
[14:59]
timlegg3Via the web interface or server? [15:00]
MichaelDaumweb [15:00]
CDotwhat a mess :-( [15:01]
gac410: small script that demonstrates the problem: http://pastebin.com/dDf4QsGL [15:09]
gac410I get 197 160 195 186 195 161
$1 195
$2 186
$3 195
$
[15:10]
CDotright
i.e. ([[:upper:]]+) matches 195
etc
[15:10]
timlegg3MichaelDaum: No go for some reason [15:11]
gac410yeah... so for some reason, the regex is matching the individual bytes that make up the 3-character string [15:11]
CDotyup
I don't really understand the definition of [:upper:]
seems to me that only works when the locale is set
if you don't set a utf8 locale, what happens?
use locale;
fixes it
[15:12]
Colas"the regex is matching the individual bytes that make up the 3-character string" yup. typical if the locale is the default ("C") [15:14]
gac410I added a "use locale;" to your test script, still failes.
fails
[15:15]
CDotwhere did you add it? [15:15]
Colasbut then, if I recall corrrectly, once locale is set to other than C, [A-Z] will not work anymore regexpes [15:15]
gac410Right at the top of the script [15:15]
CDotI simplified the regex a bit. hang on, I'll revert to what I sent you....
http://pastebin.com/vft4Fqpd
use locale deffo makes it work for me; perl 5.18.2
[15:16]
gac410Not for me. Your lastest paste, with comment removed
$1 195
$2 186
$3 195
[15:18]
CDotperl -V?
can anyone else with a different perl confirm/deny please? MichaelDaum_? jast? Colas? GuilainC
http://pastebin.com/vft4Fqpd
[15:19]
gac410CDot: What do you want from perl -V ... pretty big printout [15:20]
CDotgac410: just the version :-) [15:20]
gac410Oh. 5.20.1
My console locale is LC_CTYPE="en_US.utf8"
[15:20]
CDotLC_CTYPE=en_GB.utf8
same difference
[15:21]
gac410okay. I switched to a different perl 5.18.2 multithreaded from perlbrew and it works now. [15:21]
CDotpfffft
CDot smells camel dung
[15:21]
gac4105.20.1 perlbrew fails. 5.18.2 perlbrew works. [15:22]
CDotgreat :-(
so we can't even work around it with a 'use locale' :-(
hah! it works if you utf8::downgrade the string
with or without locales enabled
[15:22]
gac410more Strangeness. Enabling UseLocale on my live system. it fixes the *Formfield* but NOT the attachment comment [15:25]
CDotin 5.18.2
gac410: I'd guess a missing 'use locale' call in that case
anyway, this is deffo a locales problem.
CDot goes back to installing radiators
[15:25]
gac410Is it a blocker for 1.2 or do we ReleaseNote it?
Or tie UseLocale to LocaleRegexes or ???
[15:26]
Colassame output as gac410 same perl version
my system has LANG=C
same output on a system with LANG=en_US.UTF-8 perl v5.18.2
[15:27]
gac410Same outtput. Do you mean you get the $1 $2 $3 matches? [15:30]
Colas$1 195
$2 186
$3 195
[15:30]
gac410okay yeah, the broken output. :( [15:30]
Colasworks (no output) with use locale uncommented [15:31]
CDotgac410: I thought LocalRegexes *were* tied to UseLocale... [15:36]
gac410lemme look. [15:36]
CDotCDot sees a comment: "Perl 5.006 or higher with working locales"
and, as you noted, the regex does *not* match the same string in the topic body
so, what is different about Form data that causes it to get the utf8 flag set?
[15:37]
gac410gac410 has no clue.
Okay LocaleRegexes is tested / applied in Foswiki.pm independent of UseLocale
[15:38]
CDotCDot is tempted to write ASSERT(!utf8:is_utf8($text)) in Render.pm [15:39]
JulianLevensOn Perl 5.10.0 it works with '#use locale;' and '#utf8::upgrade;'
Both need to be commented out
[15:40]
gac410So the Attachments table is generated by UI::Attach and that *does* have the begin block to "require locale; import locale();" [15:42]
CDotadding utf8::downgrade($text); to Render.pm fixes it for me [15:42]
gac410By removing the utf8 flag, does that break cases where UseLocale is enabled and expects wikiword matching of i18n strings? [15:44]
CDotyes, for sure.
CDot is just exploring around the problem
I don't understand how the utf8 flag gets set in the first place
[15:44]
gac410Okay. I confirm, adding utf8::downgrade right at the top of getRenderedVersion fixes it for me too. [15:45]
jast*usually* calling utf8::downgrade is the wrong fix [15:46]
CDotthe utf8 flag is set during "expandMacros"
jast: yes, it is. but it's useful to help exploring around the problem
[15:47]
jast*usually* setting the flag is wrong, too :) [15:47]
CDotCDot wants to know where the "utf8-ness" comes from [15:47]
it's coming from a JSON::to_json call in SubscribePlugin [15:57]
***Tarbox has left [15:57]
gac410Wow. that's strange.
So that says disabling the SubscribePlugin ought to fix it as well.
[15:58]
CDotyep
unless some other plugin is also setting the utf8 flag :-(
[15:59]
gac410Nope That's enough
Disable SubscribePlugin and the problem goes away.
good catch. Do you use the debugger to find this stuff?
[16:00]
CDotno
the JSON module only supports utf8 and latin 1
any other encodings will be snafued
[16:02]
GithubBot[distro] cdot pushed 1 new commit to master: http://git.io/vfcZy
distro/master e3eaac3 Comment: Item13378: JSON produces UTF, which must be graunched to the site charset before being used. THIS WILL AFFECT ANYTHING THAT USES JSON where that JSON is embedded in the output HTML, for example in HTML5 data- attributes
[16:08]
***GithubBot has left [16:08]
CDotgac410: must check for anything using the JSON module, where the JSON generated is inserted into HTML. The JSON has to be converted back to the site charset. Note this does not affect AJAX functions which are expected to return UTF8. [16:09]
gac410Wow. Great CDot [16:09]
CDotreally got to get those radiators done now :-) [16:09]
gac410gac410 has stuff to do too.
With this I think we are ready for Beta 2 ... tonight?
There is one PlainFile bug jomo opened, moving an attachemnt. But I could not recreate it so I'll let it slide
updatesPlugin also uses to_json, as does Seralize/Json.pm
[16:10]
UpdatesPlugin does not appear to cause an issue. No rendering problems with banner displayed. [16:19]
timlegg3Is there a skin debug that will show which files get read for the skin to see if my skin customization is being read [16:30]
gac410timlegg3: Expanding of templates?
There is a TRACE option in lib/Foswiki/Templates.pm if enabled, it inserts a <!-- comment --> for each template that is expanded. It really corrupts the page, but can let you see what comes from where.
[16:30]
timlegg3Yes? I was attempting to override SolrSearchViewTemplate with MyorgSkinSolrSearchViewTemplate [16:32]
gac410I've not used solr, not sure really about all this. Enabling TRACE can be helpful, but if other users are using the site expect screaming :) [16:33]
timlegg3Its not generally busy so I did it and reverted. The address bar added the comments and it seems to show that it was not picked up [16:37]
gac410timlegg3: When you set the skin, it should not include the string "Skin" So skin for MyorgSkin woud be set SKIN = Myorg,pattern
It searches for a topic named System.$skinSkin$nameTemplate
[16:40]
timlegg3Thanks gac410 - Apparently it is case sensitive
I had put SKIN=myalc and it should have been MyAlc for MyAlcSkinSolrSearchViewTemplate
[16:45]
gac410Yeah when topic names are involved it's case sensitive. I expect the templates dir is as well, but I've only ever seen lower case there. [16:48]
timlegg3I was about to write: I assume that the skins like solr are lower case because they exist in templates dir as lowercase [16:48]
.............................................. (idle for 3h46mn)
GithubBot[distro] FoswikiBot pushed 1 new commit to master: http://git.io/vfWmY
distro/master 0c5f8fb Martin Dahlem: Item13252: Translations updated using Weblate (Danish)...
[20:34]
***GithubBot has left [20:34]
GuilainChi gac410, I've seen cdot ask for testing something in log
is there an item to reproduce ?
(item = task)
[20:40]
gac410Hang on... [20:40]
GuilainC(long log... and hum... after 8 h of painting... little bit lazy to read all :D) [20:41]
gac410http://foswiki.org/Tasks/Item13378
And fix is checked into master. CDot figured it out. Very tricky one.
[20:41]
GuilainCok so nothing to do ? or check master ?
ah is the jomo's bug
;)
[20:42]
gac410Any extension that uses JSON:: and merges data into display will cause some of the data to be flagged as utf8 and the regexes have issues.
SubscribePlugin was triggering the issue.
[20:43]
GuilainC:( [20:44]
gac410https://github.com/foswiki/distro/commit/e3eaac36180e
You just need to convert json data back to the site character set.
It doesn't effect ajax, which always runs as utf8
[20:44]
GuilainCso sorry to ask again, is there something that i can try to do ? (i'm planning my day of tomorrow) [20:46]
gac410No, I think we are in good shape on that.
Do you have a local install?
[20:47]
GuilainCyes but still in 1.1.9
on my task i plan to install beta 2
I don't think to install trunk
except if you ask me, "gently" ;)
1.1.9 is with debian package
[20:48]
gac410oh okay. Nah I meant test installation. That's okay. [20:48]
GuilainCnext 1.2 (beta or not) will be without debian package still i not have a new computer for install a dev environnement [20:49]
gac410Jomo has one other plainfileStore bug, I've been unable to reproduce. [20:49]
GuilainCmy aim is to have several install following different need : on dev install on y (future) laptop [20:50]
gac410yeah I figured that. I think we are going to have to forgo debian pkgs for now. Sven has not gotten back to me about his build tools :( [20:50]
GuilainCand 1.1.9 debian install for the next old where the data will be slide to 1.2 (probably plain store) and at least one 1.1.9 for my old install where data is "freeze"
so i've plan : current (today 1.1.9 tomorrow 1.2), 1.1.9 for freeze old data, and one dev
if need i will plan to make a trunk with "production" (local and personnal data) data in more of the dev install
[20:51]
gac410You could review the new install guide. http://foswiki.org/Sandbox/InstallationGuide01x02Rewrite and http://foswiki.org/Sandbox/InstallationGuidePart201x02Rewrite [20:52]
GuilainCi see gac410, and for the moment i can't make any improvement of that, above my skills and computer ability
ok for install guide
[20:53]
gac410Lynnwood has been rewriting it. Big thing is there anything that is unclear / confusing.
There are lots of broken links, but they will be fine once the topic is back in a System web.
[20:54]
GuilainCfor sure i will tell you if I don't understand, you know me :)
ok
[20:55]
gac410Actually ... I'll check them in. I was working on it anyway. [20:55]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vfWcR
distro/master 8af47df George Clark: Item11262: Updates from Lynnwood...
[20:57]
***GithubBot has left [20:57]
gac410Okay... I just pushed. In about 3 minutes, the will get picked up by trunk.foswiki.org. And can be reviewed at http://foswiki.org/System/InstallationGuilde01x02 [20:58]
GuilainCthis need to be rewritten
http://foswiki.org/System.AdminSkillsAssumptions
IMHO
is "heavy" (I don't know if we cannot say that in english)
need to be more direct
[21:06]
gac410yeah I don't like that. [21:08]
GuilainCwe are two :)
I will make a proposition
[21:08]
gac410Okay. The updated versions are checked in and available on http://foswiki.org/System/InstallationGuide01x02 and http://foswiki.org/System/InstallationGuidePart201x02 [21:09]
GuilainCis not the same that in sandbox ? [21:10]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vfW49
distro/master 23520b4 George Clark: Item11262: Wrong topic parent
[21:11]
***GithubBot has left [21:11]
gac410Just a couple of minor tweaks. The big difference is that the links won't be broken. :) [21:11]
GuilainCoki :) I will check these last ones
gac410, do you know http://labs.translated.net/lisibilite-texte/ ?
hoping you get an english version
[21:12]
gac410No I've never come across that.
Yeah there is an english link in upper right corner
[21:13]
GuilainCis "usefull" for evaluate the "lisibility" (?) of any text
and try to point out the word unusual, which need to take care with
so I think it could be usefull for docu
lisibility = readibility
[21:13]
gac410cool Actually the new InstallationGuide ... at least a few parts of it I cut/pasted tested as easy or average. [21:17]
GuilainC:)
Admin skills is on average
so you can see... is not very good :)
in the same manner you have : http://read-able.com (and many other by googling (type under google) with the word "readability"
but all of this index is often based on the writing on paper and not writing on screen
I'm sure, with some time is possible to think/created an wiki readability index
specially and adapted for the wiki
Is what I was looking for there were several month ago
[21:19]
........ (idle for 36mn)
for those who want to know, in real life, how a wiki is chosen and how is use, an concrete example here : http://ericadekker.com/media/pdf/dekker_projectnarrative.pdf [22:03]
........ (idle for 36mn)
oopsallberrysI am having an issue getting short urls to work; the main page loads but when I click on any Webs or SubWebs I get a 404 error [22:39]
foswiki_irc7anyone interested in helping out with perl configure problems? [22:40]
..... (idle for 20mn)
gac410Hi oopsallberrys, foswiki_irc7, I can try to help, now that I'm done with supper. Everybody running 1.1.9?
And what web server(s)
[23:00]
oopsallberrysHi gac410, I am running apache and foswiki 1.1.9 [23:01]
gac410okay. Did you use the http://foswiki.org/Support/ApacheConfigGenerator, or http://foswiki.org/Support/ApacheConfigGenerator24 to generate your config?
And I suppose I need to ask. how short. yoursite.com/Main/WebHome yoursite.com/foswiki/Main/WebHome ... ?
And are you using fcgi or mod_perl or plain old CGI?
[23:02]
oopsallberrysi used ApacheConfigGenerator (not24), and originally it was yoursite.com/foswiki/Main/WebHome but I am trying to convert it to yoursite.com/Main/WebHome
I believe it is just plain old CGI, i didn't setup anything extra.
[23:05]
gac410okay, good. that's easiest. Did you edit or re-generate your config to make the change. [23:06]
oopsallberrysI edited it
I changed most of the places where it listed /foswiki/bin, etc. to just /bin, etc
like for the ScriptAlias, the couple of Alias, and the RewriteRules
[23:06]
gac410It might be easier to just regenerate or at least compare what it generates to what you have. When you say the "Main page" works. What is the exact URL that works, and what URL gives 404. [23:08]
oopsallberrysi did regenerate to compare and I believe I made all the changes. When I go to yoursite.com it brings up the Main web of foswiki. If I click on any of the links to the subwebs, I get a 404 [23:09]
gac410Ah.... okay... you need to visit bin/configure and fix the config.
Or edit your LocalSite.cfg
[23:10]
oopsallberrysok, i changed a couple of things in there too :P
in bin/configure i changed ScriptUrlPath to just /bin and ScriptUrlPaths{view} to be blank
and PubUrlpath to /pub
[23:10]
gac410hm. okay That's what I was just going to post
if you manually visit a url does it work? http://yoursite.com/bin/view/System/InstalledPlugins for ex.
Acutally, that should redirect to just yoursite.com/System/InstalledPlugins if the apache config is correct
[23:11]
oopsallberrysI get a 404 for the http://yoursite.com/bin/view/System/InstalledPlugins page [23:14]
gac410Okay. probably apache config then.
The "right side" of things like script alias doesn't change. so you need something like ScriptAlias /bin "/var/www/foswiki/bin"
[23:14]
oopsallberrysI have ScriptAlias /bin "/var/www/html/foswiki/bin" [23:16]
gac410okay. That should be okay [23:16]
oopsallberrysAlias / "/var/www/html/foswiki/bin/view" [23:17]
gac410hm. So one thing... make sure your browser isn't caching the pages. Shift-reload on the working url. make sure it really comes up and renders correctly. [23:18]
oopsallberrysyup, i've been closing out my browser as well [23:19]
gac410So if the page comes up "styled" that says that your pub path is correct. So that's good. [23:19]
oopsallberryscould it be the RewriteRules? [23:20]
gac410stupid question ... sorry I gotta ask. You restarted or reloaded apache after updating the configuration :D [23:20]
oopsallberrysRewriteRule ^/+bin/+view/+(.*) /$1 [L,NE,R]
yup i have restarted apache
RewriteRule ^/+bin/+view$ / [L,NE,R]
[23:21]
gac410The rewrite rule does a redirect. 1st one, redirects /bin/view/..... to just /..... 2nd one /bin/view to / [23:22]
oopsallberrysyup thats what i thought, and it looks correct to me, just need a 2nd pair of eyes [23:22]
gac410They basically are typo fixups for users. and the Alias / makes it run the view script for an empty url. [23:23]
oopsallberrysI've noticed that if i turn the rewrite engine off, everything works except now my urls are yoursite.com/bin/view/Web/WebHome
I do not get 404 errors
[23:24]
gac410hm... Could you paste your apache config to http://pastebin.com/ (set a short lifetime for the config)... Or maybe just regenerate it :) [23:25]
oopsallberryssure, give me a minute [23:26]
gac410Either that, or take a look at the 404 error in your apache log. That might give you a hint when it says what was not found.
Oh... did you install using the Foswiki tarball .tgz file, or did you use the debian packages?
[23:26]
oopsallberrystarball [23:27]
gac410okay good. [23:28]
oopsallberryshttp://pastebin.com/VGR5T6M9
had to take out some server names and hostnames
[23:31]
gac410yup that's fine. I'm looking through it now. [23:32]
oopsallberrysappreciate it
apache access log gives a 404 for "GET /Main/WebHome"
so WebHome comes up when I go to yoursite.com, but if I click on the logo to go to the WebHome, I get a 404
[23:32]
gac410Jeeze this all looks okay. Nothing is jumping out as a typo or anything.
Ah.. vhosts... Are you sure it's going to the right vhost? I've more than once debugged one, and the request was ending up on a different vhost. Are you using name based virtual hosts?
[23:36]
oopsallberrysyup, this server is dedicated for foswiki
so there's the 80 for the redirect to 443
[23:39]
gac410yeah I saw that. oh. is your $Foswiki::cfg{DefaultUrlHost} set to "https:// ..." [23:41]
oopsallberrysLocalSite.cfg? [23:41]
gac410yeah. [23:41]
oopsallberrysyup, https
PermittedRedirectHostUrls is http://yoursite.com
[23:41]
gac410okay. well let me try your config here. I'll add a vhost to my apache. This shouldn't be that hard. [23:42]
oopsallberrysok [23:42]
gac410okay good news. It doesn't work here either. What the heck is going on. [23:51]
oopsallberrys:P [23:51]
gac410Doh..... Missing a trailing slah [23:55]
oopsallberrysreally? [23:56]
gac410slash on the Alias / .....view" needs to be a directory name ....view/"
nonon wait
yes.... that's it
[23:56]
oopsallberryswow that is it, i dont think i removed the slash [23:57]
gac410I finally regenerated your config on ApacheConfigGenerator and then did a diff [23:57]
oopsallberrysah so i guess i did
well thank you!
[23:57]
gac410Yeah. so alias / to ...bin/view results in /Main aliasing to ...bin/viewMain...
You're welcome. Need to solve a puzzle once in a while. Never would have spotted it without kdiff3
[23:58]

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