Currently, when the checkboxes field type is used, errors are thrown when the field is filled in by an user. This is because the value result is an array, while the other field types result in a string.

I see two possible ways of fixing this:
1. Instead of supporting multiple checkboxes in a single field, a field type with a single checkbox could be supported.
2. Accepting arrays as possible value result. This will require a database change: values will need to be saved serialized in case the value is an array (and thus a larger data type in the database is needed).

How do you think about how to fix this field type?

Comments

megachriz’s picture

As the Profile module also supports a single checkbox only, I think option 1 is the best way to go.

panthar’s picture

I agree, single checkbox might be the best here. I will look at that.

Thanks.

megachriz’s picture

Hey panthar,

Welcome back. I've changed a lot on the Extra Fields Pane module in the last couple of months. I've documented the changes in the changelog (short descriptions). You can read about big changes here #831134: New features and changes in 2.x version of Extra Fields Checkout Pane module, particular post #98.
You may also want to read post #90 in that thread, although some of the tasks written down there are already done.

panthar’s picture

Hey Megacriz,

I have not been totally out of it, last thing I did was the token stuff! :)

The module has definitely matured (thanks to everyone!), and it seems like a lot of our original data structure/organization is still there since I last peeked at it. Oh, and I finally got a updated ubercart to test it with ;)

I will go ahead and change this checkbox stuff (at least attempt the single checkbox idea), because in it's current state, its basically useless, as no one seemed to find a solution to the problem at hand.

megachriz’s picture

Assigned: Unassigned » panthar

Well, there were huge changes since the token stuff! :) Hope you can find your way out. If not, you can ask me about the changes (and/or read the posts I mentioned earlier).

Good luck with the checkboxes. :)
You will need to do most of the changes in the file ucxf_field.class.php. The method generate() should output the field (form API array), the method generate_value() returns what was filled in the fields' 'value'-field ('value' of the table 'uc_extra_fields', not 'uc_extra_fields_values') and formats it's in a way it can be used together with the field. For select fields this is a list of options, for textfields this is a default value. This method gets also called in the views handler 'uc_extra_fields_pane_handler_filter_selection'.

Other files that will need to be (little) adjusted are uc_extra_fields_pane.views.inc and checkout_pane.inc. I don't think order_pane.inc will need a change.

panthar’s picture

MegaChriz,

So I am trying to figure out the checkboxes still...

But in the mean time I ran into a bit of an issue with how you guys transitioned to the multiple files.

That is, the const UCXF_WIDGET_TYPE_SELECT = 1;
const UCXF_WIDGET_TYPE_CONSTANT = 2;
const UCXF_WIDGET_TYPE_PHP = 3;
const UCXF_WIDGET_TYPE_CHECKBOXES = 4;
const UCXF_WIDGET_TYPE_TEXTFIELD = 5;
const UCXF_WIDGET_TYPE_PHP_SELECT = 6;
const UCXF_WIDGET_TYPE_PHP_CHECKBOXES = 7;

defined inside of ucxf_field.class.php , the problem is, inside of the checkout_pane.inc / order_pane.inc, those constants are not defined, since their defined as class variables.

Would be happy to fix this, by defining them as define(UCXF_WIDGET_TYPE_SELECT , 1) as opposed to its current setup.

I guess the other option is to add the same constants to order_pane.inc and checkout_pane.inc?

megachriz’s picture

The reason I moved the constants is to keep everthing what is related to an ucxf field itself inside the class definition.

To point to a class constant, first include the file with the class definition (ucxf_field.class.php). Then you can point to a class constant using this syntax:
class::CONSTANT
So the code would look like this:

<?php
module_load_include('class.php', 'uc_extra_fields_pane', 'includes/ucxf_field');
$fieldtype = ucxf_field::UCXF_WIDGET_TYPE_CHECKBOXES;
?>

You can see an example of this in uc_extra_fields_pane.views.inc in the function uc_extra_fields_pane_views_fetch_field() (starts on line 151)

However, I'm not sure if it will be needed to check the field type in order_pane.inc and checkout_pane.inc. If we going to make use of a single checkbox I guess it won't be necessary to have an alternate way of displaying the value if the value will be a string. I saw that I made a little mistake in checkout_pane.inc. On line 71 there is this code:

