Change(b)log

Following on the announcement from my previous post on this topic (Views RSS: Change to preprocess variables?) there have been some heavy changes just pushed to 7.x.2-x-dev branch of Views RSS module.

Most importantly, the feed is now generated from one big feed array passed to format_xml_elements() (with new hook_views_rss_feed_alter() called just before), there has been big changes to preprocess functions (with most of them removed), and 2 out of 3 template files has been removed as well (views-view-views-rss-fields.tpl.php and views-view-views-rss-field.tpl.php).

If you haven't yet played with Views RSS module's preprocess functions (2.x versions only) this entry does not concern you.

If you have though, and more importantly - are using them, you probably noticed that each preprocess function receives a number of variables, based on which XML elements are later built in the template file. Those variables are:

New 6.x-2.x-dev version of Views RSS module (build 6.x-2.x-dev-20120410) has just been pushed to d.o. Most probably it will soon become rc3, if neither me nor anybody else will find any bugs in it soon (and by "soon" I mean few days until I apply all these changes to D7 version).

Full list of changes can be seen on drupalcode.org, the most important one of them though is that field formatters (both CCK and internal Views ones) return element formatted as D7-style extended array, containing the following keys:

My petit red Druplicon buddy has just returned from Morocco, when it accompanied me to the summit of Jebel Toubkal, the highest peak in the Atlas Mountains and in North Africa. Look at these pictures, how happy he is at those 4167 metres! And how he cannot get enough and still climbs different things on our way back down to Imlil! Tough little guy, you have to admit...

Absolute Messages module displays system messages in colored horizontal bars on top of the page, similar to Stack Overflow / Stack Exchange network notifications.

The plan was to use the long July weekend to go to Chamonix, spend first two days on working on our mountaineering skills with UCPA and then climb Mt Blanc over the following two. Unfortunately we never made it to the top, what's more - we haven't even tried, all because of the weather breakdown. Which finally turned out to be a very good decision, as the next day two climbers were found frozen to death in the same area where we were meant to be then. Still though, we have spent few great days on Glacier d’Argentière, Mer de Glace and around Plan d'Aiguille du Midi.

Domain Menu Access is an extension to Domain module, allowing administrators to configure visitors' access to selected menu items based on current domain they are viewing.

It lets administrators decide whether a specific menu item should be hidden on selected domains (regardless of it being enabled by default using standard Drupal functionality), or should it be displayed on selected domains even if disabled by default.

First beta release available for download on official project page.

Administrative overlay is a slick addition to Drupal 7, with all its shiny looks and Ajaxy bells and whistles. For some though it is more like "putting flourescent lights and windows in your computer case": it may look a little cool if that kind of thing works for you, but serves no real purpose. Moreover it slows down loading of the page, reduces working area and could be distracting.

In you are one of such people, there are generally two solutions available:

One of the new things introduced in Drupal 7 as compared to D6 is utilization of modified Seven as default administration theme, which - combined with new Overlay module added to core - brings completely new experience to admin pages.

Although overlay by default is designed to be used only for administrative pages, it does not mean that it cannot be used for other pages as well. All it requires, as usual with Drupal, is just a simple trick.

To illustrate it on an example - let's assume we have Terms & Conditions page defined as follows:

The Drupal Form API provides sophisticated form techniques and also allows for almost unlimited possibilities for custom theming, validation, and execution of forms. Even better, ANY form (even those in core) can be altered in almost any way imaginable - elements can be removed, added, and rearranged.

This feature comes very handy each time there is a need to change default form content or behavior - especially in case of all core forms or those provided by other contrib modules, where we cannot really change them directly in code/module source code.