Hi, seems that there's allways someone in XOOPS community one step beyond about any real world usage of our favourite tool

We've set-up some legacy modules for our users ; till now, those were mainly accessed via "normal" browsers on "normal" computers with "normal" internet connections, but we're now introducing 3G access directly from "pda-phones".

Obviously, this implies maintaining two sets of templates, best working on each kind of target browser and platform.

Which among those would you think should be the best road to go ?

1) new site : mobile.mysite.com
This implies maintaining two sites in parallel (groups, users, access rights, installed modules etc..) Seems to be lots of extra work for administrators (mainly myself i'm afraid...) Would multi-site XOOPS techniques help ?

2) detecting the browser window size or platform or even setting up a cookie to remember the current browser is supposed to be on a mobile device (just as current language)... and select the correct template in the php code : $xoopsOption['template_main'] = xxx
But this implies modifying the php code for each page ; could be simplified with some code in the module header adding a "m_" prefix on the template name but still a risk with "non home-made" modules ...

3) some clever idea based on xsl-style transformations concept ?

4) would it make sense to have some administration on XOOPS Admin side to modify XOOPS layout depending on target platform or format ?


Well, hope this will inspire some of you, dear XOOPS fans
Xavier

Hi; i am so glad to see continued interest for Wiwimod.
I've been off quite a long time, and will probably be for a while still...

Sorry Skenow i didn't see before your PM, i would have surely answered before (maybe a "mail relay" option on pms would be a good idea but that's another subject )

I was feeling a bit guilty for not taking time to deliver support, and it was a true relief discovering that you've been taking things in hands. Time for transition has come.

So long life to simplyWiki (nice name indeed ) ; i'll contact you soonly to see how we can help transition).

I would like to give special thanks here to Gizmhail, who had for long time taken the relay in enhancing the product and supporting users in both the dev site and the main site ;

And of course to Simon Bünzli, the author of "wikimod" from which wiwimod originally derived.

This was for me a fantastic experience, to see how a simple and humble work can benefit, in such a short time, and with such an efficiency, from worldwide contributions.

Xoops was surely the right community to start and to stick with !!

Hi ; i've just discovered this thread; here is a quick workaround for 2.2 version, that WON'T WORK WITH PREVIOUS VERSIONS of Xoops.
Meanwhile, i'll study Mith's code : you always learn from masters . By the way Mith, this new blocks implementation rocks !

Replace function "wiwimod_getXoopsBlock" in file wiwimod/include/functions.php with the following updated code :

THIS CODE WILL NOT WORK WITH OLDER VERSIONS OF XOOPS

Xavier

First of all, i will thank here and again the core team for the huge job on this new version. I'm discovering it slowly , and there's some deep job done here !
The new block instanciation system simply ROCKS , and as a consequence, the blocks admin page gets simpler to browse (thanks again Mith !). The idea of clean drop down menus on top of all admin pages is great, making the admin side far clearer to understand. Yet i'have a couple of questions/suggestions :

1) Preferences vs Module menus
Preferences pages are automatic forms, constructed out of module xoops_version.php. The other module admin pages are "hard coded" by the module developer, yet declared in the xoops_version.php file to have menus pointing to them.

But these are purely technical considerations : from the user point of view, both preferences and "hardcoded" admin pages show module tuning and administrating options.
Why not merging the "preferences" and "module" drop down menus (as it was before ) ?

2) XOOPS coding standard
We had previously (on dev.xoops.org) recommendations to build admin pages with top (and pretty) tabs ; i suppose this is now obsolete, as the drop down menus give quick and easy access to each page


Xavier

Hi, and thank you all for your quick answers !

You're right, this is worth a little explanation : my brother is going to live in a boat in Guadeloupe (french caribean islands) ; he's running a (newborn) XOOPS site (www.regardnature.org : ok, the theme is .. peculiar but HE wanted this !).
Well, he'll be adding content off-line, in the local version of the site on his windows laptop, then synchronize when he has access to an internet connection : new or modified pages in the Wiwimod module (that's in the database) , with added images and attachments (that's in the "uploads" directory).

This could be a "one way" synchronization, but i'd prefer to be able to handle a two way sync to let him grab questions on the forum and answer off-line.

His host is OVH , and he's contracted a simple hosting service, with plain private FTP access.

Of course, my brother knows nothing about FTP nor technical tools and i'd like this to be a "press button feature".

Xavier

Has anyone experienced a solution to synchronize a local XOOPS site (say, on a laptop) , with the hosted one ? The only access i have to my host is ftp or http (a php script ?) : no ssh, no access to "rsync" -as far as i know - ...
I need to synchronize the "uploads" directory, and the database.

Xavier

Hi Mikhail ;
what do you mean by "import the wikipedia" ? how have you done this ?

Xavier

PS : erh, forget it .. didn't see your previous post

In wiwi, you've got a workaround with the [BLK ...] tag :

1 - step one : create a custom XOOPS block with the php code you need, and keep note somewhere of its block id once it's created (or remember the block title)

2 -step two : insert [BLK xxx] in your Wiwi page, at the place you want the block displayed (where xxx is either the block id or the block title).

3 - step three : save the page ; the block should now be displayed in the page ... doesn't it ?

Note : for now, no security check is done when displaying the block, so watch what you're doing

Xavier

Hi ;
you have to place it under the root /class directory.

Xavier

Since wiwi 0.8, the editors are "outside" of Wiwimod module, as "global" classes. The thumbnail feature is part of the "image upload" feature of the editors : Wiwi just receives the content for storing and displaying.

I am currently working on a "xoops resource manager" i aim to interface with the XoopsEditors pack. This one differs from the XOOPS standard image manager in that it supports other types of resources than just images, handles "per document" attachments so that resources can be cleaned when related documents are deleted and more ...

This module is easy to extend for new resource types (pdf, flash, zip, etc..) , each resource presenting its own rendering options : thumbnail, popup, inline, size etc...

A few weeks left till i post a first "alpha" version for comments and critics

Xavier