tjnemez:

Please wait a tiny bit more. I found that on moving things around I've wrecked more than I wanted. For instance, now I lost article editing. I've already corrected that one, bu now I'm doing a complete revision of features. I hope by tomorrow night I can release a 1.3 version with all these changes applied.

Cheers.

DobePhat:

I can tell you this: I've seen most of the free DHTML menus available, as well as some commercial ones, trying to find the Holy Grail of dynamic menus, without success. Tigra's menus are among the best I've found, and they're also very low-priced. There's a free version of their menu that is good enough for most applications, and they do have a Pro and a Gold version, each with its own pros and cons.

What I asked from them was an extension of the capabilities of the free menu, and they accepted and sent me a TigraMenu4Xoops for free. This menu is the basis of the one in the example site.

All menus have problems with forms. One of Tigra's has a way around this problem, I think the Gold one. Most of the display and positioning problems are minimal with this product.

And about the .js files, I do know there's already too much fat in XOOPS's pages to add more and more. The menu they sent me uses THREE .js files, but they ARE lean: 3, 1 and 1 kb.

Let's see when this is ready, and then we'll all have better ground to decide for or against, but I'm sure for many this will be a nice choice.

Cheers.

wcrwcr:

Sorry, that's something completely out of my control. I know Naish's team will try to do it real soon.

Cheers.

Jeff:

If you wait a couple of days, I'll have another block ready, to highlight the latest article in a column (selectable by the admin) and offer on the side (or below) links to more articles in the same column.

Cheers.

vzbob:

This is not strange if you upgraded directly from version 1.0 to versión 1.2, because of a simple fact that I failed to mention, that is, that between those versions I changed the variables for columns and articles. In version 1.0 those variables were respectively colID and artID. However, the use of at least one of these variables generated conflict when using the module together with WF-FAQ or WF-Section. So from version 1.1 on I changed the same variables to columnID and articleID.

If this is indeed the problem, maybe all you have to do is open your database and rename the variables. What strikes me as odd is what you say about seeing the articles but not the columns. Could you provide more details about this?

Cheers.

freetek:

