I have noticed that the core stylesheet, xoops.css kills many professional templates when you are using XOOPS to run the site. I removed it from the header of the template and it works fine. However, it takes modification of the module template and system block files to make them work right after doing so. (see example at http://favorgreen.com) Has anyone else noticed this? Are there values in xoops.css that can be changed easily so they don't break pro templates?

I have used XOOPS for many client sites over the years and have noticed the template limitations getting worse, not better. So I have started using pro templates here and there and just integrating them into existing XOOPS templates, and I feel the sites look better. However, some of the modules like contact and newbb never seem to look quite right. Comments? Suggestions?
Mark

First, to stop most developer templates from being broken, you could actually place their style sheets after the XOOPS ones to override them completely.

Over the last few months, I am beginning to think that modules shouldn't use templates at all, but have their content 'pushed' into the main template and have module developers start using core items more and more.

Most module developers are not web designers and the make awful web designers (myself included) and when I develop new modules, my main development time is spent on developing templates and sometimes these contradict many of what the theme designer had in mind.

Modules moving away from templates will help developers concentrate on just the core templates, which to me are the most important and the ones that define the whole definition of the site.

This would mean that module developers would have to keep away from using hard coded styles within their modules. This also would mean that the core would have to give solutions to many developers come across daily when developing modules.

Having more and more templates for the system to render, adds up on server resources and increases server load and that means slower websites. Even with caching, the system still has to deal with these templates in one way or another.

On another note, I would remove the procedure of storing templates within the database and just use a disk base template system, thus reducing server load by reducing sql queries etc.

Imho, Smarty is a resource hog, and is quite slow compared to other template systems and hopefully Smarty 3 will do a lot in addressing this.

After working with the current default theme shipped with XOOPS I have been quite alarmed by the amount of CSS styles that basically override the 'standards' and these do cause problem with other css styles in other complicated modules, forums. XOOPS should be about giving people more control over their themes, not about making it more work just to make them work.

I am also one for seeing styles like odd/even/head etc being removed from the theme styles. To me these cause the 'Xoops look' to many of the XOOPS built sites on the internet just now. I personally hate seeing this. I hate having to work on a new site knowing that I am going to have to do a lot of work to just to remove this 'look' totally.

Many many css styles are hardcoded into the code and this makes it even worse for web designers to work with Xoops. Many web developers hate working with XOOPS compared to say 'Joomla or drupal' for this reason.

My two cents or pennies, or whatever you use for currency in your part of the world. :-p

lol... Well, the hardest part has been changing the value for the textarea message box in cbb.... I still haven't gotten that to happen. I have reduced the cols and rows in xoopseditor and several other places, but that message box stays the same size no matter what editor, etc.

I am moving to Canada, so I guess it's pennies. I'm not sure.

Thanks for the input and I couldn't agree more.

For the textarea width position, I do remember this myself and I think you will find that somewhere in the css there is a 100% on the textarea in there.

Personally I would love to get rid of the xoopstextarea html editor and replace it with tinymce or something like that.

I would love to do that as well.... I went through all of the newbb css elements and couldn't find that 100%. I finally have posted the question here:
https://xoops.org/modules/newbb/viewtopic.php?topic_id=67765&forum=4&post_id=307076#forumpost307076

It's the cols='60' that I need to change, but I can't figure out where it is coming from. I did it before on an older version of newbb but no luck yet with this one.

catz - I agree. As a module developer I would love nothing more than to advocate all the css look-and-feel to the designers.

As a 'fall back' it'd be great to have a set of defaults that I could count on.

I do have many ideas regarding this and I even have a couple admin modules written and I think they would be more than ok for the job.

I have a media manager written using JS with multi uploads and using JQuery, and I also have a fully working content manager that I did with Zarilia, but the problem is that I would need to do a lot of work changing XOOPS to get it to work properly.

The problem is that I don want to spend my time working on 2.3 or 2.4 when DJ is apparently working on version 3. I am not about to have to do this twice and waste my time on what will be an obsolete version of Xoops. I would rather get working with this on v3, but so far I haven't seen anything about a alpha or beta release yet.

I understand not wanting to waste the time. I have several modules I've written over the past year or so that I have just 'shelved'. Seems everytime I think I understand the direction of the API, etc. things change which means the modules would need overhaul. It would be a support nightmare I don't have time to tackle - so for now, these modules stay in my private stash.

I know this is one of the reasons a few of the other modules haven't progressed too. Unfortunately it's hard to develop for the future when the direction isn't clear - it's not DJ's fault, there's only so many hours in a day and I'm sure he's busy thinking through the version 3 architecture but some detailed vision into that would really be useful.