Please How to clear tiki caches when we can't access GUI (http commands) (I suppose that html commands into a site subtitle which was accepted in 3.2... crashes 6.2 not filtered by import). I am not sure but it is on this string that the xdebug trac stops and goes to erratic behaviour (smarty); I changed it into database but it is recalled from a cache. polom Trebly, empty the directory /templates_c, to clear the Smarty cache. ...using FTP, etc. Ok I have often done to force compilation but when they are data's (string in prefs that I have cleaned), where is the link ? Trebly, I'm sorry, but I'm not sure what you are trying to do. I got data from tiki 3.2 (sql import and treated by the actual import of existing data 3.2->6.2), with strings for titles subtitles containing html tags which are no more accepted by 6.2. I changed them into database directly (easy to do, quicker) but the soft goes on displaying old values (verified by var_dump, because of the crash) I was thinking that was generating a curious behavior and a crash, from two minutes I found an UTF8 problem. I know exactly what to do for this. But I goes on because I do think that It is useful to know why data changed into data base can not change into the displays. For apps installation and debug it is essential when the problem comes from invalid data (not well filtered). I have forgotten how to reinit admin password. After data import and utf8 conversion all pass are rejected I have not to do the last six month I forgot it OK solved. wrote SQL request "Admin-reset.sql" Hi, do you know why with the same modules and content 7.x needs three time more CPU work to generate the page than 6.2 ? polom chibaguy: ping hi marclaporte chibaguy : how are you guys doing? we're doing fine. the real trouble is a little north of here. We get aftershocks that are medium-size but no damage. Transportation is getting back to normal. Some rolling blackouts to conserve electricity. marclaporte, I've got the Canada clf theme pretty much ready and will send you the files in the next day or so. rolling blackouts must disrupt industries.... I'm not sure how industries are affected so far, outside of the earthquake/tsunami area. I know some like semi-conductors can't really start up again until the electricity runs consistently, can't stop and go easily. I see. Mostly I see reduced hours, reduced lighting, escalators turned off, that kind of thing, to reduce consumption so maybe avoid blackouts. So far we haven't been affected much, blackouts get scheduled but then cancelled because electric production could cover use. Good news for CLF. I will shortly give a presentation to some folks of Canadian federal governement They say summertime will be hard, due to people wanting to use air conditioning. OK, I'll try to send the files this evening my time. chibaguy : I put this to 6.x proposals? http://gcca.ourwiki.net/ or 7.x ? It's now a 2.2 (yuk) For the CLF theme? I developed it on Tiki 6 as I thought that's the version that would be used. It'd be pretty easy to add a Tiki 7 version, though. 6 is good site is now 6.x proposals, ready for your files :-) marclaporte: ok :-) poloms of the north scotland ? polom from the middle hi luciash - the last bit of England just before Scotland getting coffee - brb :) coffee is a good idea polom hi chibaguy how's it going? hi jonnyb. things are ok. still fairly frequent shaking, but not bad around here. i saw a documentary last night about it all - frightening! (i missed most of the news at the time as i was travelling & 'festing) yeah, devastating in the Tohoku region. hi y'all hi ricks99 New Forum Posts: No apply profile - http://tiki.org/tiki-view_forum_thread.php?forumId=2&comments_parentId=40922 New Forum Posts: Where does HomePage come from? - http://tiki.org/tiki-view_forum_thread.php?forumId=3&comments_parentId=40918 New Forum Posts: 6.2 runaway process on tiki-home.php and CPU usage - http://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=40916 Recent Bug: Tracker item: #3835 - - Plugin to display the toc of a selected page. - http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=3835 Recent Bug: Tracker item: #3837 - - Out of memory bug in tikidate-php5.php - http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=3837 jonnyb, pascal (pkdille) asked me about empty selectors in the CSS files (element or class with no properties), and if they should be removed. I had left them in as a kind of reference ('these exist and could be useful') but don't know if it's good practice really. What do you think? hmmm - a fair question with good DOM inspectors now they seem less useful than in the old days i guess i wonder if they get stripped out by the minifier? I don't know. I guess we could have a wiki page that lists all the known/useful css rules. Except that's something else to maintain/become out of date. indeed - and the DOM in the browser is really the only thing that counts... i need to feed - back later Got an issue with a Tiki of mine: toolbars do show for event editing but there is no action. Ideas? Al markup looks like present in Firebug. could it be hidden by CSS? don't the toolbar buttons require/use JS? any JS errors? Q: in tiki 6: in the file gallery, you can specify default such as %description% to be added when selecting the image from the file gallery. is there a way to not include if it is empty? no, the toolbar is there and some buttons "work" as in "showing colors" for example, but not applying them to the text in calendar. edit jonnyb, got any reports on breakages in trackers that need fixing? hi lphuberdeau - in fact, yes... thought so on Geoff's event management prototype site I didn't get so much time to follow-up on reported issues lots of nested pretty tracker stuff where would that be? he mailed me the other day - as i helped set it up in the first place i'll do another reply and copy you ok lphuberdeau - mail sent (to your tiki.org addy) i have to go out for a couple of hours - bbl thanks, I will look into it today thanks, will join in when i get back unless you've fixed everything by then! :D tikiwiki: 03nkoth * r33682 10/branches/proposals/6.x/lib/tree/ (categ_admin_tree.php categ_picker_tree.php): [FIX] Fix missing starting LI tag in category picker due to bug introduced in r31198. (these files are no longer in trunk/tiki 7) tikiwiki: 03lphuberdeau * r33683 10/branches/7.x/lib/core/Tracker/Field/Abstract.php: [FIX] When exporting tracker items, the values should not be rendered as an HTML link I have with 7.x for, quite all, my test three time more CPU needs to show a page than with 6.2. Is it something verified or must I search a problem ? Following what way ? I just ran spot check profiling on some basic test site using 7.x and I do not see anything out of the ordinary in the normal execution paths there may be an issue with one of the modules you are using or some other feature the only real way to find the issue is to profile the execution and see where time is consumed The xdebug PHP extension can generate the cachegrind profiles and those can be analysed with KCacheGrind on linux tikiwiki: 03lphuberdeau * r33684 10/branches/7.x/lib/tikilib.php: [ENH] Cache flag lists to avoid scanning the disk so much and performing multiple translations jonnyb: hi, was it you that did refactoring of js/toolbars before Tiki 6 release? I have a problem (in IE only) where the insert wiki link toolbar does not capture the highlighted text anymore (it worked in Tiki 5), and am trying to find the diff, but both toolbarslib.php and tiki-js.js changed quite a bit... hi nkoth - coincidentally just looking at one of yours :P http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki?view=revision&revision=33682 anyway - i don't recall doing refactoring but i know there are issues with IE (in trunk/7 too) right - the category picker got all messed up in tiki 6 where there is a flipper because of r31198 yes, but i thought i fixed it already in r 33617 (for categ_picker_tree.php anyway) was just trying to check... looks to me like the

