Dolphin 7 Templates Tutorial

In response to this blog about the Dolphin template system I will be writing a templates tutorial how to. It will show you how to create your own templates.

Please submit a list of items you guys want to learn how to do. For example, how to add a background or how to change the logo.

I will pick the Top 10 Items that gets the most votes so submit your request early. Voting starts today and we will end on May 2, 2010.

If we end up with more in the list then we can add those to later on. This thread will organize an FAQ that I hope BoonEx will post for anyone wanting to roll their own template and design.

Well, i actually thought i knew how to do this, but i guess not.

So what i would like to learn is how to do a black template. All black. Background of both page and boxes like my site. No white anywhere except for text. Just various shades of black, so it looks good everywhere without having to touch the CSS of any of the modules with exception to the forum of course.

I think it's safe to say that there will be some exceptions when creating a highly customized template. I know from experience that there are parts that I've worked on where I had to recode to make it work the way I wanted and that did include going into the modules.

same as daeno how to change the background color of boxes. and also how to change different text.

aaah..... specially how to change main menu buttons ( colors or images and text). because without main menu change there is no point of changing the background and boxes colours.

thankyou.

It's allways been little stuff for me. A text color that was black, so needed to be changed to white, or a div set to a white background, or a border color or something simple. No more than a couple of classes, but so far for my black template i have had to change one or 2 areas in almost every module. From what i read in this blog, i should not have to. Or at least thats the impression i got. So if i am doing something wrong, obviously i want to be corrected.

James please make Andrew wake the programmers for God's sake, what are they doing all day? Do they even read the blogs, should we stop writing? This silence is very annoying.. I feel we are fighting for someone who doesn't care about his own creation.. This lethargy and lack of interest for your members, clients and developers will be fatal to you Andrew some day..

They are. I have seen at least 2 of them today responding to posts in the forums. So they are here at least.

On the original forum post I read it as that some designers do not know how to suppress via the tmpl area for the modules. I still think that there is an element of that in the original blog post. However after re-reading mastermindsro orginal posting I would tend to agree that there could be a better structure, so that those design mods do not go off in their own direction, with their own css meaning that in order for a mod to be compatible with a particular template, extra work need to be put into accomodating that particular mod as it has its own unique css.

Let me just clarify my above comment. When I say " I still think that there is an element of that in the original blog post". I actually was referring to the comment thread in response to the blog post.

Ok, I did a quick tutorial that you can have a look. It's a draft but gives you enough info so you can override your module's css files. The one that seems to get the most attention is when a module uses a css file directly. This tutorial addresses that and will show how you can override the module's css from your template so you don't have to touch any of the module files directly. Effectively, it means you just drop in the template file and it will run.

Here's an example of the wall mod that uses this technique:

Here's the link to the tutorial that shows how to override the Wall module's view.css file:

http://www.boonexnerd.net/dolphin-7/blogs/entry/How-to-Create-a-Dolphin-7-Template-draft

Please try it out and let me know if you have any questions. If I can I will post a live sample where you can switch from UNI and JTADEOBLK1 themes.

When I finish the rest of the tutorial, I will post an update.

Forums are handled a bit differently but the same concept.

Joe, the purpose of this exercise is to avoid having to modify the css module files directly. Doing so would be a horror scenario as mastermindsro pointed out. The method works for all the other modules except for special case scenarios that I specifically notated in the draft tutorial and that you pointed out.

In reply to your other questions.

re:"Sorry James.  I'm afraid I can't buy into your suggestion of just dropping css files such as /modules/boonex/wall/templates/base/view.css into your custom templates css directory.   Where then, should I put the other 12 view.css files that belong to the other Boonex modules?  Consolidate them into a single view.css?"
No. You don't have to consolidate all module view.css files. That would be insane.

There is a reason why the styles in each of the view.css files were given unique names. So you can target and override just the ones you need to override. All the other styles you can safely ignore. That is the purpose of the unique names in all of the view.css files. In many of my productions I don't even touch the view.css except for the bubbles. So that is a total of maybe an additional 12-15 lines of styles and it addresses the central issue of modifying the modules directly. That is a much better scenario than having to work directly with the modules and then having to duplicate to accomodate another template. My method avoids all that.

In my example, I could get it down to 3 lines of css styles. So no, you don't need to put the other 12 view.css files into the templates folder. If you need anything more efficient than that then I can't help you.

re:"Should I then consolidate all 12 Boonex modules main.css files?"

Again, no. you don't need to consolidate the 12 modules main.css files. Keep in mind, only extend the ones you need to work with. The others can stay as they are.

