Welcome to the Geeks & God Static Archive. Read more »

Case Study: Fshbwl.com

0

You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialize correctly.

The fshbwl was a unique project for many reasons. It was one of the occasions where Matt was the project lead rather than Rob. In building it we did some things differently than we'd ever done before. And, it was built in more than a week but well less than 3 months. In this weeks episode we discuss building a website in a different way. Some modules are different, parts of the approach are different, and a number of the things on the site turn out differently. This even leads Matt and Rob to discuss their differing views on inline content. Differing views? Could this be a royal rumble?

But, before we dive into building the fshbwl we talk about building a site in a week. Is this a contradiction from what we talked about just a few weeks ago? You'll have to come listen to find out.

asset module

Thanks for the tip on asset module. Cool stuff!

Shrop

Mark Shropshire "shrop"
Geeks & God Forums Moderator
http://geeksandgod.com/users/shrop

The merging of blogs

Something Matt said in this caught my attention because I've been mulling around this idea in my head also. Matt could you give us a bit more attention on that topic. How is it again that you managed to bring outside blogs in and then deal with them on par with drupal's own blogs?

I love the idea of being able to share all these things in one feed.

Thanks!

I'll write that up

To answer that I'll write up a blog post on that. It'll take a little longer than a comment to explain.

Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com

Matt Farina
Geeks and God Former Co-Host
www.mattfarina.com

Thanks matt. I'll watch for

Thanks matt. I'll watch for it.

mf

Rob--glad I'm not your co-host, or you'd get a ton of mail! Haha!

Pat Peterson

HA!

Ok, I have to be honest. I sat staring at my screen for a good 10 seconds before I figured out what you were talking about. But when I did....halarious. Thanks for the good laugh.

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

Ha! part 2

Maybe my wife would like to co-host; her name is Tammy Peterson.

Keep smilin'

Pat

Clarification On Form Element Removal

Rob, you mentioned that you could remove form elements either by using hook_form_alter() or by modifying your theme template. This is true, but there is a fundamental difference between the two methods. As Addison Berry explains at lullabot.com:

Form elements can be completely removed from the HTML in the theme layer but from an access point of view, someone could still theoretically make use of the field in the form's $_POST because the field is not removed from the form process, only the HTML output is removed. Removing an element in a module can completely remove access to it in any way. This is not often a real problem so removing elements in the theme layer is still acceptable but you should be aware of the distinction.

#access

I'm surprised that she didn't write about forapi parameter #access. This is available in the theme layer as well as via hook_form_alter.

According to it's documented description it sets, "Whether the element is accessible or not, when FALSE, the element is not rendered and the user submitted value is not taken into consideration."

This is a method I often use. It preserves the form and at the same time turns elements off.

I'd be curious to know a best practice on this and why the best practice is the best practice.

Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com

Matt Farina
Geeks and God Former Co-Host
www.mattfarina.com

How do you access #access in the theme?

So how do you access that parameter in the theme layer? I understand how to do it in hook_form_alter(), but not the theme layer. Isn't it already part of the $content variable at that point? Do you write PHP code to modify the forms array somehow? I don't understand how you would do it that way.

like this

Jump down to the full example functions on http://www.lullabot.com/articles/modifying-forms-5.... Then, let's look at the theme override for drupal 5 on the user edit form.

Right below:

<?php
  $form
['account']['name']['#title'] = t('Login ID');
?>

if you added:

<?php
  $form
['account']['name']['#access'] = FALSE;
?>

That will make it work. Make sense?

Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com

Matt Farina
Geeks and God Former Co-Host
www.mattfarina.com

Permissions

Just to clarify, it was MF that suggested doing it at the theme layer...not I ;) I always do it with hook_form_alter (mostly because I'm too afraid to touch a template.php :) )

Don't forget, if you want to make it accessbile to some people but not others, you have to set a permission using drupal's permission system (instead of just using FALSE)....so you'd use a hook_perm() and then do something like:

$access = user_access('permission name');
$form['account']['name']['#access'] = $access;

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

Better to do it in template.php

OK, I see. Matt, to answer your previous question, from everything I've seen, it's generally considered bad form to put PHP code in the theme layer other than the basic if($variable) statements for determining whether or not to print the content of a variable. You usually want to keep your template for determining where to place the content in a certain variable. For something like this, where you're editing a form, it's cleaner to do it in template.php like Rob showed. Among other things, that makes the edit avabilable to all themes, not just one.

I'm confused!

Hey Wonder95....
Either you mis-wrote or I'm really confused....

First you said that it's bad form to do this stuff in the theme layer (and I agree). But then you said (and your comment title is) "it's better to do it in the template.php." However, the template.php IS the theme layer.

I have a feeling you just misspoke, and you meant it's better to do this in a module, NOT the template.php. Then, as you said, it's more secure and makes it available to every theme, not just the one. Am I correct in assuming this is what you mean and you did NOT mean that it's good to put this stuff in the template.php?

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

-Rob Feature
Geeks and God Co-Host
www.mustardseedmedia.com

depends what you want to do

The template.php file is part of the theme layer and that's where theme logic is supposed to go. Logic isn't necessarily bad in the theme layer but functionality shouldn't be in the theme layer. Logic in the theme layer should all be in the tempalate.php file.

Does that make sense. In the case of #access you can put it in either the template.php file or in a module. Either should be fine.

Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com

Matt Farina
Geeks and God Former Co-Host
www.mattfarina.com

Oops, wrong terminology

Good point. I used the wrong terminology, I guess. I wasn't thinking that template.php was part of the theme layer (maybe I should learn my terminology a bit better, eh?). My thinking was simply that you want to put code like you mentioned above (altering the $form array) in a file that is designed for that, as compared to the *.tpl.php files, since those files are designed more for placing markup than for PHP functions. I've seen code put in .tpl.php files, and it gets messy. I was assuming (and you know what they say about assuming) that you were putting that code in the .tpl.php file (and that's what I was responding to), but looking back at your comment, you didn't specify that.

Open mouth, insert foot...

So, let's try this again. Matt, if you were indeed putting that code to modify the form in template.php, you can ignore (almost) everything I said. However, my other point is still true, that if you put it in a module, the alteration is available for all themes, not just one.

Thanks.

Custom site module for drupal.org

The discussion about hook_form_alter really grabbed my attention, but I haven't really had a chance to get back to it until now. I've run across several references to this, but haven't really delved into it myself. It is clear that the time has come to start using this. I've started digging around for info on it, but haven't really found a good starting point.

You guys also mentioned that the custom site module used on drupal.org itself can be downloaded and examined. Can you provide a link for that?

Thanks,
Micah

drupalorg module

This module is available in CVS at http://cvs.drupal.org/viewvc.py/drupal/contributio.... You can check it out if you like.

Matt Farina
Geeks and God Co-Host
www.innovatingtomorrow.net
www.mattfarina.com

Matt Farina
Geeks and God Former Co-Host
www.mattfarina.com

Thanks, Matt!

Thanks, Matt!

That'll be a handy reference. And the issue count function looks like something I could adapt to build a block similar to the Contributor Links block on drupal.org.

Micah