tikiwiki: 03marclaporte * r16658 10/trunk/db/tiki.sql: [MOD] On new installs, removing obvious link to mods, as admins can find via tiki-admin.php and there are many errors in mods. http://twitter.com/afahad/statuses/1173416234 tikiwiki: 03marclaporte * r16659 10/trunk/ (templates/tiki-admin_security.tpl tiki-admin_security.php): [FIX] Updating security information related to new plugin system in 3.0 tikiwiki: 03marclaporte * r16660 10/trunk/tiki-install.php: [MOD] Cosmetic changes to installer tikiwiki: 03marclaporte * r16661 10/trunk/lib/setup/prefs.php: [FIX] Default to off for a plugin which can be used to disclose information in certain contexts tikiwiki: 03marclaporte * r16662 10/trunk/lib/setup/prefs.php: [FIX] Adding default preferences for a few plugins tikiwiki: 03marclaporte * r16663 10/trunk/db/ (6 files): [FIX] convertscripts run tikiwiki: 03marclaporte * r16664 10/trunk/templates/tiki-searchresults.tpl: [FIX] typo tikiwiki: 03marclaporte * r16665 10/trunk/lib/setup/prefs.php: [MOD] Changing default for new installs, to need to validate the email addresses (click link in email). This only is the case if users can register, which is still default to no. tikiwiki: 03marclaporte * r16666 10/trunk/tiki-admin_security.php: [NEW] More security warning messages tikiwiki: 03marclaporte * r16667 10/trunk/templates/tiki-searchresults.tpl: [FIX] Cosmetic fix in search tikiwiki: 03marclaporte * r16668 10/trunk/templates/tiki-searchindex.tpl: [FIX] Making object filters optional in tiki-searchindex.php tikiwiki: 03marclaporte * r16669 10/trunk/tiki-install.php: [FIX] Some cosmetic changes to the installer. Still not good, but less awful. tikiwiki: 03marclaporte * r16670 10/trunk/tiki-install.php: [FIX] Some cosmetic changes to the installer. Still not good, but less awful. tikiwiki: 03marclaporte * r16671 10/trunk/ (5 files in 3 dirs): [MOD] mass changing of tikineat.css to thenews.css in various system messages and error messages. tikiwiki: 03marclaporte * r16672 10/trunk/db/tiki.sql: [FIX] Changing search link in menu to be the same at searching in top bar (Site Identity) tikiwiki: 03marclaporte * r16673 10/trunk/db/ (6 files): [FIX] convertscripts run tikiwiki: 03marclaporte * r16674 10/trunk/templates/tiki-searchresults.tpl: [FIX] Making object filter optional. tikiwiki: 03marclaporte * r16675 10/trunk/templates/tiki-admin-include-search.tpl: [FIX] Clearer label tikiwiki: 03marclaporte * r16676 10/trunk/lib/setup/prefs.php: [MOD] Making search results cleaner by default, by deactivating object type, and by deactivating hit count, which some webmasters prefer not to disclose anyway. tikiwiki: 03marclaporte * r16677 10/trunk/db/profiles/basicEnabled.prf: [FIX] No experimental features in default profiles. tikiwiki: 03marclaporte * r16678 10/trunk/db/ (tiki-db-adodb.php tiki-db-pdo.php): [MOD] Cosmetic changes to the error message pages, like when Tiki can't connect to the database tikiwiki: 03marclaporte * r16679 10/trunk/lib/setup/prefs.php: [MOD] Deactivating List authors on a clean install, to make as clean as possible tikiwiki: 03marclaporte * r16680 10/trunk/lib/setup/prefs.php: [MOD] Deactivating WikiWords on a clean install, as they sometime leads to unintended links. hi is it possible to get users created automatically when you use the apache authentication? tikiwiki: 03marclaporte * r16681 10/trunk/ (5 files in 4 dirs): [MOD] Making ListOrphans page optional, and turned off on clean installs. Wiki orphan pages is a concept more useful when there is no menu. Most TikiWiki sites use a menu. Ludo_ : never heard of that I doubt it Tiki needs username, password and email well, doesn't need email but better why it needs a password, if we use the webserver authentication ? in fact I will need just the user exist with limited permissions, but I don't want to get the login/password box tikiwiki: 03marclaporte * r16682 10/trunk/db/ (6 files): [FIX] convertscripts run tikiwiki: 03marclaporte * r16683 10/trunk/templates/tiki-lastchanges.tpl: [FIX] Adding check to see if IP should be shown in Last changes. tikiwiki: 03marclaporte * r16684 10/trunk/lib/setup/prefs.php: [MOD] On clean installs, no longer show IP by default in wiki history (cleaner & confidentiality) Ludo_: : good point I keep reading about "user themes," is it possible for a user to specify a theme to use instead of the default? if so, where does the user go to do this? Nickolous: I assume in "My Wiki", or else a menu option would appear if the feature is enabled. Nickolous: I haven't enabled it, so I haven't seen it. mmkay, thanks. polom tikiwiki: 03pkdille * r16685 10/trunk/lang/fr/language.php: [MOD] get_strings on french translation file luciash: : i have same sql problem Hi, I'm currently trying the Dynamic Content System but there i sth. Wired i cannot figure out. Does DCS need HTML-Features enabled? tikiwiki: 03luciash * r16686 10/trunk/tiki-install.php: [MOD] code simplification (no need to repeat the same xhtml 3 times) + small fixes and adjustments Anyone? I'm still struggeling with this issue. R|SK: hi, wassup ? Hi luciash [11:21] R|SK: Hi, I'm currently trying the Dynamic Content System but there i sth. Wired i cannot figure out. [11:21] R|SK: Does DCS need HTML-Features enabled? if you use html in it ? How else can dynamic content be implemented? Btw. Where do I have to enable HTML to support DCS in Wiki page? Admin -> features -> wiki -> allow HTML? The problem is, that the html-syntax is even disabled, when setting up a dcs block. R|SK, dynamic content feature doesn't need HTML activated. hey gary :) luci: making orphan change now Ok, so how can it be used without HTML? The docu is a bit indifferent. The "activate HTML" is in regard to wiki content, right? Dynamic content goes into templates or modules, so wiki content isn't involved. Of course you can/should use HTML in dynamic content, but this is separate from the wiki/text area activate html. marclaporte: yay :) chibaguy: DCS can be used in wiki page too via {content id=...} hi luciash. oh ok, I didn't know that. According to docs (and my past experience) it was only tpls and user modules. chibaguy: you can see it in wiki page help edit help ah, maybe was added sorta recently? nope, afaicr it's there many years already .) Hmm... Ok, I guess i understood. but where the hell is it being activated ? should be on features admin, right? That's what I'm on, too. ;) No sign of it.... in admin text area And is there anyway I can create a checklist-form (like in HTML) that allows users to justz tick checkboxes when a task is completed? I don't see it in 2.2 features admin either. Me neither. My guess is it got forgotten at 2.0 and never was added back. In Tiki 1.9*, it's on tiki-admin.php?page=features. I just checked. tiki-admin.php?page=textarea :-) Hmm, textarea? Interesting location given that it can also go in tpls, etc. it could go in two places too bad the magic is gone too bad the magician is gone.... tikiwiki: 03marclaporte * r16687 10/trunk/lib/setup/prefs.php: [MOD] Change back List Orphan pages to on, on a default install. We will need profiles to handle both cases. R|SK, could you use the user task feature? http://doc.tikiwiki.org/tiki-index.php?bl=y&page=Task Chibaguy: interesting idea, but I guess for our purposes not useable. We want to keep track of QA checklists, and so on. what about a tracker? (just thinking of where checkboxes are already available) I was thinkinf of this too, but as far as I can say after half an hour of reviewing it, it would be hard to adapt our processes to it. tikiwiki: 03sylvieg * r16688 10/trunk/db/tiki.sql: syntax tikiwiki: 03sylvieg * r16689 10/trunk/db/ (6 files): sync I'm wondering why a tracker wouldn't work.... Maybe it will. I'm not through with it yet. #2008-11-20 JohannesMoser ALTER TABLE `tiki_polls` ADD `anonym` ENUM( 'a', 'u', 'i', 'c' ) NOT NULL DEFAULT 'u' Duplicate column name 'anonym' 2008-11-20 JohannesMoser ALTER TABLE `tiki_polls` ADD `anonym` ENUM( 'a', 'u', 'i', 'c' ) NOT NULL DEFAULT 'u' Duplicate column name 'anonym' I get this error 50% of the time that I re-install the DB marclaporte: same here, maybe sylvie just fixed it ? :) nope it's something else and the 50% is very very strange yup, that i noticed as strange too even when html allowed on Admin > Wiki R|SK: there must be a bug Luciash: Thanks. I was getting grazy on it. Err, crazy. :) Always trying to enables it, without success. actually even plain text doesn't work :-| what you need to put in ? Wondering why anbody else hasn't noticed that. try %my_dynamic_variable% if it's not too long the content you want to display And how do I implement the id? you can e.g. put the above piece of html link i tried with DCS there You mean this way: %TikiWiki Community website% ? it's called dynamic variable wat you put in between %% nope, i mean you'll be able to put it there later after you save %something% and every time you will put %something% on a wiki page it will get replaced with it Ok, than this would be the correct way: %http://tikiwiki.org/Home% nope, correct way: %tikihome% then save then edit it (click on it) and put what you want there Ah, now I got it. Thank you luciash. >doctwo dynamic+variable http://doc.tikiwiki.org/dynamic+variable I'll give it a try tikiwiki: 03marclaporte * r16690 10/trunk/lib/setup/prefs.php: (log message trimmed) tikiwiki: A- People are already setting the DB connection without SSL. Is it possible to install with only SSL? tikiwiki: B- Most people don't change the default settings and most people don't have SSL. So the current setup leads to tikiwiki: having the vast majority of TikiWiki sites having the [ Standard | Secure ] and the secure link causes an tikiwiki: error. This can lead to a bad reputation for Tiki and the site. tikiwiki: C- The current workflow is: tikiwiki: 1- go to web root marclaporte: not sure it is a good idea to have a minumum setting like wikiwords .. tikiwiki: 03pkdille * r16691 10/trunk/templates/tiki-forums.tpl: [FIX] list forums: fix the colspan of the section row Hi coders... the {INCLUDE(page=>...)}{INCLUDE} plugin is inserting extra
lines into the included page, anyplace where the original page had a \n - anyone got an idea how to stop that? The plugin itself is fine - but whatever code is calling it - is taking the returned $text and doing the change. I've tried a "grep" on the entire codebase for anything I can find that might be the culprit... no luck tho - any hints/tips would be most appreciated! cnd_, are you using the normal wiki editor or the wysiwyg editor? wysiwyg v 2.2 That may have something to do with it. fckeditor interprets line breaks as paragraphs when you're using the editor, so maybe it's doing the same thing to breaks in the included page. What's the name of the php file that's got the job of outputting page text ? No - this isn't a page-content thing. I "hacked" the plugin, and inserted my own static text with some "\n" in it - and they all turn into
as well. I haven't noticed that problem using the include plugin when I'm using the normal wiki editor. the plugin itself only returns the text - no extra info to the caller about what might have created the text, nor what format it's in. It's a somehwat subtle problem - you tend not to notice extra blank lines - and if they're inside tables or various other things - they don't show at all. gimme 5 - I'll do a plain wiki page, and check if that's suffering too... You're saying the output is the same whether or not the wysiwyg editor is used? hmm - thanks - I think you solved it for me!! I've got to put the {INCLUDE} thing into a page this is build with WYSIWYG - then I don't get the double-lines Or - more specifically - it looks like whatever editor made the thing being included, needs also to have made the thing doing the including. Hmm, I don't know. I only use the normal wiki editor usually, and INCLUDE works as expected, no extra line breaks. Rats - no - didn't work. Since fckeditor adds an empty line after a linebreak for input text, I assume it does the same thing when it encounters the text of an INCLUDEd page. fsckeditor isn't the problem The page that I'm including looks fine by itself Only after I include it - do the extra lines turn up You're including it when the editor is wysiwyg, right? I've tried both They both muck up the same hm, I've never had the problem, myself. Perhaps non-wysiwyg pages don't have "\n" embedded in their stover versions? Perhaps non-wysiwyg pages don't have "\n" embedded in their stoveD versions? or, if they do, they're *supposed* to be converted to \n Basically - the INCLUDE plugin has no idea what created the original page - doesn't care - but the calling code I epxect *does* care - and probably handles wikitext pages different to fsckeditor/html ones. Do you know the file that converts wikitext to HTML ? No, sorry. ok - thanks anyhow - I'll hunt it down eventually... See http://themes.tikiwiki.org/tiki-index.php?page=Eatlon and http://themes.tikiwiki.org/tiki-index.php?page=Sample+page. Same spacing. Both pages made with normal editor. Eatlon page includes Sample page. This suggests to me that fckeditor is involved, also since fckeditor does add an extra line break after \n by design. I expect the problem is that the code converting wikitext to HTML is being executed on the fsckeditor HTML output... the latter is already HTML with correct spacing - it's not supposed to have \n line-ends converted into
's I don't think {INCLUDE} is performed by the editor, however the output of a plugin is reprocessed by the wiki interpreter. correct happen to know what the filename of the interpreter is ? (FWIW - I fixed my problem with a work-around - clicked the "source" button, and ripped out all the \n's from my include page). Would be nice to fix this properly for anyone else in future tho. I saw something odd yesterday which might be related. I was in the normal editor, I accidentally hit ENTER. I ended up in the fckeditor, and the page's {maketoc}-generated table of contents was within the edit text. Could there be a situation where a page with \n ends up in the fckeditor and it adds a second set of \n, or converts existing \n to
upon entry? That's normal fckeditor behavior. tikiwiki: 03nyloth * r16692 10/branches/experimental/ui-revamp2/ (63 files in 15 dirs): [MRG] Automatic merge, trunk 16634 to 16691 See "The Enter key" on http://docs.fckeditor.net/FCKeditor_2.x/Users_Guide/Common_Tasks/Writing I see cnd_ asked for a filename whose job is to emit page text. Don't we leave that to Smarty, which invokes the *.tpl files? We stuff page data into Smarty variables and let the magic happen. Remember: pageA - looks fine pageB - which does nothing except {include pageA} - is double-spaced. I can't imagine how fsckeditor behaviour might be implicated here. double-spaced meaning every single line? or every line the finishes with a line break? How do your pages created with fckeditor look (with INCLUDE not involved)? No unusual spacing problems? specifically - if I go back afterwards using the fsckeditor, and look at the source of pageA - I see that what's happenned is that every \n has turned into
\n why are you adding \n to start? Something does nice intenting and newlines etc to make the HTML source look pretty - whatever is doing that is the thing adding the \n See "The Enter key" on http://docs.fckeditor.net/FCKeditor_2.x/Users_Guide/Common_Tasks/Writing You've looked at HTML source before - there's \n all over the place - web pages are generally not just 1 giant long line of text. tikiwiki: 03sept_7 * r16693 10/branches/experimental/coe/ (35 files in 9 dirs): tikiwiki: [ENH] first attemp to have FCKEditor doing wiki syntax... tikiwiki: All is based on the MediaWiki plugin of FCKEditor, with some minor tikiwiki: modifications. tikiwiki: Very basic syntax works. tikiwiki: Plugins need work as they are not properly handled for now... "The first thing you should know about editing the text is the usage of the keyboard key ENTER or in some computers called RETURN. If you press the key the editor will create a new paragraph." chibaguy - if you think it's a fsckeditor problem - why is pageA fine - but pageB is doublespaced ? pageA is fine did u check ur "use wiki paragraph formatting" setting? or is this only for wysiwg pageB would be fine also if you use the normal wiki editor. This implicates wysiwyg. This is what I suspect.... wiki pages are stored in the database wysiwyg is fckeditor ones made WITH fsckeditor, are stored using HTML ones made WITHOUT fsckeditor are stored using text eg: hello
world (with the wysiwyg), or hello world (for plain text) cnd_: did you read the link chibaguy linked? So - whatever has the job of outputting this, is *supposed* to convert the \n at the end of hello into a
[yes, caarrie - I did] BUT - **not** if the page was *already* in HTML can you link us to the pages you are testing with? It's internal behind a complicated login/category system unfortunately cnd_: since no one else here has the issue, it might just be an issue with your install or how you are making the pages It's quite subtle - dependent on internal formatting you don't see - and causes problems you might not notice... not to mention... seems related to the included page being in HTML format It would also be good for someone else to try replicating, but I don't know who isn't already busy with other tasks right now. Not common. Other tasks... that reminds me Is there someone "in charge" of v3 ? cnd_: as long as you use that editor the page will always be in html cnd_: no one person is in charge of tw ;) Yes - true - but - the page doing the {include} is not being told what format the returned $text is in - there's no hint to tell it if it's html or wikitext. anyhow - the "in charge" thing. I gather there's a "release" planned sometime? like - 3 weeks or something ? Now - this is going to sound horribly rude - but - v3.0 is a product that's been built by the proverbial "committee", except there's no boss - so the, ahem, quality of the current code is somewhat lacking. tikiwiki: 03nyloth * r16694 10/branches/experimental/ui-revamp2/doc/devtools/ (svnbranchupdate.php svntools.php): oops Or to put it bluntly - pretty much everything doesn't work. The installer fails. Most features fail. *All* the themes look radically different in various browsers everything related to the wysiwyg editor is wrong (CSS and JS errors mostly)... as far as i know 3.0 is not ready for release yet cnd_, sorry but that isn't the common perception. fwiw, my 3.x svn installs just fine :) tikiwiki: 03wggley * r16695 10/trunk/templates/tracker_filter.tpl: Fixing bug id 2276 that occurs when someone selects a filter and try to select another filter. The input for the filter where alternating between visible or not, causing the bug. Have you edited a page? I get double-warnings about everything (popups thinking I'm chaning pages) You are welcome to voice your concerns and describe the specifics on the tikiwiki_devel mailing list, where the most active devs will see and respond, I assure you. But it would be best if you had a public site to demo the problems, of course. in 3.x? i can edit pages just fine * I hate the "Page Saved" notice and wish it could be optional, but other than that... Well - nothing works on SuSE at all (the shipped PHP doesn't have mbstring), and almost everytying fails on RedHat That's prolly 30% of the linux market I'd guess? There are some warnings for sure that should be optional, but this is an implementation detail, not failing code. IE6 fails badly - again - 20-%30% of the browser market And ,by "fails" - I mean - can't edit pages. IE 6 & 7 working for me. :) Sorry, but I test in IE6, and while there are some glitches, it's hardly failing badly. and all CSS looks wrong, etc. Show some screenshots, please, so we can address any problems. cnd_: take screenshots and explain where what's your O/S ? Of course we want to improve anywhere possible. just listing a bunch of things that dont look right on your system does not help Regarding earlier discussions, yesterday I installed xampp on my windows xp laptop and TikiWiki (trunk and 2.2) work fine. i've found 3.x to be pretty solid. the wysiwyg has some issues switching back & forth, and its not yet extended to all textareas, but all-inall pretty solid No configuring of PHP or anything needed. My guess is that most of you probably have an install that you did some time ago - and are not aware that a fresh install on a new OS doesn't work. Install of what ? trunk i just svned up and did a fresh install (working on revamping installer) and it works fine using win + easyphp I'm using trunk, last update about 5 minutes ago. ie7 I'd guess it's a linux thing mostly - which is, what, 95% of your userbase ? cnd_: where are you getting these percentages?? just guessing? the tw devs work on alll different systems and test regurally tikiwiki: 03sept_7 * r16696 10/branches/experimental/coe/ (61 files in 14 dirs): [MRG] Automatic merge, trunk 16624 to 16691 ricks99 - you said IE6 works - can you see a javascript error on every page? I have a trunk release, experimental ui-revamp, experimental jquery, and 2.2 installed on several hosted domains running linux. Likewise, no problems as you describe. j.parentnode is null or not an object also ie6 has been replaced via windoze update to ie7 a long time ago Yep, I get js errors in ie6 too. "error loading ... tikistyles.xml"... on edits. This is good -- specific details. ie6. i see no errors (depends on what's turned on, js-wise.) Oh - probably related - I switched on every single possible feature... actually, in wysiwyg i do now see "ajaxautosavebutton" not an object anyhow - yeah - you're all right. I'll blow it all away, do a fresh install, and try to be more contructive. module-shading or column-hiding can cause a js error in ie -- I forgot which. rock solid with tiki editor, thoguh steps, errors, screenshots, settings... tikiwiki: 03sylvieg * r16697 10/trunk/tiki-sqllog.php: [FIX]logsql: test adodb + if table exists CSS is pretty bad - none of the themes are designed so that the WYSIWYG output matches what you saw in the editor. in other words - what you see is *guaranteed* to look nothing like what you get... too many people don't use that editor I think cnd_: if you provide screenshots it can get fixed, also dont forget to list what broswer and version you are using last i heard chibaguy was doing the major css work for TW ;) Will do. I've actually got a browsercam account, which I'll donate to the cause for good measure. And I admit I haven't looked much at fckeditor output. The output actually looks nice - only problem is it's nothing like what you see when you actually do the editing. Looks like the set of CSS for display is different to that for editing. I don't know how much of that is under the control of the Tiki css files. I'd actually prefer not to use FSCKEditor... 'cept I've got 40+ major content-producers all moving off MS-Word... There are fckeditor stylesheets, so maybe we can override if needed. But this is pretty far down my list, to be honest. I actually read about a different web editor that's supposed to be the "best" in the world - as in - works well, everywhere, all the time. open source? Yes, I think. My brain will work again shortly and I'll remember the name... I think I saw it on an SF adfert - it was like - in the most popular 10 projects or something TinyMCE - last months SF project-of-the-month. "The TinyMCE project is about creating a WYSIWYG JavaScript open source editor. It has the ability to convert HTML TEXTAREA fields or other HTML elements to editor instances and is very easy to implement. " https://sourceforge.net/community/potm-200901/ We tried it 2 years ago - so except if they did more progresses than fckeditor - during this 2 years .. it is not so good yeah - pretty sus - who runs a project and makes it "project of the month" for a web editor - and never puts even a single "try it" link anyplace... tikiwiki: 03nyloth * r16698 10/branches/experimental/ui-revamp2/: Delete ui-revamp2 branch tikiwiki: 03nyloth * r16699 10/branches/experimental/ui-revamp2/: [BRANCH] Creation, trunk 0 to 16697 tikiwiki: 03chibaguy * r16700 10/trunk/ (6 files in 2 dirs): [ENH] Improve blog and blog post page tops, unify CSS selectors with those in forums to simplify styling. doc.tw.o page Features is messed up again. Now it's worse than blank, it's mostly empty with bad formatting. hi @all hello @all, can somebody help me in deleting a data record from tikiwiki. it doesn't work the usual way. there was an wrong setup with importing old dump to the new tikiwiki. The Page name ist Matth?us and schould be Matthäus. I can't find it with phpmyadmin to delete it manualy tikiwiki: 03sylvieg * r16701 10/trunk/ (8 files in 4 dirs): [MOD]forum: avoid a query to get the sticky before + add regexp for forum attachment for sumo need joeboy1372: : did you try to rename page first? joeboy1372: : maybe try deleting from page listing (with checkboxes) tiki has internal ID for pages renaming in tikiwiki did't work. it just creates a copy of that. but i've found that page in phpmyadmin table: tiki_pages and renamed it there and then deleted in tikiwiki I am having trouble editing CSS via tikiwiki, when I attempted to edit the .css file and clicked the 'try' button I saw no evident changes I had made so I attempted to edit the file again but it was blank tikiwiki: 03marclaporte * r16702 10/trunk/templates/ (2 files): [NEW] Adding link in the admin panels for profiles. Icon still needed. Thanks jonny tikiwiki: 03sylvieg * r16703 10/trunk/_htaccess: try-out - seems that the .xml fck needs are not considered as normal file so adding the .xml is a correct extension tikiwiki: 03jonnybradley * r16704 10/trunk/ (10 files in 2 dirs): [ENH] Icon for profiles admin, also found three more unlinked admin panels, so included them too (plugins, semantic and webservices). Images and admin pages need work on these. tikiwiki: 03lphuberdeau * r16705 10/trunk/templates/tiki-wiki_topline.tpl: [FIX] Wrong permission name preventing backlinks from being displayed tikiwiki: 03sylvieg * r16706 10/trunk/lib/setup/prefs.php: [FIX]site title: the default site was appearing on pages with no breadcrumb I will kill myself there is a siteTitle in admin->general and a sitetitle in admin->look sylvieg: no, please don't :) sylvieg: :; we love you! yes, we do :) thx guys - but I will have to rollback if you think so, this will be the right choice - just stay alive please ;) tikiwiki: 03sylvieg * r16707 10/trunk/ (4 files in 3 dirs): [FIX] another try to have the title always the same- as there were 2 prefs - the genral is chosen and look is not always activated tikiwiki: 03pkdille * r16708 10/trunk/ (3 files in 3 dirs): [NEW] mail notifications: add a perm "tiki_p_admin_notifications" in order to be able to delegate this activity to a user which has not tiki_p_admin none of the suckerfish vertical menu in default theme are working on IE :-( OUCH :( - let's hope that they decide to follow their plans and start using the only sane rendering engine for IE: WebKit :) ( the web would become so much a better place - especially for developers ) hello does anyone know if i can upload pdf files to appear as content on wiki or must they be converted to word first? "converted to word first"? - uh! - a real life example of how sadly perverted our world is... :( tikiwiki: 03lphuberdeau * r16709 10/trunk/lib/wiki/renderlib.php: [FIX] Wrong permission name preventing backlinks from being displayed (part 2) amette: I hope what he had in mind was pasting the Word document into WYSIWYG. But one doesn't know. polom amette: I do see an "OCR" option in avidemux which I'm tempted to try. Video to text? Now THAT's a file conversion.