New Forum Posts: New user... Needs advice/help. - http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=38016 New Forum Posts: [solved] calendar module + tiki_p_view_calendar for anonymous = blank page - http://tikiwiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=38013 Hi. Is there any kind of limitation for the length of title? Or something about using non-latin characters? (when I go throug the categories page, the links seem to be shortened a bit, which doesn't let me actually open the page, going through, for example, search, or through structures seems to work ok) polom morning someone needs to change welcome message for this channel New Forum Posts: Can't assign menu to users + Rename url's - http://tikiwiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=38020 hi! hi j0n3 polom noon as always (fighting with trackers): I have #1 "Departments" and #2 "Instructions for departments" tracker. On #2 I have item link with #1 (or null = All departments) seems all the tw.o sites are down :( using a template with a trackerlist to show #1, shows empty (non asigned instructions) well when viewing wiki page, but shows nothing when viewing tracker item can I show trackerlist plugin on a template used to show tracker items? j0n3: you mean when there's &itemId=42 the page is empty? no when viewing template as wiki page (no item viewing), trackerlist shows all non asigned Instructions well, but when viewing tracker item shows an empty list {TRACKERLIST(trackerId="19",filterfield=119, test=0)}{TRACKERLIST} I'm doing it wrong :S what is the test parameter? and if you have a filterfield you must have a filtervalue or exactvalue well, it works on viewing template but not on tracker item {TRACKERLIST(trackerId="19",filterfield="119",exactvalue="")}{TRACKERLIST} it works the same: non asigned shown viewing template, and nothing viewing tracker item are you doing recurring trackerlist? with pretty tracker? no well pretty tracker = wiki page as template for tracker item view? so yes (no smarty tpl) if you are not doing nested trackerlist the wiki/templates should not contain TRACKERLIST on;y the original page the template should contains {$f_xxx} etc... i want to add a fixed tracker list.. static filtered it should only show all items from an external tracker with a null field As a curiosity, is it possible to use X.509 certificates for authenication, and LDAP backend for authorisation purposes? (presumably using something like apache mod_ssl to authenticate users) if you are doing nested trackerlist - goto to see the devel list about that - seems it does not always work hi JoernOtt tikiwiki: 03Jyhem * r28399 10/trunk/templates/blog_footer.tpl: [FIX] Close a tag for all cases JoernOtt: I was just updating and see your new random page include plugin - did you consider adding the randomness as an option to the existing include plugin? The random option would make the other options of the include plugin worthless for example start/stop markers might be different in each page i was wondering about that so I thought, it might be more clear to end users to have two different plugins yes, a tricky call - glad you had considered it (thought you would have) instead of specifying a parameter which will be either ignored or overrides the others just trying to keep the options down to stop people's heads exploding when they first see the list! :) understandable you did the new stuff in the quick edit module too recently, didn't you? Carsten was looking at the list pages thingie for randomnes as well but I believe adding a param there would be obscuring when someone is looking for "random" yes Carsten|coaboa and his people are paying me for a lot of things they wanted :-) i have meant to KIL that one - i refactored all the code into mod-func-search for tiki 5(it does what quick-edit, search-box and search_wiki_page did) unfortunately i never got round to the db update script to switch everyone's modules to use the same new one... oops! and by the look of the code now, quick edit probably should now stay it's own stand-alone thing (before it was very simple) their idea was to allow a quick copy/paste from for example a text processor which will be appended to an existing page or becomes the content of the newly created page + set a category and set the description to make it easy for people to contribute to the wiki sounds good, that's always a sticking point for wikis on another topic... sylvieg: (or anyone else maybe) - i'm doing this $jq to $ replacement, should i do the language files too, or not? how uptodate is the dev site concerning this As I am ajaxifying ther "Share this", I don't want to follow old xajax stuff if its going to be deprecated xajax isn't going to be deprecated is it? (afaik) ok what needs adding is a clean way to do ajax in modules there was a discussion on that on the dev list and plugins... yes, i faced that with an internal application as well yes, xajax is over complicated but it does work - change links in tpls to {self_link}s and the page automatically uses ajax jonnyb: ??? mind you, share this doesn't really use the tiki does it? it posts via JS to the shar.es server i thought hi sylvieg i'm doing this $jq to $ replacement, should i do the language files too, or not? sorry I do n ot understand don't they get updated automatically via get_strings i just remember there were issues about global text replacement in lang files - maybe not why are you changing $jq to $ because that's the standard for jQuery if ther is some $jq in lang yes you must change because the translated part must change we just used $jq for a while becasue mootools were there first i've had two plugins not work properly due to this, and i'm pretty certain it was agreed at a fest (new york i think) that we should do this change really? $jq easier to read? (i tohught i'd just got used to it like that!) is $ the default then? the rest of the jQuery world uses just $ yup ok, then we should change as well so all examples and libs use just $ i think we'll get used to it... because it makes it easier to adapt to it integrating third party stuff is far easier when sticking to the same rules i've done the search/replace locally, so have it ready to commit - but it might be messy to roll it back afterwards that's what i thought JoernOtt in fact this new one brosho reports an error about $ hi everyone hi RavenC 5.1 !! I can't keep up! Grats to all! :) that's a point - how do we change the message here? it still says *News!* Tiki 5.0 etc sylvieg: as op you should be able to do that if somebody knows the syntax set topic #tikiwiki foo also, need to remove 4.3 reference I have unknown command yay sylvieg! *clap* agree with JoernOtt: stay mainstream in conventions unless a major reason to break those comes up. What's about a sourcecode documentation tool which allows t write docs while commenting the source edits? *t/to Jeorn mentioned phpdoc (right?) hi coaboa - yes, phpdoc is used in tiki (occasionally) by the way... big $jq coming in - take cover! brb tikiwiki: 03jonnybradley * r28400 10/trunk/ (144 files in 57 dirs): tikiwiki: [MOD] Big commit, with (hopefully) no functional effect. tikiwiki: Replace $jq with the jQuery standard $ as reference for the jQuery object. tikiwiki: You will almost certainly need to clear your tiki and browser caches to clear out transitory JS errors. with tw6 being the lts, is there going to be much else going on with 5.x until then? hi RavenC - not by me. i'm flat out on stuff for 6 personally me personal tryed to avoid th usage of 5.x as the utf8 problem seemed not to be resolved prior its release. Only used 5.x for test sites. *the i wouldn't expect a 5.2 (maybe a 5.1.1 if we can fix this wiki attachment bug) ok, that is kind of what I thought. Iis there any pre-pre-pre alphas for 6 yet? ;) trunk :D as no one else seems to be volunteering i'll have a go at being release mangler for 6.0, and i'd like to leave the branching to 6.x late but brutal (e.g. i'll rollback non-genuine fixes) in the meantime it would be nice if we can be very careful with trunk, so as many people can be testing already (he says, having just globally search and replaced a var name over a hundred files!) but now is the right time, another month until freeze and already many people testing means a good chance of spotting errors before freeze that's what i'm hoping too - thanks :) tikiwiki: 03jonnybradley * r28401 10/trunk/lib/jquery_tiki/tiki-jquery.js: [MOD] JS: Assign $jq to $ so legacy custom code will continue to work hi tikiwiki: 03sylvieg * r28402 10/trunk/ (2 files in 2 dirs): [FIX]i18n: quick fix to custom language. Replace with text inputs ok, warning of another multi-file change brewing - to change the textarea & toolbars "area_name" to "area_id" (as it really needs to be a unique id for any of this to work and the ambiguity is painful) i'm contemplating doing this in an experimental branch, but then no one will test it... maybe we should think of a $tikilib->getID function which can be used by every plugin/module hmmm, looks to hairy i think (which is why i've been putting it off since 3.x!) - i'll go experimental or a general naming convention JoernOtt: it needs to be client side too - also mostly accessed from smarty tpls (for extra fun!) like taId#### will this also fix the problem of having 2 (or more) antibots on a single page? yes, I had the problem with the wikiplugin_author yes, that might help JoernOtt: you need to have register your site on facebook to use the like it? as each popup stuff needs its own ids currently they all use the same