Views

Views fields offer the opportunity to "Rewrite results: Rewrite the output of this field". The option further specifies "Enable to override the output of this field with custom text or replacement tokens." It then provides a textarea with the instruction: "The text to display for this field. You may include HTML. You may enter data from this view as per the 'Replacement patterns' below." The replacement patterns, in turn, have the introduction: "The following tokens are available for this field.

after wasting untold hours with Deploy and Services modules, i switched to using views with xml export and Mitchell's xpath parser module on the intake side. Thing is magic, just wish he hadn't disappeared again and had done it in 1/10th the time it took me

Bloody magic, i imagine a lot from feeds, but it does taxonomy terms and images perfectly, and links in the url and title pieces, once it is all exported as plain text in xml (i was more comfortable with creating the dedicated feed than doing the HTML parsing)

On the source site, download the Views Datasource project

Media module should at least come with proper Views integration and a number of default views for administration, probably making use of Views Bulk Operations.

This can be pure progressive enhancement, the code weight is in separate files and the rare person who does not have Views can use the much weaker administration pages Media currently has.

Ordinarily, when you leave off selecting a taxonomy term from a filter that says "Is one of", nodes tagged with that term will not show up in the View. However, when you make that filter an Exposed filter, the behavior changes. Even if you checkmark "Limit list to selected items", nodes tagged with that term will show in the initial view. Users see this item, but if they filter, they won't see it any more. Not exactly intuitive.

If you make a Files view a draggable view, with an integer field and using the FieldAPI handler, everything looks great except for this error:

Undefined property stdClass::$nid in draggableviews_handler_fieldapi->get() draggableviews_handler_fieldapi.inc

and the fact that it doesn't work at all.

The update sequence below - even with a ridiculous amount of cache clears - cannot run over the new Views-3.x-dev code. (Error at bottom.) However i did confirm that registry_rebuild() in a bootstrapped test.php can restore the site at least.

The solution in this place is just to do a deployment, which is due anyway, before beginning on the Continuum branch - the first two updates, anyhow, run fine on the more stable release candidate 1 Views, and then when the code is updated the final update also runs fine. I don't like it but there's nothing blocking about this.

Update: Here is the code we currently use, abstracted into a helper function with lots of comments but it's really just two lines:

Huh?

Hell, between cache clearings the Views menu link itself (under admin/structure) disappeared.

But actually the error was all me.

Wow.... it was the contextual filter i had added (thinking i was just adding it to the block and accidentally adding it to all displays).

If you give a page a default filter of use the content ID from the URL, and there is no content ID in the URL, rather than being the view page with no items you get page not found. Not the most helpful result from an easy-to-make (for me) error.

http://drupal.org/project/views_infinite_scroll

via Lynette Miles in http://drupalwatchdog.com/1/1/really-important-views-related-modules