After several months of private beta testing, Benjamin Schrauwen and I are happy to unveil Mollom, your partner in automated content monitoring. Mollom's purpose is to dramatically reduce the effort of keeping your websites clean and the quality of their user-generated content high. Currently, Mollom is a spam-killing, one-two punch combination of a state-of-the-art spam filter and CAPTCHA server. We are experimenting with automated content quality assessments, but these are still in an early testing phase.
If you're interested in learning more about how Mollom works, check out the 'How Mollom works' page and visit the Mollom FAQs for more details.
We currently provide modules for Drupal 5 and Drupal 6. For all you developers out there who'd like to build Mollom plug-ins, we will be releasing full API documentation very soon. We would be thrilled to put your home-brew plug-in for your favorite platform on our download page.
Just got back from Drupal Camp NYC 4, where I did a session on settings up advanced video functionality on Drupal in an hour. In the span of the session I installed Drupal, installed a handful of modules, and got a site that lets users upload video to their site, transcodes it and deposits the file on Amazon's S3 site. While nothing new in terms of functionality for Media Mover, it is always a bit unnerving when you do something live.
By now, I think most people acknowledge that the CCK+views paradigm for Drupal site building is a runaway success. Part of the attraction of this paradigm comes from the deep integration between the two modules. They work great together.
This week, we saw (at least) two major advances in their integration.
CCK Field Permissions (in Drupal6)My patch to CCK was committed by KarenS in record time (9 hours - yeah for Contrib). Now, admins can restrict the editing or viewing of fields to specific roles. Those without the permission will simply not see the field. This patch added two permissions for each field - edit and view. Edit affects the node form whereas view affects both all "read only' presentations like node teaser, full node, rss feed, and all Views as well. So you can use restrcted fields in a table View and only authorized people will see that column.
This role/permission based model is not the only way that people want to restrict fields. One other use case is to restrict fields based on the workflow state of the node. For example, the Issue field is only available if the article is in 'editor approved' state or higher. All of the pieces are now available to whomever wants to write that module. When you do, please contribute it!
Node/User Reference Fields and Views (in Drupal6)When displaying a referenced node or user in a table View in Drupal5, we are restricted to just showing its title. Earl Miles and yched teamed up to bring us the all of the referenced node's fields in Drupal6. This makes for much more powerful table Views. I think this will simplify Organic groups Views integration as well since it's node => node relationship is very similar. The new Views has some very neat backend improvements in addition to its shiny new UI. Nice work, team.
If you run a popular Drupal site, you'll sometimes find more queries in your MySQL server's slow query log than you really want to.
Sometimes the unruly queries can be eliminated easily by adding an index or two. Sometimes, they can be avoided alltogether (for example, the query in theme_forum_topic_navigation can be avoided by overriding the function with an empty one in your theme).
Sometimes, you need to be more ingenious. The queries in tracker.module have plagued drupal.org for a log time now. They added about 2000 slow query log entries per week on the slave server and did contribute to the melt-down we experienced last summer. There have been a lot of suggestions on how to best deal with them, but none was really a good solution.
The problem could only be resolved by a rewrite of the tracker module to use index tables. This rewrite is called tracker2 and was created by David Strauss. Since I deployed the module on drupal.org about two weeks ago, the tracker induced slow queries have disappeared alltogether. Great work, David!
Requirements: basic css, image editing, basic theming
The fivestar module provides a tidy little voting widget that allows users to vote on nodes. It also provides a CCK field of the type "Fivestar Rating", which can be used to rate a node on multiple criteria.
One of my pet projects, Hill Bomb, requires just this functionality. It's a maps-mashup site for downhill riders, for example skateboarders or mountain bikers, to upload details and maps of awesome hills around the world. Here are the some of the ratings that users can give to hills:
As one of my friendly beta testers pointed out to me, it's difficult to judge what "more flames" means in each individual context. For example, does having more flames mean a better road surface, or more danger to the rider?
It would be better to have different image sets for each rating that clearly indicates what more and less actually means. Fivestar module doesn't provide this functionality out of the box - you can only choose one set of icons for all your Fivestar fields. So, I had to do a bit of modification to get it working.
Over on his blog, Miguel Guhlin asks:
Anyone have suggestions on how to respond to this question? I welcome all brainstorming ideas...
We are ready to implement a student portal (with teacher and parent portals to follow) for our 1:1 campuses. We would like for this portal to be a web-based, searchable, "pretty"
While "pretty" is subjective, this is one place where spending a little time with either an ID or a graphic designer, or both, will benefit your site. "Pretty" has a frequently overlooked cousin, "Usability" -- sorting out your navigational structures (done in Drupal using the core block and menu items), and making sure your theme enhances these architectural decisions, will often get you both Pretty and Usable, which is a winning combination. Starting with a solid base theme, like Zen, helps you theme your site in a time-efficient way, particularly if you and your team are learning how to design/theme in Drupal. Drupal can be themed pretty effectively via css alone; if you have someone on staff who can work in php, there really isn't much you can't do. Also, if there is one element you decide to outsource, the theme is a pretty good choice.
Today I’m just demonstrating a few simple theme adjustments to comments. Comments in Drupal 5 are “not sexy”, out of the box, so in this short post I’m going to illustrate how to:
Note: This is for Drupal 5.x and views 1.6.
Panels 2 comes with a nifty exporter that will dump all your panels related stuff (pages, views panes, mini panels, etc) into one export file set up to work as a module. It's a really useful feature for moving them from site to site or simply keeping them in code for outside the database backups.
Views 1, being a much older module, doesn't have quite as nice of an exporter. It does allow you to export your views one at a time but using that export in a module takes a bit more work. This article will show you one way of doing it. There are other ways, such as putting all the views in one file, but I find this method easier to maintain.
Unfortunately, Leopard’s PHP installation does not ship with a GD module. If you use this PHP version, Drupal will report that it can’t find a GD library (and no image processing will be performed either). There is a tutorial on the web that explains step by step how to compile GD2 for the stock PHP 5.2.4 that comes with Leopard; however, PHP segfaults after the installation (at least for me).
Fortunately, there is an alternative: Entropy.ch’s PHP 5.2.5 beta package comes with all kinds of modules prepackaged. The folks over at Moodle created a very good step by step instruction for setting that bug.
Here is an (incomplete) rundown of the various 'similar/related node' type modules:
Manually entered Parsed links Search/analysis of title/body Taxonomy Same content type Related Links ☺ ☺ ☺ ☺ Related Block ☺ Similar by Terms ☺ Similar Entries ☺ Relevant Content ☺ ☺It should be pointed out that while related links is one of the oldest of the bunch, and has most features, it is not quite as flexible as people are looking for (which I think is the main reason for the other modules), and the UI is not always easy to understand.
Ever think about trying out Drupal's right-to-left (RTL) language support for languages like Arabic or Hebrew? We got to test it out for a project we're working on with the SEEP Network, a support system for microfinance and microenterprise communities around the world. Currently they're working to build the capacity and improve the services and performance of organizations within national and regional-level networks of microfinance institutions. To get feedback on their efforts and track changes that occur, they needed a tool that would allow members of these networks to give them feedback directly. And since these members speak many different languages - including RTL languages like Arabic - we got to try out Drupal's support for this while building their survey tool.
The webkit team published a terrific article about the terrible effect that multiple external javascript files can have on browser performance. Drupal6 has a terrific feature called javascript aggregation which I encourage folks to enable on your production sites. It is found on the admin/settings/performance page. While you are there, enable css aggregation as well.
If you use an external ad network, I can almost guarantee that they are using just the sort of bad behavior that this article describes. If you suspect that your ads are slowing down your web pages, try browsing with javascript disabled. If it suddenly gets fast, your ad provider is a problem. Unfortunately, ad networks have been using external includes and document.write for years despite performance concerns. I get the impression that chaning their architecture is hard or undesireable so they choose to slow down the pages of their clients.
Here’s a quick one if you are in need of a noon-time distraction. If you’ve ever used the WYSIWYG editor TinyMCE, called “tiny mice” by some, then you know that it likes to hook() up with every <textarea> that it sees.
The results of this promiscuity range from annoying (I don’t need a HTML editor for a log message!) to the disastrous (?*$! That HTML editor just stripped the newlines from my list of pages in “Page specific visibility settings!” Oh, the humanity!)
By default, a number of Drupal themes (including Garland) output an RSS feed icon at the bottom of pages which generate a feed. The feed icon is generated because of the existence of the following code in the page.tpl.php file
<?php print $feed_icons ?>
But what if you want a different looking icon? Maybe something larger, or a different color?
Well, there are a couple of ways to achieve this:
1. The not-so right way
Drupal's default RSS feed icon image is located in your site's folder structure at 'misc/feed.png'. The not-so right way to change it is to simply swap this feed.png image for another feed icon image (just making sure to also name the new image feed.png).
Assignment: Create a highly customized page/node in Drupal and:
Sure, we could do this by creating a page-node-xx.tpl.php template file (where 'xx' is the node id number), but that's just a major hassle later on when updating/theming things and it won't give us the flexibility of being able to let an end-user edit things.
In this case, the thing to do is to create a file called my-file.php (.php because we want our text-editor to still recognize it correctly), put it in our theme folder, check the PHP input filter on the node itself, and then place this code in a node: