For People looking where to edit Panel Asset. (the 'wrong' way.)

Codervault · December 2014

Okay so I have not been here all that long, but while trying to modify the core of my copy of this wonderful script i decided to search for an answer as to where to find the file to edit the theme assets.... Now if you have ever searched this you to might have been as disappointed as everyone else here to find that no one wants to divulge this info.

Regardless of their reasons I believe in sharing information and thus this is exactly what I am going to do.

To find asset coding goto library/core/class.theme.php

Now kindly before anyone decides to tell me i should not mess with this file or blah blah blah, please let me put you at ease. I know my way around PHP and OOP quite well. Thanks for your concern but it is not needed.

Let me also say that if you don't know what you are doing, and you mess it up, don't blame me. Always remeber to backup before screwing with core files, or any files really.

Bleistivt · December 2014

Sorry, but apart from this being the wrong way, it is not helpful at all.

What part of class.theme.php would you edit to modify the Panel?

Now if you have ever searched this you to might have been as disappointed as everyone else here to find that no one wants to divulge this info.

There are at least 3 tutorials about how to make a new module that can be attached to the panel and questions about how to hide, add or change the sort order of modules are frequently answered.

I'd argue that even adding to the Panel in your themes default.master.php would be a better way than hacking the theme class.

vrijvlinder · December 2014

no one wants to divulge this info

That is not true, the info is in the files, all you do is search your files for this wonderful software and find the stuff. What we discourage is editing or altering the core default files for a variety of reasons all covered here before.

blah blah blah

You are not encouraged to edit files in the core, there are proper methods to hook into functions and events and don't involve editing the core files. You can clone the files you can create plugins theme hooks modules and override pretty much anything about vanilla without having to ever edit the core unless it is to fix a mistake or patch a security flaw. If you need to do that, you are not doing it right. But that is your prerogative.

Since this is free open source software you are free to do anything you want with your website. And no one here is stopping you. But what you are recommending is not the right thing to do no matter how good at coding you are. Others may not be and this route will cause them issues.

I hope you will be around to help them out in the case that someone follows in your footsteps because it of concern to us who are here helping people learn the right way to use and modify this software.

So telling people to ignore our advice when we spend much time helping others resolve issues and creating plugins and coming up with much of everything people ask to do and want, is not only disrespectful but undermines what everyone else has learned from doing what you are and recommending others the wrong way to go about it is not helpful advice.

Bleistivt · December 2014

To add assets that are not modules, you can use Gdn_Controller->AddAsset

$Sender->AddAsset('Foot', '<div class="MyNewAsset">Hello World!</div>', 'MyNewAsset');

Codervault · December 2014

@Bleistivt
Actually I didn't want to use modules. I am working on a project and I am using vanilla as something it wasn't meant to be used for.

@vrijvlinder
You are blowing it way out of proportion. I understand newbies tend to get lost in editing things in core and breaking stuff. Please do not misunderstand. My intentions are to tell others where to find this info nothing else, and since I do not see any threads on hee stating where they can be found but instead ways to use plugins and css and other things to get around certain things.I decided I would let others know about this valuable info, so others don't have to search every file in the script to find it, as i have done that already.

@Bleistivt
Thank you but I have discovered that already. But not what I needed to do.

R_J · December 2014

Sharing knowledge about where interesting things happen in the framework isn't wrong and you've also added some kind of warning, so I think it's fine. Although I think you are nevertheless encouraging to do something that should be avoided. But the reactions here will disencourage anyone again, I think

If you know how to program, you should know that you should stick to "best practices" and changing the framework instead of extending it, is bad practice.
Simple as that.

Sure, there might be the necessity to change core files. Bad that is the least preferable way to solve a task. Have you considered asking the community how to achieve what you are trying to achieve? Maybe some of the experts can show you a way that even you think is better than choosing the dark side of the Force...

whu606 · December 2014

@Codervault‌

As others have stated, it has nothing to do with programmer experience or lack of it.

I'm putting this information up here for others, who may think that you have offered helpful advice, when in fact you have not.

Editing core files is, for the vast majority of situations, simply unnecessary and is likely to lead to complications when the core is updated.

If, against all advice, and almost certainly unnecessarily, you choose to do so anyway, that's your choice.

For anyone else reading this, you should avoid doing so, not because we don't think you are 'good enough' or 'clever enough', but because you don't need to.

I've edited your thread title to reflect this.

Reader beware.

Codervault · December 2014

@whu606 & @R_J Sorry my need to edit the core files has nothing to do with using this script on the current framework. II will explain so you see what exactly I am doing. I am porting the script to use a different framework. Laravel to be exact. So my need to change core files has to do with that. Nothing else.

Reason why i am doing this is because I know Laravel much better then this framework and It's something to challenge my mind.

@whu606
I totally understand everyone's points. Not trying to cause any trouble. just wanted to share where to find where to edit this since i couldn't find it anywhere else, not even on the wiki. Just incase someone else decides to port the system to something else. I would ask though that instead of editing the title and saying wrong way, you edit ti to say what it is for, for porting needs, and nothing else.

