It's not easily done in 2.0.7.3 without a lot of hacking, but 2.2 is supposed to support this kind of thing nicely.

--Julian

[Mostly in response to Andy, but might be relevant to others...]

I evaluated Plone along with a whole bunch of other systems for a client a few months ago. At the time, I was looking for reasons to eliminate a candidate system (since I had so many to look at), so my analysis was not exactly thorough, but it was the groups issue that I latched onto with Plone, and tried to verify in order to eliminate it.

As far as I could tell, from fiddling with the system and reading the docs, Plone has groups, as in an Editors group and a Publishers group and other groups like that, tied to the role of users in the workflow/content production process. They were really permission containers, rather than content containers, whereas XOOPS groups are permission and content containers.

There was no ability to create ad hoc groups of users, like in XOOPS, and control what content those groups have access to.

Someone with more knowledge of Plone could confirm, but I am pretty certain about this. Plone and XOOPS really are trying to accomplish very different things.

I would venture a guess that you could build something Plone-like inside XOOPS (as a module) but you could not build XOOPS inside Plone.

The more appropriate comparison would probably be between XOOPS and Zope. Zope is the framework within which Plone was built. Zope is more of a pure API than XOOPS though; Plone is not a module inside Zope, Plone is an application built on top of Zope. It's more like the relationship of an application to an operating system than the relationship of a XOOPS module to XOOPS.

I hope this helps,

--Julian

Here's a suggestion...Make sure Flash is installed in the browser you're using! For some reason Mozilla was just giving a blank page, rather than any indication that the necessary plug-in wasn't installed. Perhaps that was due to the way the embedded object was coded.

Anyway, it's all working now. *sheepish grin*

--Julian

Plone is a CMS in the classic sense of the term. You have a website, you have text and images on the pages of your website. You don't want to have to edit the web pages directly in order to update content, plus you want to be able to push ownership and editing responsibilities to other people besides the technical webmaster.

