Want to get Lullabot article, videocast, and podcast announcements delivered right to your in-box?
Let us know your email address (we won't share it) and we'll let you know when anything exciting happens.
Drupal Podcast No. 46: Full Code Press
September 3, 2007
- Artist: Lullabot
- Title: Drupal Podcast No. 46: Full Code Press
- Album: Drupal Podcast
- Year: 2007
- Length: 42:47 minutes (10.16 MB)
- Format: Mono 22kHz 33Kbps (VBR)
Jeff Robbins interviews the Australian team from the 2007 Full Code Press competition. The team built an entire Drupal site in 24 hours. They talk about the difficulties and advantages of building the site in Drupal.
Comments on this post will automatically be closed three months from the original post date.
Twitter
Mailing list
RSS Feed
Comments
Let's fix some of this!
Let's fix some of this in Drupal 7! :)
There are a couple...
There are a couple issues that are getting some attention in the final days before the beta. Cleaning up some of the classes for the menu system (one of the major issues that they ran into during theming) can definitely help. Unfortunately there's no mechanism for overriding or blocking the inclusion of core system .css files in Drupal 6, which greatly limits the usefulness of the 'Pure CSS Themes,' but there is a LOT that can now be done without hacking in 6.
We need to make things easier at the front-end
I'm relatively new to Drupal and my way of working is to omit
<?phpprint $styles
?>
A lot of development time is then trying to make the XHTML , classes and IDs suit my way of thinking, and I end up with lots of code which is there simply to simplify! I find it harder to work with code that's difficult to read, and Drupal tendency to add multiple DIVs and very long class names and IDs hinders rather than helps (even when using FireBug!).
My method of working adds complications, however, when using modules such as ThickBox, as the relevant CSS isn't added automatically. It would be nice to simply check which CSS files you wanted Drupal to include in
<?phpprint $styles
?>
To cut a long story short: it needs to be easier!
A few ideas
May be we just need to separate
<?phpprint $core-styles
?>
and
<?phpprint $styles
?>
Or maybe if a "core.css" file was found inside a theme folder phpTemplate could override drupal.css? Or it could be a theme setting in the admin. So we could use another base stylesheet, from Tripoli, Blueprint, YahooUI Reset, or any other variant.
Recently I modified a core file (actually just one hyphen replaced by a space) in menu.inc, because it was the quickest and easiest way to output
li class="first menu-1-1-2 active"
instead of
li class="first menu-1-1-2-active"
You know it's really useful to put the "active" class on the containing LI, rather than on the inside A, when you need to apply two background images on tabs :)
Improvements
...In Drupal 6, the 'active' class does go on the LI in addition to the anchor tag. So that's one big improvement!
The problem of splitting styles is a little more complex, unfortunately. One of the big improvements in Drupal *5* was breaking up the monolithic default.css into bits like node.css and system.css and forum.css and so on. There's another axis that's important, though: the purpose of the styles in question.
For example, in core, we have three specific kinds of CSS. There's pure formatting information like font sizes and background colors. There's structural layout information like column/footer/etc setup, edit tabs for nodes, etc. And then there's "functionality" CSS, like the styles used to control collapsible divs and so on.
Almost every theme wants to override the first kind. Many themes (but not all) want to override the second. And almost NO themes want to override the third set of 'functional' styles.
Right now we don't have any kind of separation between those three kinds, just separation between modules. I'm not sure if there's a super-easy way to divide this stuff.
version
You must not be using Drupal 5. There is no more drupal.css in Drupal 5.
If you don't use print $styles it won't print any css output from Drupal core or contrib modules. Instead, you can just call your specific style sheet yourself. This does mean that you are now responsible for all aspects of theming your site.
This allows you total control. You can also override any themeable output rather than modifying core.
http://api.drupal.org/api/group/themeable/5
Same here...
I did the same thing with my first Drupal site. Just pulled the
$stylesvariable right out and started from scratch. As the gentlemen stated in the podcast, I like to have full control over styles.We usually just give the admin side the Garland theme. It would be nice to have more control over what is included and what isn't in terms of CSS. On a high volume site, you either have to leave out the core css or have a lot of redundant style declarations in your code.
Side note: Jeff mentioned helping out on Zen theme issues. I've been working with the Zen theme (or modded versions of my own) for awhile and I'd like to help out with it. How does one get started with helping out with theme development?
Zen theme help
Cool! The best way to get started helping out is by hitting the issue queue. There are lots of posts that need troubleshooting and patches. Patches might sound scary but they really aren't hard at all once you get your tools set up. There is a Patches section of the handbook as well as some videos both in the handbook Development HowTos in the Videocasts section and we have some videos on setting up a localhost and installing CVS (Mac-only right now.)
You can also check out the Zen Task Force group on groups.drupal.org. There hasn't been much activity there as of late but it is always open to getting conversations going.
Thanks
Cool, I will head that direction and start getting involved. No more lurking. :)
sitepoint
The URL at the end is: http://www.sitepoint.com/blogs/2007/08/21/full-code-press-pre-built-vs-c...
http://www.sitepoint.com/blog
http://www.sitepoint.com/blogs/2007/08/21/
Judging criteria?
I just finished listening to the podcast and a couple of things keep nagging me...
First off, what was the criteria for deciding the winner? I would be willing to bet that the Drupal site is much more secure and bulletproof than any custom built solution. The advantage of millions of end users bashing away at Drupal-based sites over the years and the constant performance and security updates by the multitude of developers that have gone into it are usually the first thing I tell clients when discussing Drupal.
While it appears that the Drupal-based team did an amazing job, from listening to the podcast, it would seem that a seasoned Drupal team would be no match for just about any home-built CMS in this type of "event".
All-in-all, the event was fascinating for me to hear about. A great idea with winners all around. Bravo.
security
Rasmus Lerdorf made a comment at the Yahoo! OSCMS event earlier this year. He can pretty much own any 'custom' CMS. When he gets to a major project CMS he is less likely to find something and if he does he knows it gets fixed when reported in a timely manner.
This really should be a strong criteria for these events. If these agencies have little resources to begin with they really should concentrate on the long term maintainability of such sites for these groups. If they are unmaintainable by those without strong programming skills, then they are more likely to be abandoned, fail, hacked, etc.
Zen is a great base for building themes
I don't understand the trouble he had with the zen theme and why he had to use
important!all the time to override it. I have built many themes based on zen (e.g. http://business-transition.com ) To override a style, you simply have to understand how use the CSS specificity: http://www.w3.org/TR/REC-CSS2/cascade.html#specificity --you almost never need animportant!qualifier.I have found a few bugs in zen, but overall found it a great starting point. I am even happier with zengine and am about to launch my first site with it.
Overriding Styles
Andrew, you are correct, and I was using CSS specificity as well - I probably should have elaborated more on that in the podcast. However, there were certain situations where nothing would work except !important.
Also, the Zen Task Force group sounds interesting. Heading over there now ...
CSS Specificity Made Easy ( Star Wars )
This is the best way for any nerd to understand CSS Specificity . Trust me, you'll love this.. and you'll learn quite a bit too :) http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-sh...
Error on non-Drupal site
http://kiwi.fullcodepress.mbcomms.net.au/privacy
I laughed when I saw this.. it is a php error.
--matt
Enjoyed it
I enjoyed the podcast. I would have liked to hear more about the final Web site, what did the judges say that made Australia's site better, how easy do the people maintaining the site have to say, etc.
Looking forward to more podcasts. Thanks.