MichaelC1: joined #tikiwiki fabricius1: joined #tikiwiki Anzhe: joined #tikiwiki rodrigoprimo: joined #tikiwiki Tiki|bot: joined #tikiwiki Anzhe_m: joined #tikiwiki DarkCalf: joined #tikiwiki nkoth|nelson: left #tikiwiki rodrigoprimo: joined #tikiwiki goj: joined #tikiwiki chibaguy: joined #tikiwiki Anzhe: joined #tikiwiki chibaguy: joined #tikiwiki rodrigoprimo: joined #tikiwiki Tiki|bot: New Forum Posts: Problem with .htaccess - http://tiki.org/tiki-view_forum_thread.php?forumId=26&comments_parentId=48347 Anzhe: joined #tikiwiki
is there a way with tikiwiki syntax to automatically print the logged-in viewer's name? such that you could do "Hello (user)." chibaguy: joined #tikiwiki Anzhe: joined #tikiwiki Jyhem_laptop: Anzhe: yes, you can use the {{user}} syntax. If it just displays {{user}}, you need to activate "Wiki argument variables" in Admin → Admin Home → Editing and Plugins Anzhe: Jyhem_laptop: thank you, I'll try it now
joined #tikiwiki
Jyhem_laptop: thank you, that did it!
next question - if I create an internal link to a page that doesn't exist, TW adds a "?" to the end of the linked word(s), and that "?" allows me to create the page, well and good.
However, if I am not logged-in, I can still see the "?". Is there a way to restrict that to registered users if I already forbid anonymous edits?
I don't want guests to even see it. Jyhem_: I doubt that can be done :-( redflo: joined #tikiwiki Anzhe: localization question: if I set the user page prefix to "User:", but then I want to translate my user page, what should the new page title be?
should I just translate "User:" as well?
what does TW do if you do a language besides English as the installation language?
I'm afraid using an alternate page title will break links for people viewing the wiki in another language...
this isn't a problem for other pages because you would translate their entire title, but for users it doesn't make sense to translate their usernames arildb: joined #tikiwiki jonnyb: joined #tikiwiki
polom
changi_: has the cron job on http://composer.tiki.org stopped working? or do you need to prod it? (Last updated: 2013-07-24)
this looks interesting: http://www.indiegogo.com/projects/ubuntu-edge pianoliv: joined #tikiwiki jonnyb: hi arildb - looks like we're going to have to re-render pages for inline editing server-side somehow because of the plugin handling... dull :( Anzhe_m: joined #tikiwiki arildb: in call Anzhe: joined #tikiwiki Tiki|bot: New Forum Posts: Best way to localize user pages? - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=48350 jonnyb: have to nip out, bbl amette: polom marclaporte: joined #tikiwiki Anzhe: joined #tikiwiki
joined #tikiwiki chibaguy: joined #tikiwiki dhazel: joined #tikiwiki jonnyb: joined #tikiwiki
repolom leagris: Hello
Tracker field auto-fill with creator/modifier name does not work with admin account. Only provides None as choice. Is it a know issue/feature? chibaguy: Sorry, leagris, I don't know about that.
My complaint today is how Tiki doesn't want to change templates. I have a templates/styles/themename/tiki.tpl and my Tiki trunk refuses to use it, insisting on the default templates/tiki.tpl even if I actually replace the default file with the theme file, and clear all the server and local caches.
This is in svn trunk. lphuberdeau: In trunk, if you want to change tiki.tpl, you should consider using the layouts feature
the base tiki.tpl is now almost empty chibaguy: Hi lphuberdeau. Thanks for the reminder. I'll try that. Yes, I want to replace most of what's left in tiki.tpl with bootstrap-friendly divs, just as a preliminary test. lphuberdeau: that's what layouts are for ;) fabricius1: chibaguy: at the moment tiki.tpl is nearly emty already - it extends /layouts/classic/layout_view.tpl
/s/emty/empty chibaguy: Heh. Ok. lphuberdeau: btw, the experimental branch should have some bootstrap-friendly layouts you can import Anzhe: can anyone point me in the direction of an example sidebar for a tikiwiki wiki page? I'm thinking about the how Wikipedia has geographic information for city pages, or order of battle information for conflicts... chibaguy: Hi, fabricius1. Yes, I've been watching and enjoying tiki.tpl getting simpler. ;-) fabricius1: chibaguy: you can easily add a new directory "besides" classic and name it to your needs lphuberdeau: the classic one in there has the 3-column layout and behaves quite normally chibaguy: I figured so, looking at the layout directories. fabricius1: chibaguy: I suggest not to name it "bootstrap", cause maybe we will put there a directory called "bootstrap" by default chibaguy: @lphuberdeau, oh, maybe I'm reinventing the wheel, then, if normally means responsive bootstrap.
Sure, fabricius1, I've named it something else. lphuberdeau: I did not use the responsive ones (too hard for me) fabricius1: chibaguy: I am experimenting with that on http://bootstrap.wiki4.me lphuberdeau: but you can look in there to see the base set-up, modules handling and all chibaguy: lphuberdeau, I just found the HTML of a minimal responsive bootstrap layout and more or less mashed it up with a trimmed down tiki.tpl.
And used bootstrap css and no Tiki layout css. fabricius1: chibaguy: are you working with bootstrap3? there are some changes towards bootstrap2 and soon will be released - v3 is actually the one, where they wil dual licence and which we then will adopt to Tiki chibaguy: But I'll take a look at the experimental branch for sure.
Yes, of course bootstrap 3. fabricius1: If you want access to the server (wiki4.me) to have a look and to collaborate with me, just give me a shout
we have ssh there aswell and once something useful is coming out, it could be committed from there via svn aswell
at the moment I try to figure out the integration of the js files ... a very new topic for me
PenguinMan offered me a hand and might give me some training lesson on that chibaguy: Ok, at this point I'm just experimenting with the HTML and CSS on my localhost. I managed to get a responsive theme working which is nice but have run into problems with template caching or something, as the pages aren't consistently using the new tiki.tpl. So I will definitely check out the layout feature.
I haven't
er, I haven't even thought about the js yet.
Anzhe, do you mean just a div in the wiki page, like one made with the box plugin? Anzhe: @chibaguy: yeah I guess? I'm brand new to TW and still haven't gotten to grips with all the online documentation
box plugin is what I should be looking into? I'll check it now chibaguy: I'm not sure if it has a "float" argument, but that'd be good to place it on the side of the content. marclaporte: joined #tikiwiki chibaguy: https://doc.tiki.org/PluginBox Anzhe: thanks, yeah I just found it chibaguy: ok Anzhe: I'll fiddle with it, perhaps I can just isolate the element and add a float via theme CSS
thanks for the quick reply! chibaguy: sure. looks like it has a float specification already so it should be easy to configure. marclaporte: joined #tikiwiki Anzhe: joined #tikiwiki jonnyb: polomarclaporte
thanks for setting up (and updating) the demo wysiwyg sites marclaporte: polom pom pom leagris: I am playing with various performance enhancements. I am happy I can get some improvements from a busy loaded i3 2130. -: marclaporte is excited about WYSIWYG again jonnyb: shall i update them? (or get on with the next thing - bullet proofing the plugins)? leagris: I fired all I could: xcache, memcache, multiple cookie-less cdns, and mod_pagespeed marclaporte: jonnyb: I will update the sites
you code :-) jonnyb: super, thanks marclaporte
leagris: thanks for looking into this - are you using some sort of load testing service? leagris: It is an amateurish job (play with settings, value perceived improvment ;D
Well it is a dedicated server I haz root ;D lphuberdeau: xcache or an opcode cache is definitely required
memcache I'm not sure you will get so much benefits, except perhaps for sessions leagris: But it is loaded with a heavy clunky Minecraft server with a significant load average: load average: 1,05, 1,20, 1,11
Apache mpm_itk (not the best performer, but per user), php-fpm on fastcgi (I like it).
Default HomePage with default theme gives 406ms on php script response and 1.58s onload with 325KB out of the original 460 without pagespeed optimizations
This is the best time I get on forced reload unauth anonymous visitor marclaporte: leagris: you sound like you have experience will all this :-)
will -> with leagris: Don't name me an expert;D
Well, worst case is, accessing an de-cached admin page with 18s onload sipherdee: joined #tikiwiki marclaporte: leagris: I suggest http://www.showslow.com/all.php?search=tiki.org
and http://www.webpagetest.org/testlog.php?days=365&filter=tiki.org Anzhe: at marclaporte's request I just tried out the WYSIWYG editor demo with Mandarin Chinese. You can see my scribble here: http://demo.tiki.org/wysiwyg-wiki-11x/tiki-index.php
no problems whatsoever dealing with hanzi chibaguy: :-) marclaporte: Anzhe: now, please try http://demo.tiki.org/wysiwyg-wiki-trunk/tiki-editpage.php?page=long+Wikipedia+page
oups http://demo.tiki.org/wysiwyg-wiki-trunk/ Anzhe: same tasks? use CHN in the visual editor? Jyhem_: Thanks Anzhe :-) -: Jyhem_ wonders about chinese characters in wiki page names, also marclaporte: Anzhe: try whatever you would most commonly use. It's useful if you report differences of behavior in 11x and trunk Anzhe: I gotta say the "Rich Text Editor, editwiki" tooltip is obnoxious leagris: thanks marclaporte -: Jyhem_ thinks it may require toying with "Prevent special characters in page names" and "Wiki link format:" configs in http://demo.tiki.org/wysiwyg-wiki-11x/tiki-admin.php?page=wiki Anzhe: alright, I've created two pages, one with ENG title and CHN content, and one with both CHN title and content
also created links between
everything works as expected
the consolidation of the "link" buttons into one button threw me off marclaporte: jonnyb: I see you changed satis.json, but I think composer.json also needs editing so we get CK Editor 4.2 Anzhe: I was looking for the WikiLink button
so you can expect users to ask about that going forwards, but it's easy to adapt (duh) marclaporte: http://demo.tiki.org/wysiwyg-wiki-trunk/ was no longer in wiki format. /me reverts jonnyb: marclaporte: have to wait for composer.tiki.org to update to include it - i have the change locally ready for when it's there (changi_ not about today?) Anzhe: marclaporte: huh? marclaporte: jonnyb: it's on a cron job jonnyb: was last updated on the 24th by the look of it, so maybe it's broken
http://composer.tiki.org marclaporte: https://composer.tiki.org/dist/ckeditor-ckeditor-4.2.zip is already working jonnyb: ah, ok - just the list not up to date then...
yup, works now (didn't earlier) - commit to trunk coming... arildb: Anzhe "Rich Text Editor, editwiki" tooltip ...yes that needs to go. It was introduced by the inline editing which is being integrated now. Still a few details to fix Anzhe: thank you! marclaporte: arildb & jonnyb: I did some copy-pasting to WYSIWYG and it works suprisingly well. But it's slow. I suggest a spinner so we don't think nothing is happening Anzhe: +1 to that
took more than 2 seconds for me from Word with only a small paragraph worth of text jk101: joined #tikiwiki marclaporte: jonnyb & arild: demo sites are now at latest trunk with CKEditor 4.2
Anzhe: related thread about WYSIWYG: http://tiki.org/tiki-view_forum_thread.php?comments_parentId=48332 jonnyb: thanks marclaporte - i'm getting some odd js errors but clearing caches etc jk101_: joined #tikiwiki arildb: Anzhe I added your comment here: http://dev.tiki.org/Inline+Editing#Open_issues jonnyb: arildb and Anzhe: that "Rich Text Editor, editwiki" tooltip stuff shouldn't be happening now (in the ckeditor4 branch) - will merge it back to trunk soon if everything else is looking ok Anzhe: *thumbs up* jk101_: I am trying to register on tiki.org so that I can ask a question to a problem I am having, but I am not able to register. I keep getting the message "Error - Request not from this host." Any suggestions? arildb: jonnyb: sounds good! jk101: joined #tikiwiki PenguinMan98: joined #tikiwiki rodrigoprimo: joined #tikiwiki Tiki|bot: New Forum Posts: Bug in tiki-check? - http://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=48355 jonnyb: jk101_ (in case you return or read the log) that "Request not from this host" error is because tiki can't tell what your "HTTP_REFERER" is, which might be down to some sort of firewall/privacy thing you are running or might be a network proxy or something - some more info might help (if you try again)
arildb - going to have a go at merging the latest changes from ckeditor4, unless you've found any complete horrors? (getting concerned i'm going to miss something if too much changes there) arildb: jonnyb: I have been busy with some other things. So, I haven't tested the latest status. Should I? jonnyb: fair enough - if you could have a quick look that would be nice arildb: checking now jonnyb: you know devs only test the stuff that works! :) arildb: he he ... an OK should arrive soon then ;-)
wow, I managed to put a box inside the content by trying all letters on the "numeric" kwyboard row. Uses both with and without shift key.
strange effect, but pmaybe not a bug jonnyb: :D
i saw a few things about new keyboard shortcut stuff for cke 4.2
ah, maybe you just entered a ^something^ which is wiki syntax for a simple-box (something i intend to support properly soon) arildb: probably
It does a very good job retaining all characters in the correct form, including < and >
jonnyb: I am still� getting HTML tags inside one page that is in wiki format. This page has been switched between wiki <=> html formats. Is it possible that the history conflicts?
works fine on another page in wiki format jonnyb: mmm, hard to tell with all the changes going on - you will get wiki markup showing in inline edit mode if you have nested plugins, no way round that at the moment arildb: I am doing a new test, going through some switching, to see if I can reproduce it on a new page jonnyb: i haven't seen any html tags showing though - can you reproduce on demo?
either way, i think the chances of losing data now are pretty minimal, so i'll do the merge (soon)
if you're switching between wiki and html modes a lot something will almost certainly break - it's not really intended (yet) to be a user-switchable thing arildb: I am testing with very basic content, which the converter can handle
got it
jonnyb: try this...
0) set system in html mode (use wysiwyg-html as default)
1) create a new wiki page with very basic content, e.g. bla bla
save it in html mode
2) Reopen the editor and switch to wiki mode.
save the page in wiki mode
3) now make some inline changes and save.
>> wiki mode page has HTML tags aalex_: joined #tikiwiki arildb: jonnyb: you are right. This is not a very common use case jonnyb: when you say "save it in html mode" you mean switch to wysiwyg? (step 1.5)
there is no "html mode" really arildb: I mean save the page using the wysiwyg-html standard editor jonnyb: ah, ok - i think i see what's happening - pages have an "allowHtml" checkbox (hidden when in wysiwyg i think), so you need to turn that off once you've switched back to the normal editor
so it should like it's behaving correctly (well, at least consistently ;) ) arildb: can you fix it?
I will try it
as a user I kind of expect this change to be set automatically (if it is required) jonnyb: not really - you (or your user) has to do it really - wiki pages (using the "normal" editor) can contain html if you have that option set... arildb: "allowHtml" ... I cannopt find it. Have the wiki editor open
Is it the admin option you mean? jonnyb: ah, ok - i think it's options (would be, wouldn't it!) - so if it's not enabled it should just make it not html automatically when you switch back to normal editor
yes, feature_wiki_allowhtml arildb: testing jonnyb: it gets overridden if you use wysiwyg with html
there's a perm for it too arildb: "Allow HTML" was off jonnyb: sorry, need to do this merge - that should be fixable later... arildb: yes jonnyb: and the inline save and cancel buttons have gone :( arildb: after the merge? jonnyb: depends how long it takes (off out in about an hour)
seems there's no save buttons on "plain" wiki pages - you get that? arildb: checking
I have both here jonnyb: weird - just made a new wiki only page and there's there...
ok, going to commit the merge before my head explodes :) arildb: I did check the toolbar lib. It got messy. So, no commit
:) jonnyb: ah, the page with no save/cancel buttons had a wysiwyg plugin in it, which no longer seems to work arildb: should it be supported at all for inline editing? marclaporte: joined #tikiwiki jonnyb: no, it should lock that bit
which it does... arildb: having inline editing and the wysiwyg editor open at the same time, means 2 editors are working on the same page, or? jonnyb: going to remove it and see what happens
big merge on it's way arildb: wysiwyg plugin I meant, not editor jonnyb: ok, no wysiwyg plugin, save & cancel come back aalex_: joined #tikiwiki jonnyb: i think that's fair - why would you need both the plugin and inline editing? arildb: I don't see the need jonnyb: maybe i can tussle up a little warning
but first it's broken, probably since i added the divarea plugin a few weeks ago Telesight: joined #tikiwiki arildb: doesn't seem like commits are logged here any more jonnyb: seems not, i can't see the bot logged in (tiki_kgb or something i think it was)
another changi_ thing i'm afraid ;) (i think)
i'm thinking we need a tiki-ckeditor.js file for utility functions etc... arildb: In trunk, tiki-admin_system.php?do=all seems to redirect to ltiki-admin_system.php, not clearing all caches. Anybody else getting this? jonnyb: it should be clearing the caches ok, but some improvements i made a while back to caching (and minifying) meant that page came back really messed up - was a quick fix to redirect arildb: ok
jonnyb: Maybe I still have cache problems, but in trunk, I am unable to edit a table inline and the "Rich Text Editor" tooltip is still displayed -: jonnyb checks arildb: I see the problem
The update had not overwritten all files properly
trying again jonnyb: ok, good - looks ok here arildb: after the update it got worse... now the inline toolbar is empty jonnyb: ew
is "svn status" ok now? arildb: trying more
updated again...got tiki-jquery.js jonnyb: strange it was so bitty - i'll try updating a spare trunk here arildb: SVN should be good. Trying new cache clean + test jonnyb: my spare trunk updated ok by the look of it arildb: I get this notice...
PHP (5.4.11) NOTICE (E_NOTICE):
File: D:OpenSourceTikiWikiwwwtikitrunklibckeditor_tikiwysiwyglib.php
Line: 70
Type: Undefined offset: 0 jonnyb: maybe sf.net flaked out at some point arildb: SVN says: At revision: 46917
ah...composer jonnyb: ah yes, cke got updated arildb: still the same
tested in FF, Chrome and Opera. All the same. Trying a different trunk installation Jyhem_laptop: joined #tikiwiki jonnyb: you get nothing in the toolbars? does anything else (normal wysiwyg editing) work? arildb: no toolbars. the warning is for line: $cktools[0][count($cktools[0]) - 1][] = 'inlinecancel';
checking standard editor jonnyb: seems that smarty_function_toolbars is returning nothing then? how does toolbar admin look? arildb: standard editor works fine
It's a fairly fresh trunik installation. I don't think I edited the toolbars jonnyb: if the normal editor gets them i can't see why they're empty inline arildb: me neither jonnyb: can you debug? i'd put a breakpoint in at line 68 of wysiwyglib.php arildb: It works fine in a different trunk installation. jonnyb: (once this is fixed those line need some more checks that there is stuff in there) arildb: Maybe some "residues" of my editing is around somewhere jonnyb: could be - so many changes... that's why i wanted to get back into trunk arildb: I am reinstalling the database for the problem installation now. WIll check if I can get it back working. It may be an IIS issue (Other test was on linux) jonnyb: here comes another one i'm afraid - new tiki-ckeditor.js file :)
r46918 arildb: Using the "Basic" admin view, I can enable wysiwyg editor, but the requirement "Wiki paragraph formatting" is hidden.
You mentioned hardcoding this value jonnyb. This sounds better to me. It's very difficult to activate inline editing in a fresh installation
...if you don't know what to do jonnyb: yes... that why we had the profile for a while
trouble is, that is quite advanced - doesn't it default to on these days? (would just work if so) arildb: A cleanup in thye admin panel, and possibly auto-setting of preferences would be nice marclaporte: So no more experimental branch? arildb: maybe keep it for now, in case other "ideas" come around? jonnyb: +1 marclaporte: ok arildb: How about a "wizard" like setup of Tiki after a fresh install. One page could be the editor setup. The system could auto-activate dependencies
Currently the wysiwyg editor must be activated in "wiki" or "edit / plugins" first. Then the wysiwyg panel becomes visible. The experimental admin views must be activated to see the inline editor option. Then inline editing can be activated
Inline editing is a great feature and should be much easier to activate (even if it is experimental) jonnyb: think we should make feature_wiki_paragraph_formatting default to 'y' for new installs? marclaporte: what do you think?
(would need an update script) arildb_: joined #tikiwiki fabricius: joined #tikiwiki arildb_: joined #tikiwiki TomJarvis: joined #tikiwiki
polom
I turned on the RSS feed for a calendar and I was surprised to see the wiki syntax unparsed.
I don't find any options to strip or parse the calendar feed, am I missing something? arildb: TomJarvis: I am not familiar with RSS and calendars, but which Tiki version are you using? TomJarvis: I am stuck on Tiki 9 because I don't have the newer versions of php arildb: ok, and which Tiki 9 version? The latest release: 9.6 ? TomJarvis: 9.7svn arildb: ok
can you try to reproduce it on the demo server?
at http://demo.tiki.org use the 9x installation TomJarvis: tiki-calendars_rss.php just takes the name and description columns from tiki_calendar_items without parsing them arildb: are you able to fix it? TomJarvis: I've added some code to tiki-calendars_rss.php to strip the wiki stuff, some of the things I remove are my own plugins.
I was just wondering if I was missing an option that would parse or strip them for me. arildb: sorry, I don't know TomJarvis: Maybe people that rss feed their calendars don't use wiki syntax in their event descriptions? arildb: It's possible fabricius: joined #tikiwiki PenguinMan98: polom fabricius MichaelC|Mobile: joined #tikiwiki TomJarvis: I tested calendar rss feed in demo tiki 9, same problem. The wiki syntax is all stripped in demo Tiki 11 though. I need to upgrade my server so I can move beyond Tiki 9.
OK. I was missing something. In Admin > Calendar, I unchecked "Treat calendar item descriptions as HTML" and it now strips the wiki syntax from the description. arildb: TomJarvis: good find TomJarvis: When it worked in demo Tiki 11, I decided to go back through all the options in my Tiki 9, and that option looked suspicious. Tiki|bot: New Forum Posts: Inline editing problems on demo - http://tiki.org/tiki-view_forum_thread.php?forumId=26&comments_parentId=48357 SkiNut: joined #tikiwiki TomJarvis: I was wrong. Even though I cleared the tiki_rss_feeds table before trying it, I did not clear cache. Changing that Admin > Calendar option does not fix the problem. marclaporte: joined #tikiwiki Jyhem_laptop: joined #tikiwiki SkiNut: joined #tikiwiki changi: joined #tikiwiki luciash: polom
Anzhe: still there ? SkiNut: joined #tikiwiki brolin_empey: joined #tikiwiki pianoliv: joined #tikiwiki