re:"Then, you suggest dumping all the module images in your custom templates images folder."

You are incorrect there. I did not suggest that at all. Just use the images you need. You don't need to add "all the module images". That would be redundant. Remember, only use the ones you need to use. The other ones can stay as-is.

re:"I don't have as much a problem with that, but I'd have to hope I'll never have a module come along with conflicting image names."

There is no way to avoid that. That is something the module makers will need to take into account.  For example, I can't control if someone decides to name their main site root file index.php thuse replacing their main Dolphin index and wreck havoc on a site. You can't control that. That is where common sense comes in which unfortunately is not so common sometimes.

re:"Your method, while keeping your custom template css in a single folder, obfuscates what your template is changing."

What do you mean by this? I think it does the opposite. It unifies the whole template into a neat bundle that you simply drop in the templates folder and bam! it works. It can't get any easier than that.

Here are the instructions:

1. FTP template into your templates folder.
2. Select template in your admin.
3. Template now works across your entire site.

No need to touch anything.

re:"If you could put module specific css in your custom templates directory, and still maintain a directory structure that keeps everything organized, that would be something I could buy into."

This method takes into account the issue of having to go each and every module and then modifying those files directly. That original method would not work if another theme was applied. The method suggested can be applied to several themes without touching the modules which was the whole point of this exercise.

re:"If were possible to have a templates/tmpl_CustomTemplateName/modules/boonex/wall/css/view.css directory structure for various modules from various vendors, putting all the css into a single folder would make sense to me.  Putting everything into a blender and losing organization does not."
"If" is a powerful word. If you have a better idea then let's hear it. At this time, this method is the one I am using and I've had the great amount of success.

If any are interested in the rest of the tutorial let me know. Chime in this thread. If I there is enough interest then I might finish the rest of it.

Thanks to all who've commented.

...sip...

re:"Then.... what is a person to do with the browse.css file for sounds, videos, and photos?   Do I append all that css to the main browse.css that already exists in /templates/base?"

No.

Eek! Nice jtadeo. I feel like a toddler with a new puzzle now. I think I will fit all the bits in the right places in the end. Thanks.

Well, guess you have proven it can be done.

Now, could i get a template designed in this way certified by boonex?

This is quite interesting. I am still trying to decide what i would prefer to do. It is nice to know that there is another way.

I was going to do a complete set of my basic black template in several colors. But after the nightmare i had with the black one with all the little spots here and there that i kept finding that i missed (all in the modules) i put off that idea for a while.

I've posted on the template issues with Dolphin before, so I won't repeat it all here, but I agree with mastermindsro's observation on how module templates / styling is handled. It is not good and ideally needs to be improved.

I think that generally there are simply too many css files, and the practice of importing files into the templates is just daft. If a template includes certain base elements, then add them to the template. I cannot see the point of trying to be clever in using import statements to include some base template elements - what is this trying to achieve?? saving some disk space?? The whole /base/css. folder is just 265KB, the only thing that happens is that it adds unwanted and unneeded overheads - extra file reads that are simply not necessary. In fact I would personally get rid of base altogether and integrate it into uni - there is just no need to separate it out. Why load up base style elements only to overwrite them with the template style elements?

Additionally, all 'standard' style elements should be combined into a single css file - some of the css files have one element in them - it's simply daft. The overhead of loading all of these files is killing page load times. 80% of the time a browser spends getting and rendering a page is spent fetching files from the server - on my stock installation of D7, there are 22 css files loaded - YES 22!! Why?? It's simply not necessary!! That's 21 file open / file read / file close / read buffer flush transactions that need not happen! 42 if you consider that each css file probably just has an include statement that includes another css file from the base template. It's just madness.

Regarding module templates - they should be in the templates directory. This is the orthodox way of handling templating for plugins and modules. Okay, so modules will each have their own css file, this is unavoidable - but only because it is possible to install each module independently.

This is the correct way of handling the css - the fewer files there are - the more efficient everything is = the faster everything is + the easier it is for all to understand.

However... That is not the way Boonex have done things. But just because they have decided to create a abomination of a template system, doesn't mean we have to put up with it.

Jtadeo's solution might not be the official way of doing things - which as far as I can see is to create an additional 'tmpl_new' folder under each modules template folder, but it is a more 'correct' way of doing things as far as efficiency is concerned, and without doubt a more workable solution for those of us used to more orthodox ways of handling templating.

