Drupal

Some code to hide empty CCK fields upon display.


// hide empty fields from display
if (!$items[0]['view']) return;

Put this at top of field.tpl.php, which should be copied to your theme folder as per CCK theming documentation.

I finally sent an email to the drupal development and consulting lists about the new drupaldigest web site. This site exists only to offer rss feeds. The feeds are a collection of high quality posts to Drupal's various email lists.

Thanks to Angie Byron for editing the Documentation list. Additional editors for other lists are needed.

If you haven't joined the RSS revolution yet, this might be a good time for you.

Wow, the W3C has a useful bot called Zakim for managing IRC+telephone meetings. Check it out.

In Dries Buytaert's blog, he recently reminded the Drupal community:

So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off

I agree with Dries' premise and want to expand upon it in my own words.

Dries refers to major changes in the Drupal API which break existing modules. Often, Drupal admins/developers get angry about this breakage, and advocate that we avoid major API changes at all costs (we already avoid them where possible). They don't want to edit to their modules every 6 months or so. They want progress and backward compatibility, and don't believe that these are sometimes mutually exclusive.

I think these angry folks are missing a key idea:

We don't know what we are doing

I get the feeling that these folks think that there is a master roadmap, and all that the development team does is fill in the functions as we have time. But thats not how open source works, and especially not the Drupal project. We are making this up as we go along. We do not know what will Drupal will look like a month from now, any more than a jazz musician knows how tonight's set will sound. If we knew what we were doing, we would just design the ultimate flexible, powerful, calafragilistic API and never need to break it.

This lack of foresight leads to some seemingly silly outcomes. For example, menu callbacks in Drupal are basically responsible for the main content of any given page. They are rather central. Initially, these function s were supposed to return their content. Then we changed the API and they were supposed to print their own content. Then, we changed it again and they were supposed to return content again. Some folks wondered aloud - please make up your mind. These folks fail to realize that the Drupal project has no mind, and if it did it would be terribly conflicted.

One night my wife and I decided to invite some people over to our house to chat, drink wine and talk late into the night about the Drupal Content Management System (we've a very exciting social life). Here are some responces to that enigmatic question What is Drupal?.

Nice piece on TrollPlanet about Drupal's various audiences and aspirations.

inline.module has a nice feature where it shows all image attachments inline at the bottom of each node. this is often convenient for the node author, compared to the alternatives. this alistapart article describes a technique for automatically resizing those attachments to look pretty. nice! i hope someone can drupalize this.

I published two nice features today to the organic groups module.

• XML-RPC API. A remote system may now interact with og and retrieve all subscribers of a given group, all subscriptions for a given user, and subscribe a user to a group. The motivation for this was integration with Leo Burd's amazing voip module. Leo gave me a demo this morning and I loved it. He wants to voice enable groups just like he already voice enables the usual Drupal site. Leo is a bit busy with his 2 week old baby and his looming thesis deadline. But he promises to publish the module soon.
• OPML. OG offers each user an OPML file of his subscriptions. See the blue icon on the My Groups page for an example (requires login).

UPDATE: i just had to add a conf_init() call before that line to get this working again. Odd.

Drupal 4.7 added a session_regenerate() call which makes it harder to stay logged into multiple sites on the same domain.That call is essential for preventing session fixation attacks, so I'd rather not comment it out, even on dev sites. My fix is to add the following line to bottom of settings.php

conf_init();
ini_set('session.name',  preg_replace("/[^a-z\d]/i", "", $GLOBALS['base_url']));

This line changes the session cookie's name from PHPSESSIONID to a name based on the name of your settings.php directory path. That path should be unique enough to prevent these cookie conflicts. The preg_replace() is there to strip out all non alphanumeric characters since those are invalid in a cookie name.

Also see Cannot stay logged in on more than one site on the same server

I’ve recently learned that our new api.drupal.org web site does have a quick search feature like the old one. The path for this feature is a bit obscure. The key is the path apis, not api. For example, here is a search for module_invoke.

One annoying buglet is that an exact match is not preferred over a substring it is impossible to go directly to the doc page for url(). Patch for api.module is welcome.

I've made a web search entry in my Quicksilver and a smart keyword in Firefox for this. And I installed api.module locally so I am about as optimized as one can get for this.

Technorati Tags: Drupal

The private files system in Drupal is OK for minor usage but does not scale well. The performance problem (yeah, there are non performance problems too) is that every private file request requires a full bootstrap of Drupal which means that all the modules must be loaded and parsed. Now imagine that your site becomes very popular and you have 100 images on your home page that all require this bootstrap. This is not theory - it happenned recently on one of our (Bryght) sites. Server was quite stressed

I'm thinking that temporary URLs are our only hope here. Basically, I propose that all links to private files have tokens on them. When one of these image requests is found, the token is checked for correctness and the image is served. The token is tied to the user's session ID. Drupal need not even make a database connection.

The annoyance with temporary URLs is that they are temporary. You can't just stick one in your HTML and expect it to work forever. So, I propose that we have a placeholder syntax like [[file_path|images/fire.jpg]] wherever we want an image inside of a node or other textarea. Then the filtering system translates this at render time to a valid temporary URL. This scheme will properly show images during preview, but not in a WYSIWYG editor like TinyMCE.

One big downside to this is that any node with a private file reference can't be cached in the filter cache. This may or may not be a big problem, and may or may not solvable. We need some more minds on this issue.

Update

UnConeD came up with a couple improvements which remove the need for the filter tokens and solve the WYSIWYG problem. We use current private file urls during compose. Thos are working urls, and when WYSIWYG sees them, they work as expected. The filter system then transforms those urls into temporary urls at rendering time. This is a brilliant improvement, since we have effectively made this change transparent to all current Drupal modules and such. Old urls will still work. But Drupal will never vend them except during a compose situation.

The filter cache problem remains unsolved. Actually, I've learned that it is worse - all text written in this input format can't be cached - regardless of whether it uses temporary urls. I'm thinking that we have to direct posts with these urls into their own 'nocache' input format(s). Maybe each input format on a site has a mirror one that has temporary urls enabled? Sounds dirty.

Technorati Tags: Drupal