The term "database shards" makes me giggle.
Ben Buckman's blog
How to make a Views "exposed filter" dropdown appear as checkboxes
I'm using Views' "expose filters as a block" functionality in a custom search page. One of the filters is for content type, and users need to be able to select multiple options. Views can only generate multi-select lists as dropdowns, however, and the designs require checkboxes. Using a hook_form_alter to flip the #type from 'select' to 'checkboxes' fails because the form API structures those so differently. The views_filter_pack module claims to be able to convert from one to the other, but is extremely over-engineered for this purpose. Some searching around showed that other people had the same problem but no solutions seemed to work.
Then it dawned on me that I didn't need Drupal or Views to use checkboxes, I just needed the browser output to be rendered as checkboxes.
Content Type Selector saves a few previous seconds
CCK's standard "Display Fields" settings are good for configuring per-content type field visibility and can save a lot of custom coding time. If a field is shared over a dozen content types, however, a change to one has to be made to the others, and that's a lot of clicks.
The Content Type Selector module adds a little dropdown to the right of the tabs on the CCK settings pages. So you change the field settings on one content type, pick the next type in the dropdown, change it there, etc. It's still a lot of clicking but it's a few seconds trimmed with each page and feels more seamless.
Today I Learned: Translate custom (core) strings
On a site we're starting to build, Drupal's core "Sticky at top of lists" functionality isn't necessary (using Nodequeue for lists), but nodes need to be included or excluded from search results on a per-node basis. Rather than create a custom CCK field, and since we're building search (as usual) through Views, I decided the simplest answer was to rename "Sticky" to "Appear in Search Results," and filter accordingly in the view.
So how to do this? hook_locale() only works on non-English languages (see t()) and seems to define groups rather than strings.
The simplest solution, it seems, is to use settings.php (or in this case, a common.settings.php used by all the others). Like so:
$conf['locale_custom_strings_en'] = array(
'Sticky at top of lists' => 'Appear in search results',
);
'Sticky at top of lists' => 'Appear in search results',
);
Voila! It works even with the Locale module disabled. (It's not really needed since it's an English-only site.) And since the string is always run (by core and Views) through
t(), it applies universally. It's still `sticky` to the database but that doesn't matter.
New to me: Popups module
I've started using and loving the Popups API module. It allows other modules to create lightbox-type ajax popups of other pages and forms. Out of the box, it includes the option to convert several admin UI pieces into popups, like the Configure Block links, Taxonomy Add/List/Edit links, etc. Saving a few seconds here and there adds up to a lot of time!
(Note: Make sure to set the Content Selector in your theme settings (/admin/build/themes/settings/themename). The default is strange, but in most themes div#content should do it.)
Using SVN Merge for Dev-Prod Web Deployments
We use Subversion (SVN) to manage our code, and typically branch the code from 'dev' to 'prod' at launch time, with each project's tech lead determining the best way to manage the two repositories in parallel for subsequent development. SVN, like any decent versioning system, has branching and merging functionality, but until recently I had little success (and some disaster) trying to use it. So I used the cruder but tried-and-true method of locally rsync'ing dev to prod (with -rC for recursive and ignoring SVN metadata) and committing the changes to each separately. That mostly works fine, except it can be a very tedious process (using FileMerge to check every file and figure out which branch's version is correct); it makes SVN's logs very difficult to understand (with no clear history to a file and duplicate commits of everything); it's easy to make a mistake and mess up a branch; and it seemed unnecessary given SVN's built-in functionality. In some cases, the dev and prod branches got so out of whack that the developers had given up on merging them, and all development was done on local copies of the production branch, an inefficient (and dangerous) method that made branches pointless.
So on my latest post-launch project, I decided to figure out SVN merging. The first deployment process took 2+ hours with a splitting headache at the end; then 1 more lucid hour; now it's 5 minutes, so I do this even for extremely urgent fixes. svn help merge describes multiple ways to use the command; this is how I've gotten it to work.
Environments module: simplifying developers' management of 2-dimensional site environments
This week, I released a Drupal 6 module called Environments (shortname Envts), my first released module and EchoDitto's first for Drupal 6. Its purpose is to help developers manage "two-dimensional" Drupal site environments. Drupal is fairly good at running multi-site builds, with sites folders and different settings.php files. Modules like Domain Access are good at managing those sites one-dimensionally - a single list of hosts with primary (mysite.com), secondary (special.mysite.com), etc, and deep integration with Views and other modules.
But this single list of sites is built for one environment: one set of domains, such as for a live site. For example:
- dartcenter.org [primary]
- dartsociety.org [secondary]
Domain Access is good at listing these domains and filtering nodes by them. But in our work, there's never only one environment. There's a development environment -
- dartcenter.dev.echoditto.com [primary]
- dartsociety.dev.echoditto.com [secondary]
- and each developer usually has a local server environment -
- dartcenter.ben.local [primary]
- dartsociety.ben.local [secondary]
- and sometimes there's a staging server between dev and live -
- staging.dartcenter.org [primary]
- staging.dartsociety.org [secondary]
- and so forth.
