Quote:

Actually the analogy has a flaw. The engine is the core. The body is the theme. LOL

It would be more like this: should all cars all have all the options available on them, not working, but you can activate them when you want?

I don't particularly mind the fact that modules are not part of the core, since anyway I've never used any of them. Better third party modules were always available. In that light, the method of showing the available modules and what they do needs to be better.

Right now, I'd say that if no modules is included with the core it is easy gor the less reseourceful n00bs to find what they need, especially when testing a new system. But, if you make it so it is easy to understand where modules are and what they are for, how to install them, then not putting them in the core is fine.

We are still at a crossroads about this point. We can head in any direction the devs so choose.

Quote:

Herve this was one of the main reasons I choose xoops, in fact back in the early days, I monitored XOOPS for a long period of time before even registering on this site, I saw a lot of promise, things were developed quicker, modules available quicker, Although it was a new project it had the greatest potential out of all the CMS's.

I was testing Joomle/mambo last night after reading a thread on here about XOOPS being pulled from opensourcecms.com, I just had an urge to see what features I would of had should I have gone with them when that project was launched.

Look at the Joomla/mambo in there admin it's bloody amazing, well layed out options XOOPS members have been asking for years, they have states, custom options to the menu, better media manager, and a whole host of cool features, we've all be asking for.

Was XOOPS not considered a leader once?

Quote:

That was it, the module development team headed by Catz, I know John is cats, but who is the module development team now, do we still have one. or did we get rid of something else which would of been a great step forward.

Quote:

I fully understood that some would become obsolete, but they would be replaced with far superior ones, and your right in all the team debates there was never ever a mention of just jumping the foundations of xoops, and leave by the side of the road.

Quote:

I couldn't agree more with that point, at the moment the Module repository doesn't even contain all of the latest releases, just a couple, so that means we have to go to other sites and search engines to find them.

Does any one remember ModsCentral, does anyone remember Herko telling the leader of this website we don't need his support, I DO.

ModsCentral supported both XOOPS and E-xoops (now known as RunCMS), with two seperate websites which were repositories for module, in the early days if you wanted a module you could guarentee it was there, so you had two main sites Xoops.org and ModsCentral both had everything you could ever need, no more searching for hours on the net.

Herko then told ModsCentral they were not needs as XOOPS will deal with it, but now look at the XOOPS repository, I've been searching for a few modules which I know used to exist but there not listed on this XOOPS site, nor the Dev site and not even the XOOPS sourceforge site, oh well I have used something different.

Quote:

Bread and butter is my reply here, but why, lol?

The basic modules are the bread and butter of xoops, over time they can become more, but in the meantime we can rely upon them for all xoopsers needs, ohh, ohh no we can't because they no longer exist, well there not developed and supported officially in xoops, so now we just have bread (bare XOOPS system), and personally I dont like dry bread.

Quote:

Yeah and then we can have modules as great as all the other major CMS's, we should take mambo as a an example where the community donate to a project when a certain level is reached the project is commisioned, or we can just keep blowing $400 on bland logo's which don't really benefit us.

Also why was XOOPS down tonight?

A couple of other points are that when 2.3.* and 2.4 gets released and what ever version, modules may not be compatible.

But if there were a module development team, they would know the compatability with the soon to be released versions of XOOPS and could have those basic modules ready at the same time.

So ok when 2.4 (xoopshere) is released, we may not have any modules which are compatible?

On another note, looking at the module repository, unless the poster specifies, it's darn near impossible to tell what module will work with which version of xoops.

Looking at the themes, there is a similar issue in that you have two catagories, some are compatible some are not, where has this certification gone, I thought that was going to be a big point for the future of xoops, then users will know what they can and can't use due to compatability.

XOOPS version 4 is xoopsphere. But see This about modules.

Quote:

All modules for XOOPS 2.0* are compatible with XOOPS 2.4(right now it is 2.3) automatically.
The incompatibility is from modules dedicated for XOOPS 2.2*
There will be relevant guide coming out from XOOPS Core Dev Team very soon.

I think that the "free market" model for modules has benefits - but the "state" does need to remain involved more than it does


The documentation aspect of XOOPS is atrocious, partly because of language barriers and partly because once we (as users) work something out we are just happy and move on, leaving other users to face the same problems.

An important aspect of this is the selection of modules. Some of the "homework" should be done for us. We DO want to be spoon-fed (otherwise we'd become PHP/SQL experts and do our sites from scratch).

The module repository needs more input "from above" to ensure it (a) is up-to-date and (b) provides expert guidance on which modules are the best. For example, for XOOPS 2.2.3 (which, quite bizarrely, we are now being recommended not to download any more!!) most of the modules I use aren't in the module repository, although usually older versions are.

Just speaking as a beginner, so sorry if I've misunderstood things.

Quote:

Regardless of which ever one it is the point made is will valid

Any way reading from that then, there will be some form of module development team or am I mistaken?

Phppp, I just hope your right, I remember when we moved over from the very old XOOPS and only modules which really worked were the official core module, it took months if not years and still not all the modules people had back then are availiable.

I've only just started to see development on the friendfinder module, it's been a long time since it's really been truely compatible.

We don't have the old webring module which was made by Inconuteam, any one remember them, lol well I think they ended up forking XOOPS in the end, as development slowed down. They had a collection of some really cool modules including the webring module, it meant webmaster could run there own webring.

Thats just a couple of things, there used to be a fair few modules, not as many as other CMS's like mambo/joomla.

Peak XOOPS have a decent way to show if the module is compatible from there download section:

http://www.peak.ne.jp/xoops/md/mydownloads/

Quote:

I would love to see something like this happen. I would be willing to donate to see a few projects get off the ground (like a shopping cart!), and to put in some of my time to help organize it - if there is enough support for this sort of arrangement.

Quote:

hy,

wfdownload evolution, named smartdownload 3, is on the way to a final release. This version will permit us to add new fields in a much more cleaner manner in the future. The goal is to upgrade our repositories and add fields we need. I need one for QA stuffs.

about core modules, i personaly think that our main priority is not them in a near future (early short term). Mith has set module packages, dedicated to some usages as well.
But a agree we need to keep some within the distro. One of the strenghs of XOOPS is it's "out of the box" concept.
marco