How can I change the positions of checkbox and label and how to implement a link into the label?
$acceptGTC = new Element\Checkbox('AGBs');
$acceptGTC->setLabel('I Accept the GTC (show it).');
$this->add($acceptGTC);
regards
n00n
meanwhile:
I tried to overwrite the view helper for checkboxes.
copied
*/vendor/zendframework/zend-form/src/View/Helper/FormCheckbox.php
to
*/module/Application/src/Application/View/Helper/FormCheckbox.php
added to module.config.php
'viewhelpers' => array('checkbox'=>'Application\View\Helper'),
But it still uses the original one...
Do I have to tell zend to use my FormCheckbox?
I don't exactly know the way you are rendering your Zend_Form_Element, but in order to enhance the rendering as you want you should build a custom decorator, and add it to this element.
You should read the Zend documentation on Zend_Form_Decorators, everything is quite well explained and should lead you to a fancy solution.
In my form I create a checkbox
$form['existing_customer'] = array(
'#type' => 'checkbox',
'#title' => t('Are you an existing customer?')
);
When I validate it using hook_validate I would like to add a class to the label? Any ideas how to achieve this?
I can't imagine why you'd want to do this in a validation function, and I think there's a far easier way to accomplish what you're trying to do.
Each element in a Drupal form is wrapped with a container (which has an ID). Inside this container there will only ever be one label.
So if you need to target the element in CSS or JS you just need to do something like this:
#existing-customer-edit label {
// The rule
}
OR
$('#existing-customer-edit label').something();
If you really need to edit the label manually then you're going to have to provide a custom theme for that element, have a look at this example for more information (it's for Drupal 6 but the concept is the same in Drupal 7).
thanks Clive did a fairly nasty work around in the form validation function
$form_state['complete form']['myselectbox']['#title'] = '<span class="privacy-error">you did not check me</span>';
It ain't pretty but it works!
You can add a class in hook_validate():
$form_state['complete form']['submitted']['existing_customer']['#attributes']['class'][] = 'class_name';
Is there any easy way to disable translation of some of the Zend Navigation elements?
e.g. in this case
$page = new Zend_Navigation_Page_Mvc(
array(
'label' => $blogPost->alreadyTranslatedTitleFromDb
// ...
)
);
$container->addPage($page);
Now, when I use:
$page->getLabel();
the label is translated twice. The same for breadcrumbs, sitemaps etc.
I wrote a patch with unit tests for this:
http://framework.zend.com/issues/browse/ZF-10948
If you want only some specific elements to be disabled, i think that only way is to use a partial view script and create your own logic for the menu.
You may add custom properties to the pages. Example: add a property doNotTranslate and in your view script check for this property to know if element should be translated or not.
More info about partial view script is available at http://framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.initial.navigation.menu
I find that even if I just declare an element like
$this->addElement('textarea', 'txt1');
I find that it already has decorators set
Zend_Debug::dump($this->getElement('txt1')->getDecorators());
http://pastebin.com/7Y24g62w
I want to test that I didn't set decorators using setDecorators() or using something like
$this->addElement('textarea', 'txt1', array(
'decorators' => array(...)
));
If I didn't set any decorators then apply default decorators, how can I do that. I want to apply default decorators per element basis, not using Zend_Form#setDisableLoadDefaultDecoraotrs()
There are two options, depending on how exactly you want to be sure a decorator hasn't been changed.
Decorator without option
If you just want to know if all default decorators are set, without thinking about the options of each decorator, you can use this option. Of course you can alter options of a default decorator and this method won't recognize this (but it is faster than an extensive check). Unfortunately the default decorators are hard-coded in the Zend_Form_Element at Zend_Form_Element::loadDefaultDecorators() so you need to copy that list. When in future releases the chain changes, you need to alter your code.
<?php
$default = array(
'Zend_Form_Decorator_ViewHelper',
'Zend_Form_Decorator_Errors',
'Zend_Form_Decorator_Description',
'Zend_Form_Decorator_HtmlTag',
'Zend_Form_Decorator_Label',
);
$decorators = array_keys($element->getDecorators());
if ($decorators === $default) {
// They are the same
}
Check decorators with all options
Here you create a copy of your element and at this copy you reload all default decorators. They get instantiated again so it takes a bit more resources, but all options of the decorators are checked as well.
$clone = clone $element;
$clone->clearDecorators()
->setDisableLoadDefaultDecorators(false)
->loadDefaultDecorators();
if ($clone === $element) {
// They are the same
}
I'm trying to create a node form for a custom type. I have organic groups and taxonomy both enabled, but want their elements to come out in a non-standard order. So I've implemented hook_form_alter and set the #weight property of the og_nodeapi subarray to -1000, but it still goes after taxonomy and menu. I even tried changing the subarray to a fieldset (to force it to actually be rendered), but no dice. I also tried setting
$form['taxonomy']['#weight'] = 1000
(I have two vocabs so it's already being rendered as a fieldset) but that didn't work either.
I set the weight of my module very high and confirmed in the system table that it is indeed the highest module on the site - so I'm all out of ideas. Any suggestions?
Update:
While I'm not exactly sure how, I did manage to get the taxonomy fieldset to sink below everything else, but now I have a related problem that's hopefully more manageable to understand. Within the taxonomy fieldset, I have two items (a tags and a multi-select), and I wanted to add some instructions in hook_form_alter as follows:
$form['taxonomy']['instructions'] = array(
'#value' => "These are the instructions",
'#weight' => -1,
);
You guessed it, this appears after the terms inserted by the taxonomy module. However, if I change this to a fieldset:
$form['taxonomy']['instructions'] = array(
'#type' => 'fieldset', // <-- here
'#title' => 'Instructions', // <-- and here for good measure
'#value' => "These are the instructions",
'#weight' => -1,
);
then it magically floats to the top as I'd intended. I also tried textarea (this also worked) and explicitly saying markup (this did not).
So basically, changing the type from "markup" (the default IIRC) to "fieldset" has the effect of no longer ignoring its weight.
This sounds pretty strange because the manipulation of the form elements' #weight parameter always works reliably for me as advertised. One thing to note, though, is that the weights only affect the order relative to the elements siblings, so if the element you want to move around is on a level below that of the other elements, you'd have to change the weight of the parent element that is on the same level as the ones you want to move against.
To clarify, if you have a hierarchy like so,
$element['foo'];
$element['bar'];
$element['bar']['baz']
you can not move 'baz' relative to 'foo' by setting the weight of 'baz'. You'd have to either set the weight on 'bar' (moving it also), or pull out 'baz' and bring it to the same level as 'foo'.
Another possible reason could be CCK: If you have CCK installed, it allows you to set the order of its own as well as other fields under admin/content/node-type/<yourNodeType>/fields. It changes the order by registering the pre-render callback content_alter_extra_weights(), so this would run after your changes in hook_form_alter.
Edit: Update to answer the question update
The markup field type has a special behavior when used inside fieldsets, which is hinted on in the forms api documentation:
Note: if you use markup, if your content is not wrapped in tags (generally <p> or <div>), your content will fall outside of collapsed fieldsets.
It looks like if it does not only fall outside of collapsed fieldsets, but also refuses to respect the weight in those cases. Wrapping the content of the markup field in <p> tags makes it respect the weight on my machine:
$form['taxonomy']['instructions'] = array(
'#value' => "<p>These are the instructions</p>",
'#weight' => -1,
);
Sometimes (or always, when weighting CCK elements) the line that works in your hook_form_alter or $form['#after_build'] callback is this one:
$form['#content_extra_fields']['taxonomy']['weight'] = 5;
Wanted to insert a <div> I could use in JS. This didn't work for me:
$form['you_as_reviewer']['ui_container'] = array(
'#type' => 'markup',
'#value' => '<div id="le_reviewer_tags_ui"/>',
'#weight' => 5,
);
Weight was ignored.
This worked:
$form['you_as_reviewer']['ui_container'] = array(
'#type' => 'markup',
'#prefix' => '<div>',
'#value' => '<div id="le_reviewer_tags_ui"/>',
'#suffix' => '</div>',
'#weight' => 5,
);
Added prefix and suffix.
I do not quite understand what it is you want to achieve. Could you maybe clarify? Do you want to change the position of the taxonomy's drop-down on the page?
In the mean time you could install the Drupal Devel module (if you haven't done so yet). Then enable "Display form element keys and weights" from Admin > Devel Settings.
This should help you to debug your problem.
Edit after feedback:
I looked into it some more. The taxonomy weight is set in taxonomy.module on line 556 (Drupal 6.12):
$form['taxonomy']['#weight'] = -3;
To test I also implemented hook_form_alter for my module like this:
function mymodule_form_alter(&$form, $form_state, $form_id) {
...
$form['taxonomy']['#weight'] = -9;
...
}
This works for me i.e. it moves the taxonomy drop-down to the top of the page. I can change the weight and it moves accordingly on the rendered page.
Since you said you tried setting $form['taxonomy']['#weight'] in your original post I can currently think of only two possible checks:
Make sure the cache is cleared before testing. (you can use the Devel module for this)
Check to see if your hook_form_alter is called after taxonomy_form_alter
I you post the code you currently have we could look at it in more detail.
Please note: the weights displayed by the Devel module are not very useful for this situation. The weights of the elements on the "sub-forms" are displayed and not the weight of the "sub-form" itself. E.g. when I set $form['taxonomy']['#weight'] = -9; the -9 is not displayed by the Devel module but rather the weights of the elements inside $form['taxonomy'].
Have you specified the weight of another field and now your node form is not organized properly? The form api is kinda touchy and altering the form can result in things getting mixed up. I sometimes have to reassign a weight to my submit/preview buttons to get them back at the bottom of the form where they belong.
Just to cover all bases, make sure that you are clearing your cache as necessary. Drupal stores forms in it's cache by default, if you have the caching module enabled.
This is working for me
$form['forgot_password']['#markup'] = '<div class="text-align-right"><a class="text-primary" href="/user/password" target="_blank" title="Forgot Password?">Forgot Password?</a></div>';
$form['forgot_password']['#weight'] = 3;