probably misunderstood the commit msg
:-p
luciash: oh, yeah that's a specific page (or rather, place, header.tpl). it seems the fix is similar to what we're doing with tabs. I'm not sure how single quotes in translations are supposed to fit in a single-quoted title attribute value though
it looks like the escape is misplaced, should go after the default just in case. sylvieg?
hi
i wonder if caching can be somehow buggy in 3.2 ?
i have set cache 0 and still the wiki pages get cached by smarty
moreover i don't see any refresh icon on top of my wiki pages... or is this "another" cache ?
i am very puzzled by this :-\
does the smarty templates caching depend on user IP ?
nope, just tried from another IP and it is still cached :(
tikiwiki: 03chealer * r22595 10/trunk/ (3 files in 2 dirs): 
tikiwiki: [ENH] change upcoming_events module to new module style (modules-doc).
tikiwiki: [SEC] proper check for personal calendar owner
tikiwiki: [MOD] limit by future event start date instead of end date
tikiwiki: [FIX] show parsed event descriptions
tikiwiki: [FIX] many undefined Smarty array indices
luciash: cached *by smarty*??
chealer: well, cached in templates_c/
luciash: that's the Smarty templates cache, which of course contains Smarty templates for the Wiki features, but it's not "wiki cache"
even when they shouldn't... i then see first user submitted tracker data in trackerlist on the wiki pages :(
instead of his own
ah, where is the wiki cache stored ?
this sucks... it doesn't happen on one site but does on the other :-/
luciash: in tiki_pages.wiki_cache
chealer: ah, in db, ok
hmm, it seems to have problem with pretty tracker template which has trackerlist plugin using another template... then it becomes compiled in smarty templates cache as static rendered text result instead of tracker fields vars...
but i wonder why not on the first site ? it should be the same 3.2, just one is from SVN and the other from tarball
grmbl, now i see it on the first site too in the compiled templates
but it seems to be properly overwritten when i access the page with another user
tikiwiki: 03chealer * r22596 10/trunk/tiki-user_cached_bookmark.php: [FIX] link to Google cache pointing to actual page (r1030 regression)
tikiwiki: 03chealer * r22597 10/trunk/lib/bookmarks/bookmarklib.php: [FIX] HTML special chars encoding
tikiwiki: 03chealer * r22598 10/trunk/templates/tiki-user_bookmarks.tpl: "Add/Edit a bookmark" instead of "a URL"
tikiwiki: 03chealer * r22599 10/trunk/db/tiki.sql: bump tiki_user_bookmarks_url.name from varchar(30) to varchar(200)
tikiwiki: 03chealer * r22600 10/trunk/ (3 files in 2 dirs): 
tikiwiki: [ENH] change user_bookmarks module to new module style (modules-doc).
tikiwiki: [FIX] HTML special chars encoding
tikiwiki: [FIX] cache links not showing
tikiwiki: a few code readability improvements
 New Forum Posts: Directory categories undeletable - http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=34999
 New Forum Posts: Corrupted Word files - http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=34998
tikiwiki: 03chibaguy * r22601 10/trunk/templates/ (tiki-admin-include-look.tpl tiki-site_header_options.tpl): [FIX] Implemented logo background style in tiki-site_header_options.tpl (was missing); made logo background style examples more clear on Look & Feel admin, and unified examples styles.
tikiwiki: 03chibaguy * r22602 10/trunk/styles/layout/design.css: [FIX] Padding was applied even when there's no logo image, causing position problems when there's only a site title. Logo padding, if needed, should be specified using L&F admin since logo size varies.
polom
poloms also
did other gsosc persons play with google wave?
hi sylvieg - um, think i logged in to the test account, but just tried it this morning and i was invalid or something
i never worked out what it was really
google wave is gsoc specific ?
no but all gsoc members received an invitation - that is almost impossible to have otherwise
ah
sylvieg: through the night i was struggling with pretty trackers again... found out that on one server there is problem with pretty tracker templates which include other pretty tracker while on the other it works fine (both 3.2)
the problem is that the included tracker or trackerlist is being compiled (cached) as rendered and isn't refreshed when other user views it
ahah..... what do you mean call TRACKERLIST in a wiki used as a tempalte?
i think i can workaround it removing the inclusion but was wondering why on one server it works while on the other one it's a significant problem
i mean...
you remember the test we did on SNiPTT ?
there is template for that "user profile"
and inside this one i have trackerlist for the "user posts"
and the "user posts" are causing the problem
it works there fine as we tested
but i have tried to repeat the same on another server and there the problem with caching appears... one doesn't want to see admin posts in every other user profile page ;)
until i clean templates_c
you could be problem with the smarty variable because there are not stacked but accumulated
ah yes
well, now looking at it, the only difference seems to be that on the problematic server i don't specify the fields explicitly for the TRACKERLIST
check that the cache is effectively deleted in lib/smarty_tikireource.wiki.php
as you allowed this enhancement
hmm, how can i check that ?
some echo; die; ?
change if (preg_match("/\{([A-Z0-9_]+) */", $info['data'])) to if (true or preg_match("/\{([A-Z0-9_]+) */", $info['data']))
like this we will know if it is a cache problem
if not it is probably smarty var that are not reset...
ok
tikiwiki: 03jonnybradley * r22603 10/trunk/lib/ajax/autosave.js: [FIX] Autosave missing changed events (doc.ready too early)
changed, the result is the same... user test sees user's luci TRACKER and TRACKERLIST data
(whose are included in another TRACKERLIST template)
tikiwiki: 03jonnybradley * r22604 10/trunk/lib/ajax/autosave.js: [MOD] JS Lint
sylvieg: is it necessary to clear the cache ?
luciash - I do bnot know - I need to try to reproduce your problem on my local
jonnyb: if the textarea is a tracker problem - it is easy -every textare should be in templates/tracker_item_field_input.tpl
well - sort of.... it's actually most of the other textareas that need changing
sylvieg: grmbl, that server is weird... must be mysql character encoding problem there too or something because if i make a change in the wiki page template, save and see the history of changes, not only that little change it shows but also every double quote and every "<" ">" characters are marked as changed and then i get error after tiki cache refresh: Parse error: syntax error, unexpected '&' in .../templates_c/en^%%CA^CAC^CAC0B156%%wiki%3AUser+Profi
i think i have to create fresh db there with mysql encoding (i am not sure what the user created it, maybe latin as he is american)
sylvieg: thanks for help, anyway
tikiwiki: 03jonnybradley * r22605 10/trunk/templates/tiki-objectpermissions.tpl: 
tikiwiki: [FIX] Make it hard to remove all global perms because that would almost always be A Bad Thing
tikiwiki: TODO - Stop admin loosing tiki_p_admin as that's quite hard to fix
hmm, also every & is converted to &amp;
ah, maybe i have to allow html in wiki pages to avoid that
yep, that helps this
tikiwiki: 03jonnybradley * r22606 10/trunk/lib/smarty_tiki/block.textarea.php: [FIX] Only wiki page edit counts changes to anything in the form as a saveable change.
tikiwiki: 03jonnybradley * r22607 10/trunk/templates/tracker_item_field_input.tpl: [FIX] Tracker item text area needs to tell toolbars it's a tracker (so as not to show fullscreen button etc)
tikiwiki: 03jonnybradley * r22608 10/trunk/ (2 files in 2 dirs): [FIX] Part 2 of newsletters textarea fixes.
jonnyb:  tks
:)
could do lots more tidying up in there, but not now...
apparently today is that last time it'll be sunny here for several years (months?) so i'm off out - bbl
sylvieg: having two trackerlist plugins on one wiki page doesn't behave correctly with max param different for each
jonnyb: :)
hi luciash - see you later
tikiwiki: 03sylvieg * r22609 10/trunk/ (5 files in 2 dirs): [FIX]report: unused columnn needs a default
sylvieg: is it possible to display trackerlist data in wiki page for specified user in URL ?
sylvieg: like ...&user=foo
or is it another tracker* plugin ?
not so far I know - no
ah :-/
i hoped it is possible... i know how to display list of current user entries and list all
and using TRACKERFILTER ?
i see there is $_REQUEST['filter']
you can do probably everywhere itemId=xxx
ah, nice, i will try
if it doesn't work i can try to extend exactvalue param to allow user by request
but for itemId i need to know the number user registred with the tracker item :-(
i will try with filterfield and exactvalue
tikiwiki: 03sylvieg * r22610 10/trunk/ (3 files in 3 dirs): [FIX]daily report: show also wiki file attachement
Daily report: is there something about cron job?
tikiwiki: 03sylvieg * r22611 10/trunk/lib/notifications/notificationemaillib.php: oops
tikiwiki: 03jonnybradley * r22612 10/trunk/lib/setup/last_update.php: [FIX] Last update time fix (had a line feed char after the date int)
any idea what's wrong there ? → http://paste-it.net/public/na1e240/
i get Fatal error: [] operator not supported for strings in /.../tiki-3.2/lib/wiki-plugins/wikiplugin_trackerlist.php on line 467
line 467 == line 3 in the code snippet
it happens only when i have &tr_user=foo in URL
i can't get it :( later maybe i will be more clever :-p
or try to solve, and get Czech beer
heheh
what does that '1%' mean btw ?
$f = $trklib->get_field_id_from_type($trackerId, 'u', '1%')
1% means that it looks for a field which option begins by 1
tikiwiki: 03pkdille * r22613 10/trunk/styles/layout/layout.css: [FIX] wiki table of content: no bullets or style for the lists in the toc context
in case of 'u' type, means auto-assign
tikiwiki: 03pkdille * r22614 10/branches/proposed/styles/coelesce.css: [partial bp/r22613][FIX] wiki table of content: no bullets or style for the lists in the toc context
ah, thanks mose... what i try is to add support in TRACKERLIST to get items of exact user by request... i just changed what's on line 486 in trunk wikiplugin_trackerlist.php
well, that part which begins there
i wonder why it fails on the line 488 then
and, sorry, correction: line 467 == line 488 in trunk == line 3 in the code snippet
I am a newbie here, but desparate to solve a <Find>  problem show-stopper. Is it appropriate to ask a question?
hi Larryg, o'course
tnx. Website: http://n1mm.hamdocs.com   Working mostly OK; but Find is very weird. Find ( the, box, or edit ) succeeds. Find ( run, key, band ) fails. A week's experimentation suggests that a tiki_pages table larger than 1.0MB is the problem. Is that possible?
Certainly there are tikiwiki deployments larger than mine where Find still works... Shrinking the db only masks an underlying issue? How to troubleshoot this thing?
maybe, check your server logs what it says there... maybe low memory or execution time
Tried increasing both MEM and TIMEOUT in config.php with no affect; and this ISP does not let me see my server error logs (ARGHHH!!) In a sense, I am flying blind if it is a server-side problem. 
sorry - = php.ini
also it might be that server uses apache security mod... but i wonder if the word "band" would be filtered
The words that fail are popular words in this hobby/documentation: entry, space, radio, contest, frequency. Uncommon words seem to succeed.
i see, it looks like there's some limit... i think mysql have also some which can be set in my.cnf or something
tikiwiki: 03jonnybradley * r22615 10/trunk/lib/wiki-plugins/wikiplugin_img.php: 
tikiwiki: [FIX] Filegal thumbnails now set size in html correctly.
tikiwiki: Also a couple of notices and globals fixed.
polom
tikiwiki: 03luciash * r22616 10/trunk/styles/layout/design.css: [ENH] don't indent and display bullets for unordered lists in remark boxes when items have even or odd class
Well, I think the scenario is walking through the woods.  One response would be an arrow with a message tied to it.  So I suppose >>---POLOM->
SEWilco2: hahah
luciash: I saw you did a nice comment on a wiki page somewhere, which looked like a quote but was in fact remarksbox.  Can we have that look for quote plugin?
marclaporte: hm, you mean info.tw.o quote on top right or something else ?
top left, err
:)
err, no..  but that one is nice too
lemme find
and h1, h2, h3, could use some styling
luciash : http://dev.tikiwiki.org/Zend+Framework&highlight=remarksbox  -> this is much nice than current quotes
h1, h2, h3 -> look here http://www.open-organizations.org/view/Main/IntroToOpenOrg
h1 has different styling that h2, and makes the document so much nicer, just with a little styling
ok
i see
http://tikiwiki.org/Model  -> this page is semantically ok.  but looks ugly, and squished
we can style quote plugin better
with nice quote like you made, and nice css headers, the page would both semantically good and nice looking :-)
tikiwiki: 03luciash * r22617 10/trunk/styles/layout/design.css: ul list in remarksbox... better like this
tikiwiki: 03luciash * r22618 10/trunk/styles/layout/design.css: oops, forgot .wikitext class selector
lucish I have no problem with different max for a list of TRACKERLIST in a page..
tikiwiki: 03jonnybradley * r22619 10/trunk/lib/smarty_tiki/function.debugger.php: [FIX] Typo and missing var
tikiwiki: 03jonnybradley * r22620 10/trunk/lib/smarty_tiki/function.debugger.php: [MOD] Extra $Id: removed
tikiwiki: 03jonnybradley * r22621 10/trunk/ (3 files in 2 dirs): [FIX] Correctly position help dialog where it was left - added a link to the plugins help to make it more obvious, a couple of comments and plugins filter
tikiwiki: 03jonnybradley * r22622 10/trunk/: [SVN] Ignore .lastup and last.log
sylvieg: oh, really ? hm, must be my filtering then...
tikiwiki: 03jonnybradley * r22623 10/trunk/tiki-objectpermissions.php: 
tikiwiki: [FIX] Show other features if using 'select features' when editing single object perms.
tikiwiki: This allows you to edit comment perms on a wiki page, for instance.
polom
hi chealer 
tikiwiki: 03sylvieg * r22624 10/trunk/ (2 files in 2 dirs): [FIX]categ: do not assign a nul category to object without category (is_null(false) is false in php)
sylvieg: thank you
sylvieg: regarding your mail, is 22624 supposed to be the regression or the fix?
chealer - I do not know exactly when it happens - I only know that in my tiki3 bases I have no categId=0 in the tiki_category_objects
perhaps it is adodb /pdo...
tikiwiki: 03nyloth * r22625 10/branches/3.0/ (. tiki-setup_base.php): 
tikiwiki: [QT] Quality Team Backport
tikiwiki: r22485 | Jyhem | 2009-10-20 18:30:41 +0200 (mar. 20 oct. 2009) | 1 line
tikiwiki: [FIX] parentId=-1 needs to be allowed otherwise only admin can create a new root file gallery (trunk #22484)
sylvieg: sounds more like a lazy mode MySQL issue. the fix looks good but it's not clear why this problem would have just appeared. perhaps we have a new or modified call to update_object_categories().
tikiwiki: 03nyloth * r22626 10/branches/3.0/ (. templates/modules/mod-articles.tpl): 
tikiwiki: [QT] Quality Team Backport
tikiwiki: r22455 | eromneg | 2009-10-20 15:50:56 +0200 (mar. 20 oct. 2009) | 1 line
tikiwiki: [MOD]Allow the use of a new parameter (showpubl=>y/n) to show the publishDate - to be used as an alternative to showcreated=>y/n: trunk commit #22372
It will take so much time to find why it happens now .. as the code whatever is cleaner now - I prefer to spend time to fix other bug in trunk
right. thanks again
tikiwiki: 03nyloth * r22627 10/branches/3.0/ (3 files in 2 dirs): 
tikiwiki: [QT] Quality Team Backport
tikiwiki: r22452 | eromneg | 2009-10-20 15:26:04 +0200 (mar. 20 oct. 2009) | 2 lines
tikiwiki: [FIX] podcast directory reference re: bug report #2377 and trunk commit #22378
chealer - do not forget to do a script for your commit 22599
sylvieg: I don't care about it that much, I'm fine if new installs have a better length. I don't know if varchars fields can be lengthened trivially, if so it might be worth a schema script. of course, anyone should feel free to also change it for old installs.
the rule is db schema new install == db schema upgrade - otherwise it will be impossible to maintain
i'm fairly certain extending varchars is ok - and one day there should be a script to compare the two, chealer 
alter tiki_user_bookmarks_url modify `name` varchar(200) default NULL;
we did the same type of modification sometimes ago for the user (because user was 30 or 100 or 200....)
#1064 - 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 'tiki_user_bookmarks_url modify `name` varchar(200) default NULL' at line 1.
alter table `tiki_user_bookmarks_urls` modify `name` varchar(200) default NULL
tikiwiki: 03chealer * r22628 10/trunk/installer/schema/20091023_bookmarks_name_lengthen_tiki.sql: [FIX] add a schema script for r22599. it seems there's a rule to keep database schemas identical. oops, thanks Sylvie
perhaps it's time I read about Tiki rule
wow
"Prefer to use only tabs for indentation for a new file. "
lphuberdeau had told me the convention was spaces. I just knew that couldn't be true :)
"Merges should be done frequently from branch to Trunk" -> doesn't that depend on the branch?
uh, Zend coding standards cover line length :!
off now - but i've been wondering about the tabs rule (still my personal preference but less robust)
what's the zend line length?
80 is too small IMO, I can fit over 205 on my screen. but I'm just amazed by a line length policy, whatever the limit would be. I feel like I'm reading RFC 2822.
molop
why would tabs be less robust (jonnyb)?
if no opposition, I'm removing "Merges should be done frequently from branch to Trunk"
why?
I oppose
we discuss the tab / space so amny times :-(
it was tab since the beginning - not exactly since teedog summer - I do not remember
then the zend that is space... and again...
sylvieg: so doesn't that policy depend on the branch?
sylvieg: because it doesn't make sense to me
why?
sylvieg: I think it would be better to approach it on the other side; what does that policy improve?
it is not improve is about not introduce chaos
all the files - except lib were tabs... this famous summer
sylvieg: and how does not merging branches regularly create chaos?
merge space and tab -> create conflict
trust me on this one
sylvieg: no doubt, but I'm not questioning the indentation policy, I'm questioning the "Merges should be done frequently from branch to Trunk" policy
because otherwise people develop diffrent stuff and merge is hard
merging each commit will be the best
but when you solve conflicts resulting on 10 commits - it takes a while
if svn had a better merging soft - I will not care
but it is not the case
svn merge = cvs merge - almost the same number of conflicts
I would like the policy to cherry picking - as nyloth is doing when backporting to 3'
but it is  A LOT of work
in an ideal world merging will not be used - but only commit one by one - as svn allows 'logical' commits
but .. too much work
sylvieg: what do you mean by "I would like the policy to cherry picking"?
global merge is painful because not preserving history - what I do with a log fill of 'Automatic merge'
chealer : if you do not agree with the merge sentence - and rol back your change - I think we have to start a devel post
sylvieg: I agree that big merges are difficult with svn, and that merges don't preserve history, but still I can't make sense of the policy.
sylvieg: if merging each commit was possible, there would be no branch to start with
merging each comit indivudually is for log reason
perhaps the merge often must only address the latest release / trunk
if it is why you mean
- I rellauy do not care coe_experimental or whatever is sync
sylvieg: OK, then I see the point of merging commits individually - but not *frequently*
sylvieg: we could tell people to merge branches to trunk branch commit by branch commit, but I don't think that's realistic with our tools
if I can do individually easily then ok but we have no tol to do merge individually
so back to merge frequently
I think you get it - the 'principle ' is there because we do not have the tool
sylvieg: well then I'm back on my opinion that merging frequently doesn't make sense. do you have an example of a branch that should be merged frequently?
branch 4 ->trunk when there will there
it is the only merge that is crucial
sylvieg: branch 4 won't be merged to trunk. all commits to branch 4 will be backports from trunk, except if the bug does not affect trunk anymore, which means there will be no need to merge to trunk anyway.
if feature freeze is true - 4->trunk will be ncessary
sylvieg: well then, do you have an example of a commit that would need merging from branch 4 to trunk?
bug fix 
sylvieg: as I wrote, bug fixes on branch 4 will be trunk backports, so they won't be merged to trunk.
all the meesy stuff - happens between feature freeze and release
hehehe
i do not like changing and changing again
s/the/that/
I was not active when the first decision was taken
emacs can do the 4 spaces tab or tab with no pb
me neither, but if we'd be using spaces, I'd be for switching to tabs (but only if it could be done automatically everywhere, of course)
we are not switching to tab - we are switching to space??? perhaps???
almost all the code except the ;ib are tabs
if we aer using space - tell me one line in the doc that says how many spaces is the identation
I do not refer to Zend that is a new addition
sylvieg: no, I was talking in the conditional (though bad French translation, should have written "if we were using spaces, I would be for switching to tabs"
sylvieg: what do you mean, "we are switching to space???"? is there anything which indicates we could be doing that?
we are not using space currently
sylvieg: well, in *theory*, anyway :)