Erich Beyrent :: Beyrent.net

I recently built my first module for Drupal, which exposes data from the Userpoints module to Views. There was some talk with the CEO of my company about releasing the module to the community as a contributed module, and some hedging about whether to release it or not.

Releasing modules shouldn’t even be a topic of discussion within a company. The work I did on this module was built off the many, many, many hours others have spent on Userpoints and Views. In addition, thousands of developers contributed to, and continue to contribute to Drupal. For a company to even consider taking an Open Source project, developing a feature on top of it and then not releasing it, is rude and insulting to all the developers that have work on this OSS project.

Companies who use Drupal and other open source software have directly benefited from the work of thousands. These companies have saved gobs and gobs of cash by stating with Drupal as a base and then building on top. That base was built by ordinary people, and that base depends upon people contributing their code.

Credit should be given where it is due and if your company has sponsored the development of Drupal modules by paying your salary, that should be mentioned. At the very least, your company’s name can be in the module itself with the README file and within the code.

Again, this should not even be a topic of discussion. If you work with Drupal and extend its functionality, release the code to the community.

tags: community, drupal, extend, modules, open-source, oss, philosophy, php, release, software

I have found that the core Drupal profile module provides very limited customization possibilities. However, the Usernode and Nodeprofile modules help out immensely with this.

If you want access to custom user profile fields, such as CCK fields, you simply load the profile:

tags: drupal, image, nodeprofile, php, user+profile, usernode

Drupal is a fairly flexible system as far as CMS applications go, and is even more flexible as a development platform. The Views module gives developers ways to dynamically build queries of data, and display that data in many different ways. Sometimes, however, you want to display views in ways not supported through the admin interface. Fortunately, there are other ways to get the job done.

For example, I have a block in my sidebar where I want to display a list of the latest blog post, latest forum topic, and latest user poll. Each of these lists can be created as separate views. However, there doesn't seem to be any functionality, either in the Views module or another third-party module, that allows you to display multiple unrelated views in a single block. So, we turn to the code. The Views API provides a mechanism for building and displaying your views anywhere in your templates:

and

Clearly, the views_get_view() function retrieves the view definition from the database, while the views_build_view() function renders it.

Back to my example - I simply created a new block, and set the input format to PHP. Then, I used the following code to populate the block with the views:

The above code shows the rendered view. However, there are times where you want or need to do some additional processing on the values returned by the view. Fortunately, the Views module is incredibly powerful, and has a ton of options for retrieving the views.

In the above example, the first argument to the views_build_view() function is 'embed'. There are several other options:

• page - Produces output as a page, sent through the theme. The only real difference between this and block is that a page uses drupal_set_title to change the page title.
• block - Produces output as a block, sent through the theme
• embed - Use this if you want to embed a view onto another page, and don't want any block or page specific things to happen to it.
• result - Returns an array of information, including a database object that you can use db_fetch_object() on
• items - Returns an array like resul, however, it contains an array of objects found by the queries, so you don't have to fetch the objects yourself.
• queries - returns an array, summarizing the queries, but does not run them

This information comes directly from the code, and hopefully, it will be of some assistance to people who are looking for this kind of functionality.

tags: views, block, cms, development, drupal, php, templates