I have created a custom field in woocommerce where i want shopowners choose a year of publishing (books in this case).
So far i have:
//Custom Product Date Field
woocommerce_wp_text_input(
array(
'id' => '_custom_product_date_field',
'placeholder' => 'Publicatiedatum',
'label' => __('Publicatiedatum:', 'woocommerce'),
'type' => 'date',
'date-type' => 'years'
)
);
How can i set the date-type to years, as the last key => value (date-type:years) is not working?
I was curious since I was looking for details on using the date field in a woocommerce custom field. I didn't need year only specifically but it was an interesting rabbit hole to run down.
Trying to understand a bit more how woocommerce_wp_text_input creates these fields it started to become more apparent that supplying the type attribute simply passes it on to the HTML attributes. That said, these are standard HTML elements, not a wrapper of sorts that produces more fancy fields utilizing things like jQuery which seems like what the OP was expecting.
Looking over the specs for the date-related HTML text input fields it becomes apparent that there is not an <input> of type="year" available in the spec. We are limited to the type's specified in the specs.
I was able to successfully create a month input with the following:
woocommerce_wp_text_input(
[
'id' => '_my_month',
'label' => __('My month', 'woocommerce'),
'value' => get_post_meta($post->ID, '_my_month', true),
'type' => 'month',
'custom_attributes' => [
'min' => '2020-01',
],
]
);
So understandably, from what I can see, doing what you are asking isn't possible unless the HTML specifications add a year input or woocommerce provides a bandaid when specifying type as year. Hopefully this better explains how woocommerce_wp_text_input expects the data to be formatted and what is really supported.
As an aside that might assist in completing the requirements of the original question through alternate means, you could attempt to implement a jQuery UI picker which supports year only. I however feel that the jQuery UI picker using year only is a bit clumsy being it provides a popup to simply choose a date from a dropdown AND the left/right pagination of the popup still pages through months while showing only years. You might as well just use a dropdown or a number field with the date min/max values you require, both have example code that can be seen in other answers on that aforementioned answer I linked.
Related
I've made a custom page in backpack admin panel. This page is non-CRUD (not related to any model). There are several forms on it, with date pickers, select inputs, etc. So I'am trying to find a way to use backpack fields to create these date pickers and select inputs. Because it seems to be awkward to embed custom js-controls into the project, as Backpack already has appropriate fields.
The only solution I came up with, is to create a crud controller for random model, disable all operations except create, use create operation view as custom page (backpack fields are available this way), and finally override store() method - to prevent creating new model entry in DB.
So, is there a proper way to access backpack fields on custom (non-CRUD) page?
Backpack 4.x fields aren't meant to be used outside CRUDs, but you can do that.
Option A
At their core, Backpack fields are just Blade views, so you can load them using the Blade helper #include(). Just make sure to pass along all variables that the blade file needs. I believe in 99% of the fields that will be a $field and a $crud variable, so this will work:
#php
// set the CRUD model to something (anything)
// but ideally it'd be the model of the entity that has the form
$crud = app()->make('crud');
$crud->setModel(\App\Models\Monster::class);
#endphp
#include('crud::fields.number', [
'crud' => $crud,
'field' => [
'name' => 'price',
'label' => 'Price',
'prefix' => '$'
]
])
This way, you only load the bits you actually want (the inputs), without the overhead of a CrudController. You can point the form to your custom controller and do the saving yourself. What you need to pass for a $field above is a Backpack field definition in array form.
This way is super-simple, but it has a big downside if you ask me. The field definition has to be 100% correct and complete, you lose all the magic and assumption logic that Backpack usually does to make your life easier when you add field using addField(). That's why in most cases I think it's more convenient to go with Option B.
Option B
Instead of manually loading all each field Blade view, add them using addField(), then load all of them just like Backpack does it in the Create or Update operation:
#php
$crud = app()->make('crud');
$crud->setModel(\App\Models\Monster::class);
$crud->addField([
'name' => 'price',
'label' => 'Price',
'prefix' => '$'
]);
#endphp
<form method="post">
#include('crud::form_content', [ 'fields' => $crud->fields(), 'action' => 'create' ])
</form>
The above will produce an output like this:
The benefit of this second option is that you can "forget" to mention stuff in the field definition and Backpack will assume it, you can use the fluent syntax, you can use most Backpack features, really...
I have in my symfony5 form input
->add('required_amount', IntegerType::class, [
'label' => 'Požadovaná částka',
'grouping' => true,
]);
when run form the thousand sepator isn dispaly on typing number
whatis wrong in my code, may I use number format in input in form in symfony
I copy your code and runs just fine to my 4.4.4 symfony project. If you submit this form the output will be 1,000,000 or 1.000.000 depending on your locale value default set in .env file. The grouping property is in IntegerType , MoneyType and NumberType and do the same in all this classes , so this is not your problem. If you describe something in client side (as you type the numbers to add the separator) you need to go with javascript not php, but i don't thinks this is the case.
I'm using HTML::FormHandler to create some forms, and I'd like to be able to validate any select fields on the form by making sure that whatever value submitted was actually a value given to the user. Right now this is how I have my select field set up:
has_field 'choice' => (
type => 'Select',
label => 'Choice',
options => [{value=>"1",label=>"One"},{value=>"2"=>label=>"Two"}],
empty_select => '---Choose an Option---',
apply => [{
check => ['1','2'],
message => 'Must be a value in the list.',
}],
);
Right now this works, but I was wondering if there was a more elegant way to do it? Since HTML::FormHandler already knows what options it has for the field, is there any way to just tell HTML::FormHandler to validate that the what the user choice is in fact one of those options? I've looked through the documentation and can't seem to find it anywhere, but it seems like something that would make sense to have for a field with predefined values. Thanks!
According to the code for HTML::FormHandler::Field::Select this check is already done. Have you tried it?
I added custom fields as described in magento add custom input field to customer account form in admin
But I want a select list, not only a text input one. I don't know which kind of parameter I have to set and how to tell the list of possible values.
Please help :)
Thanks,
Plantex
Where you might do something like:
$setup->addAttribute('customer', 'custom_attribute', array(
'type' => 'text',
'label' => 'Customer Custom Attribute',
));
Use these values instead:
$setup->addAttribute('customer', 'custom_attribute', array(
'type' => 'int',
'label' => 'Customer Custom Attribute',
'input' => 'select',
'source' => 'eav/entity_attribute_source_boolean',
));
The type is int because you will typically be storing the index of the value chosen, not the value itself. The input is select so the admin renderer knows which control to use. The source shown here is a common example, it provides an array of "Yes" and "No" values with numeric indexes.
There are many source models already in the Magento code that you can use and you can create your own too, look at any existing one to see how it returns an array. If you make your own and if it uses text indexes instead of numeric then the type will have to be changed back to text.
Try adding this at your module setup file
'value' => array('notate_to_zero'=>array(0=>'Bleu',0=>'Rouge',0=>'Vert',0=>'Violet',0=>'Noir',0=>'Orange'))
),
or look at this --> http://inchoo.net/ecommerce/magento/how-to-create-custom-attribute-source-type/
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;