development

Tips using Eclipse and Drupal, at Wednesday's Meet-Up at pingVision

2008-11-10T17:49:06-06:00

This Wednesday's Denver/Boulder Drupal Users' Group Meet-Up will have, among other things, a presentation by Al Steffen on working on Drupal using Eclipse, the open source integrated development environment that makes coding -- and specifically coding for Drupal -- so much easier.

Also, Matt Tucker will continue our ad hoc series on things to do with Views by giving a little overview of Draggable Views, which is a module that pretty much does what you'd expect: drag-and-drop ordering of nodes in Views.

But that's just part of the meet-up. As always, the agenda is open.

Have a question?

Launched a website?

Created a cool new Drupal module?

Share it with fellow Drupal aficionados!

Meet-and-greet-and-Za start at 6:30pm, right here in our main meeting room. (Map below.) Presentations start around 7. All are welcome, from experts to the merely curious!

Node Bodies, Teasers, and hook_nodeapi('presave')

2008-11-05T18:16:43-06:00

Here's something interesting to keep in mind the next time you're getting fancy with your nodes during the hook_nodeapi presave step: Don't forget your teaser.

I was having trouble with a Drupal 6 website I've been working on, where it seemed almost as if the body was duplicating part of itself (or sometimes all of itself) on the edit - it looked fine when you were viewing the node, but editing it caused things to duplicate within the body field. I tried the usual suspects for fixing - I searched for nodeapi calls inside of the custom modules we'd written to find the culprit, and then even just started turning off modules, and the theme, one by one, hoping to find the culprit that way.

Eventually I just tried using sql to modify the teaser in node_revisions, and when this modification showed up in the edit form, I started doing a search in the code for 'teaser .' - and I found it in node.pages.inc's node_body_field:

