matwho: joined #tikiwiki marclaporte: joined #tikiwiki
polom deeku: polom Marc! marclaporte: Hi Neil!
or is it spelt neil ? :-)
never sure about spelling :-)
how are you? deeku: there are many possible variations - Neil will do!. I am well, thanks.
quick question:
I want to display a random image from a file gallery as a CSS background-image, e.g. #header-top { background-image: url({IMG(randomGalleryId="3")}{IMG});} Is there an easy way to get this result?
Would this work: {if $page ne 'HomePage'}{literal}<style type="text/css">#header-top { background-image: url(http://vlpl.in/tiki-download_file.php?randomGalleryId=3); }</style>{/literal}{/if}
Hmm, it works!
Its not very obvious but this is a neat way to display random images from a file gallery as rotating background images: see http
http://vlpl.in CIA-36: tikiwiki: 03eromneg * r40840 10/branches/9.x/templates/wiki-plugins/wikiplugin_trackerlist.tpl: [FIX] add a class to 'No records found' error message so that it can be suppressed with css when the message is spurious goj_killedByISP: joined #tikiwiki RobertPlummerMob: joined #tikiwiki
left #tikiwiki Tiki|bot: joined #tikiwiki
New Forum Posts: Help anybody with pictures - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=43766 rodrigoprimo: joined #tikiwiki CIA-36: tikiwiki: 03jonnybradley * r40841 10/branches/9.x/lib/core/:
tikiwiki: [FIX] Switch to tagged release of Zend library as the dev branch has a typo in it which messes up RSS feeds (issue reported to Zend but not fixed as yet)
tikiwiki: Needs doing before release anyway... jonnyb: joined #tikiwiki ricks99: joined #tikiwiki benoitg1: joined #tikiwiki ricks99: joined #tikiwiki
polom y'lall jonnyb: hi ricks99 ricks99: hi jonnyb RobertPlummerMob: joined #tikiwiki RobertPlummer: joined #tikiwiki
polom all jonnyb: hi RobertPlummer RobertPlummer: jonnyb: Did we get that blocker you were working on fixed?
Also, do we tag in svn in tiki? jonnyb: not yet - did one of them, (mostly)
still a problem with html entities getting encoded inside plugins
sidetracked by the themegenerator bug at the moment (can't remember how it all works!) RobertPlummer: jonnyb: Is anyone else working on the html entities?
I can jump on that if you think it is a good idea?
Jyhem.... Feel free to chime in. jonnyb: yes please - the plugin code all seems very fragile regarding this sort of thing RobertPlummer: I've made some progress with the Jison Parser, hopefully this old parser will start to find its way out after 9, but till then... I'm jumping in. Tiki|bot: Info: TikiFest + Kaltura - http://info.tiki.org/article189-TikiFest-Kaltura sandroandrade: joined #tikiwiki
joined #tikiwiki Jyhem_laptop: polom jonnyb: molop ricks99: bolow Jyhem_laptop: jonnyb: FYI last night's rebuild worked after I moved the pluginR files away. I took approx 2hours and a half
Today I rebuilt again, and I see it's finished after 2h and 10 minutes jonnyb: wow, that's slow - what sort of server? Tiki|bot: Info: TikiFest + Kaltura: Video development the wiki way - http://info.tiki.org/article189-TikiFest-Kaltura-Video-development-the-wiki-way Jyhem_laptop: a virtualbox on a Kimsufi 16G server. The bottleneck seems to be the CPU -: Jyhem_laptop wonders how he can evaluate the CPU capacity of a virtualbox Jyhem_laptop: strangely, as I wanted to put the pluginR files back in temp/cache I realise they are already there since during the rebuild. So, no conclusion on the suspicion that pluginR conflicts with unified search -: Jyhem_laptop goes eat something StuartIanNaylor: joined #tikiwiki eromneg: joined #tikiwiki radek82: joined #tikiwiki CIA-36: tikiwiki: 03jonnybradley * r40842 10/branches/9.x/ (lib/tikilib.php tiki-switch_theme.php): [FIX] Switch theme: Empty values were obscuring site defaults following prefs overhaul (so themegen theme could not be set - thanks Chibaguy!) RobertPlummer: jonnyb: How do I reproduce the problem with encoding html? jonnyb: there's a demo page - i find it...
http://demo.tiki.org/9x/tiki-index.php?page=HTMLentities
i fixed it for the entities outside the plugin, but as you'll see the ones inside {code} get displayed as the entities, not the markup
this is for non-is_html pages
brb RobertPlummer: So is this plugin specific or parser? jonnyb: b
RobertPlummer: parser i think RobertPlummer: So the issue is that they shouldn't be encoded, correct? jonnyb: yup rodrigoprimo: joined #tikiwiki RobertPlummer: Why would the plugin be any different? Jyhem_laptop: joined #tikiwiki jonnyb: i think it's connected with the fact the plugin args need to be decoded but the body gets done too? RobertPlummer: yes, very odd. jonnyb: the upgrade script i'm working on is in the same area - it's v tricky... -: Jyhem back jonnyb: by the way, spotted a couple of codemirror issues - no html "brush" and custom css etc prefs highlighter won't change...
i'll carry on with the entity horrors, i've been in it for a couple of days so sort of know my way around (a bit)! Tiki|bot: New Forum Posts: Features for a theme I am developing - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=43772 CIA-36: tikiwiki: 03tikii18nbot * r40843 10/trunk/lang/de/language.php: German translations done on i18n.tiki.org RobertPlummer: jonnyb: It looks like it is <pre> related jonnyb. If you look at the page source, it looks like it should.
jonnyb: Codemirror on/off has no affect, can css be set to encode? jonnyb: i didn't think so - but well spotted
most odd RobertPlummer: no, I found it!
Our little buggy friend, who we don't all agree on how should work....
~np~~/np~
When I place him in there, it works fine, but things are parsed.
So I wonder if there is some sort of nesting issue. jonnyb: but you're right the source looks like it should, just that <pre> encodes them, no? RobertPlummer: I'm not sure, honestly....
if I wrap $data in pre, it looks fine.
no, it is deeper than just the ~np~, but that makes it do it or not.
I guess you are right....
jonnyb: So we are good then? jonnyb: hmm? you fixed it? RobertPlummer: I'm guessing that there is some js doing it or something. I don't think pre can do it.
Right?
So we are done inside the parser. jonnyb: i think so - i have this upgrade script ready to commit it think... RobertPlummer: ok
let me see if I can find something affecting pre CIA-36: tikiwiki: 03jonnybradley * r40844 10/branches/9.x/installer/schema/999999992_decode_pages_plugin_args_tiki.php: [FIX] Another go at decoding entities - the previous script was tricked occasionally by double encoded entities so this one re-decodes any found in plugin arguments. Jyhem: I'm sorry i can't really help. Just getting into the parser would take more time than we have :-( jonnyb: agreed, don't go there! :) Jyhem: Plus, I'm currently worried with my tracker issues
the rebuild of my dev sit took 10 minutes (same computer)
the rebuild of my dev site took 10 minutes (same computer) jonnyb: sounds better, so it's a virtualisation issue then? Jyhem: Main difference I see: one has 295 000 entries in tiki_tracker_item_fields and the dev one has 90 943 (same virtual box, other virtual domain) jonnyb: ew RobertPlummer: It is ~np~ jonnyb, confirmed. Jyhem: Yes... That's only part of the data which will eventually get there jonnyb: RobertPlummer: yes, but what if there's wiki markup in there? RobertPlummer: I know, I'm not saying we should remove it.
I've traced it to the beginning of parse_data still working backwards. jonnyb: yes, but i see it "works" here - changes the &'s to &amp;
isn't there an "output mode" flag for plugins? wiki or html? RobertPlummer: But look in firefox, in source it highlights the syntax.
But if wrap $data in pre from wikiplugin_code and die, it is fine.
hmmmmm.... Cold it be smarty? jonnyb: grrr... 'format' => 'html' and removing the ~np~s makes the entities ok, but the wiki markup gets parsed... RobertPlummer: Right, that is no good. jonnyb: i used the popup plugin edit form and it encoded everything :(
putting the inner content through htmlspecialchars() seems to work...
so with line 129 of wikiplugin_code changed to " . htmlspecialchars($out)" it seems to work...
shall i commit?
looks ok to me, and can't break anything else (inside the parser etc) RobertPlummer: sure
If I can get the ordered and unordered lists handled, the new parser is nearly usable. jonnyb: ok, will do, but my local uni-search index has broken, which is a good thing as i can now try to report the problem in a civilised manor (makes a mess at the moment!) CIA-36: tikiwiki: 03jonnybradley * r40845 10/branches/9.x/lib/wiki-plugins/wikiplugin_code.php: [FIX] code plugin: encode html chars on output so the full source is displayed
tikiwiki: 03jonnybradley * r40846 10/branches/9.x/lib/smarty_tiki/block.textarea.php: [FIX] wysiwyg: rollback setting display:none on hidden textarea so the ajax loading message appears in the right place for "normal" editors (will have to find another solution for template contents) RobertPlummer: jonnyb: You da man. jonnyb: is good? (hope it doesn't gang up with all the other entity fixes i've done and turn nasty! :) ) Tiki|bot: New Forum Posts: where can i see files of pages wiki? - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=43774 Jyhem: Have you guys tried the database upgrade after tiki9 update ?
I got Mon Apr 09 18:13:44 2012] [warn] [client 85.168.216.146] mod_fcgid: stderr: PHP Fatal error: Call to a member function convert_cdn() on a non-object in /var/www/clients/client2/web3/web/lib/smarty_tiki/function.icon.php on line 198, referer: http://spiral-dev.alsawiki.com/tiki-install.php?install_step=4&lang=en jonnyb: not for a few days... Jyhem: I commented line 198 out. iT is $params['file'] = $headerlib->convert_cdn($params['file']); jonnyb: probably no headerlib in installer :( Jyhem: then F5 and it claimed to have upgraded, then entered my Tiki again and all the plugins are disabled on the home page CIA-36: tikiwiki: 03jonnybradley * r40847 10/branches/9.x/lib/search/refresh-functions.php: [FIX] search: Add a more helpful message when the exception doesn't have one. jonnyb: got the convert_cdn error here :( Jyhem: That's reassuring in a way. Easier to fix this way :-) jonnyb: ok, should have a fix
can you rollback your tiki? Jyhem: hmmm, not really :-(
It's not backep up, it's for testing Tiki|bot: New Forum Posts: Deactivate profile - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=43775 jonnyb: i've deleted the script CIA-36: tikiwiki: 03jonnybradley * r40848 10/branches/9.x/installer/schema/999999992_decode_pages_plugin_args_tiki.php: [KIL] remove previous upgrade script pending investigation - seems to have corrupted pages when run in the browser installer - do not use! jonnyb: sorry about that - hope no one else has run it... :(
i'm working out a way to de-trash my local tiki... Jyhem: I doubt it. Maybe robert? jonnyb: weird how it worked fine in the shell - usually it's the other way round, hence testing the shell version more these days
first i'm trying to work out why these ones don't have a "rollback" link on tiki-lastchanges.php (would be handy! :) Jyhem: :-)
tonight I plan to launch a rebuild + log. So we have an idea of what stage takes all the time RobertPlummer: I didn't run it. CIA-36: tikiwiki: 03Jyhem * r40849 10/branches/9.x/styles/ (coelesce.css eatlon.css): [FIX] Admin boxes should not look differently when already visited jonnyb: just done a grovelling mail to the dev list Jyhem: I reinstalled from the would-be production site. -: Jyhem now has 2 websites with 295 000 entries in tiki_tracker_item_fields Jyhem: So don't look for a way to roll back if it's on my behalf jonnyb: ok, thanks - still trying to work out why lastchanges is so odd... Jyhem: It seems that the site is a tiny bit more responsive, but item links with multiple fields still make tracker display timeout :-( jonnyb: just found i seem to have also broken the custom search plugin - html escaping again... so dull! Jyhem: :-( Too many things happening behind the stage. We need to get KISS back in the design arildb: joined #tikiwiki arildb_: joined #tikiwiki dlech: joined #tikiwiki
!help Tiki|bot: You can get a more complete list of commands that work with this bot at http://tiki.org/TikiBot . dlech: !bugs Tiki|bot: Recent Bug: Tracker item: #4190 - - PATCH: wikiplugin_userlist.php handles privileges the opposite way - http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=4190
Recent Bug: Tracker item: #4191 - - LDAP/Active Directory Multiple Domain Support - http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=4191
Recent Bug: Tracker item: #4192 - - tags columns in tiki-listpages.php - http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=4192 sandroandrade: joined #tikiwiki jonnyb: joined #tikiwiki CIA-36: tikiwiki: 03robertplummer * r40850 10/branches/9.x/lib/core/JisonParser/ (Wiki/Handler.php Wiki.jison Wiki.js Wiki.php): [FIX] Got non-working lists somewhat working. eromneg: RobertPlummer: hi Robert - are you there - geoff Trebly: joined #tikiwiki eromneg: left #tikiwiki Trebly: <sylvieg>Hi, The ui principles of image-gallery had been modified from 6.x to 8.3. But 8.3 is not coherent and contain many bugs, do you know if something is planned on this subject for the 8.x trunk version.
This because I initiate an important site development based on 8.3, and I have to push out the bugs and rewrite a new ui. I would not want to work without utility and in another way than the way defined, may be for 9.x trunk ui (I have not looked at, no time).