How to change the label of the default value (-Any-) of an exposed filter in Drupal Views? - drupal

I created a view which has three exposed filters. Everything works fine except the fact that I can neither translate or change the default string (-Any-) for the dropdowns. Is there a way to change this string to something more meaningful like "Please Select" and make it translatable so the German version displays "Bitte wählen"? I have two screen captures that may be helpful:
and
A further improvement would be the ability to change the text "any" to something like "please select a (field name here)" but I am losing hope for that =)
UPDATE
IMPORTANT: On further testing, I found that if you choose to display "-Any-" from "admin/build/views/tools", then THAT IS translatable.

For anyone who wants to just change the value of "- Any -" to something in particular then use a custom module to override that looks like this:
function yourmodulename_form_alter(&$form, $form_state, $form_id) {
if($form_state['view']->name == 'your_view_name_here') {
$form['your_dropdown_name']['#options']['All'] = t('- Type -'); // overrides <All> on the dropdown
}
}
The reason you might want to do this is if you have 3 (for example) dropdowns for 3 separate fields. Then having on them wouldn't be very useful for a user (especially if you are not using labels).
In the code above just remember to change "yourmodulename" to the name of your module.
your_view_name_here should be the name of your view (replace dashes with underscores - for example "property-search-bar" would become "property_search_bar")
And change "your_dropdown_name" to the field name - I found this by using dsm($form) with the devel module installed and enabled. This is usually the field name of your drop down so it might be something like "field_my_custom_value".
Hope this helps anyone who needs it!

Three options:
You could change it with localisation, if you have that enabled already. Introducing localisation only for this string is far too much overhead.
You can change it with a form_alter, if you already alter the form anyway. Introducing a module with a hook_form alter for just one string is way too much (maintainance and performance) overhead.
You coud change it with a simple string override in your settings.php
In Drupal 7 (Drupal6 differs in details only)
/**
* String overrides:
*
* To override specific strings on your site with or without enabling locale
* module, add an entry to this list. This functionality allows you to change
* a small number of your site's default English language interface strings.
*
* Remove the leading hash signs to enable.
*/
$conf['locale_custom_strings_en'][''] = array(
'<Any>' => 'Whatever!',
);
Note though, that this will change every occurrance of the full string <Any> (case sensitive) to Whatever, not just the ones in that single form.

Views exposed filter label is not translatable in D6.
Go to Administer > Site building > Views and select tab tools.
Replace 'Label for "Any" value on optional single-select exposed filters: ' by the translatable '- Any -'.
Important: visit the views with exposed filters in at least one language which isn't your default language.
Then you can translate "- Any -" through Aminister > Site building > Translate interface (case sensitive).

Or you can simply use a line of jQuery code like this:
$(document).ready(function(){
$("#views-exposed-form-url-name-display-name #edit-tid-all a").text("All");
});

The Better Exposed Filter module allows you to change the "-any-" label in a Views exposed filter.

I'd rather go with the simple solution: String Overrides.
With this you simply add a string you want to change on your site, and replace it with anything you want (Strings of course).

May be module https://www.drupal.org/project/views_advanced_labels helps?
I found it, but have not tried it yet.

if ($form['#id'] == 'views-exposed-form-project-search-block-project-search') {
foreach ($form['#info'] as $filter_info) {
$filter = $filter_info['value'];
if ($form[$filter]['#type'] == 'select') {
$form[$filter]['#options']['All'] = $filter_info['label'];
}
}
}

If you use Better Exposed Filters module, go into Exposed Form > Exposed form style: Better Exposed Filters | Settings > look for your field > Advanced Filter Options > put "- Any -|All" in the "Rewrite the text displayed" field.

Related

How do I make a node title translatable?

