Quote:
Well thats the way it would have to be. I don't understand why people are trying to force themers into this box when it's not the theme code that's the problem, it's the module code. There isn't a standard for how modules are templated by the authors except for "dont use too much css, k?", THAT's the problem.

If you forced module devs to create their templates a certain way telling them when and where they can or can't use classes and what classes they can and can't use, themers will default into using standard classes because that would allow their theme to render properly for every module. Module devs are supposed to make their module look right with every theme...themers shouldn't have to create an override for every module.

Quote:
Morpho is not the solution to all your problems. As i said its horribly simplified into a ton of useless classing to make up for lack of visual quality. Contrary to morpho-belief, you don't need to give EVERYTHING a class, let me decide what I need to give a class rather than telling me to fill in the blanks. That isn't going to help anyone learn, that's just going to confuse them and cause more badly templated morpho-babies in addition to the ones that exist now. Yes, new people have the right to learn, but everyone shouldn't need to sacrifice every theme to allow them to do that. People want every XOOPS theme to be a tutorial for newbies...thats ridiculous. Give me a template that isn't as backwardly coded as Morpho and I'll happily adopt the classes to benefit module appearance.

Quote:
Definately.

The contest...is bull#OOPS#. I may as well screenshot my new theme and give that to kris and let him code it considering it would be all his code if i did it anyway.

First of all, I absolutely refuse to base anything off of those themes. They are so weighted down with useless code and oversimplification that its just not worth it to make that a template for a future theme. It seems that someone is compensating for lack of graphic ability with an overly excessive amount of code. As I said many times before, I'm not theming via _INSERT_THEME_IMAGE_HERE_ just because "John Doe Team Leader" says I have to.

I refuse to accept "you have to code this way because its easy for new designers to understand". That has got to be the most ridiculous thing ive ever heard in my life. If you can't figure out how to make your theme work and you can't ask someone to explain it to you or code it for you, then you have no business making a theme in the first place. I'm not "noobing-up" my themes so that Jim Bob Newbie can understand how to make his own. I'm not here to teach the world, I'm here to make themes. If a new designer wants to learn how to theme for XOOPS he can go look at the default theme just like anyone else with common sense would do. Perhaps this is why XOOPS rarely has _new_ themers...or themers with any noticeable talent aside from "lookie i made my header blue!" because its too much of a pain in the ass to make a XOOPS theme that doesn't make devs head's spin because you didn't use THEIR code. You have been trying to force this "morpho-template" for how long? I don't see a line of new designers flooding in, eager to make uber themes based off of it.

You guys go ahead and theme-by-numbers, have fun with it, but count me out.

Quote:
1. Does't "break" anything in XOOPS or limit its functionality
2. W3C compliant
3. Doesn't hack the core

I do agree that certain CORE css classes should be kept compatible for use (even, odd, row1, row2, etc...). That only makes sense so that ALL modules look good with your theme. But the problem with that is that quite a few nameless module developers insist on hardcoding classes in awkward places (a forums module i currently use hardcoded even/odd/row1/row2 randomly on everything and makes for horrible theming). One of the biggest flaws i've seen isn't in the theming engine, it's in quite a few module developers inability to place css functions properly so that a theme "fits it"....so the themers just try to make due with what we have to work with. However I don't think you should be given a css file and told: "here change these to make your theme".

Which brings up another problem that theres 5600 different modules that do the exact same thing and NONE of them use even/odd/row1/row2/etc in the correct places. I can make my CBB forums look snazzy with a theme, but someone installs my theme on their site & they use d3 or newbb etc etc, and my theme looks like shyte on it.

What you NEED to do is set standards for css classes used in module/block code, or make a wrapper for them like every other cms on the planet, THEN let the themers adapt to those, THAT way when I set something to row1 it's going to look right in every module and I don't have to sit here and template override every #OOPS#ing module. But sadly none of that will ever happen even though it makes MUCH more sense than the current system...themers/module devs are lesser mortals, their ideas matter not.

Stop trying to put shackles on themers, get your code straight first, then talk to us to make it look pretty.

PS: This is the part where kris says: "I'm right you're wrong and theres nothing you can do about it because I'm the Design Team leader, muahahaha"

you need to raise the allowed memory in ur php.ini

memory_limit = 32M

is ours

if you dont have root, try making a php.ini in the public_html directory with that setting in it.

or use

ini_set("memory_limit","32M");

in ur mainfile

or use a phpflag in .htaccess

they're all english...?

http://sourceforge.net/project/showfiles.php?group_id=41586

First of all I would highly recommend NOT using dreamweaver.

If you're capable of coding manually use something like notepad2 or metapad.

link to the site? did you add any mods recently? what theme are you using? did you modify your bbcode (xoopscode) at all?

It could be alot of things, a link to an example would be most helpful.

if your semi-familiar with your database, the quickest way to put something in your signature that bbcode generally doesnt accept would be to go into your database and find your signature field and paste the code into that

Yeah, i guess i was a bit vague. Sorry about that. You may have to modify the row type and collation to match the proper settings for xoops. Also, you may consider changing the password hash in XOOPS to match what you had in Nuke Sentinel (cant remember where the setting is but it's there)...that COULD be why it's not allowing you to login....or you could just have everyone do "Forgot your password?"

Your best bet is to export your evo users database and alter the tables to satisfy XOOPS then import. I did XOOPS -> evo that way about a year ago and it worked fine. It's just a matter of dropping/renaming tables.

And to add my 2 cents: I would personally rethink that decision to switch. Technocrat completely ditched all nuke code for the upcoming 3.0 evo release.

we run et-main.com...just call it "et dash main dot com"