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

but what if one with enough knowledge recreates the theme from a print screen?
bottom line nothing is impossible and unless you have theme protected by some license there's nothing you can do about it

ultimately, no... if something is live there is no way to protect it against rippers.

However, php does make it more difficult, as the source does not generate php code.

I think what Sublime is getting at here, is why is it that that you can so easily access the theme.html of any theme you want. Where in most other php based engines there have been measures taken to protect the work of their local designers.

Its one of the big reasons that there are only a handful of designers for XOOPS. Why would anyone who isn't already a member and producing themes want to come and have their worked ripped so easily? XOOPS does not provide a secure environment for commercial designers, doesn't even try. End of story.

Look here - http://xoops-tips.com/news-article.storyid-25.htm

I think you missed the point...

Quote:

I could be wrong but I thought the job of templates_c was to improve speed of xoops, it was never intended as a mechanism to protect themes (or otherwise).

@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 ....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.

Just so I'm sure I understand...

Your primary question was "What is the benefit of templates_c?"

And your primary concern is protecting the file or files that are used to generate the HTML and images presented to the browser.

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.

So I think I get the point, now.

No answers here, just another perspective.

Some of what you are proposing, though, sounds more like the data layer than the presentation layer, but I have been wrong before!

Have you looked at how 2.3 does themes? A completely new approach - the output layer (themes and templates) can be leveraged for more than just the HTML output. They can also be utilized for RSS, RDF, PDF and XML - whatever form of output you desire.

Take a look here - http://xoops.svn.sourceforge.net/viewvc/xoops/XoopsCore/branches/2.3.x/2.3-main/htdocs/themes/default/

Not theme.html or even theme.php - but theme-canvas-default.xotpl

We'll see how things go.