I'm trying to implement #field_prefix on a text field so I can add some extra UI to my form.
I have a module where I'm doing other overrides like this, with a function that basically looks like this:
function modulename_form_alter(&$form, $form_state, $form_id){
if ($form_id == "contenttype_node_form"){
$form['field_contenttype_fieldname'][0]['#prefix'] = 'prefix'; //this line works
$form['field_contenttype_fieldname'][0]['#field_prefix'] = 'field_prefix'; //this line doesn't work
}
Here's the docs, seems pretty straight forward:
http://api.drupal.org/api/file/developer/topics/forms_api_reference.html/6#field_prefix
I've renamed my theme to effectively disable it - should prove I don't have any other overrides hanging around that would conflict.
What am I missing?
Update:
Ended up overriding theme_form_element to insert my prefix manually when the #field_name meets the right condition. Feels hacky, but text_textfield simply doesn't support #field_prefix.
My guess is that as a CCK field field_contenttype_fieldname isn't actually a textfield, but a custom FormAPI field CCK provides that's like a textfield, and as such it doesn't consume the field_prefix attribute.
Try print_r()ing that field out of the $form and see what its #type is.
Related
My problem:
I have replaced the color input in the customizer with an input that supports the alpha channel. The sanitization function from Wordpress is only for hex colors but I get rgba() colors. I wrote a sanitization function that works perfectly for any new control I add to the customizer but if I replace an existing one and change the sanitize_callback parameter of the corresponding setting to my own function ($wp_customize->get_setting("background_color")->sanitize_callback = "slug_sanitize_color";) Wordpress still uses its standard sanitize_hex_color. The output of var_dump($wp_customize->get_setting("background_color")->sanitize_callback); is string(19) "slug_sanitize_color" so I guess it should work. If more code is needed I can provide it.
My question:
What do I have to do to make Wordpress use my sanitization function for a preexisting control instead of the one Wordpress ships with?
Addition: It all happens inside a function hooked to customize_register
I found the solution myself.
If you want to change the sanitize_callback, sanitize_js_callback or validate_callback you have to manually unregister the old callback function (remove_filter("customize_sanitize_{$settingid}",$wp_customize->get_setting($settingid)->sanitize_callback);), then change the value for the object ($wp_customize->get_setting($settingid)->sanitize_callback = "my_custom_filter_function";) and finally register the new filter function (add_filter("customize_sanitize_{$settingid}",my_custom_filter_function,10,2);).
I'm running Wordpress 4.1 with the TinyMCE editor. In the TinyMCE editor, I've enabled the Advanced Lists plugin, which allows customizing the list style type of list items (ex. <li style="list-style-type: lower-alpha">).
When I submit a post with a modified list style, the list-style-type declaration gets stripped out, but other CSS declarations are just fine (ex. text-align).
Looking at the Wordpress source, the CSS is being filtered by the safecss_filter_attr() function in kses.php. In safecss_filter_attr() I can see an array of CSS declarations. If I add list-style-type to that array, I can then save my post, and list-style-type is no longer filtered out.
However, editing the Wordpress source isn't maintainable, as it'll eventually be overwritten when Wordpress is upgraded. So, my question is this: How do I prevent Wordpress from filtering out the list-style-type CSS declaration in a maintainable fashion?
That array you are editing is actually being passed as a parameter to the 'safe_style_css' filter. The return value of 'safe_style_css' is being stored in $allowed_attr. (Line 1482 in kses.php)
So in your functions.php, write a function that looks something like this.
function my_css_allow($allowed_attr) {
if (!is_array($allowed_attr)) {
$allowed_attr = array();
}
$allowed_attr[] = 'list-style-type';
return $allowed_attr;
}
add_filter('safe_style_css','my_css_allow');
I've not tested that but it looks like it should work.
HTH,
=C=
I am using a multi form model. A $model array is passed to the view and for each model object I am trying to have a text field and it works fine this way. See the code below.
foreach ($model as $f=>$edu):
echo $form->textField($edu,"[$f]schoolname",array('size'=>30,'maxlength'=>128));
I am trying to have an autocomplete text field coded replacing the activeform text field. It is not working. Any ideas how to make this work.See the code below.
foreach ($model as $f=>$edu):
$this->widget('zii.widgets.jui.CJuiAutoComplete', array(
'model'=>$edu,
'attribute'=>"[$f]schoolname",
'source'=>$this->createUrl('AutoComplete/acschoolname'),
// additional javascript options for the autocomplete plugin
'options'=>array('showAnim'=>'fold',),
'htmlOptions'=>array('size'=>'30','maxlength'=>'128',)
));
This appears to be a bug in Yii. Tabular form input is broken with widgets.
A workaround was posted in the Yii forums. I haven't tested it, but it's reported to work:
http://www.yiiframework.com/forum/index.php?/topic/10685-collecting-tabular-input-with-zii-jui-widgets-is-broken/
Baiscally, around Line 82 in CJuiAutoComplete.php, comment out the following lines:
//else
//$this->htmlOptions['name']=$name;
To make sure you are not modifying the Yii core and breaking upgrades, I would copy CJuiAutoComplete.php in to your /components folder and rename it MyJuiAutoComplete or something, and call that instead of CJuiAutoComplete.
Good luck!
I have a really silly problem that has cost me a load of time already.
I have created a content template with a URL in there. When I look at the HTML code for it, I see a big fat "maxlength=256" in the form tag. I'd like to expand the length of this field, because my customer wishes to enter really long links (over 500 characters). Any idea how I can change it? When I do a generic search through the code I see so many occurences of 256, but the length might just as well be in the database somewhere. I have of course made the database field a longer varchar (1024 sounded poetic to me), so that's something I don't have to worry about.
I think it's silly, but the customer's always right, as we know.
I am using Drupal 6.14.
You want to use a hook_form_alter() in your templete.php or a custom module.
It will look something like this:
MODULE_form_alter(&$form, &$form_state, $form_id) {
if($form_id = 'name_of_form_you_want_to_alter') {
form['name_of_url_field']['#maxlength'] = 500;
}
}
Just replace MODULE with the name of your theme (if in template.php) or replace it with the name of the custom module your using.
To find the id of the form, inspect the element with firebug. Same goes for the id of the url field.
Let me know if you need more detail.
EDIT: As pointed out, it looks like you can't call hooks from the theme level.
The best way to go about this is to create a small custom module for you site. You can call it something like SITENAME_customizations.
All you need is a simple .info file named MODULENAME.info which will look something like this:
name = SITE customizations
description = "Customizations"
You will also need a MODULENAME.module file, which is where you will include your hook_form_alter call.
PS. Make sure that you don't close your php tag (?>) in your .module file.
Yahoooooo! I fixed it, thanks to the helpful Drupal pages:
http://drupal.org/node/300705
I figured out I could edit the form after it has been generated completely. The solution presented by Erik is good, but doesn't appear to work for CCK fields. In my case Erik's solution could have worked if it wasn't for this generation step that needs to happen first.
My new code is as follows:
function longerfield_form_alter(&$form, &$form_state, $form_id) {
$form['#after_build'][] = 'longerfield_after_build';
}
function longerfield_after_build($form, &$form_state) {
// This is for a node reference field:
$form['field_page_boeken'][0]['data']['url']['#maxlength'] = 1024;
return $form;
}
Now, I too see that it's ugly, especially because there might be other form elements here (just increment from 0), but it works for the first element! Yippeee!
By default a CCK form creation has a title of the form
Create [Your Content Type Name Here]
I want to change mine to
Register for Such and Such
It was suggested that I could use string-override, but I can't find the string to replace. I've also tried writing code to form_alter, but can't seem to figure out how to get the "title" to change.
Ideas?
There are two possibilities, either you can use the theming laying and set $title variable used in the page templage. You can do this with a preprocess function like lazy suggests.
The other options which I prefer would be to use the drupal_set_title(), this would need to go in a module. I haven't tried this, but I would think that you could use this in your hook_form_alter() implementation. That way you could control which titles get changed pretty easily.
Hook form_alter doesn't affect the title, but you can use a preprocess function:
Try this code to start:
function MYMODULENAME_preprocess(&$variables) {
$variables['title'] = 'test title';
}