x00 · December 2014

If you wish to edit the core field you are a making a fork, in which this .org forum is not for fork questions.

However even if you are making a fork, and using other frameworks your suggestion still really isn't how to go about it.

x00 · December 2014

I suggest you actual don't make a fork at all, it probably isn't necessary.

It would be better if you wrote out in a new discussion what it is you actually want to do.

hgtonight · December 2014

I agree with @x00, porting Vanilla to a framework shouldn't require you to edit Garden at all. You should only be porting what is in the /applications folder. Anything the applications reference needs to be shimmed in by you on top of Laravel.

On top of this, anyone doing porting is probably using an IDE, which makes the question of "which file is this in" extremely trivial.

Codervault · December 2014

@hgtonight Actually I don't use IDE's. I am porting to Laravel to use Blade template system which is alot more powerful then smarty and allows you to do much more with alot more ease. I have noticed some problems trying to get the theme to work in the ways I want it to. The point of smarty is to separate logic from design. and the amount of editing I had to do just to get simple modals to display outside links is a bit of a headache.

I don't clearly understand everyone's objection to how I am choosing to edit the system. Kinda makes me feel as if you posters think I am undoing everything you worked hard to setup.

It's a bit disconcerting that you guys, don't want to accept an expansion of an idea. Which is the whole point of opensource.

I am not here to cause trouble. I just want my flavor of this system to work a bit differently and use other systems and libraries to get the job don. I want to expand on vanillaforums framework. I see nothing wrong with this.

x00 · December 2014

codervault, it is nothing to do with that. Honestly we don't care. We don't accept it simply becuase it is not necessary, or a good approach. It is really that simple. So if you want to this to stand as advice expect criticism.

The people replying most of them did minimal or no contribution to the core, and even so it is no skin off their back what you do for yourself.

If you are forking the framework to create new spangled framework, that would be one thing, but that is not the reason why you are doing it. You are forking the framework becuase this is the first workable solution that you came up with. As advice that is not good.

You opened the OP, expecting criticism and you were right to expect it. Not everyone can know everything. If you approached your "question" differently, people might help you with what you want to do.

The advantage of not forking the core, is you can update it easily, and you don’t have maintain it as a whole.

R_J · December 2014

@Codervault said:
whu606 & R_J Sorry my need to edit the core files has nothing to do with using this script on the current framework. II will explain so you see what exactly I am doing. I am porting the script to use a different framework. Laravel to be exact. So my need to change core files has to do with that. Nothing else.

I think that's a great idea. If I had time and skill I would try to port Vanilla to another framework, too!
But as stated by other and smarter guys than me, I wouldn't try to port Garden to another framework, because that way I would emulate a framework with another framework in order to run an application on top of that emulation. No need to port anything other than /applications folder.

@Codervault said:
I am porting to Laravel to use Blade template system which is alot more powerful then smarty and allows you to do much more with alot more ease.

So you only want blade? I bet this could be done "easily" with a plugin. And I could swear I have seen a plugin for some other templating engine before, but I do not find it right now

hgtonight · December 2014

@R_J said:

Codervault said:
I am porting to Laravel to use Blade template system which is alot more powerful then smarty and allows you to do much more with alot more ease.

So you only want blade? I bet this could be done "easily" with a plugin. And I could swear I have seen a plugin for some other templating engine before, but I do not find it right now

Swapping out the template engine could be done as an addon (I would go with application). You write your own theme class, and register that in the bootstrap process as an alias for Gdn_Theme. Create any other overrides you need. Completely done independently of the Garden framework.

@R_J I think there was a plugin for Mustache templates floating around somewhere.

@Codervault I take no issue with you contributing. I take issue with what you contributed. You described a fork but didn't share it.

Saying "hey the theme class is in this file" is not useful in itself. Share how you found it. That would be helpful for others that are looking to fork the core.

vrijvlinder · December 2014

@Codervault said: My intentions are to tell others where to find this info nothing else, just wanted to share where to find where to edit this since i couldn't find it anywhere else

So you are telling people where to find this info but you are not telling them what to do with it.

What is the point of knowing where files are if you don't know what to do with them once you find them ?

don't want to accept an expansion of an idea

You are not the first who has come in here with such ideas. They never came back so most likely their idea did not come out as they hoped.

If you want to expand the framework maybe you should be at github pushing code and expanding with the people who made this.

I find it interesting that people are so eager to turn Vanilla into what it was not made for instead of building their own frameworks from scratch like Vanilla did. Which amounts cherry picking code to make a frankenframework...

Bleistivt · December 2014

@hgtonight said:
@R_J I think there was a plugin for Mustache templates floating around somewhere.

https://github.com/vanilla/addons/tree/stage/plugins/Mustache

Codervault · December 2014

blade is a core piece to laravel, so it is not so easy to just write a new application. also the smarty version used in vanilla is quite a bit behind, 2.6 doesn't work with php5.4, 2.8.5 smarty does but that won't work since my php is 5.5 and thus you need to use smarty v3.

