Another approach:

WF-Channel, or TinyD, are good modules to use for this kind of thing. They will add entries in your main menu that display pages of text and images that you can either code in the module, or upload from your PC.

TinyD allows you to have multiple copies of it installed at the same time. I wrote a perl script that lets you clone WF-Channel with a different name so you can have infinite copies of it installed too. Details on the script are here:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=26041&forum=4

Good luck,

--Julian

Sure, anyone can hack up something like this fairly easily, and if someone wants to use this script as a starting point for a similar script for another module, go right ahead.

For anyone attempting this kind of thing, here's the basic structure of the code (though it's so simple, anyone should be able to figure it all out):

1. Grab the command line arguments

2. Setup the variables you need for changing text later on (the names of the template files, etc)

3. Open up the xoops_version.php file and put the contents in a string.

4. Do a series of search and replace operations based on the new names. This is the part that will be unique for each module of course; what you search for will be different.

5. Overwrite the file with the new text you just searched and replaced on.

6. Repeat 3 to 5 for all files in the module that need changing. That's the other part that will be unique for each module -- the number of files that you have the do operations on, and what changes you have to make in them.

7. Rename any files that need renaming. Another unique operation.

They way WF-Channel is cloned here should be a good guide. Here's a good overview of what's required to clone a module:

https://xoops.org/modules/news/article.php?storyid=1714

Good luck!

--Julian

FYI: the script has been updated to make a few more changes in the cloned copy -- change name of sql file, and names of the search and comment functions. Renaming the search function is actually necessary in order to avoid a fatal error on the userinfo.php page of your site. So on the off chance that anyone has grabbed a copy of this and used it, we highly recommend manually making these new changes, or starting over.

--Julian

Hi all,

My company really likes the WF-Channel module. It's got the simplicity of something like TinyContent/TinyD, but it's got the group permissions structure that more heavy duty modules have too. Basically it's a great way to embed HTML pages in a XOOPS site when you aren't looking for article management and just want the content up there on the screen.

But there is one big problem: You can't have more than one Main Menu entry; all your pages are part of the same series of pages. For example, you can't have some pages that are part of a section called "How to use this site" and have some other pages that are part of a different section called "Information About Giaks"

The solution would be to clone the module. But that takes some time and care, right? All that file renaming and search and replace operations in multiple files....

Enter clone.pl

clone.pl is a simple little perl script that will make a copy of the wfchannel module that is ready to be uploaded to your server and run as a separate module from any other copy of wfchannel that you might have running already.

You can grab a copy of the script here: (right-click and select Save link target)
http://www.freeformsolutions.ca/clone.pl

Here's how to use it (there are a few things that you have to get right or else it won't work).

1. Make a copy of the wfchannel folder on your local computer (the idea is the modify this copy and then upload it to your server).

2. Rename the copy of the wfchannel folder that you just made. Don't forget what you renamed it to!

3. Put a copy of clone.pl inside the renamed wfchannel folder you just made.

4. Run clone.pl with two command line arguments. The first argument is the name of the folder (it must be the exact name of the folder), the second is a human-readable form of the module name. For example:

perl clone.pl aboutus "About Us"

5. If all goes according to plan, you'll get a message like this: "Cloning complete. About Us module ready for upload."

That's it. Upload the new module and install it and away you go. Don't forget to CHMOD the permissions on the folders that require that, as per the wfchannel readme.

If you have any questions or run into trouble, please reply to this post. Thanks and good luck!

--Julian

============

Notes:

This script was written using ActivePerl for Windows. I think it will run okay on Linux, but I can't say for sure. If you have problems, it's probably related to the syntax for the paths to files, which should be easy enough to modify and fix.

If you want to run this on a Windows computer and aren't sure how, get a copy of ActivePerl here:
http://www.activestate.com/Products/ActivePerl/

Install that and then you will be able to run perl scripts from a DOS Prompt box (not sure how that works on XP, sorry).

This script is meant to be run from the new folder you make. I believe if you run it from another location, the paths will be screwed up, depending on your operating system, version of perl, etc. What this means is, make sure the new folder that you made is the active folder when you run the script, ie: if the folder you made is called c:\xoops\modules\aboutus then make sure the DOS prompt is c:\xoops\modules\aboutus> when you run the script.

Or to put it another way, this is good:

c:\xoops\modules\aboutus>perl clone.pl aboutus "About Us"

While this is bad:

c:\>perl c:\xoops\modules\aboutus\clone.pl aboutus "About Us"

This script does not do anything with the upgrade folder since the idea is that you're starting a new wfchannel module from scratch.

Of course, make sure that your new folder name has no spaces!

The admin icon for the module looks exactly like the wfchannel icon, and says wfchannel on it. Not much a perl script can do about that (without all kinds of extra work), but the module name does change to reflect the human readable name you pass in at the command line so that makes it a little easier to tell your different copies apart.

