Is Panels necessary in Drupal 7? - drupal

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.

Related

Drupal 7 - method or correct procedure for globally updating content types - Advice/Suggestions needed

(I added this on the Drupal support forum also, hope that's ok :) Just hoping to get plenty off feedback)
I am not long after finishing my first major Drupal 7 build, which was really enjoyable but I would admit a rather large learning curve, which after over a year of development, I would admit I still don't know the full power and capacity of Drupal.
My build started off with building our own sub theme, and using that to overwrite all the core theme styles and tailor it to our needs.
Next, I will explain the structure our build. I was tasked with approx 20 different page styles, so in turn I developed 20 content types(templates) for each of these different styles, from here I then added a number of key fields to each content type and then inputted my code into these fields within each content type. e.g. A page with a banner region, a slider region below and a content region below that, for this example say they are all 960px the width of our sites body. So this content type would be made up of three fields, with the the div's and content added to each.
The node developer process would be, if the user wanted that above e.g. style of page, they would select that content type, and simply edit the demo content with the new nodes needed content and set live. So this is the process of the site for developing pages, which has not hit a wall, sadly for me.
So my question is, would it be possible to have say a content type (Or suggest a better approach) which we could globally switch around the layout/styles which then would filter down to all the children nodes? or be able to assign nodes to different content types or anything along them lines? I did look at switching between subthemes for a specific content type, which on each of the subthemes would have different set .css styles but this could maybe get messy and quickly get out of control.
If you guys could give feedback on our build and how it compares to yours and how we could go about making more efficient that would mean a lot.
Guys, any help or suggestions at this time would be greatly appreciated.
Best Regards,
Joe
There are (at least) three modules which help you lay out and/or modify content on a page. They are: Panels, Context, and Display Suite. Here's an amazing tutorial which walks you through each of them so you can get an idea of how they are used. Use the dropdown at the top-left side of the page to jump to "Advanced Site Building" and scroll down from there.

Drupal 6x Wall-like module

Is there a FB Wall-like module for Drupal 6x?
I'm looking for module which will list all comments, privatemessages and other actions done around user account in a short table.
I would like to avoid using views (heavy!).
Some useful thoughts:
http://groups.drupal.org/node/17847
I would actually use Views as often os possible. It's one of the top modules for a reason. FOr you wall, you should combinate it with Panels.
If you realy want a avoid views, you should create different page regions that hold different parts of the wall inside them (but again, Panels already are capeable of creating something like this).

Best Drupal layout techniques

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.

Tool / plugin for laying out web page with minimal efforts applied on raw CSS

First things first. I have been struggling while dealing with raw CSS to generate complex page layouts. It gets further complicated with browser vendors looking in different directions. Well, now that can't be changed.
So after a lot of efforts I started looking for:
A WYSIWYG editor that would take in content and allow me to define the desired layout and magically generate CSS that would honor most of the latest browsers, while also taking into account the liquid & fluid attributes of the layout
jQuery plugin that would take care of content arrangement complexity while just taking in inputs for the desired layout.
I haven't been able to find anything for the first quest. I'd like to know if there is any such WYSIWYG editor out there. There are many CSS editors but they don't abstract the raw CSS. One needs to know CSS thoroughly and that IMHO beats the need of such an editor. Notepad or a regular IDE is good enough.
For the second point, I came across this thread on stackoverflow. Now this put me in a problem of abundance (not a bad thing BTW). This post has links to several jQuery plugins that do the trick. Some of them are:
jQuery UI.Layout Plug-in
jLayout jQuery Plugin
Docking Layout Manager
I am looking for comments and recommendations from people who may have used 1 or more of these. Plugin's simplicity is important and equally important is the flexibility (plugin shouldn't be restrictive.
Frankly, I'd like to offload much of the CSS job to a tool.
Most layouts shouldn't be that hard to get working - it's probably worth checking you understand the different ways of positioning: float, relative and absolute properly, and that you are aware of how to clear floats.
You could try looking at blueprint or 960.gs for ways to get complex grid based layouts without much hassle.

How/Where to learn laying out Webforms in ASP.NET 2.0+ versus Winforms (VB.NET)?

Looking for some direction here as I'm running into some migration problems.
We have a legacy application. The 'infrastructure' is running just fine. Business logic and data access layers written in VB calling SQL Server for the database.
I have a LOT of experience writing Winforms (desktop) application and have had no problems. However, the last time I wrote any ASP.NET stuff was in 1.1 (VS.NET 2003).
Among other things, for ASP.NET 2.0 and up, the Grid layout is gone. It's not just a simple case of dropping controls on a form, aligning them, ordering them and working with the code-behind anymore.
The new web-based application is starting out pretty simple. Just a common header (already made a user control for that) and footer with your typical CRUD functions in the middle.
I tried being 'intuative' in using a master page with content place holders but I couldn't get the placeholders to "grow", to say nothing of not being able to put a text box where I wanted one. Oh, I found the option in VS2008 to allow absolute positioning but it only worked for SOME controls - others I had to manually edit the asp tags.
Then I saw examples using div's and tried to implement them but I ended up with results that had objects writing on top of each other. The online help wasn't helpful to say the least.
Does anyone know of a good book, website or tutorial that can give the basics of what I'm looking for? In practice, I'm looking to make simple pages where some objects may have to push others gurther down the y-axis (as in, several comments being made and that section would push the section listing the 'attachments' down further). I have no trouble when it comes to all the other aspects of this application. It just appears that my webforms skills are about 3-4 years out of date.
This isn't going to be some fancy flash/silverlight application - just simple 'data maintenance' to get rid of some ugly and bug-prone processes involving reading common mailboxes and decoding Word files. The new goal is to have a nice weborm with proper validation.
I guess what I'm looking for is a "Webforms for Winforms programmers" book or site.
Help!
Thanks in advance.
The best advice I've heard on learning to use html/css layout goes something like this:
When building a new page, don't try to get all fancy up front. Start by building a very basic, text-only page. It should look like something from 1996- that brief period where everyone had just discovered the web but had not yet started using the table tag for layout- only no comic sans font. Don't use images at this point, unless the image is genuinely a part of the information being conveyed (as opposed to the window dressing to make it look pretty: you can add those later). There will likely be an h1 at the top of the page, and give each sub heading an appropriate hN, but at this point there shouldn't be any layout information in the page at all. The only place you'll have a table tag is if you genuinely have tabular data to show. If it helps you write this code then you can wrap everything in old-fashioned <center> tags for now- just don't forget to remove them later.
Now let's start tweaking the markup a little. Use things like ul (unordered list) for your list of navigation links and label/legend to identify and group your form areas. The general idea here is to have each element on the page encased in the most appropriate html tag, and to use the full set of available tags- each for it's designated purpose.
At this point you have a page that is ideally suited for a screen reader or search engine. By building this page first, you have made SEO and accessibility compliance easy on yourself. Of course those aren't the only requirements, so we're not done yet.
Now you need to identify the different sections of your page, from both the layout and logical perspectives. The page should largely already be divided logically, but you may find a few places where the normal tags don't cut it. You'll also want to group certain elements for layout reasons. Encase each of these areas with a div tag, and give the tag a class name that refers to the purpose for the tag: the group your are creating. This is just another case of using the a tag (the "division" tag) for it's intended purpose. Also, since elements can have more than one class, you may want to think about also grouping your classes logically. For example, you might want to have a separate class that distinguishes the site template from the rest of the page.
By and large this should not have changed the appearance of the page, but now you have something where it should be very easy to start adding styles. At this point you can now start adding images and layout. The goal here, though, is to change the actual markup as little as possible. If you can manage it only add ids and classes, though you will likely need to add an additional span or div that you had not identified earlier, and sometimes you'll need an extra block level element to force a compatible layout across browsers.
If things are done correctly, the result is a page that not only looks good, but is also easier to work with when testing across browsers, will naturally degrade well when a style or javascript feature isn't supported, and scores well for SEO and accessibility. This also makes it easier to have a developer build a simple page that provides a certain level of functionality, which they can this pass off to a separate designer to make it look good.
You may also want to check out A List Apart. This is a great website with lots of "tricks" for using CSS to layout things on the web along with lots of other web oriented content.
Grid positioning was an abomination for websites. Sure it made for an easy transition from those familiar with the WinForms designer, but it produced horride HTML that is nearly impossible to maintain.
The very best resource I can recommend to you is CSS Mastery. You'll need to learn HTML and CSS, but they're quite easy to get into.
By the sounds of it, you're looking for a crash course in HTML ?
the "Design Canvas" of an ASP.NET aspx Page & ascx Control is just HTML tag markup.
If you've no web design experience, I'd recommend starting somewhere like
W3Schools
When Microsoft gave us ASP.NET, they tried to make programming websites, more like programming rich client applications. However, there are a lot of issues you have to deal with, the major one being statelessness, when developing for the web that don't exist when developing a thick client app (WinForms). So the first step is to not think of the two as similar in anyway.
The drag and drop tools are nice, but what you really need to understand is HTML and client server models. HTML will help you understand how things are getting laid out, and client server models are important to understand how data gets to and from the web to the server. If you have developed in ASP.NET 1.1, then things really haven't changed for 2.0. The concepts are the same, just some of the provided controls have changed.
A lot of people were really unhappy with the grid-based layout from 1.1, because it didn't really work in a number of situations. It still has to ultimately render as html, and html just isn't suited to that kind of layout. For example, things might not be ordered properly or pushed off the screen for mobile browsers (iPhone, etc). There's also things like screen readers for the blind. If you work for the government, that 2nd item is a legal requirement rather than just a nice-to-have, and there are a lot of developers who do work for the government.
So ASP.Net 2.0 tried to generate markup that's at least a little nicer for html. The downside is that you actually have to understand html layout now. But, c'mon: you're building a web site. If you can't handle a little html you're in real trouble.
My advice to build one static page using something other than visual studio. Use <input tags rather than server controls on that page and don't actually implement any logic. Use it to understand how your layout will need to work. Once you have that down, it's really easy to duplicate that for your pages in Visual Studio.
This doesn't really belong as a separate answer, but I wasn't sure you were likely to see another comment to my response above.
The normal behavior of all block-level elements, including divs, is for each new element to appear below the previous element. It sounds like you've set position:absolute; on everything, perhaps while playing with the Grid-based layout option in visual studio. Don't do that- it's hijacked the expected behavior and that's why you see everything piled on top of each other.

Resources