I'd like to translate each node title as a string (using i18n). I'm trying this function in my theme template:
function theme_process_page(&$variables) {
$variables['title'] = t($variables['title']);
}
Yet when I refresh strings, none of my node titles are on the list. Is there something I'm missing?
And to clarify the function name is using my theme name, not the word "theme".
Title is my usual solution for this (I use Entity Translation, it works fine with Title module).
This module replaces node titles by a regular translatable text field. You can choose wich content type titles must be replaced (on the "Manage Field" forms, you'll find a "replace" link in the title row). Pretty useful.
Good luck
You should never use t() to translate user-supplied or variable strings. See the documentation on the function.
That said, there are some solutions, one is to use the built-in language support for entity fields. Following that you should be able to do something like this in a field hook (in a module, not in your template):
$langcode = $field_info['translatable'] ? $content_langcode : LANGUAGE_NONE;
$entity->{$field_name}[$langcode][0]['value'] = t("Salut!");

What is the standard way to get/set datetime from fluid in typo3 flow?

What is the standard way to get/set datetimes to/from fluid in typo3 flow?
Is there editable html field which - like a basic f:form.textfield - will allow the datetime to be entered, edited and persisted?
I know I can display a datetime with eg
<f:format.date format="d.m.Y - H:i:s">{productArticle.classdate}</f:format.date>
but in that case the value is null nothing gets displayed and no entry is possible anyway. Does property work with f:format.date in some version? I get "property not registered" when I try it.
Or do I need to have two fields on my page, one for date and one for time, that I put together in the Action?
Thanks
I'm not sure if it's standard way, and personally I don't like it.. but it can be done like this:
In Fluid for new/edit actions:
<f:form action="create" objectName="girlfriend">
...
<f:form.textfield property="birthDate" placeholder="1991-12-30 - 18:25:58" value="{newGirlfriend.birthDate->f:format.date(format:'Y-m-d - H:i:s')}" />
...
</f:form>
In your controller you can add initialize*Action and update propertyMappingConfiguration for \DateTime if standard isn't good for you (it has to be done for both create and update action):
public function initializeCreateAction() {
$mappingConfig = $this->arguments['girlfriend']->getPropertyMappingConfiguration();
$mappingConfig->forProperty('birthDate')->setTypeConverterOption(
'TYPO3\Flow\Property\TypeConverter\DateTimeConverter',
\TYPO3\Flow\Property\TypeConverter\DateTimeConverter::CONFIGURATION_DATE_FORMAT,
'Y-m-d - H:i:s'
);
}
Sometimes it's easier to not pass object directly to controller but create it on service layer. You can also take a look at TypeConverters - they do not require initializeActions and you can easily override existing ones setting higher priority..

Drupal 6: how to make CCK default values translatable?

In my multilanguage Drupal 6 website I need to make my CCK field default values translatable, i.e.
Hello - in the English version
Bonjour - in the French one
I cannot find this text with Translation Table, neither are these values in variable table so that I can use multilingual variables.
Do You know how to have different default values in different languages?
When you define the CCK field, you can enter a PHP code snippet to override the default value of the field.
Enter the following there :
return array(0 => array('value' => t('Hello')));
Now access a node add page with this CCK field from a non-English version so that it gets added to translatable strings.
Now you're able to translate it using the "Translate interface" menu (it might take a visit to the "create" page of your cck type first though). It doesn't require any extra modules in fact, just basic D6 (and it probably works in D5 and D7 as well).
This method is a bit of a hack. Im not sure I would deploy this without really considering the consequences. For a simple usecase it MIGHT be ok.
Create a custom module, lets say def_translate. To def_translate.module, add a function
function def_translate_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
if($node->type == "sometype"
&& $op == "load"
&& $node->field_some_cck_field_type[0]['value'] == "your default value")
{
$node->field_some_cck_field_type[0]['value'] =
t($node->field_some_cck_field_type[0]['value']);
}
}
Ok - so what is this doing?
When a node is loaded, hook_nodeapi gets called, with $op set to "load". This gives us an opportunity to do manipulate the node before it is rendered. Before we do anything we check
Is this the right type of node?
Is our op = "load"?
Is the value our default value?
What we then do is pass the existing default value through the t() function. This will make the default string available to i18n translation table, and you can then use the normal way of translating strings.
*DISCLAIMER*
I have not tested this myself in production. Im not entirely sure what the effects will be. You probably want to think this through before implementing it, and you probably want to put some features in to look up the default values from the DB incase they are changed in the CCK UI.
Hope this helps - or possibly shakes a hint of a solution to your problem!

Drupal Taxonomy Block, Vocabulary Listing

