Sometimes the incredible power that Drupal gives me comes at the pain-in-the-assification of smaller things I took for granted in my pre-Drupal world.
For example, a client had given me a comp with a really small (100px wide by 50px tall) block for the login. Using logintoboggan, the default output for a logged in user is
[username] | Log out
on a single line and was wider than the box for most usernames. If this were a static html page, I could just replace the pipe (|) with a line break (<br />). Going into the module and replacing it wouldn't be much more difficult, but upgrading the module at some future date would eliminate that change. You could try to remember to make the same change again, but that will cause headaches even if you do remember. Plus, if you have that mindset, it probably won't be the only thing you changed that your updates broke!
The way I solved it (with a little help) was to create a new block template file for that block (I didn't have to worry about a node view) and make the changes I needed within the template. This creates one additional file, but it's tiny and preserves your abiility to make clean backups and clean upgrades.
The first thing I did was to view the source code for the page I wanted, looking for the block name. I scrolled through until I found this line:
<div id="block-logintoboggan-0" class="block block-logintoboggan">
which gave me the name of the block. I then made a copy of block.tpl.php in my theme's folder and renamed it block-logintoboggan.tpl.php cutting and pasting from the line above.
I then opened this file in a text editor and found the line that is displaying the html. I quickly found <?php print $block->content; ?>, which displays the content element of the block object. I treated that element as a black box and simply modified its content on output. The only thing I had to do was replace this line with a line that does a regular expression replacement. That's it! I didn't have to touch anything anywhere else.
Here's the new line to replace that one:
<?php
print preg_replace("/ \| /", '<br />', $block->content);
?>This goes through the output, looking for the pipe character with a space on either side and replaces it with the line break. I had to escape (\) the pipe because it is a special character.
So everything worked and I was excited enough to write this up for others, but then I found out that this isn't the standard way to do this! Although this method is fairly clean and easy, I was just informed that the more standard way is to override the function in template.php and is called a theme override.
The pipe is created by a function in the logintoboggan module. If you open the main file (logintoboggan.module) and search for "|" or "log out" you'll find the function:
<?php
function theme_lt_loggedinblock(){
global $user;
return check_plain($user->name) .' | ' . l(t('Log out'), 'logout');
}
?>Now copy and paste that whole function into template.php in your theme folder and rename the function to phptemplate_lt_loggedinblock. You can override any function that has the prefix "theme_" by changing the prefix to "phptemplate_". (You could alternately change the prefix to your theme's name, but that would have the small disadvantage of breaking if you're theme name is changed.) This all works only if you are using the default theme engine, phptemplate. If you aren't, you presumably know a lot more than I do and aren't reading this.
Once you've pasted the function into template.php and renamed the prefix, you simply edit the function. In my case, I simply changed the pipe to a line break. Here's how it looked:
<?php
function phptemplate_lt_loggedinblock(){
global $user;
return check_plain($user->name) .'<br />' . l(t('Log out'), 'logout');
}
?>In case you weren't counting, that's only three quick steps: Find the function, paste it into template.php with a new prefix, and make your changes!
If this html isn't overrideable, you should file a bug with the module and (try) to attach a patch that fixes it!
If you'd like to learn more about the guts behind this override, a good place to start is the well commented theme engine file, found here in your drupal install: themes/engines/phptemplate/phptemplate.engine.
I had fun peeking under Drupal's hood and was glad that something that would have been so daunting not long ago ended up seeming easy in the end!
]]>Drupal can make forums, blogs, and articles, allow commenting, create user types and assign them different permissions, and much, much more just from the basic install. Despite the incredible set of functionality built in, chances are your idea isn't exactly covered by the basic install. But you don't need to be a programmer to add functionality. You can add modules that others have written! And someday soon, you can write custom modules for your needs, and contribute them back for others to use!
Chances are, someone has already created a module for what you need. It may not work the way you envisioned it, but the beauty of open source is the ability to make your own changes! The massive library of modules people have written for Drupal is nothing short of amazing. Here is one opinion of the top ten drupal modules that I tend to agree with. If you find something close, but not exactly what you wanted, find a PHP programmer to customize the module and contribute the changes back to the community. Open source allows you to spend your money exactly where you need it, and feel good about spending it, because others will benefit from your efforts in the same way you are benefiting from theirs.
Modules are called "core" if they come with the Drupal install, and "contributed" (or contrib) modules if you have to download them separately from Drupal or if you write one yourself. Note that not all core modules are enabled by default. You may have to turn them on. Modules are controlled from /?q=admin/build/modules and administered at /?q=admin/by-module.
Although core modules are in /modules, you'll always copy any modules you create or add to /sites/all/modules. Note that you'll have to create the modules folder within /sites/all, just like you hopefully already created a themes folder. If you mix core and contributed modules in the same folder, they'll still work, but you'll open yourself up to lots of trouble when upgrading, and will have a much harder time backing up your project. Adding modules to Drupal is as simple as copying the module to the modules folder - next time you go to the modules admin page (or refresh it if you're already there) your modules will be visible and waiting to be enabled!
The two most powerful and probably most important modules you need to learn are CCK and Views. CCK allows you to make custom content types and Views lets you display what you need in a wide variety of forms. You can think of CCK as a graphical way to create databases, and Views as a graphical way to design the display of the data. With these two modules, you have some serious database power at the tip of your cursor without having to learn PHP and MySQL.
I found this basic tutorial that's a nice sampler of some of the most common and most powerful modules: CCK, Views, Panels, and Contemplate. After installing all the modules into the sites/all/modules folder, I went through the tutorial. I learned more CCK basics from this tutorial than I had anywhere else. (Although the tutorial was written for 4.7, the modules are now all available for 5, and I was able to do everything in the tutorial on my 5.1 install without any problems.)
At this point, I had a basic understanding of how Drupal worked and what it could do. I was getting excited! (and depressed, wishing that all my old sites were already in Drupal.)
I still didn't feel ready to begin converting my sites to Drupal, so after asking around a bit, found a friend that needed a simple site, that would need some custom CCK fields and organizing by taxonomy, but not much more - a perfect site for a beginner! I recommend following a similar path. Tutorials show you what capabilities are, but really learning Drupal doesn't start till you make real sites, because that's where problem solving begins.
Drupal core includes the upload module that allows you to upload a variety of file types, including images. But the real power comes from contributed modules. imagefield and imagecache in conjunction with CCK and Views are very powerful, and allow a surprising amount of automated image control. You can create resizing and cropping rules and name them (e.g. "thumb", "full", "600wide", etc.), then use Views to call the specific sizes in different views. Read more in this article.
If you're creating a site for a client that hasn't given you any content, or just playing with a blank install to learn Drupal, use the devel module's content generator to create fake nodes, categories, comments, and more. Others have had trouble with the devel module, but I didn't, and found the generator invaluable. Having the site populated with content was a big help in seeing the mock-up site as it might look in real life and gave me more understanding as went through tutorials.
In addition to installing drupal, exploring it, and doing tutorials, you should also read Pro Drupal Development, drupal.org's Handbooks. You can post questions on the drupal.org forums, and you'll be surprised at how quickly you may end up being able to answer other people's questions in addition to asking your own!
A quick note on caching css and html: Keep both off until your site is live! If you turn them on, you'll have a hell of a time troubleshooting as you make small changes to your css or html and they don't show up!
]]>I've been learning PHP and MySQL for almost two years. Every time I began to feel I was learning a lot, I'd be humbled by a whole new category of things to learn: OOP, security concerns, etc. I wanted to use open source products wherever I could, but was frustrated with the understanding that most of my programmer friends gave me: It's usually faster to write something yourself, than to modify someone else's existing work. The time spent dissecting and becoming familiar with work that wasn't yours was not worthwhile for single project use. It only made sense to learn someone else's code if you knew it was solid, and you were going to deploy it again in the future.
I looked into pre-written e-commerce, CMS, blog applications, and more. They were all written by different people and all had different "feels." To combine the functionalities of these disparate pieces and make them look and function well together on one site would require an even more massive investment, and quite a bit of customization. In looking for solutions to these requirements I was introduced to Drupal, Joomla, and other solutions that went way beyond just a CMS. I slowly realized I'd found what I was looking for: A single knowledge investment that would pay dividends over and over again. You know the coding styles and methods, you know its capabilities, you can customize it in so many ways that an end user would never guess that two sites were using the same framework. I researched the various options and decided that Drupal was my best bet. There are plenty of CMS comparison sites and heavily opinionated write-ups that compare Drupal to Joomla and other solutions, from people more knowledgeable than I am, so I won't rehash any of that here. I will say that the more I learn about Drupal and its competitors, the happier I am that I chose Drupal.
How to Begin
I re-tiled my bathroom about a week ago and had never done any tiling before. Along with the tiles and the needed tools, I bought a book on tiling. Several days later, I was ripping up the old floor, paying attention to the layers and how it had been put together, thinking about direction, where to begin, and what obstacles i might face. After week and ten trips to the hardware store, I was done, quite happy with the way it looked, but had never opened the book. I learned from taking the old floor apart, just like I'd originally learned html, and later, CSS. That's how I wanted to learn Drupal.
Since we're each coming to Drupal with a different knowledge base, let me me first tell you where I stood. I had a solid base of css knowledge, was a proficient hand coder of html, and had a modest knowledge of php and mysql.
Learning Drupal's Capabilities
I began going to Drupal meet-ups hosted by PingVision and Denver Open Media and subscribed to a bunch of lists for the various aspects of Drupal I was most interested in. I felt lucky to be in Denver and have access to the great meet-ups. I hadn't even installed Drupal when I went to my first meet-up, but began absorbing the vocabulary and building up my understanding of the architecture on a superficial level. After installing Drupal (version 5) and getting it working, I went through the tutorial in the book "Building Online Communities With Drupal, phpBB, and WordPress." This only showed me what the core install could do, and didn't get into any customization or what contributed (non-core) modules could do. It was also written for 4.7, but the only difference I noted at that low level was that I had to poke around the admin navigation menu a bit, as some items had been moved or renamed. This book helped me in understanding Drupal from an end-user perspective and is great for that, or for someone who will only be customizing the site from the user interface. If you come from a coding background, or want a stronger reference book, Pro Drupal Development is a better choice, however, it doesn't read as easily as Building Online Communities.
Theming in Drupal
Like when I first installed windows 3.1 waaay back when, and since Drupal doesn't have minesweeper, the first thing I wanted to do was change the appearance. Despite the great look of the default themes, I wanted to be able to make my own look, and to be able to port designs from existing sites. Chapter 8 of the book "Pro Drupal Development" covers theming briefly, but enough to get you going. I focused on only the basics: page.tpl.php, which controls the html shell, and style.css, the style sheet. After downloading a design from Open Source Web Design, I renamed the index page to "page.tpl.php" and stuck it in a new folder I'd made in the /sites/all/themes folder along with the style sheet, which I renamed style.css. After just a couple of minutes of inserting some PHP calls and renaming the style sheet, I was surprised to already be done. My instinct was to create the new theme in the /themes folder, but Drupal best practice says that you stay away from modifying files outside the sites folder. This can make the difference between a simple drop-in update and a huge headache at update time.
Outside the world of tutorials, theming can get quite a bit more complex. When I compared what I had just built to other Drupal sites, I noticed that tabs were missing on some admin pages, along with other things I maybe didn't even know were missing.
In my first attempt at theming, I had inserted several lines of PHP into my html file, but missed out on tabs and several important Drupal functions. To make sure I got everything I needed, my next practice site was made by taking an existing page.tpl.php from a strong theme, and modifying only my CSS (from yet another oswd.org design) to fit the ids and classes skeleton that existed in page.tpl.php, leaving it untouched. For the most part, I just had to figure out the structure and rename my selectors to fit. I used the Zen theme. From the Zen theme page:
"Zen is the ultimate starting theme for Drupal 5. If you are building your own standards-compliant theme, you will find it much easier to start with Zen than to start with Garland or Bluemarine. This theme has LOTs of documentation in the form of code comments for both the PHP (template.php) and HTML (page.tpl.php, node.tpl.php)."
"The idea behind the Zen theme is to have a very flexible standards-compliant and (relatively) semantically correct XHTML theme that can be highly modified through CSS."
Using page.tpl.php from the Zen theme created a much more powerful page, calling the "t function" (which allows for translations and localization,) tabs, and more.
Next installment: The Wide World of Modules.
]]>