Now then knowing this since i have quite a bit of files I will need to edit since smarty is used as a core library for vanilla there is quite a bit of work that needs to be done either way. For the same amount of work to update smarty i could just essentially get rid of the problem all together and wrap VF into Laravel.

Bleistivt · December 2014

also the smarty version used in vanilla is quite a bit behind, 2.6 doesn't work with php5.4, 2.8.5 smarty does but that won't work since my php is 5.5 and thus you need to use smarty v3.

I am running Vanilla on PHP 5.4 and have been running it on PHP 5.5 for a short time without problems.
Are there any specific functions that don't work with 5.5?

Now then knowing this since i have quite a bit of files I will need to edit since smarty is used as a core library for vanilla there is quite a bit of work that needs to be done either way.

It is a core library, but you can overwrite core libraries and use you own, see this discussion:
http://vanillaforums.org/discussion/26740/how-to-override-gdn-email-phpmailer

I also found this
https://github.com/PhiloNL/Laravel-Blade

For the same amount of work to update smarty i could just essentially get rid of the problem all together and wrap VF into Laravel.

For the amount of work to port vanilla to a different framework you might as well build your own forum software on top of laravel.

Don't get me wrong, I would be interested to see the result of your endavour, I just don't think this is something that can be accomplished in less than ~4 months of work.

Codervault · December 2014

smarty 2 is for php 4, thus on php 5.5 i can't even get it to compile correctly. smarty 3 compiles correctly. there is also alot of extra things that took more code to do with smarty 2 that you can easily do now with smarty 3 that didn't take any extra code to do. I will list the differences so you can see them.

Known incompatibilities with Smarty 2

Syntax

Smarty 3 API has a new syntax. Much of the Smarty 2 syntax is supported
by a wrapper but deprecated.

The {$array|@mod} syntax has always been a bit confusing, where an "@" is required
to apply a modifier to an array instead of the individual elements. Normally you
always want the modifier to apply to the variable regardless of its type. In Smarty 3,
{$array|mod} and {$array|@mod} behave identical. It is safe to drop the "@" and the
modifier will still apply to the array. If you really want the modifier to apply to
each array element, you must loop the array in-template, or use a custom modifier that
supports array iteration. Most smarty functions already escape values where necessary
such as {html_options}

Delimiters and whitespace

Delimiters surrounded by whitespace are no longer treated as Smarty tags.
Therefore, { foo } will not compile as a tag, you must use {foo}. This change
Makes Javascript/CSS easier to work with, eliminating the need for {literal}.

Unquoted Strings

Smarty 2 was a bit more forgiving (and ambiguous) when it comes to unquoted strings
in parameters. Smarty3 is more restrictive. You can still pass strings without quotes
so long as they contain no special characters. (anything outside of A-Za-z0-9_)

For example filename strings must be quoted

{include file='path/foo.tpl'}

Extending the Smarty class

Smarty 3 makes use of the __construct() method for initialization. If you are extending
the Smarty class, its constructor is not called implicitly if the your child class defines
its own constructor. In order to run Smarty's constructor, a call to parent::__construct()
within your child constructor is required.

class MySmarty extends Smarty {
   function __construct() {
       parent::__construct();

       // your initialization code goes here

   }
}

Autoloader

Smarty 3 does register its own autoloader with spl_autoload_register. If your code has
an existing __autoload function then this function must be explicitly registered on
the __autoload stack.

Plugin Filenames

Smarty 3 optionally supports the PHP spl_autoloader. The autoloader requires filenames
to be lower case. Because of this, Smarty plugin file names must also be lowercase.
In Smarty 2, mixed case file names did work.

Scope of Special Smarty Variables

In Smarty 2 the special Smarty variables $smarty.section... and $smarty.foreach...
had global scope. If you had loops with the same name in subtemplates you could accidentally
overwrite values of parent template.

In Smarty 3 these special Smarty variable have only local scope in the template which
is defining the loop. If you need their value in a subtemplate you have to pass them
as parameter.

{include file='path/foo.tpl' index=$smarty.section.foo.index}

SMARTY_RESOURCE_CHAR_SET

Smarty 3 sets the constant SMARTY_RESOURCE_CHAR_SET to utf-8 as default template charset.
This is now used also on modifiers like escape as default charset. If your templates use
other charsets make sure that you define the constant accordingly. Otherwise you may not
get any output.

newline at `{if}` tags

A \n was added to the compiled code of the {if},{else},{elseif},{/if} tags to get output of newlines as expected by the template source.
If one of the {if} tags is at the line end you will now get a newline in the HTML output.

trigger_error()

The API function trigger_error() has been removed because it did just map to PHP trigger_error.
However it's still included in the Smarty2 API wrapper.

Smarty constants

The constants SMARTY_PHP_PASSTHRU, SMARTY_PHP_QUOTE, SMARTY_PHP_REMOVE, and SMARTY_PHP_ALLOW have been replaced with class constants Smarty::PHP_PASSTHRU, Smarty::PHP_QUOTE, Smarty::PHP_REMOVE, and Smarty::PHP_ALLOW respectively.

This post was edited to take advantage of MarkDown formatting