#foswiki 2012-07-30,Mon

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

WhoWhatWhen
SvenDowideitoh my, my internet was dead all nite [00:35]
......... (idle for 40mn)
GithubBot[foswiki] foswiki pushed 1 new commit to master: http://git.io/7Hy70w
[foswiki/master] Item11268: start adding user dashboard customisation persistence - SvenDowideit
[01:15]
***GithubBot has left [01:15]
FoswikiBothttp://foswiki.org/Tasks/Item11268 [ Item11268: build a User topic dashboard using widgets. ] [01:16]
............................... (idle for 2h30mn)
***gac410 has left [03:46]
....... (idle for 30mn)
dj_segfaultIs anyone but me having problems with SqlPlugin? I updated it and now most queries that worked before the update are saying "ERROR: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 at /home/neagile/foswiki/public_html/lib/Foswiki/Plugins/SqlPlugin/Core.pm line 138. at /home/neagile/fo [04:16]
......... (idle for 41mn)
OK I think I identified the bug in SqlPlugin. It's not properly detecting the end of queries that span multiple lines. I created http://foswiki.org/Tasks/Item12018 [04:57]
.............. (idle for 1h9mn)
SvenDowideitdcommiting a simple foswiki.post() that can do strikeone, embedded and none
and using it on Hallo.js and DashboardContrib
mmm, pharvey what was that drag&drop re-parenting plugin i did?
[06:06]
pharveySvenDowideit: slick-something-contrib [06:09]
SvenDowideitah, tnx :) [06:10]
pharveySlickSitemapContrib [06:10]
GithubBot[foswiki] foswiki pushed 4 new commits to master: http://git.io/JRmFZQ
[foswiki/master] Item12019: simplify strikeone and non-strikeone ajax use - SvenDowideit
[foswiki/master] Item12000: use foswiki.post() - SvenDowideit
[foswiki/master] Item11268: use foswiki.post() - SvenDowideit
[06:15]
***GithubBot has left [06:15]
FoswikiBothttp://foswiki.org/Tasks/Item12019 [ Item12019: Development.AjaxAccessFixes ]
http://foswiki.org/Tasks/Item12000 [ Item12000: Hallojs and Createjs contrib - html5 and rdfa inline editing. ]
http://foswiki.org/Tasks/Item11268 [ Item11268: build a User topic dashboard using widgets. ]
[06:16]
SvenDowideitdarnit, it thinks jQuery is not defined
this kind of thing should just simply not go wrong :/
[06:16]
pharveySlickSitemap? It might be pre-Zones [06:16]
SvenDowideitADDTOHEAD [06:16]
pharveythere ya go :) [06:17]
SvenDowideitwhich means we broke addtohead :( [06:17]
pharveyno, we broke everything that assumed script lives in the head
which... was every plugin written for Foswiki 1.0.x
{MergeHeadAndScriptZones} was a compatibility hack
[06:17]
SvenDowideitgee, same thing only more typing
which explains why i'm wary of doing the work that it should all be replaced by
jsRequire type stuff
SvenDowideit is getting sick of tossing around strings, which might mean its time to move to new code
[06:18]
pharveyX-Wiki?
Actually, they have a pretty nifty DOM... :)
[06:19]
SvenDowideiti must admit, the more i look a lucene stuff, the more i have trouble justifying saying no to java
except, i hates java
[06:20]
pharveyindeed :(
it can be made to work
I've been trying to dive into python (no, the book is stupid) for the last few weeks
[06:21]
SvenDowideitshrug [06:22]
pharveyI didn't realize how painful the 2.x -> 3.x transition is
not quite as bad as perl5 -> perl6, haha.
but it's hard to write non-trivial code that runs on both.
moot point anyway, the libs I need aren't 3.x ready
[06:22]
SvenDowideitgads
hey pharvey,
you have solr on trin right?
SvenDowideit mumbles something about having 2 unstructured json stores as foswiki caches
[06:24]
pharveyit's disabled atm. [06:25]
SvenDowideit:( [06:25]
pharveythere was a schema change, and I need to reconfigure our solr server; it's on my todo list...
there's nothing wrong with having more than one cache
[06:26]
SvenDowideitexcept .... [06:27]
pharveyif you wanted to ditch mongo and use solr for everything, you'd have to make a lot of new logic to manage dynamically generated views (and even more logic to track which ones can be ditched/expired)
s/views/indexes
[06:27]
SvenDowideitgood to know :) [06:28]
pharveywell, it's just that solr isn't as expressive as mongo. As you know.
don't take my word for it. I'm summarizing a conclusion I formed about 18 months ago, I can't remember the details :P
I *do* suspect, however, that materialized views (as per CouchDB & friends) - intelligently managed, created & expired on-demand - done properly - would give us the best of scalability without awkward caveats
but, there's still a lot of low hanging fruit with the current mongo impl.
[06:29]
SvenDowideitand in foswiki itself :/
considering what i just commited
[06:32]
ok, an updated version to play with
going to get girls :)
[06:40]
GithubBot[foswiki] foswiki pushed 1 new commit to master: http://git.io/Y7c-Cw
[foswiki/master] Item12019: update SlickSitemap reparenting to use trunk's foswiki.post(), might have to make a 1.1 shim? - SvenDowideit
[06:46]
***GithubBot has left [06:46]
FoswikiBothttp://foswiki.org/Tasks/Item12019 [ Item12019: Development.AjaxAccessFixes ] [06:46]
.................. (idle for 1h26mn)
CDotSvenDowideit: nice.... (s1 changes) .... does it work? [08:12]
SvenDowideitCDot, it works for the 3 eg's i commited, and tested for s1, embedded and none
but i bet there are improvements to be made
[08:19]
CDotI read the (JS) code quite carefully, and it looks spot on AFAICT [08:20]
jastthe concept is great in any case [08:20]
SvenDowideitit (un)amuses me that there is in fact no real way for the js to detect if s1 is enabled [08:20]
CDotyeah, I wondered about limiting the cookie release for that [08:20]
SvenDowideitlimiting doens't help, it needs to be explicitly unset [08:21]
CDotright now we vomit out the cookie regardless, I think [08:21]
SvenDowideity, kinda
in that its only there if s1 was on at some point in the session
[08:21]
CDotyes, but at *any* point. You are right about unsetting. [08:21]
SvenDowideitmind you, if i get this right, no-one should care [08:22]
CDotyes, agreed. [08:22]
AlexisHazelli'm getting very odd viewfile errors - odd because i can't find a pattern to them.
Partially it seems to be connected to folder depth. But not totally.
[08:35]
CDotAlexisHazell: tell us more.... [08:35]
AlexisHazelli get messages like "Attachment '/folder/file.pdf' does not exist". [08:35]
CDotand does it exist? [08:36]
AlexisHazellBut it certainly does.
Well, the path being listed in the error message isn't actually the full path.
[08:36]
CDotdoes it happen consistently on that attachment?
you can switch on full paths in error messages
[08:36]
AlexisHazellYes, and randomly on a number of other attachments.
In configure?
[08:37]
CDotno, in code
hang on, just reminding myself
easiest way is to switch on DEBUG
[08:37]
AlexisHazell*nod* Okay.
Will try that shortly.
[08:38]
CDotset the environemnt variable FOSWIKI_ASSERTS and it will stop rewriting paths [08:38]
AlexisHazellBut to give but one example: if i copy the file that's not being found up a directory, it then gets found. [08:38]
CDot"up a directory"? show us the path to one of these files, and the path to the topic you think it is attached to [08:39]
AlexisHazellSo i have a file: foswiki/pub/Archive/General/folder_a/folder_b/folder_c/image.gif
If via ssh
i move image.gif from being in folder_c to folder_b, viewfile doesn't have a problem with it.
[08:41]
CDotinteresting. and are folder_a/folder_b etc paths reflected in Foswiki i.e. web/subweb/subweb?
cos otherwise I'm not sure what the permissions checks will do; the problem may stem from there
of course if you have other files following this pattern that work OK, then ignore me :-)
[08:42]
AlexisHazellArchive is a web, General is a subweb of that; but the folders under that aren't subwebs of General. [08:43]
CDotok, then it sounds like the permissions checks might be throwing a wobbly [08:43]
AlexisHazellHm. [08:44]
CDotswitch on FOSWIKI_ASSERTS, and check the apache log and all foswiki logs you can find
just to make sure
[08:44]
AlexisHazellOkay, will do, thanks. [08:44]
"Assertion (this is not a topic object) failed!" [08:49]
CDotthere should be a stack trace somewhere for that. But bear in mind that the use-case you describe is not "officially" supported [08:51]
AlexisHazell*nod* Yeah, it's just supposed to be a temporary measure as we move documentation into FW. Which seems to have worked overall up to this point.
The assert seems to be in Foswiki::Meta::hasAttachment.
[08:56]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Meta [08:57]
AlexisHazell"Foswiki::Meta::hasAttachment('Foswiki::Meta=HASH(0x676c5f0)', 'flyer.png') called" [08:57]
.............................. (idle for 2h29mn)
***ChanServ sets mode: +o MichaelDaum [11:26]
.......................... (idle for 2h8mn)
jastMichaelDaum: just wanted to let you know that I had a problem with LdapContrib when the filter contained UTF-8 characters (the LDAP server expected UTF-8 but received Latin1). not sure if you've already taken care of that.
gac410: so apparently CKEditor (or CKE+IE) destroys whitespace in everything but <pre> and <textarea>. we might need an alternative sticky protection mode in WysiwygPlugin for CKE...
[13:34]
MichaelDaumnope. never occurred to me [13:35]
jastI think you already handle encoding for some of the fields
I can't remember whether the problem occurred in baseDN or in something else
just looked at my monkey patch again
[13:35]
MichaelDaumcould be the _filter_ expression needs recoding before sending the query to the server [13:38]
jastI think you do take care of encoding {filter}... but not {base} (in LdapContrib::search) [13:38]
MichaelDaumargh [13:38]
jastof course only a weird person would use a base DN with utf-8 chars in the first place, but then again I can't magick away our customers' IT departments ;) [13:39]
MichaelDaumOU=Frühlingserwachen [13:39]
jastyeah, that kind of thing
gac410: re CKEditor issue: http://dev.ckeditor.com/ticket/3603
[13:39]
gac410hm... so why is it okay on TMCE then. :( [13:43]
jastI tried removing their code that changes the whitespace
but in IE it still ends up destroying the whitespace
perhaps I forgot to clear the cache or something
I'll try again in a while
[13:43]
MichaelDaumwhich IE? [13:43]
jastpessimistically, I tried IE9-in-7-mode
(luckily we make a point of not supporting IE6)
[13:43]
gac410That's showing it in a paragraph. I'm not sure what we do with sticky blocks, probably a div.. gotta run... [13:44]
MichaelDaumtry to add <meta http-equiv='X-UA-Compatible' content='ie=edge,chrome=1' /> to all of your wiki [13:44]
jastnot all of our customers actually use IE9 [13:45]
MichaelDaumdoes not matter. result of this x-ua-compatibility meta is that whatever they have installed it will use the most recent mode the ie version supports [13:45]
jastand I'm fairly sure we can't go like "well, then just give your 5k employees a newer browser than IE7" [13:45]
MichaelDaumthat is no more automatic intranet compatibility downgrade yadda
most have ie8 or 9 already ... but accidentally run it in ie7 mode
[13:46]
jastwe have a few that definitely run ie7 [13:46]
MichaelDaumhow many? [13:46]
jastdoesn't matter [13:46]
MichaelDaumor asked the other way around: does you client want to pay for these few? [13:47]
jasteach customer is a couple hundred end users at least
their UAs are not per-user.. they are per-company. central deployment and such.
[13:47]
MichaelDaumseems they run winxp .. and never updated it [13:48]
jastsome of them run the weirdest things [13:48]
MichaelDaumcouple of links that might help: http://www.webdesignerdepot.com/2011/05/how-do-you-convince-the-average-web-user-to-switch-to-a-non-ie-browser/
http://gs.statcounter.com/
http://www.smashingmagazine.com/2012/07/10/dear-web-user-please-upgrade-your-browser/
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0&qptimeframe=M
http://www.netmagazine.com/features/developers-guide-browser-adoption-rates
*phone*
http://www.smashingmagazine.com/2012/07/09/old-browsers-are-holding-back-the-web/
[13:49]
jastI know all of that [13:50]
MichaelDaumff it to your client [13:51]
jastwe're talking about big company IT departments here
they basically don't care
[13:51]
MichaelDaumthen they cant get the same web experience [13:51]
jasthmm, in the LDAP cache, are the GROUPS:: entries really supposed to contain a comma-separated list of DNs? :}
I suspect something is misconfigured here
[13:52]
Babaryeah, I second jast. The good old "do your job" motto. IT dept there isn't doing their job, so they don't care. Blaming it on others. [13:53]
jastlast week we set up a wiki on a virtual server for a company. a few days later the server suddenly didn't respond to anything anymore. [13:54]
MichaelDaumIve just recently added a banner warning for ie6 that their browser isnt supported anymore [13:54]
jastwe phoned them and learned that the guy we'd been talking to was on vacation, and *someone* had shut down the server [13:54]
MichaelDaumI would have flagged the banner for ie7 too but unfortunately ie8-compat reports as ie7, even with x-ua-compat = edge
jast, haha. you bleed.
[13:55]
jastluckily the other guy we called seemed like a competent person and had us back running in a few minutes [13:56]
MichaelDaumand they didnt notice by themselves? [13:56]
jastthe wiki isn't live yet
our consulting guys are still busy preparing the content/structure
it won't be in real production use for quite some time
right-o. LDAP fixed.
[13:56]
MichaelDaumMichaelDaum looking forward to your patch attaced to a task item, jast. thanks in advance. [14:00]
jastMichaelDaum: I'll try... but the straightforward approach using toUtf8() didn't seem to work. I had to mess with Encode directly. will have to try and figure out something better
oh yeah, I remember
the problem is that your toUtf8 function basically returns the string as-is if the site charset is utf-8
that's a problem because the string will be a perl unicode string at this point and during its getting sent to LDAP, it'll go into a file handle that has no specific binmode set, so perl transparently recodes it back into latin1
s/binmode/IO layer/
or something like that
might have to set ${^OPEN} or just always make it a byte string
[14:01]
MichaelDaumdon't make waves while the shit leaps up to our necks
but yea
[14:06]
jasthere you go: Item12021 [14:19]
FoswikiBothttp://foswiki.org/Tasks/Item12021 [ Item12021: LdapContrib: baseDN has wrong encoding in searches ] [14:19]
CDotgac410: you left me confused..... the broken test versus the test you changed? The test you changed is what's wrong, IMO. [14:21]
MichaelDaumhm that worked out for you? [14:21]
jastI haven't tested this particular patch. I used a much dirtier version in the field [14:21]
gac410Web contains topic BlahTopic. Rename Web to NewWeb. BlahTopic in that web should remain BlahToipc. [14:22]
jastcan't really test it now, anyway... it turned out that we were supposed to use a different, saner base DN
(well, "saner" is almost certainly the wrong word... let's say, a base DN that doesn't have any special characters in it)
[14:22]
gac410Links to topics IN the web should not be changed to Web.Topic format when the web is renamed.
It was Micha's fix that I cherry-picked.
[14:22]
jast. sticky areas are encoded in a div, and use explicit <br /> for newlines and &#160; for encoded spaces. Doesn't make sense that ie would discard the breaks or encoded spaces. [14:29]
jastoh, that's interesting [14:30]
gac410<div class="WYSIWYG_STICKY"><br />asdfd<br />&#160;&#160;asdfasddf</div> [14:30]
jastsomehow that's not what happens in my version
I think...
lemme check
[14:30]
CDotgac410: that test is not renaming the web, it's renaming a topic from web to another (i.e. moving the topic)
so a relative reference to another topic in the same web will no longer point to the same place
.... unless you prefix the originating web name.
Of course the code you deleted may not be related - I didn't go into it that far
but the test is deffo wrong now.
[14:33]
gac410Need to talk to MichaelDaum - As i said. I cherry-picked fixes that were running on trunk for quite some time now. [14:35]
CDotso the trunk tests have been failing for quite some time? Ouch
CDot has not been receiving test failure mails
[14:35]
jasthmm, I dunno. my version is based on 1.1.9 and somehow it encodes spaces to &nbsp; and leaves newlines unchanged. I don't see any commits in that range that would change this, though. [14:36]
gac410They pass.
The change to the test was to fix the change made in the next consecutive commit.
[14:36]
jastthere must be some other kind of desync between our branch and the official one... :/ [14:36]
CDoty, the test has been incorrectly modified on trunk as well :-( [14:37]
gac410That means that rename is broken by Foswikirev:14958 [14:39]
FoswikiBothttp://trac.foswiki.org/changeset/14958 [ Changeset 14958 – Foswiki ] [14:39]
gac410jast: Look in TranslatorTests.pm, search for sticky. Wysiwyg inserts the <br /> and &nbsp; Looks like TMCE encodes the &nbsp; into the &#160; [14:41]
CDot14957 is the checkin that broke the test [14:41]
MichaelDaumthe test was pretty wrong as far as I remember. the code was horrendeously broken. a kind of occupation therapy for computers. [14:41]
gac410Right. and 14958 breaks rename so that the test broken by 14957 passes. [14:42]
CDotthe code may have been wrong, but the test was correct
it is wrong now
[14:42]
MichaelDaumwhat exactly does it test. I seriously cant remember. all I remember is that it did not make any sense.
and gac410 agreed
[14:42]
CDotthe comment on the checkin is "adding a SMELL for one failing test as it is unclear why this should ever work" [14:42]
gac410NO NO ... comment is on a different test [14:43]
MichaelDaumthis is about 14 OtherTopic right? [14:43]
gac410yes [14:43]
CDotMichaelDaum: yep [14:43]
MichaelDaumthe test now says: leave it like it is, i.e. dont try to rewrite it [14:43]
CDotcorrect
i.e. it's a spec change
[14:43]
MichaelDaumwhich rename operation is being tested? [14:44]
CDotrenaming a topic from one web into another
so, rename A.B to C.B
[14:44]
gac410The underlying issue being fixed is that even though Rename is given a list of topics to fix, which you pick with the checkbox. It then does a full scan anyway ignoring the checkboxes. [14:44]
MichaelDaumwhat is OtherTopic related to A, B, and C, CDot
gac410, spot on.
[14:44]
CDotA.D, referred to in A.B sinly using the string "D"
^sinly^simply
since B is now in web C, then "D" will refer to C.D, not the original A.D
[14:45]
MichaelDaumthe test is "rename testweb->OldTopic to newweb->NewTopic" ?
MichaelDaum can't deal with A, B and Cs.
[14:46]
CDotno. testweb->oldtopic to newweb->oldtopic [14:46]
MichaelDaumokay [14:46]
CDotMichaelDaum: if you check your svn checkins, I wrote a more complete description for George this morning [14:46]
MichaelDaumso in how far is OtherTopic related to this operation ... not at all [14:46]
CDotright, OtherTopic is not being renamed. It is just referred to. [14:47]
gac410Ah. I understand. Test and fix is indeed broken. Now to explain. [14:47]
jastgac410: okay. definitely one of our random and completely undocumented changes to WysP. I'm just going to go cry in a corner. [14:47]
CDotI have no problem with a spec change, BTW. I always thought this was overkill. But it needs to go through the process.
if that's the only reason for poor rename performance, it's not worth keeping.
[14:47]
MichaelDaumwhy should OtherTopic be rewritten to testweb->OtherTopic when some totally unrelated topic called OldTopic is moved into a different web?
MichaelDaum just tries to get a grip on the test
[14:48]
gac410You rename oldweb.OldTopic to newweb.OldTopic. It had a link to OtherTopic. That needs to be renamed to oldweb.OtherTopic. [14:48]
***Babar sets mode: +oooo AndreU CDot Colas gac410
Babar sets mode: +ooo pharvey SvenDowideit terceiro
[14:49]
gac410It still should not require a scan of the whole web. though. [14:49]
CDot*unless* we change the spec to exclude this type of "relative topic reference" [14:49]
MichaelDaumthis isnt about renaming webs. it is about renaming topics, gac410 [14:49]
CDotthus forcing people to use "Thisweb.OtherTopic" if they want that reference to be correct after the containing topic is moved. [14:50]
gac410Right. read what I wrote. It is renaming (moving) a topic from oldweb to newweb. If that topic contains relative links, they need to become explicit. [14:50]
CDot(if they are not made explicit, they will be broken after the rename) [14:50]
MichaelDaumgac410, now I got it. thanks gac410 [14:50]
CDotof course, if you are referring to (for e.g. "WebHome", you *want* the reference to be relative [14:50]
gac410So test was correct, and is now broken, because we lost that feature - converting relative to explicit. But the original code, scanning all webs all topics - was bogus.
;P
:P
[14:51]
CDotso we can describe "SimpleWikiword" as always applying *within the containing web* [14:51]
gac410That sounds very reasonable. [14:51]
CDotand ignore it when we rename the containing topic. However this is a behaviour change, so has to go through the process (feature request) [14:52]
gac410agreed [14:52]
CDotand yes, the original code was bogus; I'm very glad someone took a microscope to that.
I tried to be faithful to the functionality of twiki 3.0, but I was untangling spaghetti.
[14:52]
MichaelDaumactually the code and the test case arent really related to each other [14:54]
gac410For the feature request, this aspect of rename is 50/50 chance of always being wrong. WebHome, WebStatistics, WebSearch, etc. should always be relative. But Webarifictopic could probably become explicit. So relative links remain always relative. [14:54]
MichaelDaumif the feature was to be preseved, then the code only had to scan the topic being renamed. not all of the other webs, source and target.
the feature is/was: preserve the link origin
[14:54]
gac410right. It was just by luck that the renamed topic was included in the scan :) [14:55]
MichaelDaumoutgoing relative links shall still point to the same topic
these are _in that single topic only_ ... or what am I missing
the list provided via url params was only listing incoming links, not outgoing.
[14:55]
gac410I don't think you are missing anything. Just a retroactive feature request that relative links within the renamed topic remain relative, as there is little chance of getting them right.
right.
[14:56]
MichaelDaumokay so what do we do? change the specs or fix outgoing links?
there's a third case by the way
there's already a newweb->OtherTopic that the moved topic will happily point to
[14:57]
gac410I lean toward changing spec. As CDot said, odds of getting the outgoing link correct are not good. Unless you do things like testing if the topic exists in the new web.
right exactly.
[14:58]
MichaelDaummy stance: rewrite as few data as possible. in most cases it will break wiki apps anyway when processing formfields, thus renaming field names ...
I've seen too many data being destroyed due to renames
may I resume: the tests are fine now (even though we have a slight spec change here) - the code is fine as well
as fine as can be atm
[14:59]
gac410Need to update the docs and make sure the behavior change is in the release notes. [15:03]
CDotwould you like me to generate a feature request?
CDot is concerned this needs to be documented, as people *will* be affected in unexpected ways
[15:06]
gac410Interesting that it took a scan of the entire wiki to accidentally fix up the outoing links. If we want this feature, then rename needs a separate function that fixes up outgoing links, maybe depending on whether or not the referenced topic exists in the new web. [15:09]
MichaelDaumgac410, yea
in the end a relative link is a relative link
(new behavior)
[15:09]
CDotI don't think the scan of the entire wiki was just doing that; at least, I can't imagine why it would scan beyond the originating web for that sort of fixup
and TBH, I can't see why you would have to scan at all
CDot goes back to check the deleted code
[15:12]
gac410Right, I suspect it was an accidental side effect [15:13]
CDotok, so the deleted code was doing something different. It did fix up these links, but the main work - and this is another spec change - was *removing* web specifiers
for example, if you move Thisweb.Topic to Thatweb.Topic, and Topic already contains a ref to Thatweb.Topic, it would find that and *remove* the Thatweb. prefix
frankly a bit pointless, and a spec change that we can ignore IMHO
[15:15]
gac410yeah. IMO, the only topics modified should be the ones selected by the checkboxes. Other changes would be unexpected and could be undesired. [15:17]
MichaelDaumit is a kind of granted permission to also change the checkboxed topics [15:17]
CDotwell, Michael's hack changes that behaviour and TBH I don't think it's worth any effort to re-enable it.
I will create a feature request to alert others of this change. I doubt anyone will be too worried.
[15:18]
gac410agreed [15:18]
..... (idle for 23mn)
CDothttp://foswiki.org/Development/ChangeRenameBehaviourOnRenamingLinks [15:41]
......... (idle for 40mn)
MichaelDaumMichaelDaum rewritten it to better explain whats going on [16:21]
CDotMichaelDaum: you have a good point there. The current scan that identifies *referring* topics includes a regex to scan for relative links. But if we regard relative links as strictly relative, then the topic those links refer to can change *without* the referrer changing. This would reduce the number of referring topics still further - at the cost of some further expected behaviour. [16:24]
MichaelDaumhm no these two are in different sets
there are relative links coming in
there are relative links going out
relative links coming in need to be rewritten
not so the latter
as a rule of thumb: the less you touch the data being moved, the better
[16:25]
CDotfor some value of "need". If we don't rename incoming relative links, it would be more efficient and our treatment of relative links would be more symmetrical
another rule of thumb: the less you touch *other* data, the better
[16:28]
MichaelDaumbacklinks are quite a different concept
we are maintaining backlinks, much more than normal links.
[16:28]
CDotyou mean we are maintaining incoming, but not outgoing. Except, of course, where a topic is self-referential. [16:30]
MichaelDaumyes
it would be very hard for users to fix broken links manually to point to the new location of the topic
[16:30]
CDotindeed. [16:31]
MichaelDaumit is relatively easy for them to review the content being moved [16:31]
CDotwell, it is when they move a single topic. But many moves are bulk. [16:31]
MichaelDaumso theres a need for a kind of service fixing backlinks [16:31]
CDotand review in that case is often very hard. [16:31]
MichaelDaumyou mean moving a web? [16:31]
CDothowever the "relative link compromise" is IMHO *better* for bulk moves
no, moving a subset of the topics in a web to a different web
[16:32]
MichaelDaumis there a feature that I know nothing of? [16:32]
CDoterm, possibly
CDot does it with a script, but may not have published it :-8
[16:32]
MichaelDaumhow does a user move 3 topics in one go
anyway. we are very bad in bulk operations.
[16:32]
CDotah, yes, unpublished. It's command-line only anyway, so not very friendly; a UI method would be better. [16:34]
MichaelDaumeach iteration in a bulk operation fires a whole slew of handlers per plugin [16:34]
CDotwell, it depends how the bulk operation was implemented, but yes, that's often the case. [16:35]
MichaelDaumMichaelDaum thinks of bulk operations on attachemtns ... uaaah [16:35]
CDotI can imagine
plenty of scope for someone to improve that :-)
[16:35]
MichaelDauma bulk upload boils down to one save thingy per attachment [16:35]
CDotyeah; why did you never fix that? I thought you had a bulk upload plugin? [16:36]
MichaelDaumwell the conceptual problem is that our plugins are not ready to deal with a bunch of items affected by an operation.
afterSaveHandler -> takes one topic being affected
afterUploadHandler ->takes one attachement being affected
and then they do their thing on each iteration
[16:36]
CDottrue; but it's only a few handlers that would need to "collect" such handler ops
for example, "beforeEdit" will only ever be on a single topics
[16:37]
MichaelDaumrealy ;)? [16:37]
CDotok, so it *could* collect, but is there such a great value there?
I can see the value for bulk save, bulk attach, but bulk edit? Hmmm
[16:38]
MichaelDaumedit an item in an n:m relation
or: an editor made up of a bunch of topics used to hold the data under the hood
[16:38]
CDotif you want to go to the nth extreme, then yes, you could do that. but so much code would have to change ......
and given the size of the interaction window, "n" is quite a small number for edits.
[16:39]
MichaelDaumlocking, merging and exceptions, transactions ... becoming important [16:40]
CDotI'd personally want to bite off a smaller problem. [16:40]
MichaelDaumme2
I'd be happy with a bulkAfterUploadHandler
[16:40]
CDotMichaelDaum: do you use PublishPlugin? [16:40]
MichaelDaumnope [16:41]
CDotok. Why not? [16:41]
MichaelDaumno use case for me personally. some clients do use it to generate books. [16:41]
CDotok, sure, I was kinda asking through you to your clients :-)
CDot wants to change the way the PDF generator works, but doesn't want to break anyone's use cases.
[16:42]
MichaelDaumit definitely is an important wiki building block. and I promote its used regularly.
for some %INCLUDE + GenPDFxxxPlugin is enuf
[16:42]
CDoty, PublishPlugin supports that using Bookmaker to auto-generate the %INCLUDEs. It can then generate a flat HTML with the entire content in it, or a PDF, or any other flat content - with all internal links cleanly redirected.
The PDF generator currently generates a PDF from a directory of HTML files. I want to change it to generate the PDF from that flat HTML.
[16:45]
MichaelDaumthats better for several reasons [16:46]
CDotthe only real change would be the loss of an automatic page break between each topic
but someone might be relying on that - hence my question
[16:46]
MichaelDaumbetter let the typographic algorithm take care of page breaks [16:47]
CDoty, agreed, but that not the way it used to work, so it's a change
anyway, I just found a way to offer both routes, so it's academic :-)
[16:47]
MichaelDaumpeople will be able to cope with it I guess [16:47]
Procopiohi [16:54]
gac410hellp Procopio [16:54]
Procopiohi :)
i came here to find some help with some app im doing over foswiki
i had the chance to write it in the mailinglist , but i though i it might be a bit faster in here
u think u can help me?
?
[16:54]
gac410You need to ask your question ;) If someone knows the answer they will answer.
ie. No need to ask to ask.
[17:01]
Procopioah ... :) [17:01]
AlexanderStMichaelDaum: Hi Michael, i just faced a LdapContrib thingy what was reported long time ago...the cache.db file owner sometimes changes from apache to root. I don´t really get an idea when this change takes place. do you have a hint for me, what could be the reason? [17:01]
Procopiowell here goes. [17:01]
MichaelDaumAlexanderSt, you've got a cronjob running as root. [17:02]
Procopiothe problem: create a topic with pre-defined data (passed through input fileds of a form) and an attachement ... all in "one go". [17:02]
MichaelDaumshould be running as user apache [17:02]
AlexanderStyes, but not the cronjob for refreshing the ldap cache [17:02]
gac410Ah. that question. :( [17:02]
Procopiothe ideia is that the user fills out a form with some data, including a input field for a path of a local file, and hits one button (submit) and the topic is created with the attachment. [17:03]
gac410One thing not asked on the list. Does this topic/attachment combination get created by someone using a browser, or is it something that some task creates. [17:03]
Procopioits created by a user (through browser) [17:03]
gac410Okay - from the web. You answered before I finshed typing. :) [17:03]
MichaelDaumAlexanderSt, try to disable automatic ldap refresh [17:04]
AlexanderSti have a job refreshing solr and i checked it today...it´s seams not to be the reason, since the job was running today and the cache.db is still apache [17:04]
MichaelDaumwhich occurs once in a while under the hood [17:04]
AlexanderStok that would be an idea...since the customer doesn´t like to give the apache user a shell
...very "security" aware...
[17:05]
MichaelDaumthats no problem [17:05]
gac410Procopio: so I think you are onto the solution - use javascript to both save a topic, and upload the attachment. [17:05]
MichaelDaumcronjob -e -u apache
or just change the user part of the root cronjob using su
[17:05]
Procopiogac410: yeah Kruger already suggested that ....
but i have no ideia how to proceed ....
[17:06]
MichaelDaumvery "security" aware ... yet still run cronjobs under root ... hum -> does not compile [17:06]
Procopioi would need some pointers to even start that task [17:07]
gac410MichaelDaum: Does TopicInteractionPlugin have any js that might help as examples of creating a topic and uploading an attachment? [17:07]
MichaelDaumgac410, yes
UploadPlugin, the predecessor of TopicInteractionPlugin was invented for attach+create+dataform in one go once upon a time
[17:07]
AlexanderStok, but does a cronjob work if i cannot use the shell for the same command? so if su apache -c "blabli" is not working in the shell, does it work in the cronjob? [17:08]
MichaelDaumgac410, a DataForm driven WikiApp to archive and annotate pdfs [17:09]
gac410Hm. So UploadPlugin %UPLOADFORM% target= can point to a non-existing topic? [17:09]
MichaelDaumAlexanderSt, setting the login shell to /bin/false (which is normally the way to prevent somebody to login as user apache) does only affect the login, not the stuff that runs as that user.
gac410, I honestly forgot
but yes
thats more or less how it worked as far as I remember
[17:09]
ProcopioWelll i can give it a try
giver a few minutes
[17:10]
MichaelDaumUploadForm transaction created a topic and then attached the file being transfered on the same request
no magic actually
[17:11]
gac410That sounds exactly what Procopio wants to do ... great [17:11]
MichaelDaumnote however, I am pretty sure UploadPlugin is out of order atm [17:11]
gac410:( [17:11]
MichaelDaumbit rot [17:12]
Procopioummm
so ... should i try it?
[17:12]
MichaelDaumgac410, we could teach save upload
in core
[17:12]
AlexanderStMichaelDaum...thanks, i will give it a try tommorrow [17:13]
MichaelDaumAlexanderSt, yw [17:13]
gac410Procopio: There are no open bug reports specific to 1.1.x, and nothing in the "compatibility" ... so I'd give it a try. But MichaelDaum would know better, he is the author. [17:13]
Procopio:)
yes he is the author of many things in foswiki :)
[17:14]
MichaelDaumMichaelDaum hides his head [17:14]
gac410hm. We really ought to make a point of marking the "bit-rot" plugins that don't work and even moving them to Extensions/Archived. Makes for a much happier user experience if know breakage is hidden. [17:15]
MichaelDaumgac410, would prevent the rotten bits to be picked up and fixed effectively [17:15]
gac410MichaelDaum: The only open task calls out a compatibility issue with NatEdit. [17:16]
MichaelDaumyep. there's an open todo for me to bring back the upload dialog in natedit ... this time using TopicInteractionP
... which is disabled for now.
[17:16]
gac410I understand the conflict. But users need to at least have an expectation as to whether or not an extension will work. Anyway, if the issue is natedit specific, Procopio might have some luck? [17:17]
MichaelDaumnatedit has got no upload dialog right now. the existing code is pointing to UploadPlugin but is disabled. [17:18]
Procopiojust tried it
doesnt seem to do anything :(
[17:21]
MichaelDaumthats why I did not chim on on the ML [17:22]
Procopioclick the upload button and nothing happens
i even looked on the server side for the file
nothing
:(
hangon .. it worked
i changed one of the settings (embed)
and now it created the topic with the attachement
:)
so ... now all i need is to have the topic created with my predefined template , and passed the other arguments to it
[17:23]
***ChanServ sets mode: +o Babar [17:35]
gac410MichaelDaum: Playing with UploadPlugin on trunk, I see two issues. Keeps reporting upload.js JQuery not found. The +more -less buttons in the form are NOP, and had one uncaught exception
Error: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative" nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)" location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: onxblpopuphiding :: line 862" data: no]
But it's actually working find for uploading single attachments.
[17:37]
Procopioyeap
the thing now is having it integrated in the other form
[17:37]
jastalways a good sign when stuff is triggering internal browser errors [17:38]
Procopioand make sure it uploads to the newly created topic [17:38]
gac410The default %UPLOADFORM{}% does successfully create a new topic and upload the attacment to it. [17:39]
Procopioyeah
but now i need it to add to a new topic created based on a template, with all data filled with info collect from another form!
[17:39]
gac410MichaelDaum_: CDot: I think you used the word "prevent" in a couple of places where you meant "preserve" ??? [17:41]
CDotprobably Micha - he rewrote almost all my text [17:41]
gac410The intention is to leave these links untouched to prevent the relative nature of the WikiWord. Aren't you preserving the relative nature, not preventing it? There are a couple of instances that seem to read funny.
Procopio: beyond my pointers, I don't know much about that plugin. You may need to modify it a bit. And the jquery issue sounds strange. JQUery is indeed in the <script> tags for the page. Not sure what's going on.
javascript / jquery is not my expertise.
[17:41]
Procopioummm :(
i'll have to look into it later ....
i got move now
thanks alot guys, you were a great help
[17:44]
gac410At least it's a starting point.
good luck with it.
[17:45]
Procopio"every No, brings you closer to the yes"
:)
see u
[17:45]
.......... (idle for 46mn)
GithubBot[foswiki] foswiki pushed 1 new commit to master: http://git.io/S9RAcg
[foswiki/master] Item8260: fix it so that links to topics that are not published don't get rewritten. Also refactored generators into a subdirectory to make life a bit easier. - CrawfordCurrie
[18:31]
***GithubBot has left [18:31]
FoswikiBothttp://foswiki.org/Tasks/Item8260 [ Item8260: Links to webs/topics _outside_ of the published web should not be translated to relative links ] [18:31]
.......................... (idle for 2h5mn)
foswiki_irc0Hello
Anyone here?
[20:36]
I did a fresh install of foswiki on a clean windows XP serverabout 10 days ago. The "Find More Extensions" button does not appear in configure. Any ideas? [20:44]
gac410foswiki_irc0 really?? bin/configure, Extensions tab, "Plugin Operations and Maintenance" sub tab, and just a bit down the page, the line: If you have made any changes, consider saving them first. Install, Update and Remove Extensions
The "Install, Update and Remove Extensions" is the button
[20:55]
foswiki_irc0I don't have a "Plugin Operations and Maintenance" tab. I don't have a "Install, Update and Remove Extensions" tab either. I have a "Install and Update Extensions" button at the end of the "Install and update extensions" tab. If I click on the button I get the following: Note: To install extensions, the webserver user has to be able to write files everywhere in your Foswiki installation. Otherwise you may see 'No permissio [21:06]
gac410okay - that's the find more extensions button. [21:07]
.......... (idle for 46mn)
Procopiohi there ...
anyone know anything about javascript?
i need som serious help :(
hi gac410
i have been messing with michaels js for the uploader .... but for someone who never even opened a js file before ... its a very frustrating endeavour :(
[21:53]
........ (idle for 39mn)
dj_segfaultHI. I submitted a bug yesterday. Am I automatically subscribed to that topic so I get email updates? I couldn't find any indication either way. [22:33]
.... (idle for 15mn)
***ChanServ sets mode: +o Babar [22:48]

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