if ($field->value_type == UCXF_WIDGET_TYPE_PHP_CHECKBOXES ||
$field->value_type == UCXF_WIDGET_TYPE_CHECKBOXES ) {

This should have been:

if ($field->value_type == ucxf_field::UCXF_WIDGET_TYPE_PHP_CHECKBOXES ||
$field->value_type == ucxf_field::UCXF_WIDGET_TYPE_CHECKBOXES ) {

I think these line can be removed now if the resulting value of the checkbox will become a string. I'm not completely sure of this yet though. If it still results in an array, we should convert it to a string before it will be added to the order object (this is when the order reaches the operation 'process').

The following lines in checkout_pane.inc (line 31 and 32) are also wrong:

case UCXF_WIDGET_TYPE_PHP:
case UCXF_WIDGET_TYPE_CONSTANT:

This should have been:

case ucxf_field::UCXF_WIDGET_TYPE_PHP:
case ucxf_field::UCXF_WIDGET_TYPE_CONSTANT:

Hope that this clears things up. :)

mattcasey’s picture

subscribing

megachriz’s picture

Status: Needs review » Needs work

Hi panthar,

Are you still working on fixing the checkbox field type? Please let me know. If you have stopped working on it, can you send me the code of what you currently got?

maurizio.ganovelli’s picture

Hi MegaChriz, i'm working now on a project that need this feature. I'm following the second way (accepting arrays as possible value). As soon as possible i'll commit some changes to repository.

megachriz’s picture

Hey, blackice! Fine you want to implement this, but maybe you want to stick with just a single checkbox implementation (because the profile module also supports a single checkbox only)? I think things will be getting less complicated when only supporting a single checkbox.

Tell me what you think about this.

maurizio.ganovelli’s picture

Yes, supporting arrays is a bit more complicated but in some circumstances can be really useful (e.g. selecting more than one day of a week or in general when options can be logically grouped).
I need also to change db value field type from varchar(255) to text to store serialized arrays, but in my current project i also need to implement a "textarea" new type with more than 255 chars.
There are drawbacks also in views integration for this implementation of checkboxes.

What do you think about implementing two distinct type (single and multiple)?

megachriz’s picture

Hi blackice,

I was thinking to support only a limited amount of field types, as I was not planning to copy CCK.

Can you explain why these fields have to be a part of an address?

For non-address fields users also have the ability to use the Ubercart Webform Checkout Pane module, so I guess they should use that module if they want more field types. That module is not designed to add fields to existing panes, so we take care for the address fields.

maurizio.ganovelli’s picture

You are absolutely right, these fields have nothing to do with an address. They are linked to an order and could be managed with uc_webform_pane. My choice for the project I'm developing is to manage data without using webform.

However, I think I can still develop the logic of the single checkbox.
The idea then would be to eliminate the types:
UCXF_WIDGET_TYPE_CHECKBOXES
UCXF_WIDGET_TYPE_PHP_CHECKBOXES
and define only:
UCXF_WIDGET_TYPE_CHECKBOX
Is that right? Php can be useful to define the value of a single checkbox?

Just a curiosity: what's the use of the panel "extra information" then? It does not create some confusion?

megachriz’s picture

Extra information pane
The information pane was already there before I joined this project. The pane had been requested in #751898: Additional fields unrelated to billing/delivery.
Initially, the idea was there to provide multiple information panes, but at a certain moment arski, maintainer of the module Ubercart Webform Checkout Pane, told us about that module and we realized supporting multiple panes was sort of copying functionality already provided by Ubercart Webform Checkout Pane. However, the information pane remained. I believe panthar did not want it to be removed, but I'm not sure. Maybe it just remained because we were not sure which direction to follow yet.
Currently, I am using the information pane in one of my projects, but only because I then don't need to install two extra modules.

Checkbox field type
Great you want to implement this!
I think you can drop the PHP checkbox field type. There is no PHP equivalent for a text field either.
But, there probably could be a use case for letting PHP generating the checkbox value, but I think it's a uncommon case. In those cases maybe users should be implementing a hook_form_alter().

maurizio.ganovelli’s picture

StatusFileSize
new10.3 KB

Attached is the modified code (3 files in includes directory). I've tested it with address fields and seems to work well during checkout and order editing.
Let me know: if there aren't problems/bugs i will commit changes to git as soon as possible.

megachriz’s picture

Assigned: panthar » megachriz
Status: Needs work » Needs review

I will test it tomorrow. Thanks, blackice!

maurizio.ganovelli’s picture

StatusFileSize
new1.57 KB

Here's a patch for views integration (uc_extra_fields_pane.views.inc).

megachriz’s picture

Assigned: megachriz » Unassigned
Status: Needs review » Needs work

Hi blackice,

Thanks for your work.

I tested the changes and this were the issues I had with it:
- Setting the field required has no effect.
- Checkboxes act differently in the information pane (review page displays '1'|'n/a' instead of 'Yes'|'No'). An update in checkout_pane.inc will be needed.

I have not yet tested the update for views integration.

maurizio.ganovelli’s picture

Status: Needs work » Needs review
StatusFileSize
new12.31 KB

Hi MegaChriz,

- Setting the field required has no effect.
I think that can be related to D6 issue: #259292: Required radios/checkboxes are not validated (D6).
A possible solution is to use module http://drupal.org/project/checkbox_validate.

- Checkboxes act differently in the information pane (review page displays '1'|'n/a' instead of 'Yes'|'No'). An update in checkout_pane.inc will be needed.
In attachment you can find a patch with all the last changes i've done, including those made to checkout_pane.inc.

maurizio.ganovelli’s picture

Hi MegaChriz, i tested the patch and also made some other changes for token and i18nstrings integration. Everything seems to work fine so i think i can commit to dev branch.
Have you found issues on attached patch?

megachriz’s picture

Assigned: Unassigned » megachriz

Hi blackice,

I hope to test the patch tomorrow.

Regards,

MegaChriz

megachriz’s picture

Assigned: maurizio.ganovelli » megachriz
Status: Needs work » Needs review

Hi blackice,

I tested the patch and I have found two small issues:

  • The checkbox field type does not respect the display options at lines 69 to 82 in checkout_pane.inc. A custom order field is viewed even when the field may not be be displayed (see further).
  • You added extra spaces at some places:
    • Lines 73, 77, 126, 132, 133 and 136 in order_pane.inc
    • 3/4 space indents instead of 2 at lines 358 to 376 in addressfields.inc
    • Lines 451 and 502 in ucxf_field.class.php
<?php
// Display it as data, unless its a checkbox
if ($field->value_type == ucxf_field::UCXF_WIDGET_TYPE_CHECKBOX ) {
  $review[] = array(
    'title' => $field->output('label'),
    'data' => ($arg1->extra_fields[$field->db_name] == 1) ?  t('Yes') : t('No'),
  );
}
elseif ($field->may_display('review')) {
  // warning: user input --> check_plain
  $review[] = array(
    'title' => $field->output('label'),
    'data' => ($arg1->extra_fields[$field->db_name]) ? ' ' . check_plain($arg1->extra_fields[$field->db_name]) : t("n/a"),
  );
}
?>

Values of checkbox fields are shown even when $field->may_display('review') is false.

EDIT: typo

megachriz’s picture

Status: Needs review » Needs work
megachriz’s picture

Assigned: megachriz » Unassigned
maurizio.ganovelli’s picture

Assigned: Unassigned » maurizio.ganovelli

Hi MegaChriz, thank you for testing the code. The field display issue in checkout_pane.inc has been resolved with the last changes (after patch at #20): i've patched also lines 30/31 (post #7) to match constants definition and deleted extra un-needed spaces and new lines.
I'll commit all changes to repository as soon as I have some time off from work (hopefully in the afternoon).

megachriz’s picture

Assigned: megachriz » maurizio.ganovelli
Status: Needs review » Needs work

Great!

maurizio.ganovelli’s picture

Status: Needs work » Fixed

Changes committed to repo, mark this issue as fixed!

Status: Fixed » Closed (fixed)
Issue tags: -checkboxes

Automatically closed -- issue fixed for 2 weeks with no activity.