I personally might choose to name the file module_styles_override.css or perhaps simply modules.css, but this is just makes sense to my way of thinking - it may be different for you.

HL, I am surprised that you would support Boonex's way of doing things here, you are normally very vocal about efficiency, and the correct way of doing things. It was only a few days ago that you were complaining about Boonex's 'spaghetti logic' when you were trying to figure out your image hover mod - now you seem to be endorsing it.

As far as getting Boonex certification for templating, I don't think that even Boonex's own template could get certified, it's simply not well structured enough.

/DM

Ahh yes - almost forgot...

Top marks for jtadeo for stepping up and getting this together.

Good job James. Well written toot as usual. If you are new and reading this, do it James' way, it's most $efficient. Imagine a world where you can put in any color template and the whole site just matches up. Plates on modules was not needed-they should follow the class names of the site overall. If you plan to use a few templates, install your modules then bring the css and images to the main templates folder like james does. It may only be 54kb but times that by hundreds of thousands of requests an hour and your site is just a little better. Plan to be big from the start. Once your done you can use the yslow plugin and see the difference.

HL thanks for getting everyone new confused. Please argue in an area you are an expert at. James Tadeo is the most sought after template expert here I believe... I will listen to him. I sure hope everyone reading this does too.

I think that for a custom template, anything within the 'template' folder is free to be changed and modified as the template writer see's fit. It is often necessary to change things like script elements to achieve certain effects , this is why they are put within the templates directory - so that they are free to be edited without affecting the rest of the code - as are the rest of the files there. This is the whole idea of templating. If you limit the designers ability to change the template by insisting that it conforms to a strict set of rules, all that happens is that everyone's templates look exactly the same - just different colours.

HL, I can appreciate that your choice is to use the module/templates directories, but to say that the other method is not a good idea is simply not founded. There are no incorrect answers here, just different ways of addressing the same problem, each with their relevant merits.

In response to your earlier concern about not being able to easily find the CSS associated with modules at a later date, I would suggest that if you do not already do so, it's a good idea to keep a detailed log / journal of the mods you carry out to your site - not only does it help with situations like mod reversal, but it also provides a 'backup' that allows you to repeat the mods should the need arise - very helpful when it comes to upgrade time and ten of your mods have stopped working.

I personally would like to see an 'Afterburner' style template for Dolphin, (Afterburner is a re-written Joomla template that condenses page load times), this would be a complete re-write of the templates system and end up with something that does not resemble the stock template in any way at all. Would this be considered wrong? I do not think so.

/DM

Well i have to agree with HL on this one.    Who's to say i want all my pages to be black on every single page of the site.   What if i want blue for blogs, Green for store, and red for events. ....     I would need to either go in each module folder and change the css   or bring each module css upfront to the /tmpl_name  folder and edit the css in there.  Either way its work for the designer but may be easier for the end user if it was all up front.

I see james point having everything upfront is nice.  Again have a look at my case where i want colorfull pages for each module.... 

I guess you need to look at it like it was a mod install for dolphin 6 now.  Look in view.css for line blah blah  and change it to this.  Look at line blah blah  and change it to that.... 

Either way you look at it,  its work.   Its not something that is going to take you ten minutes to complete anymore and there is no way around it. 

So Again after thinking about it, in the end it really don't matter how the job gets done as long as you the end user is happy with the template and the way it functions then its all good.   

In reply:

re:"What if i want blue for blogs, Green for store, and red for events. .... "
With my method you can do all that and much more. With the old method, you are stuck with one template that needs to directly access certain key modules, which in my opinion increases error. My method avoids all that because you don't directly touch the modules.

re:"I would need to either go in each module folder and change the css"
With the old way then yes, you will need to do that for each and every module where the css is used. With my method, no. For example, if I had to edit the view.css file, I just have to edit 1 file. With the old method, one has to edit 12 in addition to having to navigate 12 directories. That a total of 24 system objects. To do the same thing using my method, 2 system objects.

re:"or bring each module css upfront to the /tmpl_name  folder and edit the css in there."
dolphin_jay, my question to you is: Where did you get the idea that you had to bring all of your module css upfront? I never at all suggested the method you are describing. That is not how it's done.

That's where some people are confused. There seems to have been this preconceived notion that you had to do that. You don't have to do it for all the modules. I have no idea where people got that idea. I never wrote that in my tutorial and the BoonEx documentation doesn't say that either. You just need the one that is called by the module. The modules and Dolphin in general will inherit the template design.

