tikiwiki: 03lindonb * r29935 10/branches/6.x/tiki-browse_categories.php: Line eye icons up a little better with text.
http://doc.tiki.org/User+Preferences says "If enabled from the admin menu you will see a link to user Preferences in the main menu"
It doesn't say how to enable.  I presume it is Admin->Community->User Features->User Preferences Screen
I checked it, but don't see anything in the menu.  Of course, I've altered the modules/menus, so it's surely my fault.
Is anyone willing to help me figure out how to get the menu item to show up?  I'm stumped again...
re hrsms
what are you trying to enable?
hrsms: I'm just sending normal messages, but I take care to address them starting with your nickname to "highlight" you. your IRC client reacts to your nickname being mentioned depending on its configuration (often making a sound)
hrsms: do you see MyTiki in the menu?
I want the user to be able to edit their information, including password, email, etc.  When I log in as registered user (not admin), I don't see any way to do that.  I get the impression the User Preferences Screen is the place to do that.  I've enabled it, but don't see any difference
I did not enable MyTiki
I reported the Web Developer Validate Local HTML bug to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599773
@hrsms: if u enable mytiki, an option will appear in the menu. otherwise, you need to add your own menu option directly to the preferences page
Thanks.  I had hidden the application menu for non-admin because I thought it was too busy (I'll see if I can't make it collapsed by default - that will help).  But it seems I need it afterall.  I changed the permissions and have the link now.  Thanks for the help.  
your welcome
My screen flashes repeatedly as it is loading.  It driving me crazy!!   It's only on my tiki pages, and only seems to be Firefox (3.6.10) and not IE8.    Anyone else seeing this?
huh - sorry but could anyone subscribed to tikiwiki-devel tell me what is the latest message they received from me through that?
OK, did someone get my mail from this morning to tikiwiki-devel titled "HTML Strict vs Transitional (Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[29512] branches/6.x/templates)" ?
y. i saw it
ricks99: thank you.
can anyone see that mail on gmane? I can't
what is gmane
ricks99: a mailing lists archive
http://news.gmane.org/gmane.comp.cms.tiki.devel
sorry, got to go but I'll read answers in the log
o. its in the regular archive  http://sourceforge.net/mailarchive/message.php?msg_name=4CB1FDCF.1000409%40gmail.com
ricks99: oh. so our archives were fixed?
yay!
http://sourceforge.net/apps/trac/sourceforge/ticket/14178
ricks99: so, my mails show. thank you
hrsms: yes. see http://sourceforge.net/mailarchive/message.php?msg_id=4C7FF7BA.2030807%40gmail.com
tikiwiki: 03lindonb * r29936 10/branches/6.x/ (10 files in 5 dirs): [FIX] Fix issues with adding availability of all child categories for trackers started with r27935 and deploy better and fix a couple of pre-existing related issues. Wound up being a bigger change than I expected.
polom
hi all :-)
is mem issues on tw.o fixed? I'd really like to re-apply some of th emodules
polom
hello all  :-)
tikiwiki: 03jonnybradley * r29937 10/branches/6.x/lib/ckeditor_tiki/plugins/tikiplugin/plugin.js: 
tikiwiki: [FIX] wysiywg plugins: Let cke do it's data process before we do the tiki one. Should stop many of the phantom blank paragraphs being generated before plugins.
tikiwiki: Also added close </body> tag to the page contents as it seems ckeditor 3.4 "forgets" to add one (temporary fix).
hi Kimberlee 
hello jonnyb!  are u home from ny?
physically yes, but waking up at about 4a.m. still
you got back ok, i guess
waking up at 4 am can be adventageous in terms of productivity but no so good for your health.
yes, still playing catchup  :-o
not if you don't get up, and finally nod off at about 8 ;)
true, true
did u enjoy ur time in ny?
tikiwiki: 03jonnybradley * r29938 10/branches/6.x/lib/smarty_tiki/block.textarea.php: [FIX] Firefox 3.5+ selection issue: Remove workaround for body {display:table} problem now body is back to display:block (since r29844 and r29859)
tikiwiki: 03chealer * r29939 10/trunk/lib/tikihelplib.php: Help links: remove deprecated border attribute for img
Kimberlee: (sorry, distractions) - yes, very much enjoyed NY - especially seeing a bit more of it than the 2 blocks around Lindon's place this time!
polom chealer_ 
Hi - was wondering if anyone had seen the Tiki6 problem with uploading new users/passwords that I posted to the devel list last week?
jonnyb: no worries, i am a slow multitasker today.  I bet!  I saw some of luci's pics and it looks like you all did some site seeing.  :-D
eromneg: sorry
hiya chealer.
hi jonnyb
Kimberlee: one day i might get my photos uploaded somewhere...
hello Kimberlee :-)
eromneg: saw the mail, but haven't tried it (ever actually) - did it work before?
jonnyb: yes it works fine in 3.x - but a test file that uploads fine in 3.x just does nothing in 6
eromneg: I saw it. I'm working on another regression in Admin Users and am planning to address that next
hmmm, wonder when it broke - chealer: any chance you can find what broke it? (so good at finding regressions ;) )
chealer: that's great - let me know if I can help in any testing
jonnyb: yes, I talked with Sylvie about a related problem but I probably broke it
ok, let me know if i can help
jonnyb: regarding the CSRF confirmation breakage, I'm sure it's not due to HTML Strict, because it affects Tiki 5.3 too
is it still broken for you? seems fine for me now
jonnyb: it's fine in 6.x, yes
i think we had the same problem before the doctype change - to do with the input with name="name" getting muddled up with the form's "name" attribute
tikiwiki: 03jonnybradley * r29940 10/branches/6.x/lib/ (jquery_tiki/tiki-jquery.js tiki-js.js): 
tikiwiki: [FIX] Firefox 3.5+ selection issue: Wiki (normal) editor:
tikiwiki: Remove multiple workarounds for body {display:table} problem now body is back to display:block (since r29844 and r29859)
I was also wondering if anyone had worked out why we are getting a Fatal error with memory exhaustion whenever Preferences are used in Tiki6
eromneg: how do you mean? when saving admin pages? (prefs are "used" all the time)
if so that's bad - seems ok for me on 48M (last time i checked)
jonnyb: sorry meant the Preferences menu ie to set user password etc
even though tiki.org needed to be up'ed to 64M (it has some funny caching stuff set up, and masses of data)
oh right, yes - user prefs page - yes, seen it dying for a while now
usually on something to do with timzones
I'm using 128M and I get Fatal error memory exhaustion tikiwiki/lib/init/initlib.php on line 188 whenever I try to save the changed Preferences screen
yes, that's just wrong
doesn't seem to matter what I change
sounds like a blocker to me - can you add it to http://dev.tiki.org/Tiki6#Blockers pls?
ok will do
Columbians? ;=_
;-)
tee hee!
In Tiki 6: is there a way to easily move a trackerfield from one tracker to another?
i want/need to retain the same intrnal ID
hmmm, i saw a new little green arrow recently, but i think that was to move an item, not field
sounds like some db hack required
:)
it might just work...
here goes nothing...
hm... so far so good... now to test the dynamic lists...
wow. pretty painless
unusual (for trackers)
good afternoon everyone
Question for you all - I'm installing tiki 5.3 at a hosting site and it is going well
I have the site running, but I noticed something odd
often when I click Save on an Article, I'm getting a prompt that navigating away from the page could cause a loss of data
I first got this using IE9 and figured it was me.  The I tried IE8 and it is still there
is this a browser problem or is there another place I should look?
if u click OK is the article truly lost? or is it ok?
It is there
actually, clicking OK doesn't mvoe me off the page, browser just waits...
then i'd guess a tiki-issue. probably something with the js that checks if you are leaving an editing field.
Should I try this with  a wiki page to see if the behavior is universal?
uSlacker: yes, it's due to unfinished implementation of the consistent  {textarea} object deployment started in 5 - there are still a couple to clear up for 6.0 (like in trackers)
the "browser just waits" sounds like a bigger issue. but y, edit a wiki page and see if you (1) get the false warning and (2) if the page saves
ah. jonnyb: this is a known issue?
clicking ok should save ok afterwards
all text fields or just articles?
the button need a needConfirm=false adding
i think it's fixed in 6.x (can someone check?)
wiki page is fine i think
tracker textarea needs some help still i believe
@jonnyb and uSlacker: pls confirm at http://tiki.org/ReleaseNotes5.3#Known_Issues
ok
jonnyb: can I turn off that feature?
don't think so, sorry - might be a pref for it (in textarea or wiki admin)
tikiwiki: 03sylvieg * r29941 10/branches/6.x/tiki-install.php: [FIX]multitiki: fix link to tiki-install.php
tikiwiki: 03sylvieg * r29942 10/branches/6.x/templates/tiki-install.tpl: [FIX]multitiki: link
tikiwiki: 03jonnybradley * r29943 10/branches/6.x/ (3 files in 2 dirs): [FIX] tracker notifications: Various fixes - add static text items to mails, don't include empty fields if doNotShowEmptyField is set, and use item "title" in mail (thanks Xavi).
polom!
actually I am setting up a general demo site for perspectives and workspaces
just to make that visual
some small problems appear - I guess I will get everything done so far
one issue: when I am somewhere in a perspective or workspace and want to go back to the HomePage in the default perspective (no perspective) then I either:
arrive at HomePage staying in the perspective I started OR same page I started in default (last possibility just because I did not yet assigned the categories)
tikiwiki: 03jonnybradley * r29944 10/branches/6.x/ (lib/wiki/editlib.php tiki-auto_save.php tiki-editpage.php): [FIX] wiki & ckeditors: Use correct is_html option for parse_data when showing preview or switching modes to wysiwyg form wiki.
Using the link /tik-edit_perspectives.php seems not to be appropriate and ((HomePage)) aswell not
hi fabricius - yes i've experienced that - you need to go to tiki-switch_perspective.php?perspective=0 to get out of the current one
... /tiki-edit_perspectives.php ... sorry
if that's what you mean...?
ah perspective=0 THATS the default one?
yup
ui - perhabs tthat could solve at least some of my probs
did you ever experienced this white-page-problem in Tiki5?
just add it as an external link - e.g. [tiki-switch_perspective.php?perspective=0|Home]
sometimes
usually lack of memory on the server
any idea what it is?
memory?
but not with a nearly unused server with 64M?
the memory_limit setting in php.ini
64M should be enough, agreed
which pages? edit persp when searching?
different times by editing wikipages or adminstuff
sometimes the search timesout when it's rebuilding the cache, but is ok 2nd time (usually)
yes
no, that sounds worse than usual
but at the moment very often - so not so good a reference for my project right now
try a config search in tiki-admin.php first to build the cache file after updates etc
can you try using 6.0 beta?
(sounds like it shouldn't be any worse)
and worse I have some problems with anonymous users and perspectives, but at first would have to com any closer to the problem, before discussing in the IRC
is this a publicly available server?
right now I am slaving away some stuff, but asap Tiki 6 is on my shedule (wanted this weekend, but have to hope for tomorrow)
know what you mean ;)
it is - but the site with the problems I have to check ... a sec
it's just i haven't got time now for anything other than 6.0 stuff really
jo
big job you and the others are doin there
jonnyb: The editing problem I mentioned earlier seems to work fine onm wiki pages
not articles
uSlacker: good - that's what i thought - need to check and fix in 6.x
also tracker textareas (of various configs)
any thoughts on what I should do for this project?  is there a previous version I could use?
hack the template? i'll find a fix for you
I'll give it a shot if you can steer me to the correct file
long time user, but not a php dev
tiki-edit_article.tpl
thanks - I'll take a look
I have one more question.  I'm hosting this site on a virtual at 1and1.  Site seems to work fine until I wait awhile to  do something
then I get an error that MySQL has gone away
obviously a timeout of sorts
ok (sorry - 1 thing at a time pls)
is there anything in the tiki db config I can modify to maintain the connection
at the bottom of that tpl you see the three <input> buttons? (it's html, don't worry)
ok
you need to add   onclick="needToConfirm=false;"    to each one
I'll give it a shot right now
see wiki_edit_actions.tpl for an example that works (for wiki pages)
will do
tikiwiki: 03jonnybradley * r29945 10/branches/6.x/templates/tiki-edit_article.tpl: [FIX] articles: missing needToConfirm=false on cancel button (thanks uSlacker)
uSlacker: your site is on a virtual 1and1 -> 1and1.com or 1und1.de? and do you mean shared hosting? we have a 1und1.de managed server and are running into problems actually, while I cannot configure perspectives on this server.
on another providers server (both 64 memory limit) there is no problem with configuring them
are u using perspectives on ur server?
fabricus we're on 1and1.com in the US
It is a linux virtual
not sure about managed
tikiwiki: 03jonnybradley * r29946 10/branches/6.x/templates/wiki-plugins/wikiplugin_googlemap.tpl: [FIX] gmaps: Fix find (form is "this" in onsubmit) and zoom value update - save TODO
tikiwiki: 03jonnybradley * r29947 10/branches/6.x/tiki-user_preferences.php: userprefs: php warning
hi all. frankfurt  bookfair is over, so I'am back to tikiverse ;-)
jonnyb: there is an if clause right after the two submit actions that might be a problem. http://pastebin.com/zb81Ffbc
uSlacker: no, that just stops the cancel button being there if it's a new article
Ah, got it
the changes appears to work
:-)
thank you
just addding  onclick="needToConfirm=false;"
correct
good - maybe someone will backport that fix to 5.x for the next one (if there is a 5.4)
or just upgrade to 6.0 if you're brave! :)
I'll give it a show, but I haven't committed in a LONG time
'give it a shot'
i'll help review it for you if it helps
where else did you say it was needed?
the tracker text area, but that needs fixing in 6.x first
ok - well, thx again
i think blogs are ok (were broken once)
now I'll move on to the other problem
where ever there are textareas with toolbars basically
don't blame you :)
fabricus:sorry for the delay - my day job keeps getting in the way
tikiwiki: 03nyloth * r29948 10/branches/experimental/coe_fgal_relook2/ (100 files in 35 dirs): [MRG] Automatic merge, trunk 29820 to 29939
tikiwiki: 03chealer * r29949 10/branches/proposals/5.x/templates/tiki-adminusers.tpl: [bp/r29918][FIX] Admin Users: User edition CSRF confirmation screen broken with JS error "document.forms.confirm.submit is not a function"
jonnyb: finally...
jonnyb: ##javascript suggested going for javascript:HTMLFormElement.prototype.submit.call(document.forms['confirm']);return false;
jonnyb: unfortunately that didn't work in MSIE 6
chealer: what's this for? the confirm form thing still? (thought that was ok)
jonnyb: yes
tikiwiki: 03jonnybradley * r29950 10/branches/6.x/templates/wiki-plugins/wikiplugin_googlemap.tpl: [FIX] gmaps: Update "other" input (e.g. tracker field) when moving the marker around so the data gets saved (and so hide the other save button). Also clear the find box when you click on it.
yes the confirm thing but no it's not ok (i guess)
anyone got any thoughts about the order of the tracker navbar buttons? they skip about all over the place...
uSlacker: don´t mind the delay :-D ... i meant, is it a server, so do you have full access, like ssh/ptty, such kind?
jonnyb: I did use tiki-switch_perspective.php?perspective=0|HomePage to come back to the HomePage in the default perspective
works fine
yippee!
aswell did assign the default menu module (left hand navigation) to perspective=0
that does NOT let show up the module in the default perspective
in the other perspectives (1 to n) it works and everywhere the appropriate menu appears
tikiwiki: 03jonnybradley * r29951 10/branches/6.x/lib/smarty_tiki/block.wikiplugin.php: wikiplugin: php warning (in parse_data)
tikiwiki: 03jonnybradley * r29952 10/branches/6.x/lib/trackers/trackerlib.php: trackers: php warnings
re-polom
Kimberlee_: hi, did u got my message ?
tikiwiki: 03jonnybradley * r29953 10/branches/6.x/templates/tracker_item_field_input.tpl: [FIX] trackers: Don't try and use wysiwyg on tracker textarea (it was failing badly) and use simple mode when no toolbar (recommend only 1 non-simple textarea per tracker)
hi luci - you not abroad anymore?
hehe, still abroad :) just tired writing it all again to freenode webchat ;)
:)
luci: fancy squashing some validation errors? i'm in a squashing mood (and they're easy - usually)
jonnyb: i have something else on my todo list now, but will join u later prossibly
actually i've just found the merge conflicts sylvieg reported... ho hum
what aptana studio version u use ?
going to give it a try again on win7 thi time
*this
2.0.5 i think
3 not php ready yet afaik
ah, i c, it is beta still
no php debugging :(
jonnyb: trying top look at the parsing / line break : Why the feature_wiki_paragraph formating is only considered if non is_html
should it be only if not wysiwyg?
sylvieg: there isn't really an option just for wysiwyg sadly (down that deep)
tikiwiki: 03jonnybradley * r29954 10/trunk/ (123 files in 72 dirs): 
tikiwiki: [MRG] Automatic merge, branches/6.x 29878 to 29950
tikiwiki: Manual resolution of conflicts:
tikiwiki:  lang/fr/language.php replaced with version from 6.x
tikiwiki:  lib/language/Language.php manually merged - sampaioprimo please check
but I think itis the onl;y way to solve the problem
i'll take a look - been in there quite a bit recently
hope i did the right thing with the lang/fr conflict (it's rebuilt by get_strings right?)
Hi - I've just seen that tracker plugin seems to have broken in Tiki6 - was Ok a few hours ago - now no input fields are showing just the labels and descriptions
in any case it is impossible to go on with lang/fr/ trunk...
ik - that might have been me eromneg 
and the get_strings will be worst
hope so sylvieg 
eromneg: mine's ok locally
i'll svn up
tikiwiki: 03pkdille * r29955 10/branches/6.x/lang/fr/language.php: 2 french translations for admin panels
no tracker files modified
jonny: I'm on 29953 - and none of the tracker input forms are working for me
ok - just checked using the direct tracker admin screens - and no input fields showing there either - just the labels and descriptions
i'm on 29955 - should be similar
i just saved a new record from a tracker plugin - even the map locator worked!
sylvieg: the wikiparaformat thing - you mean the wpf should depend on the page's wysiwyg setting? good plan!
blogs also have one i think
btw switching a page from wiki editor to wysiwyg -> gives me an empty page content
ik - doesn't for me usually
complicated page?
can you send me the source?
http://pastebin.com/CVq2kkK4\
sorry http://pastebin.com/CVq2kkK4
ok, got it (wow, i would never have tried that! ;) )
it is called realistic test ;-)
with allow_html on before you switch i guess
yes there is an allow_html in the tiki parser
and it looks "wrong" when viewing the page (everything on the same line)
it is what I am trying to devug - the wiki et CR problem
seems to switch to wysiwyg ok for me (in safari, but sounds like a server-side thing)
see message on devel list
jonny: I've now svn up'd to 29955 (just to be sure) and all trackers are still broken for me - even the simplest tracker is not showing any input fields in either plugins or direct tracker screens  - is anyone else seeing this?
switchinh ck editor does not work also on safari
trackers ok for me
me svn up
hmmm - something odd here - another of my sites at 29953 looks ok - maybe something corrupted 
still ok after svn up
at least on text textarea, user selector
do you have a conflict in a tpl
?
no, do you? (might explain the loss of edit data)
me? was asking to eromneg
sorry - was catching up
yes, eromneg's thing might be a conflict
sylvieg: on the wysiwyg editor do you see a notice about "the new ckeditor implementation"?
i'm thinking it might have broken if autosave is off (i'll try)
no, that seems ok
yes .. but ... either the profile installer is broken or it is silent - because when I execute the profile nothing happens
yep - sorry all - it was a conflict - which I've cleaned up now - feeling stupid!
eromneg: it happens all the time ...
it is not my day profile insatllation does not work too
sylvieg: just applied the WYSIWYG_6x fine here (and it switched autosave back on)
any js errors? (minify seem fragile)
sylvieg: this WPF line break thing for wysiwyg is the right way to go - i'm thinking of adding a param to parse_data called 'process_wiki_paragraphs' - but not now (late here)
default true
tikiwiki: 03pkdille * r29956 10/branches/6.x/styles/coelesce.css: Some styling for search infos in coelesce
hey everyone
i need some help
do not aksk to ask - just ask
jonnyb: sorry the ck/tiki conversion is fine ... it was a trace that was bugging javascript
phew
W O W 
same browser - same time - same website
in one tab I am loged in in oner perspective and in the other tab loged out in the default  perspective
checked twice and switched from one to another perspective
so now normal behavour again
funny
tikiwiki: 03nkoth * r29957 10/branches/6.x/lib/comments/commentslib.php: 
tikiwiki: [FIX] Problem was that all the forum topic replies was appearing as topics in
tikiwiki: the topic list. Bug only appears when post data content is long. This additional
tikiwiki: grouping by anything other than the threadId seem not useful. I think what
tikiwiki: happens is that when data is long the group by query gets overwhelmed and does
tikiwiki: not group at all, thus showing all joined lines.
for a virtual work group - in a company or in a community or ngo doesn´t matter so much for the moment - what features everybody would think to be most important?
wiki pages, blog, article, IM, forum?
just as standart, if predefined
what would be the most important to you guys and girls?
article are not interactive
wiki and forum for me
jonnyb: sorry, I was unclear. I meant yes the confirm thing, indeed.
I meant "Finally...it's fixed!"
though this is a local fix, other forms may get the problem later
indeed, keep an eye out for them
##javascript suggested a fix for everywhere, even if a field named "submit" would mask the submit function, but that was not portable
sounds scary
tikiwiki: 03nyloth * r29958 10/branches/experimental/coe_fgal_relook2/ (7 files in 3 dirs): [FIX] filegal manager : do not allow massive actions + hide checkboxes + make a first upload dialog that works + remove buttons in upload dialog + fix basic column sorting + remove some useless comments
sylvieg: i have a patch fix for the line feed thing, but too tired now to commit - do you want to try it?
need to check it doesn't break anything else (much)
tikiwiki: 03nkoth * r29959 10/branches/6.x/lib/comments/commentslib.php: [FIX] Count of number of replies in topic was wrong (it was going 1,2,6,etc...)