So you user a Content Management System to edit and update the content on the web pages without actually editing the web pages. A good CMS has workflow controls and strong role-based permissions for different users (can edit, can publish, can add new content, etc). And a good one will differentiate between different types of content (text, images, certain kinds of text (intros, body text, tables, etc), and even let you create new types to suit your needs.

A good CMS also has versioning control, so you can go back in time and see what a page looked like last week or last month because all versions of all content are stored, along with the identity of the user who made the change.

XOOPS has none of that. But WF-Sections, or another module, could be built that would give people the ability to have true CMS-like features in XOOPS.

Unlike Plone, XOOPS is a plug-in driven portal framework. Lately people have been pushing the term CMS to include such things as XOOPS, but a couple years ago, you never would have heard that use of the term.

XOOPS is good at giving you a way to bring different users together into groups, and providing the users with different ways of interacting with each other and with content (ie: through modules).

Plone is really bad at that. Plone doesn't even have the ability to put users into groups the same way XOOPS does. If all your users are just sitting in "registered users" or you only care about anonymous users, then the lack of groups support may not matter to you. But for anyone concerned about certain groups having access to certain stuff, and certain other groups having access to certain other stuff, Plone can't do it.

The two systems are really quite different, and each is very good at what it was designed to do.

Personally, I would like to see a module in XOOPS that let you manage content in a separate website, rather than controlling the look and content of pages inside XOOPS.

We have clients who use XOOPS for their "private" intranet style sites, and who also have public sites for which they need CMS features. Why not continue to leverage the XOOPS portal they have invested in, and turn it into, among other things, a control panel for managing their public website's content?

Give it a year or so, maybe we'll release such a module ourselves if there's enough interest on the part of clients.

--Julian

Hi there,

Does anyone know of any part of XOOPS, or a module, that can create a directory and move an uploaded file into the new directory, while PHP Safe Mode is on?

PHP Safe Mode seems to prohibit this.

xcGallery has a config switch that lets you alter how it works so that when Safe Mode is on, all uploads go into a single folder instead of it trying to create a directory to put files into.

We would really prefer to be able to still have separate directories created for files that are uploaded, but Safe Mode must be on. Any insight greatly appreciated.

--Julian

Quote:

Yeah, that was it for me too. Or so I thought. But although it installs fine now, when I click on FlashChat in the Main Menu, nothing happens, the content part of the page (center block area) is simply blank.

Anyone have any suggestions? Here's what I've done:

1. Set the CMS include lines in common.php so that only the XOOPS line is uncommented.

2. swapped index.php and index_xoops.php

3. changed the folder name to flashChat.

4. Uploaded the files to the xoops\modules\ folder (the install instructions say to upload to the XOOPS root, but if you did that you couldn't install it in XOOPS, so the modules folder is the right place, right?)

4. CHMOD the config.srv.php file and the appTime.txt file to 777.

5. Install the module in XOOPS through the Admin Menu

That all seems to go fine, but when I click on the link for FlashChat in the Main Menu, I get a blank content area. Any insight greatly appreciated. Thanks.

--Julian

Quote:

Yeah, sometimes I wake up in the morning and just want to give it all away!! And we don't think twice about releasing stuff that's related to the core. But modules that provide specific functionality are another story.

It's a more complicated issue than just "release early and often." Doing that would help make our product better than others, and would make lots of people want to use it, etc. So that's a good thing right?

But the problem is, our "product" is not the product. We're not trying to compete with others who make products like our modules. Our product is the overall service we can provide to customers. And some of our XOOPS modules are key ways we can differentiate our services from other competitors in the consulting marketplace. They let us do things for clients that other consultants can't provide.

So it's not really about releasing the software, it's about the effect releasing the software would have on our competitors' ability to compete with us for new clients. Releasing the code levels the playing field between us.

That's the fundamental effect of open source software on the entire software industry.

But why should we level a playing field we think is in our favour right now? One train of thought says that since we think we're better on other merits too, who cares if we level the playing field?

As a not-for-profit enterprise in the first place, leveling playing fields is sort of what we're interested in. It helps raise the tide for everyone, which is a goal of ours. But not if it undercuts our business so we can't go on doing that.

I suspect we will release it all eventually. A lot of things become very simply when everything is open source *and* freely available. But how and when I'm not sure.

I think the issue is very similar for others who do similar things like Andy Mayer and his event manager module. If you're reading Andy, I'd love to hear your thoughts.

--Julian

Quote:

Here's a great link that discusses how things are changing, and about open source and business models:

http://tim.oreilly.com/opensource/paradigmshift_0504.html

Quote:

"I have a simple test that I use in my talks to see if my audience of computer industry professionals is thinking with the old paradigm or the new. "How many of you use Linux?" I ask. Depending on the venue, 20-80% of the audience might raise its hands. "How many of you use Google?" Every hand in the room goes up. And the light begins to dawn. Every one of them uses Google's massive complex of 100,000 Linux servers, but they were blinded to the answer by a mindset in which "the software you use" is defined as the software running on the computer in front of you."

Quote:

I recently found this very interesting thread, and thought I'd mention...

For the past three months, my company has had about one and a half full time staff positions devoted to work with XOOPS. We are a not-for-profit company that helps other not-for-profits make better use technology.

Not all of those 4.5 "man-months" have been development time. The difference between using XOOPS for fun in your spare time, and using XOOPS in a professional context, is that professional software projects require a lot of different types of work besides just lots of web hacking.

So besides development of modules and core modifications, we have also had to do documentation, workflow design (to figure out how real world business processes will map onto the tools and modules in XOOPS), and a whole lot of support to end users.

There are also a lot more ways that business models and open source can work than simply whether you are being paid by someone else to write code or not. I would argue that being paid to write code is an old-economy view of how software development gets paid for. Technology, and software, is everywhere now, and the internet has put a lot of people and organizations in situations where they are relying on software without any need or interest in owning it. It's a service, like water or electricity, not a product. Most organizations don't have the technical capacity to manage the technology even if they owned it.

In our case, we are not a web development company, we are a consulting and general IT service company. Our clients don't pay us to develop. They pay us to provide solutions to them (in many cases that does mean websites). And technical issues like whether its XOOPS or not, or open-source, or proprietary, or anything like that, the client doesn't care, they have a specific need and they leave technology issues to us (that's why you hire consultants, because you don't know what to do yourself). We solve the need and they don't really care how it's done, as long as it works and they know how to use it in the end.

We host all the sites ourselves too, another part of the service we provide. And so far we have not distributed any of the major work we have done, yet it is all GPL. So XOOPS and money and open source sure do mix, but they also mix up the normal way we think about the business models that have supported software development up until now.

When software is a service, not a product, everything changes.

There can be excellent benefits for open-source projects when this kind of thing happens, as Bunny suggested. In our case, we are most likely going to be implementing some more sophistocated group and user administration features because our sites require them, and if or when we get around to that, they will be returned to the core for everyone's use.

--Julian

Quote:

Until someone makes a module for XOOPS that allows for article/content management, including versioning, and different roles for different users.

--Julian