would be getting opened twice now (just from reading the diffs) ok, checking (because I don't actually run proposed only 6.x) that might explain it ;) ok, looks like a double fix then anyway - the IE textarea selection stuff - there were some fixes i did for Marc than need backporting to 6.x, but still don't work perfectly, i guess i should attend to that now jonnyb: can I roll back your fix? I think mine is better checking - my fix had some styling stuff in it too I think the tyling stuff can stay ok agreed, i'll do it... ok nkoth: by the way, got distracted by your r33660 - it needs php 5.2.3 i'm afraid according to http://uk.php.net/manual/en/function.htmlentities.php yes, I rolled that back already 6.x is 5.1 up oh, jolly good - the diff here didn't spot that r33660 yes, my bad - back to aptana and the diffs show up on the opposite sides to netbeans :P tikiwiki: 03jonnybradley * r33685 10/branches/proposals/6.x/ (lib/tree/categ_picker_tree.php styles/layout/layout.css): [FIX] Rollback r33617 - nkoth's fix in r33682 is better and the styling differences were trivial. bbl tikiwiki: 03lphuberdeau * r33686 10/branches/7.x/ (5 files in 4 dirs): [FIX] Fail gracefully when incremental update fails due to permission issues (when re-indexed from the command line and rights are not set correctly afterwards) tikiwiki: 03lphuberdeau * r33687 10/branches/7.x/lib/ (queuelib.php search/searchlib-unified.php): [FIX] Clear the pending incremental queue before rebuilding the index to avoid re-indexing the same objects again once completed nkoth: back again - the IE selection issues are tricky as trunk has diverged from 6.x quite a bit - in http://tikiwiki.svn.sourceforge.net/tikiwiki/?rev=33256&view=rev i made quite a big change to the $.selection function - do you think this should be backported? (not easy) jonnyb: I've traced the IE selection problem to "document.selection.createrange().text" beong nothing. It's almost as if the selection disappears before the user opens the dialog. I do an alert(document.selection.createRange().text) right on the open function and it is still blank. Any hunches? yes, IE clears the selection as the dialog opens anyway to avoid that? It was ok in tiki 5 in trunk in r33143 i added a fix to store it before ok I will look for it but i'm not convinced it really works on all IE's in trunk still... i only have IE 7 here (on laptop) but will also test i have ie8 Marc suggested i keep a "real" IE7 install here for testing... as IE8 in IE7 mode acts differently (it's _such_ fun!) ha-ha jonnyb: its not working for me when i backport it is the underlying reason some changes with jquery? because it works with Tiki 5.... and I'm wondering why it might have been some of the firefox workarounds that were removed for 6 as that seemed to be fixed maybe IE was using them too ok, let me try putting some of that back fo nkoth: plugin edit in IE7 in trunk seems ok here what about from the toolbar? yup, seems ok but running windows on this machine makes it practically unusable let me chear cache ah, ok - no - with no selection i get an error was checking with selection... hmmm - stuff still inserted at the wrong point i seem to be getting an error in handlePluginFieldsHierarchy() when clicking the file icon looks like it's paramValues.parent which IE thinks is a window, not an array element - bad choice of var name i think jonnyb: any reason why if I click on the wiki link icon it doesn't seem to call popupPluginForm, , but the file icon does? which branch? 6.x maybe it's not using jquery ui should be well, it's not calling the old function in tiki-js.js anyway oh i see, the dialogs don't use that? no, that should go one day (when jquery-ui is always on) i found one IE problem - fix on it's way... do we overide the open handler in jquery at all? tikiwiki: 03jonnybradley * r33688 10/branches/7.x/lib/jquery_tiki/tiki-jquery.js: [FIX] IE didn't like the object "parent" being reassigned, so declare (and use) a var. Also convert $.find() call to context selector. open? i don't think so - like window.open you mean? dialog.open I am think of, but I think I am just getting really confused here easily done :P the bug in handlePluginFieldsHierarchy seems to be in 6.x too so merging then will backport... btw your latest commit, why var $parent and not var parent? should fix the plugin form non-appearance things becasue parent is a keyworkd ok also i like having $ at the start of vars containing jquery objects - makes it a bit easier to read imho so you can see they're "special" one question: does all this changes only affect plugin edit or do they affect toolbar icons like the "color" and the "Wiki Link"? no, just plugins then how do we solve the problem for "Color and wiki link? getting there... ok (because I am at a total loss there) tikiwiki: 03jonnybradley * r33689 10/branches/proposals/6.x/lib/jquery_tiki/tiki-jquery.js: [bp/r33688][FIX] IE didn't like the object "parent" being reassigned, so declare (and use) a var. Also convert $.find() call to context selector. jonnyb, still around? yup seem to have got sidetracked into some horrid IE stuff (been putting it off!) having fun? tikiwiki: 03jonnybradley * r33690 10/trunk/ (16 files in 12 dirs): [MRG] Automatic merge, branches/7.x 33666 to 33688 looking into the pretty tracker thing I don't really know what I am expecting nor how pretty trackers are supposed to work really yes, they're a mystic and strange place but it seems like smarty mangles with the template while compiling stripping out part of the wiki modules expected as output adding {literal} blocks seem to fix most of that part of the equation the nyloth commit stopping them working in trunk was rolled back by luciash before 7.x curious - it didn't use to however, the {$f_xx} variables it attempts to access seem to all be empty (that might be new) could be - i added a little function in parse_data around tiki 5 that tries to set them but really... pretty trackers should have used a different smarty delimiter, like used in jq also a flag to try and detect when you're in a nested template i didn't write pretty trackers! :P they should be top of the list for replacement with {list} in 8 I know but i don't think there's anything fundamental we did to trackers that should mean they're irrepairable need a refill - brb (it's beer o'clock here) polom ok, fixed part of the issue still does not quite work though tikiwiki: 03lphuberdeau * r33691 10/branches/7.x/templates/tracker_pretty_item.tpl: [FIX] Field not sent correctly to trackeroutput lphuberdeau: do you think we could de-smarty that template? i've been meaning to for ages but never dared when the rest was such a mess polom chealer pretty item one? i think so - there's one that's only about a page long and really should be in php Might do it, but will have to wait until the whole issue is fixed on geoff's test site when I add the literal bits, I get correct wiki syntax formatting, but then the plugins don't seem to execute at all jonnyb: I will wait for your backport to proposed of all the jquery fixes then I will try them all at one shot. ok? I mean selection fixes ok nkoth - still battling with actually running IE at all here lphuberdeau: yes, agreed - repair first then refactor of course hmmm got it :D pretty sure that did not work before the refactoring it's most likely related to the plugin parser switch and no one bothered to report/fix any of that before branching, of course btw guys - perhaps one of the problem with pretty is that they use a smarty ressource - perhaps there is a way to use output filter? no, the issue is that the plugin parsing happens at the wrong moment and the pretty tracker output is enclosed in an ~np~ block then there is the confusion about showing or not showing links, which is highly context dependent apparently and {$f43} does not provide enough information to know {$f_43} must behave like in travker vire item it is the same problem than to be able to express an input or an ouput in a pretty tracker - the syntax {$f_43} is not enough powerful well, I'm in pretty trackers now, so that is the issue tikiwiki: 03lphuberdeau * r33692 10/branches/7.x/templates/tracker_pretty_item.tpl: [FIX] Don't display links in pretty tracker output only fix I didn't commit yet is this one: but pretty tracker is nothing lese that a loop on assign and a parse... +++ lib/wiki-plugins/wikiplugin_trackerlist.php (working copy) @@ -1522,7 +1522,7 @@ $smarty->force_compile = $save_fc; // presumably will be false but put it back anyway } - return "~np~".$str."~/np~"; + return $str; } with that, it all seems to work to the best of my knowledge, but I really can't say if it's the correct behaviors all hacks depend on ... strange this behavior changed.... if it's what works for you lphuberdeau then give it a go - as oyu say, no one else seems to be using them in trunk or 7 maybe it's related to the plugin parsing if set to type html will not parse change tikiwiki: 03lphuberdeau * r33693 10/branches/7.x/lib/wiki-plugins/wikiplugin_trackerlist.php: [FIX] Execute the output of the template through the plugin parsing - if not happy with this, add ~np~ in your template anyway if it works in 7 without the np that makes more sense nkoth: in 7.x on IE7 i'm getting even bold etc not working reliably - is ok for you on IE8? will check... and it seems to vary depending on the content of the textarea hi marclaporte - how you doing? better good good i fixed the plugin dialog failing in IE thing, but much of the rest of the toolbars/selection stuff seems to have got worse again :( ewll, blold does not work for me wven in firefox same for color really - versions? tiki 7 Firefox 3.6.16 on Mac the selection becomes "text" grim oh right - you have codemirror on? ye nothing much works with that ok, i turn that off i don't have time to fix it so i'll be moved to experimental before release unless it gets lots better quickly hmm in firefox, if I select teh entire line the ending __ for bold ends up on the next line maybe not maybe user error hmm, going to have to re-re-revisit this another time again - need a break & food etc ok let me try IE8 currently IE is selecting exactly 2 chars to the left of the real selection, but only on some lines and i can't work out a pattern right I noticed that in tiki 6 too, i have one more commit here which improves the logic (converting between windows and real-world line-ends) in ie8, at first i thought it was my mouse but... well, things re looking better tikiwiki: 03jonnybradley * r33694 10/branches/7.x/lib/tiki-js.js: [FIX] IE selection again - better logic for calculating offset of selection due to extra line-end chars inside IE's textarea object (compared to the jQuery val) but there are still some quirks i think continue later miht be a good idea definitely (both) it seem to lose the last 2 characters near the end of the line wiki link works ok (if you select a bit where bold also works ok) the trouble is it's not always 2 chars - it seems to depend on the text preceding it i also seem to have ruled out wrapping long lines anyway - you may find something i've missed - sort of going blind on this! back later... Weird behavior on a TRACKERLIST: check this: http://tiki.socius.be/tiki-index.php?page=Organisaties&trackerId=7&tr_offset=9 URLs are correct but clicking doesn't work. Weird Anybody having had this issue? try restarting firefox, those links seem to work fine for me Wow, they don't here... FFX 3.6 Links are fine as URLs but they when I click, there is no update of the page. Chrome same story tried a link in each column, they all point somewhere pointing yes, but clicking doesn't give any effect. Type page 4 of X This old sample works: http://code-postal-facile.be/wiki/tiki-index.php?page=Rechercher%20par%20Code%20Postal&refresh=1&tr_initial=g&tr_sort_mode=lastModif_asc&tr_offset=0 yes, clicking works mmmh yeah clicking on "items" work. But pagination links at the bottom or letters at the top? IE8, FFX, Chrome: pagination doesn't work. Weird. Weird. HTML is okay. Links open with "open in new tab", but not in the current window.... Aarrrgh http://tiki.socius.be/tiki-index.php?page=Organisaties right those pagination links seem broken must be some JS catching the click event or some div being on top of it New Forum Posts: Trackerlist: Merging columns - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=40929 where to look? div on top, I couldn't open in new tab I think. JS, how to see which script is hooked there? Firebug doesn't help me (moron me) I don't have tools to figure that out either Geez I am in for a while... Thx anyway. I think there is a firebug extensionthat does it but I never tried it JS-crap I fear... JavaScrapt it's not really javascript, every event-based UI in the world could cause issues like that well, yeah. Excuse my french tikiwiki: 03chealer * r33695 10/branches/proposals/6.x/lib/setup/js_detect.php: [FIX] date seems unreliable before PHP 5.2, check for that instead of just the date extension (ref: r33679) This: http://www.sprymedia.co.uk/article/Visual+Event was key in finding out. There is a jquery with disable default behavior and... doing a submit. Which doesn't work. Damn .trackerfilter_result form New Forum Posts: Remove Underline button in wiki editor - http://tiki.org/tiki-view_forum_thread.php?forumId=3&comments_parentId=40932 New Forum Posts: Pretty tracker: How to hide empty fields - conditional display - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=40930 I guess I am using an old {pagination_links} code... good night! Thank's for your answer, I forget to set me away... The problem is that I run with windows and I have nothing to analyse the xdebug cachegrind. Sorry Kcachegrind is available for windows with xdebug 2 Plugin supported by KDE and KDE windows version (an RC windows from stable linux)