Didn't notice the post you made before mine, I guess we were posting at the same time.

Quote:
I completely understand that quite a few people don't understand php and don't want to understand php, but I don't understand why that means that those of us that do understand it and are comfortable with it are unable to use it because of those people.

Quote:
My first post was an example of why I personally would prefer php over html, I should have probably made that more clear, that was my fault. The reason behind my argument is the frustration with limitations of the XOOPS template system and steps being made to further complicate a system which could be "de-complicated" simply by allowing a regular theme.php as well as a theme.html and implimenting a caching system that would actually cache php...that way those that don't understand php are free to use their smarty and html while those of us that do understand it can use straight php and accomplish more than we ever could with html...If you would like to know what limitations with the current template system I'm speaking of see skenow's post about what's being implemented in the 2.3 system in addition to many other things that I've come across that simply cant be done in the current template system. My point being that all of that could be solved with allowing php instead of further complicating the current system.

Quote:
No I was referring to phpNuke actually...nuke is a HORRIBLE CMS and is poorly coded, but the themes for it are outstanding. Try porting a high quality, well designed, feature filled nuke theme to xoops, you will find that you will have to leave out tons and tons of features simply because although the features are present in xoops, but you just cant do _insert_feature_here_ with the XOOPS template system.

@hervet
I appreciate the reply, but um, the answer to why I can't use a theme.php is because it's too hard for some people? And you're serious? Come on...
Quote:
Me not having to theme exactly like everyone else does: INSERT YOUR THEME CODE HERE....would be alot better.

I've worked on some systems using php as well and I didn't find it to be a pain at all...I mean I'm not asking you to throw out the XOOPS template system for a php system instead, but is it really so much to ask that I be able to code a theme in php without breaking some aspect of xoops? I understand the function of templates_c...it holds the conversion of smarty -> php for each page and of course would decrease page load time as each page would already be complied in templates_c and would not have to be recompiled from the theme.html every time a page is viewed.

So...how about a NORMAL caching system instead of being dependent on smarty's templates_c to hold each compiled page. That way a designer could use html and smarty or php without it taking 5 seconds to load each page. I understand that I'm fairly new around here and my opinion is probably not regarded too highly, but I definitely do not understand why XOOPS is so driven to limit designers to doing things the XOOPS way and only the XOOPS way and if I don't like it that's my problem.

Like i said before, I've worked on the theme.php's for other CMSs, one who's name i wont mention has to be the worst CMS you could ever use, HOWEVER it has the best themes that I have ever seen, it has a TON of experienced designers producing themes for it....Why? Because even though the CMS is one big security hole, its theming engine is FLEXIBLE. You can code your theme any way you please you can add as many bells and whistles to it as your little heart desires...you just put your block code in the block function, header code in the header function, etc etc just like xoops...only difference is, you can add variables outside of those functions to customize your theme EXACTLY how you want it...because it uses a theme.php. But with XOOPS on the other hand, you end up having to comprise...I can only INSERT THEME CODE HERE, and add a few little customizations provided they comply with the XOOPS template system.

Sure, you could further complicate the template system to allow for a little bit more customization in themes and keep telling people to theme like this with smarty or your theme simply won't be cached (compiled)....OR you could write a cache system that doesn't ONLY compile smarty, but will also cache php themes to allow designers to use smarty OR php without completely nullifying a core function of xoops...Like Will said....different isn't always better...

lol, yes, that was my question, more specifically, is it entirely necessary to utilize templates_c for a theme even if i can call the php directly instead of having templates_c do it, but yeah, you got it.

And I don't really have a primary concern per say, but what I posted originally about security is one of many reasons I'd like to use a theme.php, yes....other reasons being in my second post @you

Basically i've themed for another CMS in the past which used .php themes, and i find myself having to limit features and little bips and bops that I've used or have seen used in straight php themes in the past....i mean yeah, theres <{php}> but it does have its limitations.

@ske

Yeah, an .htaccess works, and thanks for your attempt, but you did kinda miss the point. My example was just one of many reasons why someone would want have a theme.php...another example being, what if I want to define a number of variables....something like
$link1 $link2 $link3 $bgcolor
to allow them to be modified in a separate file or advanced theming module

what if i wanted to create a definition calling some XOOPS function that isnt defined by a the XOOPS smarty system and use it throughout my theme.

what if i wanted a separate block format to be displayed depending on the state of the content of a block requiring me to use an else-if statement.

what if i wanted to decode a cookie rather than adding another hit to the database to pinpoint whether the user visiting the site is a guest or a member and what their member name is if one exists.

My question was:
Quote:

@madfish

yeah that's kinda why I was asking, there seems to be mixed messages about templates_c throught the forums. What brought the question about in my mind was someone saying that templates_c was for compiled templates, not cached templates considering the only thing it does is replace <{smarty_code_here}> with <?php code_here ?>....and I couldnt really deem whether or not that would be in any way beneficial to the speed of the website as opposed to just calling the php directly without the use of templates_c...i could be wrong but it just seems like you'd be removing a step which would be unneeded if using php directly. Blocks/modules would still cache if they're setup to do so.

So basically I got around to thinking. Lets say for example you buy a theme from someone and you put that theme on your site. Someone else can quite easly go to your site and simply go to yoursite.com/themes/yourtheme/theme.html and save it, save your images...and tadaa, with absolutely no effort put fourth from them they can now use your brand new theme that you just purchased. Yes, there are certain precautions you can take to have theme.html restricted from browser viewing, but I've yet to see a theme come with an .htaccess.

Using a theme.php and taking certain security measures in your php file would be quite a bit safer than having a plain html document for your theme, no, your theme is not totally secure...but it's definitely more secure as it would require quite a bit more effort to steal, and you can call the same variables that smarty calls just by using the variable instead of smarty....only problem with writing a theme.php that is that ya cant parse XOOPS smarty in a php file (or at least I havent been able to figure out how)...and therefore it doesnt go to templates_c.

Basically my long-winded question is: Is there any absolute benefit to having your theme compiled in templates_c? And is it considered "okay" around the XOOPS community to have a php coded theme?

Thanks

Yeah, never, ever, ever use fantastico lol.

I was brought into XOOPS by Mr. Theme a couple years ago, to be honest I didn't really like it at first, but it grew on me and now my own business site is running XOOPS.

What you're basically saying is: I don't want to put time into a XOOPS site just for it to become a dead CMS in the near future. I really wouldn't worry about that

Admin >WF Downloads >Preferences >Upload Size (KB)

change it to 10240

well with smtpauth XOOPS defaults the port to 25...SO:

go to /class/mail/phpmailer/class.smtp.php

find


change it to

(I use 587 to connect to gmail)

then find

and on the blank line directly above it put

And try again


OR if you wanna try sendmail again....try changing the sendmail path in your admin panel to


and see if that works....if not, ask your host where sendmail is located

Try chmoding to 757 instead of 777

If that doesnt work:
Quote:
posting the error log would be most helpful ;)

/modules/directfriends/language/english/main.php

As to why the English language file is in German, I have no idea, but you'll be able to change everything there.

@mjz55
Quote:
Here