To make a new icon, get a copy of the Bit3 font that is used for the XOOPS module icon text (or if you don't care about it matching, use any old font), and open up the .png file that contains the icon and edit it.

Quote:

Thanks for the great post and references!

Regarding that one question quoted above, yes I think you're right, there would have to be a company that controlled the code and then chose what version to give away when. Since XOOPS already exists as a GPL'd product, no company can start up to do that, they would not have rights to the code. Perhaps some conglomeration of the current core development team could do it, but that's a very complicated legal question.

However, there is nothing stopping an enterprising company from developing the code base themselves, either as a fork, or in conjunction with the core team, and basing their business on providing XOOPS consulting. This is essentially how the very successful Typo3 product/project works I believe. There is a company behind Typo3, but the product itself is completely open source. They provide support and help setting up Typo3 installations (I believe they also originally developed Typo3 themselves and chose to release it as plain open source, no dual license).

And Draven, I don't think we live too far from each other, hmmmm.....



--Julian

The LGPL is intended for libraries and other "utility level" code, not an application like XOOPS.

-------------

Quote from the LGPL:

This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.

....the Lesser license provides advantages in certain special circumstances.

For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.

In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software.

--------------

I can think of no reason to use the LGPL with XOOPS. It makes no sense. XOOPS is not code that can be embedded into another application. We're not talking about a protocol implementation like OpenLDAP or OpenSSL here.

Since XOOPS is GPL code, to release it under another license would require rewriting it from zero, wouldn't it?

--Julian

Quite an open-source religious war has flared up here! A question that might clarify some issues: what actually is the "open source philosophy?" Who is the arbiter of what is OSS philosophy and what isn't?

Richard Stallman?

The GPL is only one open-source license. There are many others, some very similar and some not. I believe the common thread is that they all mandate that source code be made available as part of any distribution.

Andy, it sounds to me like you're saying something like this: because the GPL says that you must release code *if* you distribute, then therefore you *must* distribute when you have GPL code. And anything short of that is just plain wrong.

Even the Free Software Foundation itself has the LGPL, which recognizes the incentives for development (ie: money) that can arise from allowing inclusion of closed source software in an otherwise open source distribution.

I think ransomware is a very interesting approach to funding software development, and to turn up your nose at it because it is somehow philosophically impure seems like a very dogmatic thing to do. The GPL does not tell you when to release, it just says that if you share, then you allow others to share and share alike. How is ransoming code in defiance of that?

We too believe in giving away modules and code in order to benefit the community and make XOOPS a more attractive and better product, but there are a ton of competing interests here to balance.

The biggest is, of course, that the development work has to be paid for somehow. Andy, did you finance the thousands of dollars it cost to develop your modules through a bank loan? Or did a client actually pay you to complete that work? If a client is paying, then there's other issues on the table...

In our case, clients pay for particular work; we don't work unless someone pays. Not all clients would be especially happy if the work they are funding were instantly turned around and handed out to everyone in the world, including perhaps competing organizations. The key thing is timing. We think that paying for the development effort should entitle the client to some extra benefit that others don't have, to help create an incentive for people to pay for development.

Because if you just release everything you develop, as you develop it, then you have a serious "free rider" problem: If one client pays thousands toward development of a particular feature or module, and then the next client gets it for free just because someone else asked for it first, then that's a huge dis-incentive for anyone to be an originator. It gives everyone a big reason to just wait until either they absolutely need something immediately, or someone else has already paid for it.

To combat that, we don't immediately release all code, until it has reached a properly tested, bug free, feature complete stage. Clients that are paying typically want the first version that will work, and that version is not released, and anyone else who wants that version can contribute to the development, and the code is released publically when the development is "done."

(Is that much different from the WF-Projects team waiting until a module is well tested, etc, before release?)

I think the essense of "open source philosophy" is that you give away the source, that is is available. I don't think OSS developers should be derriding each other because they have different ideas about when to release, or how to finance their development efforts.

(This is the kind of thread that people laugh about when they talk about those crazy open-source developers! How can they get anything done when they're busy arguing about the number of angels that can dance on the head of a pin!)

--Julian

2.2 is the next planned major stable release of XOOPS. There might be a 2.0.9 for instance, if there is a crucial bug fix required or something. But the next "big" release, with lots of new features, will be 2.2 (2.1 will be the testing/beta version of 2.2).

--Julian

You can edit the theme.html file for your current theme to change the location of the blocks.

For the default theme, this is the relevant code:


<{if $xoops_showcblock == 1}>

<{foreach item=block from=$xoops_ccblocks}> <{include file="default/theme_blockcenter_c.html"}> <{/foreach}>
<{foreach item=block from=$xoops_clblocks}> <{include file="default/theme_blockcenter_l.html"}> <{/foreach}>	<{foreach item=block from=$xoops_crblocks}> <{include file="default/theme_blockcenter_r.html"}> <{/foreach}>

<{/if}>


If you fiddle with the order that the blocks appear in the table, then you can change their order of appearance on the page.

--Julian

Am I the only one who thinks that all the ideas out there for alternate/different/more block positions are a little short sighted?

What I mean is, certain blocks in certain modules are really designed to appear in a certain block position, and really look like crap if they're used elsewhere.

If we had a dozen or more block positions, this would be an even worse problem. The fact is, for all the flexibility different block positions would provide, you're still contstained in all practicality by whatever positions the module writer has decided to design his or her blocks around.

[And Mambo is not the "next level" of CMS. It's just different from XOOPS. That has been discussed elsewhere many times, for instance here:
https://xoops.org/modules/newbb/viewtopic.php?topic_id=24748&forum=3&post_id=108151]

--Julian