User login

Agaric

Return user to current page: How to link to a form from a Drupal menu

Press login / press account links for anonymous and logged in users, respectively. Subtly added to a bottom menu. Via code in order to allow for the redirect back to the page you were on after login or editing.

There is surely a way, or should be a way, that does not involve hook_page_alter(), but hey, this works.

Media module should use Views for Administration

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.

Exposed filters and VIews Gotcha

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.

Capturing Menu Block configuration in code with hook_menu_block_blocks()

<?php
/**
* Implements hook_menu_block_blocks().
*/
function feature_about_menu_block_blocks() {

Adding non-menu things to primary links menu items with Drupal 7's page alter hook

The request was to stick search in a menu. I said "I bet that's easy with hook_page_alter()!"

Not quite.

The primary links menu is output directly by the theme, and so is one of the very very few things that occurs after hook_page_alter().

You can tell the theme to stop outputting it directly, and put it in a block that is displayed in a region, or you can add it to the page rendering array in code with hook_page_build().

Theming with Display Suite and Preprocess Functions

Display Suite does not use node-*.tpl.php. This would is be by design. There are three ways i see to bring in custom elements.

Custom fields

Typical usage for custom elements would seem to be creating entire custom 'fields' (as opposed to small variables) which can then be placed by Display Suite-- as shown in the first part of this post:

Procedure for resolving a a left-behind branch that has merge conflicts

DRAFT. Better methods from better minds invited!

Situation: Someone has been working away wonderfully on a git branch on your project. You do some crazy stuff with it over the weekend, and when they, on their continnum branch, go git pull --rebase origin continuum and get conflicts they don't know how to deal with, or when they go git fetch origin and git rebase master and have conflicts.

You want to take this off their hands.

Settings for sets of sites: Putting Drush configuration into your project repository

Inherit local-only options with 'parent'

Parent is not working across files. Filed support request: http://drupal.org/node/1262230

In an aliases file that lives with your project, so for our SDL project, sdl.aliases.drushrc.php, put in all settings that are true no matter who is using Drush and from where. This is the settings for an externally hosted development collaboration site.

Syndicate content