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