In my example, I was requested to work with the view.css file. The view.css file is one of the most difficult css files to deal with as it relates to the modules. It has has stumped many template designers so much that they then needed to go directly into the belly of the modules and manually adjust it. That approach causes a cascading problem when a new template is introduced. My method avoids all that with 1 file. This is a problem.

Continuing with the view.css file. Some interesting notes about this css file:
1. It's called directly by certain modules.
2. It's not included in the templates/base.
3. It's not included in the templates/tmpl_uni folder.
4. It is included in 12 modules so that you will have 12 css directories with 12 view.css files to deal with.

For the other css files there is no problem in overriding the css from the templates folder. So it's easy to deal with. As for the view.css file, it is the exception and thus a workaround was needed. Once again, a workaround like this is not needed for all the others.

What I proposed was use 1 css file to control all 12. But only extend the ones you need. The file is very light. So in essence anytime you want to work with the view.css file, then you only need to modify the one file. I only have to touch 2 system objects. With the old method approach, you will need to touch 24 system objects.

You can also stay organized with this approach, I append my css styles with a comment. For example:

/*wall css*/

.....


/*file css*/

....

and so on. By commenting the css, I can instantly see what that css style is for and change it on the spot. I don't have to navigate through 12 directories to change the view.css file to match a them style. 1 directory and 1 file to rule them all. It can't get any simpler and efficient.

re:"Either way its work for the designer but may be easier for the end user if it was all up front."
If set up properly, it will allow the end user to not have to deal with modules folder if there is ever an upgrade. I can tell you right now, if a module or more had to be upgraded, some who use the old method may need to spend some time dealing with modules directly. My approach does not touch the module files directly and it does no harm.

re:"I guess you need to look at it like it was a mod install for dolphin 6 now.  Look in view.css for line blah blah  and change it to this.  Look at line blah blah  and change it to that.... "
Yes, that is a step backwards and going into each module to change css files is a step backwards. With my approach, anyone who uses my templates will never need to do that. The modules are hands off.

re:"Either way you look at it,  its work. Its not something that is going to take you ten minutes to complete anymore and there is no way around it."
With my method, I can change 12 view.css files in mere seconds with 1 file. The old way approach will probably take 10 minutes or and by having to deal with 24 system objects. The old method also increases the chance of error as one is modifying the modules files directly. Again, my method does not touch the modules files.

re:"So Again after thinking about it, in the end it really don't matter how the job gets done as long as you the end user is happy with the template and the way it functions then its all good."
By going the old method route, then you are stuck to one template design and dealing with the modules directly. In my opinion why be limited by that approach and increase your chances of erorr. Where's the logic in that? However, if you have resolved that you are ok with 1 template then I guess this info is not important to you.

btw, we haven't even gotten to the forums. I know several template designers that have nightmare scenarios with that. My solution solves all that.

Again thanks for everyone's input.

...sip...

This is for JTadeo (because you sound so smart) or anyone else on here.......H.E.L.P.!!!!!

I have a friend who i thought was an expert or good at using dolphin 7 well he is not, so now i am stuck with dolphin and having trouble figuring it out..... if we dont have to be webmasters to understand or use dolphin why does it seem so hard to make the few minor changes that i want, and why arent the switch black templates that are 6.1-6.6 not compatible with dolphin 7 ???? 

can someone please share with me how to load the template so i can use it i thought that the templates would upgrade automatically with any changes that dolphin makes?

can someone help me or assist me in this progress i want to meet a 2 week building goal i have so i can put some people to work for me that need jobs due to being laid off, and i want to be able to share what i have learned about this process with other females and males like me trying to figure this free social networking site out. i am NOT a webmaster or studied web design custom building graphics or anything i have a vision and well dolphin has it laid out i just need to know how to gear it towards what i need it for and be able to figure out how to load content

thank you in advance for your prompt responses i am humbled as well as greatful for any assistance or guideance you can provide me. Please send me an email if you can help me or just point me in the right direction.... and i can gladly provide you with the info on the problems in addition to the template that i am having. THANK YOU THANK YOU THANK YOU!!!!

MISSMILLION06@YAHOO

Gayle-

Suggest you look at these two sites:

http://www.boonexnerd.net/dolphin-7/

http://www.mrpowless.com/

Dolphin 6 templates don't work with Dolphin 7.... end of story.   If you want a different look, do yourself a big favor, and check the Market for one that you like.  You'll find some great templates here at very reasonable prices: http://dolphintemplate.com/category/templates/

O.K., Thank you for your feed back on 6 not being comp. with 7...........................

thank you for the links i will check them out.

thank you!

gayle-