How do You define the layout of Your Drupal sites?
Which techniques do You find most useful?
I'm quite old-school and stick to templating.
It's true that I haven't practices the others too much. Yet, I'm also afraid that HTML output from Panels, Fusion or other fancy helpers would be twice as big as reasonably customised Zen.
Such techniques, however, probably reduce development time.
What do You think about these "clickable" solutions?
playing with template files tpl.php
Panels
Fusion + Skinr
Display Suite
Some articles to the topic
Assembling Pages with Drupal - Blocks vs. Context vs. Panels on Lullabot
dynamic page layout in Drupal on Drupal Groups
Display Suite vs Panels by Jan-Yves Vanhaverbeke
When you talk about Panels and Context which you didn't mention, they are much more than simple clicky layout tools. They can be used as such, but if you only want to setup layout you shouldn't use those two. That is not what they are meant for. These modules are used to create rules for how and what to display given the context of something, fx a node, a term or something else.
Related
This is a serious question, specifically relating to the many frameworks out there for Wordpress and Joomla - Warp, T3, Gantry etc. What I dont understand is how they are different to a starter template and what exactly you are supposed to do with them - simply child theme them or is it a whole other codex to learn? I mean, all of the native codex is there with Joomla and WP anyway to construct a theme simple enough so what good does a whole proprietary app do between your design and the CMS? Are they faster to develop with?
What confuses me is that people seem to love them and claim that they make life easier but I dont get how adding another technology to learn can make things easier. Like I say, it is a serious question, not one for effect to make a point.
Can anybody define the difference between a framework and a starter template? I ask in part because I am one of those anxious developers who always feels like I am somehow missing a trick or doing things the "wrong" way - what am I missing?
This is definitely mostly an issue of definition, and I can guarantee that some cases will not follow what I outline below. Obviously, anyone is free to call the template/framework by whatever they want.
Generally though, a template is comprised of basic HTML and CSS that works with the platform (Wordpress, Joomla, etc) that is used to build the output to the page. In Wordpress, this contains the loop and other constructs to get all the content for the page. In Joomla, it outlines all the module positions available and such.
Typically when you purchase a higher end theme, you will have significant choices on the backend to customize the theme without having to actually code. These parameters let you typically change colors and such.
Some of the theme developers and others have taken this parameter settings system to the next level and made it into a framework. In all the cases that I've seen, "framework" is really the basis for the template parameter system. In this way, you can have consistency between different themes and expect the same settings and features between different themes. This is why they use a different word, because it really isn't a "theme" any more. It really is like a "theme engine" in that it is a backend system for changing things in the theme.
Yes, many platforms offer some basic options for editing the theme out of the box, so in most cases, the framework is really an improvement on the base platform's theme engine.
It's been my experience that a theme will be a visual style along with a set of theme options available in the admin (in addition to Customize if it's supported).
Theme Frameworks on the other hand, like Thesis, are installed just like a theme but have a very vanilla visual style that you build your theme on top of. Usually the framework provides many added features that aren't available in WP core.
tl;dr - Themes frameworks aren't installed and used right away, they are installed and built upon to deliver a site.
I run a design firm and have frequent need for Drupal development. I'm looking for a bit of guidance on a Drupal workflow that will work best for my company.
My experience working with Drupal developers in the past has been great for back-end development, and chaotic for front-end development. Projects end up with multiple and inconsistent CSS styles, and doing quality control on the visual aspect is very time-consuming.
Moreover, I'm a front-end coder, and use HMTL/CSS/JS prototypes for all phases of projects. I would prefer if the front-end coding I do to was used by the developer instead of going to waste.
However, this workflow hasn't been compatible with Drupal dev partners so far. Because they use themes, and retro-fit them to the design I give them, they aren't able to use the HTML/CSS/JS work I do. Moreover, I have a responsive framework that I like (Foundation), and my developers want to work with the standard responsive Drupal theme (Omega). I don't like Omega because it isn't fluid.
Then there's things like my developer telling me they can't do a carrousel that uses CSS (background-image), because the available Drupal carrousel modules are all based on using the HTML img tag. Does everything have to be based on modules?
Going back to the HTML/CSS inconsistencies and the time-consuming design QA, I think this comes from trying to retrofit a theme. The code is very messy and it makes it hard to target elements for styling. It also makes it impossible for me to do my own CSS changes if I want.
So, in short, I'm looking for a completely different design workflow, and I'm looking for feedback on whether it's workable in Drupal without inflating costs.
Is it possible in Drupal to use front-end code (provided by me), throw in some PHP tags, and end up with cleanly-coded pages, instead of relying on themes? Would this reduce costs (because the HTML/CSS/JS is provided), or would it inflate costs (because it's easier to use a theme)? Are there any security issues involved? Are there update issues involved? In short, what's the big advantage with working with pre-fab themes?
I really, truly appreciate your comments.
We usually develop from the backend to the front end. Modules like Views add many div tags, classes and tags so the theme developer can make better use of them and fine tune the design.
I do not think that is a "messy" code unless you are doing all of the work in tpl.php files.
Modules simply processed the data. It should not heavily theme the output. For a better understanding, see the image below (from drupal.org):
If you want to do any database intensive work in the template level, you will have to load many stuff again that you could simply do in a module.
In my opinion, if your developer is not hardcoding the HTML stuff, he is doing it right.
Keep in mind that you can override most of the theme functions so you already have the flexibility if you want.
Is it possible in Drupal to use front-end code (provided by me), throw
in some PHP tags, and end up with cleanly-coded pages, instead of
relying on themes?
Yes. But you can't simply use slider-image.php like files for that. You will have to add necessary theme functions to and pass the variables to it. IMO, it's relatively more work if you need to completely rewrite the theming functions.
Would this reduce costs (because the HTML/CSS/JS is provided), or
would it inflate costs (because it's easier to use a theme)?
I do not think so. If you have multiple backend developers working on code, ask the theming team to make changes to HTML/CSS. CSS can make your site look worse, and a security bug can ruin your business, expose all your user information or even worse.
Are there any security issues involved?
Most likely. Default theme functions tend to come with much better security. Even though few bugs come out, they will get fixed soon by the community.
Are there update issues involved? In short, what's the big advantage
with working with pre-fab themes?
Because there is a whole lot of work that you can simply adopt. That will also block you from adopting others' CSS work though.
I work somewhere with highly stylized well thought out front end builds which are almost not compatible with the way Drupal theming is handled currently. Having front end developers track down bugs is also very problematic. It looks like there's some acknowledgement of this in Drupal 8 at least. At this point we frequently rework Drupal to work as an API and then build a lightweight PHP Framework app on top to pull content when we need it which gives us total flexibility to do anything we want with the frontend. Another alternative is to checkout Expression Engine where you are explicitly telling it what markup you want outputted and how you want your content to be placed in the markup.
The holy grail would be a very lightweight layer that was part of Drupal where we could use Twig to pull the content the way we want it and all HTML output was defined in Twig.
A bit of explanation - I'm a Drupal 6 developer who has never used Panels, but was looking at it for a new site that I was going to initially build in D6, but am now going to build in D7 since the modules I need all seem to be available.
This will be my first D7 site.
For this site I was going to use Panels in D6 for the following reasons:
The majority of the pages in the site will have a sidebar, but the composition of that sidebar will vary, and the 'content area' may be subdivided in up to 3 divisions, either in 1+1+1 or 2+1, including back and forth from one to the other in the same page (ie 2+1 on top of 1+1+1).
The homepage will be completely different and have its own layout.
Some pages, such as the forum, will be "full-width" and will have no sidebar whatsoever.
It seemed like Panels could accomplish all of these (if not, that would be good to know :-).
In Drupal 7, is Panels still a good bet for this, or is there a better way? It seems beyond what my understanding of simple blocks and regions can do, but I may be wrong...
It's all possible with regular blocks and regions, Panels is just much easier to administer, and has the added advantage of being exportable.
Although its possible to achieve the results without using Panels at all as indicated by mirzu's answer above but I would highly recommend you to use Panels module, because Panels are nothing but visual page builders that allow you to change your page's layout by simple drag and drop. You can define and customize your layouts easily (without touching any CSS or HTML) right from the front end.
Panels also allow you to embed content (views, nodes, mini-panels etc) within regions that you can specify in the layout which allows tremendous page customization.
IMHO Panels module is quite easy to configure and saves a lot of time and you should use it instead of the block/region combination.
I've been coding in PHP for 4 years and even I find it so convoluted and hard to grasp. I have no idea how they expect designers to manage theming.
I know basic theming, theming with tpl files, views templates, contemplate templates etc. However I get lost whenever I enter the template.php file.
I needed to theme a node input form for a custom content type. I wracked my brain over it with like 7-9 tutorials and it's still not coming together. I understand why module building can be complicated - because most people who work with modules are developers anyway.
However, when even a developer can't understand theming, it's definitely over-engineered!
Maybe it's my fault, maybe I didn't learn Drupal properly. In that case, is there a step-by-step system to becoming a Drupal guru?
Theme is really not that difficult, if you only know basic php. You have 3 ways of altering the markup, the css and js, you should be able to handle.
Template files. By creating a template file in your theming and naming it correctly, it will take precedence over other template files, and you can thus create custom markup for views, nodes etc. By creating a template for a noce type, you can do stuff like printing out the cck fields in any other instead of using $content. All you need is on the node object.
Preprocess functions, which are placed in your theme, will give you the possibility to add or alter variables that will be used in your template. You name the functions like hooks: yourtheme_page for the page template yourtheme_node for the node template etc. Here you can create some custom logic, or modifications, to help make your templates more clean and just handle the printing of the variables.
Theme functions. You can overwrite theme functions to alter the markup that's used. You only need to create a function called yourtheme_[theme_function_name]. You don't need to understand much php to do this. Often, you can just copy the original theme function, and make a few alterations in it to get the markup you want.
With the above you can do 90-95% of what you need. Forms are a bit special since you in Drupal 6 can't alter them (easily) in your theme. Instead what you want is to create a small module and use hook_form_alter, which allows you to modify the form, text used on buttons etc. This is changed in Drupal 7, which will be even easier to theme.
So it really isn't all that complicated, just use the 3 basic tools described above. The tricky part can be to name your functions and templates, but devel themer can help you with that. Another tool you use is devel which can assist you in printing out variables so you can inspect them and see what you have available, fx CCK fields on the node.
Maybe you should get a copy of Front End Drupal.
In my opinion, Drupal theming is not difficult once you wrap your head around the concepts like templates, overrides, .info files and preprocess functions. Those things are not directly related to php skills, it's all about understanding the system.
It's interesting to see that you're a themer, yet you only talk about php, not CSS and HTML. In my experience, a lot of theming tasks can be accomplished with CSS, without even touching php.
Finally, I don't know if you are using a base/starter theme (like Zen or Genesis) already. I recommend using a base theme and realizing your own design as a sub theme.
Most people get an 'ahah!' moment when themeing suddenly starts to make sense.
I'd argue that this is probably tougher for experienced PHP developers, since you have to get past a lot of concepts that don't make sense in vanilla PHP ("the function is magically called at the appropriate time ... because of how it's named?!")
#googletorp's answers is pretty comprehensive, so I'll just add some practical tips that helped me along:
1) Try building a module that implements it's own themeable output and simple hooks. Hooks and theme functions make a lot more sense when you see how modules are actually calling them and using them.
2) Make liberal use of the devel module, especially the Theme Registry menu (note how it changes when you add a new theme function), the 'Render' tab, and the dpm() and dvm() functions
3) Buy a old-tyme dead-tree book on Drupal themeing. The online docs are really outstanding if you already know what you're doing, but can be extremely confusing if you're not sure what you're looking for.
4) Empty your cup. At the theme level, PHP is really just for simple logic and syntax -- almost everything of substance is getting handled by Drupal API functions. Try to think like a Drupal developer and not a PHP developer (i.e. don't assume you know how to do something just because you built a vanilla PHP site that does the same thing) and you'll have an easier time.
Keep with it! The theme system is actually really easy to use once you've figured it out.
to answer your question on why it is so hard:
Drupal themes may seem overwhelming, due to the sheer amount of possibilities, see #googletorps answer for a good overview.
Having "many ways to do one thing" brings power: power users can choose the best of all possibilities. But it also brings complexity: new users don't get a good lead, because there is no "you should do it this way. fullstop."
Alongside that amount of ways to get stuff done, there is the problem of nesting. Drupal has a concept of very deeply nested items. To take a random, yet simple example:
username<menuitem<menuitem<menuitem<menu<block<region<page.
Will render a menu-item, containing a username in a three level deep menu-item in a sidebar-block.
Where most templating-environments have concepts of a page, containing several "contents" that, at most, might contain some partials. the nesting is at most three levels deep. And each level has a clear, distinct area of expertise. Drupal does not have that: the nesting is fairly arbitrary. And each nested item is no different from its parents. This, again, offers power-users a great concept and power to work with, but is hard to grok for new developers/designers.
Lastly, another reason why it is hard to learn, is that the Drupal online documentation is more a wiki then a read-from-begin-to-end manual. There are great books that fill htat gap, you will have to buy them, though.
If you haven't seen it already, this is a great presentation on why Drupal 6 theming is difficult and how it is improved in Drupal 7. There is hope! The video made more sense to me a second time watching after more experience theming.
http://sf2010.drupal.org/conference/sessions/design-and-theming-whats-new-drupal-7
One of the biggest tricks is to override something that is normal rendered with a theme function into a template. This gives you much more control over the markup, and also lets you use the preprocess functions to manipulate the variables before handing it over to the template.
This is a huge boon to theming forms. See a short video that explains it better than I could here: http://drupaldojo.com/session/fine-tuning-ui-theming-forms-drupal-60
I am new to Drupal and I am figuring out a set of steps for developing a Web Application. I planned:
1) Develop the application without any template or graphic effect. Just create your nodes, your views, integrate some plugins and so on. Goal: to have a website up and running from a functional point of view
2) Customize plugins: if some functionality is missing, customize plugins or develop on your own
3) Choose Theme and Customize it
4) Insert graphic effects (ex. JQuery)
5) Fine tuning
I am learning Drupal so I haven't any experience. Am I figuring out correctly ?
There are different approaches. This is how I work:
Define the goal of the site
Define functions
Define menu / pages
Deleveop theme / templates. Either from scratch or themes you downlowd.
Replace dummy text with Drupal code to show content. Here you functions comes in to place.
Remebmer that a node i Druapl, is basicalle your content / your text when you write articles.
When I tried to learn Drupal, I summarized some content here : http://stiengfoto.wordpress.com/category/development/drupal/
If you never have used CMS before, find some tutorials and start with the very most basic things.
Drupal i a great piece of machinery, but it might not be the best choice as a web app framework. It depends what you want to do really, but usually web apps is a lot of custom code / logic. Here Drupal's complexity might become a hindrance for you.
If I was going to build a site or application I would probably do something like this.
Find all the modules that I need. This can involve
Finding the contrib modules that I absolutely need.
Figuring out if I should use a contrib module + alterations or build my own module.
Searching for modules that can solve a problem, looking for solutions to problems that seem common etc.
Do the actual development, and create the features needed.
This include functional jQuery like AJAX.
Theming - this can in some extend be done while developing.
First step is usually to find a good base theme for your design, like Zen.
Then you need to implement the design.
Add jQuery where needed for flashy effects
Test and bugfix.
This should be done while developing, but when all looks good, be sure to give it all some good testing to make sure that it doesn't fail anywhere.