I am all for more flexibility in templating. Don't exactly have suggestion for a great solution. Mambo allows for custom naming more slots which is good but the way you assign components to slots is completely up to you to keep track of and offers no visual representation of the slots that are available. Would be great in XOOPS to have an html wireframe with slots in their relative positions based on the selected template and then a drop down or other in each slot to assign modules to that slot. I've attached screen shots of the way Zope templating has been customized where I work. UI still clunky but a step in the right direction for XOOPS I think.

jegelstaff: Thanks, great link. However I completely disagree. To purposely limit flexibility of implementation and design because certain people think it's ugly is short-sighted. From my experience some of the most interesting and refreshing things happen when technology is used and abused. And why should technological limitations dictate "good" design and style? Sharing source and technology is about freedom right? If people want to do crazy stuff let them hang themselves. It often stimulates and pushes innovation.

I whole-heartedly apologize for my comments regarding Mambo not really having really immersed myself in it yet. But it seems that most people don't really disagree that Mambo is a content-management system with more flexibility of layout and content types whereas XOOPs is a community driven site with the future posibility for modular addons that would make is behave more like a CMS, i.e. staging, revision, granular editing process.

To clarify I should say I wish the limitation of XOOPS to 5 blocks would not take it out of the running for certain projects. As far as code implementation I can't say but for many projects the flexibility of design far out-weighs the need for hundreds of free modules. I'm recklessly sticking my neck out here but my guess is that most sites, XOOPS sites included, don't use more than a small handful of the modules common to all CMSes and portal software. If most sites need these basic modules and one has more flexible templating I'd say XOOPS might not nessarily be the best choice. That said I do like what I've seen of XOOPS so far so I'll probably take the time to experiment with it.

I think generally you have to just do it. Many of the developers here are already crazy busy with their own modules. I'm sure if you tried your best and asked questions when you run a ground you'd get help from other developers. If you don't know PHP I'm not sure module development is a thing you'd want to get into as a first project. Do you program at all?

On a side note this might be a very popular product however the hammer is coming down on sites that provide P2P-related content, ShareReactor for one. AfterDawn interviews ShareReactor owner. Even if you could skirt by legal troubles seems like decent torrent sites need massive bandwidth and hefty servers which is not something most XOOPS users have.

Good luck.

Kick ass!!! Ask and ye shall receive. The control panel was one of my biggest but few complaints I have about XOOPS. Wow, this was just released today and I just installed it without major problems yet. Somebody deserves sloppy wet kisses... not from me mind you ;)

I've been contemplating more flexible block structure too. What I think you are trying to do can simply be accomplished by Weighting your blocks so whatever you want on top is 1 and whatever on bottom is the highest number in that column.

I feel sure this must have been discussed but after scouring the forums I didn't not find any thread discussing this topic so I'm reviving this old thread to hear the status of this request from developers. Instead of Left, 3 Center and Right what about completely user configuable slots?

Have a screen where an unlimited number of slots can be created with custom naming. Then on the blocks page instead of the radio button there would be a dropdown select or something that can assign to any slot. Of course this makes the responsibility of theme designer MUCH greater because a misspelling or omission of a block means it doesn't show up and would be confusing to a content editor. But not having looked at the core code enough I'm not sure how difficult this would be. My guess is one more database table and a few mods to the admin menuing. I suspect this might cause a slight hit in render performance but by how much I have no idea. I think the design flexibility far outweighs that concern.

What I'm suggesting is similar to the next level of CMSes like Mambo which I am in the process of evaluating. XOOPS will always have a place in my heart however. :)

Not that I don't apprecitate the work done to make a slick DHTML admin menu but I don't think it's well suited for that job. The floating positioning (relative to where the cursor hits the icon) is a little clumsy.

Is there a hack or ongoing work to perhaps make the admin interface more like a tree structure with graphical nesting, basically like Explorer? What would be great is if all the open and closed folder sets could be retained.

Thanks for all the great work XOOPS crew!

Kick ass! Great to hear. Trying to get up to speed so I too can give back to the community.

Instead of displaying articles in increments of 5 I think it would be a more logical grouping to show articles by days. So in addition to the numberical grouping also have "today", "past 2 days", etc.

Hmm... you're right. Not sure why it doesn't work in the Sage implementation. I think Sage looks through the source for a file like *.xml or *.rdf but it gets tripped up because XOOPS uses backend.php. From personal experience I don't think linking to a PHP script is as common as linking to an XML file.

I am using Mozilla Firefox (browser) with the Sage extension (feed agregator) which has a cool little function that will parse through a page and look for the RSS feed. I found that it doesn't work with XOOPS sites or at least not on mine and XOOPS.org.

I'm not sure if what I am suggesting is proper XHTML but this hack works for the feed auto detection now. I just added the line below to the head theme.html but it should probably be more part of the core than a theme level hack.