To add submenus, you might explore the logic behind the main menu. You can read this logic in the file modules/system/blocks/system_blocks.php, lines 106-135. You'll see there that it's actually not that easy, because the logic is tied to the definition of a module (that's why in the xoops_version.php file you have a specific syntax to define the module's menu and submenus. But you can certainly try, exploring also the logic behind a recent post by chapi about highlighting menu options.

As to the showing of blocks tied to the showing of specific articles, I think that you can't do precisely that, because of the fact that blocks are linked in the database to one specific module, and the rules of display are tied to user groups, not to content items.

What you can do, however, is set some logic inside those articles so you show whatever you want inside the article. Check my module Soapbox (I just uploaded a fix, there's a recent post about it) and look in the article.php file. There I include the logic to show a list of articles pertinent to the article you're reading (the list excludes the actual article).

Of course, I might be mistaken. If anyone has an idea of how to accomplish the things mentioned here, I'd be happy to learn I'm mistaken. Wouldn't be the first nor the last time.

Cheers.

wildo, wilsonjr, tjnemez, marcan, and all Soapbox users in xoopsdom:

I'm sorry to say that the module had been released without a second thorough revision of all main points, so it slipped my sight this matter of permissions in blocks. I've corrected the relevant files and uploaded a new subversion of the module:

Soapbox v1.2 ZIP 882 kb

Soapbox v1.2 RAR 872 kb

In order to upload this fix quickly, I still haven't updated correctly the module, just corrected this issue and another one: I had no problems with the print at all, but just in case, I implemented the same thing following a different path. If you detect problems, please let me know.

The remaining text strings still hard-coded, as well as some other things left to do will wait a few days. There's just another thing worth mentioning:

Anonymous users will NEVER see the submit link, because a column MUST have an author, and the author should be a registered user of the site designed by the webmaster to author a particular column.

Again, sorry for the mishap. I hope this fix works for all.

Cheers.

PS. I'm happy to report that 1,058 users have downloaded the module so far. However, 944 of them downloaded version 1.0. I highly recommend getting this last fix, as it includes many things that were solved after the 1.0 release. Thanks.

wildo:

Sorry about that. I'll check as soon as possible and get back with an answer. This is one of those things that used to work fine until some other change wrecks them...

Cheers.

Kaliman:

Please take a look at this.

Sample dynamic horizontal menu

This I did by hand using Tigra Menu (and still I'm unsure about its display in a Mac). I talked to one of the menu's developers, and they graciously donated XOOPS a custom developed version, so now we have a Tigra Menu for XOOPS.

After that, Naish's team (look here to see a sample implementation) has built a XOOPS module that's actually a menu generator. This module includes plugins for different kinds of files, and one of these plugins is for Tigra Menu, so the module creates an XML file with the links hierarchy, and Tigra Menu reads this file and uses it to create and display the menu.

To sum this up, let's say that the menu given to the XOOPS community plus the module developed by Naish will together provide end users an easy configuration of dynamic menus. Please be aware that this dynamism IS different from the one presently offered by XOOPS native menus.

Naish is making the module ready for release, and it probably won't be long before it is made generally available. That's my hope, at least.

For the moment, then, the answer to your questions is: yes, its feasible, though not quite yet (unless it's done by hand). Soon we'll all have this choice at hand.

Cheers.

Amok:

Are you ready for a long while of delicate work? Grab a cup of coffee or something that keeps you awake, fire up your XOOPS site, launch phpMyAdmin and goooooo!:

Let's proceed one thing at a time.

1. I don't think you have a problem with tables. You need to drop the following:
+ xoops_xfs_article
+ xoops_xfs_broken
+ xoops_xfs_category
+ xoops_xfs_config (this will also delete the data)
+ xoops_xfs_files
+ xoops_xfs_votedata

2. Then you need to delete the module's id in table xoops_modules. In your example, the module was created with id = 30. You'll need to find (and note down) the IDs for your bad modules.

3. Next, you have templates added to the database and compiled. The compiled ones are written into templates_c so they're easy to delete. The ones written to the database need more work.
a. Open your table xoops_tplfile. There you have references to every template in your XOOPS system. Each template has an ID (first column) and is associated to a module (third column, tpl_module). In your case, I'd erase every line pointing to the xfsection module. But be careful: you need to take note of every tpl_id you erase, because you need to also erase the source for that template.
b. Once you've finished erasing from xoops_tplfile every reference to templates associated to the module xfsection, open your table xoops_tplsource. From there, very carefully, delete every record whose Id you noted down in the previous step.

4. Remember you saved the IDs of your bad modules? Open your table xoops_block_module_link and there you'll see associations between block numbers (block_id) and module numbers (module_id). Look for the records of your bad modules and note down the block_id numbers. Then delete the records.

5. Go now to your table xoops_newblocks. The first column (bid) holds the blocks numbers, so you'll be able to delete those blocks associated to the bad modules, using the block_id numbers you noted down in the previous step. The block templates should by now be deleted (you erased them in step number 3).

6. Now it's time to get rid of the module's configuration data. Open your table xoops_config and there locate every record whose conf_modid corresponds to the bad modules' ids. You'll need to delete all those records, but before doing that, note down their IDs (first column, conf_id). Armed with those values, open your xoops_configoption table and delete there the records whose value confop_id matches the values of the conf_id you just noted.

7. Time to take care of permissions. Look for the records whose gperm_modid matches the IDs of the bad modules. You'll see a lot of values, because you have permissions for each group, both at the module and the block level (you can identify the blocks looking at the gperm_itemid value. Once you delete all the records for gperm_modid, you'll be done.

Whew! That was complicated, right? It's hard to do it by hand, and it should give each one of us reasons enough to have more respect for the developers of this excellent piece of software, because all this is usually hidden from us so we just have to worry about using the software.

Cheers.