I looking for the best way to implement a block that lists all terms of a certain vocabulary. Each term should link to page that lists all nodes associated with that term. Any help would be greatly appreciated. Thanks!
See here for a great tutorial to achieve exactly what you want
http://chrisshattuck.com/blog/how-add-block-menu-tags-or-other-taxonomy-terms-drupal-site
The easiest way to approach this would probably be to use Views, and simply create a new view of the type "term". Here's a quick example which assumes that you have some basic familiarity with the Views UI:
Visit Views > Add (build/views/add), give your new view a name, and select Term from the "View type" radio buttons.
On the next page, start by adding a Taxonomy: Vocabulary filter and selecting your vocabulary in the filter settings.
Add a Taxonomy: Term field and enable the Link this field to its taxonomy term page option in the field settings. You might also want to remove the field's label, since this is just a simple listing.
You probably want your display to display all terms in your vocabulary, so change the "Items to display" 0 (unlimited). By default, new views only display 10 items at a time.
Check out the Live preview below to see if it's outputting what you need.
Add a new Block display using the dropdown on the left side of the Views UI.
Give your new block a name in the "Block settings" area. This is the description that will appear on Drupal's block admin page.
Save your view and visit admin/build/block to place and configure your block.
It's worth noting that Views does indeed have some overhead, but in my experience, its flexibility and ease-of-use far outweigh the relatively minor performance hit.
If you'd like to avoid using Views, you could write a pretty simple custom module using hook_block() and adapting http://drupal.org/node/247472. If you'd like, I can edit this answer with an example module based on that.
(Posting this as another answer, since this is a different approach than my first answer.)
As I mentioned above, here's another approach involving a custom module based on the code at http://drupal.org/node/247472. You could also just drop that code into a custom block with the "PHP" input format selected, but that's generally considered to be bad practice.
Add a new folder in sites/all/modules called vocabulary_block. Customize and add the following two files:
vocabulary_block.module
<?php
/**
* #file
* Exposes a block with a simple list of terms from [vocabulary].
* Each term is linked to its respective term page.
*/
/**
* Lists terms for a specific vocabulary without descriptions.
* Each term links to the corresponding /taxonomy/term/tid listing page.
*/
function vocabulary_block_get_terms($vid) {
$items = array();
$terms = taxonomy_get_tree($vid, 0, -1, 1);
foreach($terms as $term) {
$items[]= l($term->name, "taxonomy/term/$term->tid");
}
if(count($items)) {
return theme('item_list', $items);
}
}
/**
* Implementation of hook_block().
*/
function vocabulary_block_block($op = 'list', $delta = 0, $edit = array()) {
switch ($op) {
case 'list':
$blocks[0]['info'] = t('List of [vocabulary] terms');
return $blocks;
case 'view':
if ($delta == 0) {
$vid = 43;
$block['subject'] = t('[Vocabulary]');
$block['content'] = vocabulary_block_get_terms($vid);
}
return $block;
}
}
vocabulary_block.info
name = Vocabulary Block
description = Exposes a block with a simple list of terms from [vocabulary]. Each term is linked to its respective term page.
; Core version (required)
core = 6.x
; Package name (see http://drupal.org/node/101009 for a list of names)
package = Taxonomy
; Module dependencies
dependencies[] = taxonomy
Notes
Be sure to change $vid = 43; to
reflect the ID of the vocabulary that
you'd like to load. You can find the
VID by visiting
admin/content/taxonomy and looking at
the destination of the edit
vocabulary link for your
vocabulary. The VID will be the last
fragment of that URL:
admin/content/taxonomy/edit/vocabulary/[vid].
I wouldn't normally hard-code the
$vid into the module itself. However,
setting up the necessary Drupal
variable and administration form (to
allow users to select a vocabulary
from the Drupal interface) would be
overkill for this answer.
For your own documentation purposes,
don't forget to search/replace
[vocabulary] in those two files and
use your own vocabulary's name
instead.
This method may not necessarily be more performant
than the Views method I described
earlier, especially once you start considering caching,
optimization, etc.
Since performance is a priority,
I recommend thoroughly testing a
variety of different methods on this page and
choosing whichever one is fastest for you.

How do I dynamically change ubercart's default messages from my module

There are some products for which I would like to have a special checkout complete message that would differ from the default.
I know that I could probably do this by changing the default redirect page to something else. [And I'm not sure if that would introduce another problem]
However, I would like to know if there is a standard/better way of approaching this problem.
Thanks!,
D
Consider the String Overrides module. Here is a quote about it (from the module's project page):
Provides a quick and easy way to replace any text on the site.
Features:
Easily replace anything that's passed through t()
Locale support, allowing you to override strings in any language
Ability to import/export *.po files, for easy migration from the Locale module
Note that this is not a replacement to Locale as having thousands of overrides can cause more pain then benefit. Use this only if you need a few easy text changes.
I guess the only other possible way of doing what I am thinking of is to override the theme function that ubercart uses to display the message. And this probably seems like it would make the most sense.
In this case I would override theme_uc_cart_complete_sale
I could set a
$_SESSION['is_special_product'] == TRUE;
and then set $message to my $special_message if it's been set.
if ($_SESSION['special_product']) {
$special_message = t('This is my special message');
$message = variable_get('special_product_message', $special_message;
}
Finally, to override from my module I will need to hook into the pre-process hook:
function $modulename_prepocess_$hook(&$message) {
if ($_SESSION['special_product']) {
$special_message = t('This is my special message');
$message = variable_get('special_product_message', $special_message;
}
}
It is important to note that it is not enough to have this function in your module. The preprocess functions are only invoked when the template file that overrides the theme function is called.
More details can be found at http://drupal.org/node/223430

Resources