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 & 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 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 :)