function node_body_field(&$node, $label, $word_count) {
  // Check if we need to restore the teaser at the beginning of the body.
  $include = !isset($node->teaser) || ($node->teaser == substr($node->body, 0, strlen($node->teaser)));

... $form['body'] = array( '#type' => 'textarea', '#title' => check_plain($label), '#default_value' => $include ? $node->body : ($node->teaser . $node->body), '#rows' => 20, '#required' => ($word_count > 0), ); ?>

The problem is that the edit form for nodes compares the teaser with the start of the body data. If they don't match, then it prepends the teaser to the body data - which is normally used for when the person writing the node splits the teaser/body into two parts.

However, I was changing the body in hook_nodeapi('presave'), which turns out to be after the node teaser was created. The fix was as simple as adding $node->teaser = node_teaser($node->body); to the end of the presave code.

"Pro Drupal Development, Second Edition" has arrived

2008-08-22T16:21:17-05:00

One of the signs of maturity of an open source software is when some really high-end books about the software start hitting the shelves.

Pro Drupal Development set a new high mark when it was initially released. Now this Second Edition covers even more (and has the higher page-count to show for it), with everything updated for the Drupal 6 API.

We just received our first seven copies, to get us started. We'll be picking up some more as needed.

You can pick up your copy at Amazon. Go there through http://drupalbook.com and a piece of the sale benefits the Drupal Association.

Subversion, OS X and the elusive folder merge

2008-08-15T19:56:33-05:00

Lo and behold, this past Wednesday, after waiting all day for the Drupal 6.4 update that was rumored to be coming out, it finally was released at around 6:30pm MDT. We saw it at the DBUG Meetup during setup, and I knew that once again it was time to do some updating. At pingVision, we have an entire dev/test/production process for all of our clients' and our own sites. But when it comes to my own sites, I prefer to do it myself as much as possible so that I can keep my fingers in code and configuration, even while my more official presidential responsibilities tend to pull me in other directions.

And yet my own sites are still under Subversion, so it's not just a matter of uploading the new code and being done with it. No, I have to do it through SVN.

Now if you are like me (and unlike our developers), and have a general preference for a good GUI over using the command line, and are working on OS X and using version control like Subversion, then you likely have run into the problem that the architects of Finder have not deigned to solve: You cannot "merge" folders in OS X using Finder. No, Finder will overwrite folders completely.

Why is this a problem? Anyone who uses Subversion (or other version controller) will know what I'm talking about: If you try to just overwrite wholesale a folder that's under version control, you end up deleting the hidden .svn folder, which has the versioning information. And that leads to Dante's SVN Inferno, where all sorts of error demons torment you while you wail with pangs of regret: Oh, why didn't I merge that folder instead of replacing it?

Using Unix command line, you can of course use mv -v to merge folders, but that forces you to use command line. Since OS X is built upon Unix, I and many others wonder why Finder does not offer this option, not even with contorting combinations of control, option, command and shift.

It's ridiculous. –Especially when you consider that your basic (s)ftp applications can merge folders without a problem. This isn't rocket science.

A trick to merge folders on Mac I figured out a couple of years ago (when I was first introduced to SVN workflows) is this: ftp from your computer to your computer, using your favorite ftp application.

That's right, rather than copy or drag files from folder to folder using Finder, you drag files from folder to folder using ftp. (I use Transmit, but this will work with any ftp app that can merge folders. A free one I can recommend is Cyberduck.)

To enable this approach, all you need to do is turn on ftp access in OS X.

You do this in Preferences -> Sharing.

Click the checkbox to enable "file sharing".

Then, with the file sharing option highlighted, as pictured, click on the Options button down in the lower right-hand area of the window.

This reveals the kinds of file sharing you want to enable, and one of them is ftp. Enable that.

Underneath you will now see a message that provides the IP address where your computer can be reached. You just enter that IP address into your ftp app as the remote server. You may need to enter your username and password for your Mac.

That's it. Now just drag folders over from your desktop into the appropriate area on your ftp app and the merge will happen.

Note: Depending upon the ftp app, you may need to set appropriate preferences to merge folders. Here are the settings I use in Transmit:

This way you can maintain your website in a dev environment on your Mac desktop or laptop, and manage updating tasks easily without having to do SVN gymnastics or work in Terminal.

I welcome your comments.

pingVision presenters at DrupalCamp Colorado 2008

2008-07-25T16:02:31-05:00

While pingVision as a company is one of the many sponsors of DrupalCamp Colorado 2008, several pingVision people are doing presentations and panels.

Here's a quick run-down:

Kevin Bridges

...is doing a BOF on Project Workflow Management and Client Expectations.

Waterfall, Agile, Scrum, UML, Process Diagrams, Wireframes, Design Comps ... how does it all fit together into a clearly defined purpose?

John Fiala

...has a presentation on Advanced AHAH and Modifying Forms, which gets into that lovely UI goodness of dynamic forms generation, drag-and-drop, etc. He's also doing a presentation on Using SimpleTest to Prove Your Code. Very useful to any coder.

Ezra Barnett Gildesgame

...has a presentation on Drupal Benchmarking and Performance, covering:

- Factors that affect performance
- Measuring performance
- Different types of hosting (Shared, VPS, "Grid", Mosso)
- Techniques used to make enterprise websites scalable (ie Facebook, LiveJournal)
- Basics of Performance-friendly Drupal Module development

Greg Hines

...is presenting on RESTful services and Drupal, and will be showcasing his brand spanking new REST provider module which provides something of a REST API.

Ben Jeavons

...is presenting on Contributing to Drupal, which is about how anyone can participate in the Drupal community. He is also presenting Drupal Lightning Demos:

Rapid-fire demonstrations of modules, themes, Drupal-powered sites, fancy Drupal code snippets and anything else Drupal related that can be demoed in 5-10 minutes. These are quick, 5-10 minutes including time for questions, demos of something you've built on or with Drupal. Unless we have very few demos there probably won't be time to go looking at code so just show how it works or what it looks like.

He's also doing a session on the Drupal Community:

I'd like to talk about the Drupal community, the ways in which we are open and sponsor participation and the ways we've push people away. Because we have pushed people away. What do we do that is right and what are we doing wrong?

Make it better?

There is also going to be a BOF about Making DrupalCamp Colorado better, led by Kevin Bridges and (hopefully) many other interested folks. Maybe we can pull together a DrupalCon proposal?

The geek weekend

I was going to be joining Greg Knaddison in a session where we, as permanent members of the Drupal Association General Assembly, were going to give a little update on what's been happening and attempt to answer questions that may arise, but that proposal was rated lower than the others, so it's not going to happen. No, this is a weekend to get your geek on! See you there!

In Drupal 6, Blocks Need Extra Consideration

2008-05-08T11:19:55-05:00

One of the interesting new opportunities - and thus pitfalls until you understand them - is Drupal 6's built in block caching. As a developer, I'm generally used to creating hook_block by just specifying the 'info' data in hook_block, and letting the other options be set by the admin via the blocks page. However, you can't set the caching level there, and more troublesome, you can't change the caching level of a block once it's been put into your site.

That can be a real problem, given that the default for the cache flag is 'BLOCK_CACHE_PER_ROLE'. If the block in question is customized to a user, then Bob's going to see George's data, and that's no good. Additional problems result with javascript or css that are linked to the block - if drupal_add_js or drupal_add_css are invoked in the block, their effects aren't included in the cache.

So what to do? From now on, you've got to plan out your blocks with a little more care than before. Is the block going to change quickly? Is the block using javascript or css that you can't (or don't want to) include as in-line data in the block's returned data? Then you may need to go with BLOCK_NO_CACHE. Is the block's information personal? Then BLOCK_CACHE_BY_USER. On the other hand, if you've got something that shows up on every page and doesn't change much, you might want to go with BLOCK_CACHE_GLOBAL.

But it's important in Drupal 6 to take a few moments when laying out a new block and consider how you want it to be cached, because once you've created it you'll need to dig into the blocks table to change it.

Drupal for Seasoned Professionals - A Quick Guide to Code and Community

2007-06-01T18:31:34-05:00

We've been in hiring mode for a while now. As most any Drupal Service provider will tell you, there's big demand for people and companies that have an expertise in Drupal. There's also a bit of a shortage of people to satisfy that demand. We've decided on a strategy of hiring great people regardless of Drupal experience and then getting them plugged into the "Drupal way" of doing things as quickly as we can.

There are really two pieces to that process - learning the Drupal code, API, modules and learning how to interact with the the Drupal community and the social values of that community. I distilled some information into a quick document that gives a guide to what I consider to be required reading and actions for anyone serious about being a full time Drupal developer.

Learn the Mantras and the Standards

"Code is gold." Idle discussion or complaining is not valued and will decrease your karma in the eyes of many. Contributing high quality issues, ideally with patches attached, is valued. But don't take the phrase too literally - "Code" is just one thing that's valued. In a big project like Drupal all substantive contributions (e.g. documentation, spam-policing) are valued.

"The drop is always moving." New major releases of Drupal will break the API. This is not a bug, it's a feature. On that topic, releases happen between every 9 months and 18 months. Generally there are about 5 months of feature enhancements before the "code freeze". After the code freeze the only changes allowed are UI improvements, performance improvements, and bug fixes. Once the beta releases start the only changes allowed are bug fixes and string changes. At some point in the betas there will be a "string freeze" to allow localizers to translate the interface. Once a release candidate has been released which saw no new critical bugs a final release will be made. There is no calendar schedule for releases. Only the current and last versions are supported, but more could be if someone skilled enough were willing to do it.

"Where's the roadmap." There is no official roadmap. But with a little effort you can guess it, and if you provide the code then can write it. There are Dries' wishlists, personal battle plans, and predictions for each year. Official roadmaps only barely make sense in command-and-control environments like corporations. Open source projects are Do-Ocracies - the roadmap is determined by those doing the work. That said, the predictions and battle plan threads are great ways to glean a roadmap.

Join Forces With Others. Don't fork modules. We have many modules that do basically the same thing in a slightly different way. That's a great way to lose karma points. Instead you should work together with other developers to make one really great module.

"Don't hack the core." Drupal is built from the ground up to be extensible without having to edit the core code. You shouldn't ever have to edit any of the core or contrib code unless you are providing that as a patch. Instead, use the hooks, overrides, and theme layer to alter the behavior of the code (Laura has written more about this as a theory of open source and practically in our presentation at OSCMS2007).

One-Way Communication you Should Tap Into

planet.drupal.org - aggregated feeds from around the web
Drupal.org front page rss feed
Groups.Drupal.org/rss.xml
Association.Drupal.org front page feed
Lullabot podcasts - listen to them all.
Read Pro Drupal Development - it's really good, particularly if you already know PHP/MySQL.

The Community

Mailing lists support and devel for everyone. Themes or consulting or others if they interests you.
Drupal Dojo - great for developers looking to improve their Drupal chops. Provides a Library of past screencasts, documentation, great tips and tricks discussion on g.d.o. Avoid the desire to just use this as replacement for general support!
Drupal.org forums - they're OK but often deteriorate to lower quality conversation and bickering. Find the ones of interest and grab the respective RSS feeds.
Groups.Drupal.org - look through the group list, find some of interest, subscribe, and then hit http://groups.drupal.org/unread on a daily basis to see what's new in your groups. In particular look for a regional group near you and working groups on topics that interest you. Both are valuable.
irc - pound the #
- #drupal - devel/coding talk only. Unless you are on topic and/or have serious karma don't go off-topic. It's a friendly room, but not always patient.
- #drupal-dojo - a little nicer than #drupal, but don't push the boundaries. largely for discussion of dojo specific stuff.
- #drupal-support give and receive support.
- #drupal-themes - theme discussion
- #drupal-ecommerce - ecommerce discussion
- #drupal-consulting - you get the idea
- See also: Drupal.org Handbook Page

The filtered firehose

If you want to know the top posts from mailing lists but don't need to see a color of the bikeshed discussion, these filtered lists are valuable. drupaldashboard.com - cvs commit messages, important module releases - "Our editors read the lists so you don't have to."

The Contributions

First, go to your Drupal.org account, edit it, and turn on the Contributions Block. Those links are really handy. Here are tips organized by tasks appropriate to your skills.

Aspiring Coder - hit the patch bingo button, apply the patch, test it out and review it (really review, not just +1). Look for any ways to improve the patch that are in the scope of the issue. This process will teach you tons about Drupal's inner workings and endear you to other developers.

Coder - contribute patches (hit the bug bingo), create a module, conform to the coding standards, read the CVS README/FAQ, ask for a CVS account, contribute that module AND support it. Fame, glory.

Themer - provide patches for existing themes (including themes that are in Drupal core). Once you learn theming, write your own theme, read the CVS README/FAQ, ask for a CVS account, contribute that theme AND support it. Fame, glory.

Not a coder or a themer but want to help?

Refine bugs by using the "HOWTO Make good issue" guide and applying that wisdom to the bugs you find from the bug bingo button. Enormously helpful to all parties.
Provide help in the handbook refining the documentation. Do it enough and you can join the docs team. Fame, glory.
Join the support team. Ok, we don't have one. But you can self-appoint yourself to it. See sepeck and michelle for examples of members of the support team - all you have to do is consistently provide help which both of them do in amazing amounts AND they have huge community karma as a result.

Zero to Hero

To go from Zero to Hero in terms of your community karma and also your skills try to figure out the answer to someone else's problem. Great places to find problems are in #drupal-support, the support forums, and the support mailing list. Just pay attention to the chatter, find a problem that interests you and figure out how to solve it. Your knowledge and reputation will shoot through the roof and the discussions of how to solve the problem will teach you about parts of Drupal you would never investigate on your own.

Stay Safe Out there

The Drupal.org Handbook has a section on Writing Secure Code. Drupal provides lots of facilities to make it easy to write secure code, but if you ignore them then you risk danger.

So, what else is out there? Does anyone have any other good, quick ideas for learning the code and the community?