Support for non CCK fields (e.g. main Ubercart product fields)

I thought I'd answered this somewhere else, but I can't find it.

Personally I object to any non CCK fields. I dont see why body/title/etc should not be CCK fields themselves.
I remove the body and use autotitle for the title such that I have a "clean" object, then I use CCK fields

Thats my personal view.

Technically, there is no reason why non cck fields can not be treated in a similar way to the CCK ones, it's just I didn't write that bit of code. If somebody wants to have a go, I'm happy to help :-)

Just wondered if anybody else was interested in this?
I sort of agree with your point regarding any new content types I create myself tend to be CCK-built - however, I also use modules such as Question which define their own content types and I'd like to be able to edit them in editablefields too...
MarkFoodyBurton - can you give an idea of how much would be involved in adding support for this, and whereabouts one should start patching the existing code?

Yeah, it shouldn't be that hard, I can try and help a little...
Drop me an email, and I'll point you at the right places.

(Mind you, thats the least of the problem, the module really needs a much deeper re-write :-( )

Cheers

Mark.

This module would be really good for Übercart products, but only if it affects fields that the module defines. Even if I had to do it over again (and it looks that way for the Drupal 6 conversion), I still wouldn't use CCK for the product specific fields because the rest of Übercart relies on those fields behaving in a consistent way.

I guess this means I'm volunteering to help code in this support. It's just too useful to let go, and I know a few salesmen at my company who would really appreciate this.

Fixed non cck fields are easy (because you know what they are) - but things that some module defines without using the "formalism" of CCK --- good luck :-)

Happy to try and help though :-)

Do you need CVS access?

BTW, in what way is a CCK field not consistent?

If it was me (and I am), I'd use CCK fields for my cart (and I am). I get to choose how I define a product nice and flexibly, I get to use views etc to search/compare/etc etc... I get to use this module to edit the fields... it all hangs together OK... thus far the only reason I can see for not using CCK fields is that it's not so easy to "package them up into a module"....

Packaging them into a module is the main reason, really. I want lots and lots of people to be able to use Übercart, and it's a good thing if everybody's installation works the same way, at least in certain respects.

I guess I mean persistent rather than consistent. If some yahoo was able to go in and delete the price field, it'd be really hard for the cart to deal with it.

Also, module-defined fields are easier for other developers to deal with when they make new modules. The domain of CCK's fields extend only as far as a single site, so any system of modules that could be used in more than one place shouldn't rely on a particular configuration without enforcing it.

Thanks for the really well thought out response. I really was asking because I want to know, and you've given me some things to think about. I'm in the process of writing a module, and I'm thinking of adding a cck field that "has" to be used with that module - the question is, what would happen if that field was not there....

Thanks :-)

Cheers

Mark.

I would also like to see non-cck fields supported, especially Ubercart product fields, but also Location module, and possibly others.

The ability to make bulk edits is really helpful ... could this additional functionality be considered?

Without CVS access, I can't make very good diff output, but the attached file should give you the general idea.

If the field isn't a CCK field, it looks in the views field definition for the 'form_parents' key. This shows which part of the node form should be retrieved and displayed. Any module developer that wants to support editablefields can put this in their hook_views_tables(). Core node fields can be handled with a hook_views_tables_alter(), I believe.

Do you want CVS access?
(You should have read access for diff's anyway?)

BTW, I have one or two bug fixes to check in too - so I should do that first!

Cheers

Mark.

I can't seem to check out from CVS, so I don't know what the deal is there. I'll see if the Bazaar mirror is up to date, I guess.

Send me a private message, and we'll take this off line
But, basically you should always be able to check out anonymously.

It's been a while, but the changes were committed. I'd still like more people to test it before a new release is made. You can get the new code on the HEAD branch.

I've been trying to use this great module for Ubercart 2.0 (Drupal 6.x) with no success. Is this patch committed to the 6.x version? If so, maybe someone can give me a pointer since I can't use Views and this module to mass edit multiple prices like I did before.

6.x was re-written, I dont think this got re-written.

Please open the issue again on the 6.x branch
Island Usurper MAY have time to look I dont know

Cheers

Mark.

Done. #451090: Work with non cck fields

Thanks Mark!

Juanzo, #451090 is a different (but related) issue. That deals with the Views Bulk Operations functionality, this is about exposing editable fields in views.

I'm reopening this issue as I'd like to see this working on D6 too. Editable Fields in conjunction with Ubercart could be a killer combination. I have a client who needs to be able to update stock levels in a catalogue that's too large to make individual node editing practical, but too small for one of the full blown stock management systems. Being able to build them a view of their current products with editable stock fields would be a massive boost to them.

Marked #421662: Ubercart non cck fields as a duplicate of this issue.
Marked #451090: Work with non cck fields as a duplicate of this issue.
Marked #611678: Support for Ubercart as a duplicate of this issue.

This would be really good to make happen. Lots of people need this functionality for making rapid editing of Ubercart product prices and stock levels possible. Can Island Usurper or markfoodyburton provide any guidance? Is this is a simple forward port of something above, referred to in #13 above, or is it more complex than that?

I cast a vote for a one click publish/unpublish editable field. That would be sweet.

How far along is this now?

+1 to this!
I would need to make editable inside each view some profile fields!

Has anyone discussed making workflow states appear as a dropdown list? I need to try and implement *something* like this for a work project, if there's a discussion already about it could someone point me towards it? I couldn't find one myself...

...Some pointers would be nice too ;o)

Thanks,

Pobster

28 Months Later ... worse than a Zombie flick.

I'll rack this up to experience. Not bothered either way anymore.

At the moment I will need to implement integration with ubercart prices fields. As far as I can see I will need to modify views handlers for ubercart fields (for example uc_product_handler_field_price). I believe we will need to create submodules in order to integrate different kind of non cck fields with editablefields.

Did anyone have tried to make ubercart prices working? I would like to share my thoughts and develop this submodule as I can see that it will be very handy.

I made a module to do #23 but it has little to do with editable fields... I'm happy to share the code if it helps with implementing ubercart?

Pobster

Pobster, please do. I will try to use it for Ubercart fields if possible. Thank you.

No worries, I'll dig it out tonight. TBH, it wasn't complicated and only involved making an additional field for Views of which I have an example here;

/**
 * Implementation of hook_views_handlers().
 */
function gravy_views_handlers() {
  return array(
    'info' => array(
      'path' => drupal_get_path('module', 'gravy') .'/plugins',
    ),
    'handlers' => array(
      'gravy_views_handler_field_sid' => array(
        'parent' => 'views_handler_field',
        'path' => drupal_get_path('module', 'gravy') .'/plugins',
      ),
    ),
  );
} // gravy_views_handlers

/**
 * Implementation of hook_views_data_alter().
 */
function gravy_views_data_alter(&$data) {
  $data['workflow_node']['sid_int'] = array(
    'title' => t('Current sid'), // Appears in views UI.
    'help' => t('The current workflow state sid that the node is in.'),
    'real field' => 'sid',
    'field' => array(
      'handler' => 'gravy_views_handler_field_sid',
      'click sortable' => TRUE,
     ),
    'argument' => array(
      'handler' => 'views_handler_argument_numeric',
      'click sortable' => TRUE,
      'numeric' => TRUE,
    ),
    'filter' => array(
      'handler' => 'workflow_views_handler_filter_sid',
      'numeric' => TRUE,
    ),
  );
} // gravy_views_data_alter

Then I just made the handler at gravy_views_handler_field_sid.inc and provided a form to pickup an ahah selection which from memory is something like this;

function gravy_views_workflow(&$form_state, $node, $default) {
  $form['gravy_workflow'] = array(
    '#type' => 'select',
    '#title' => t('Workflow State ID'),
    '#options' => workflow_field_choices($node),
    '#default_value' => $default,
  );
  return $form;
} // gravy_views_workflow

But that isn't the actual code (of course, none of the ahah stuff is there!) I'll dig it out tonight when I get home, it'll look something like this;

class gravy_views_handler_field_sid extends views_handler_field {
  function construct() {
    parent::construct();
  }
  function render($values) {
    // I forget how I passed in $node but as it's a join of workflow_node - it's in there somewhere!
    return drupal_get_form('gravy_views_workflow', $node, (int)$values->workflow_node_sid);
  }
} // gravy_views_handler_field_sid

Thanks,

Pobster

Subscribing. If the node body field is supported this module will be very useful to me.

Why don't you just not have a node body then use a CCK textarea instead? This'll then allow you to utilise all the CCK goodness you like!

Pobster

I have managed to make sell_price editable. But it looks like hack actually. In order to reproduce apply patch to DRUPAL-6--2 version and enable module editablefields_uc. In views add sell price and choose formatter "Click to edit". Enjoy.

I have faced a lot of problems and due lack of time didn't find solution. I try to get form element of the price from node edit form. There should be civilized way to find needed element from the form array.

Also the problem is to know how to theme element in editablefields_view() function. I think we should provide some hooks in editablefields to gather this information from other 'plugin' modules.

I think in this way we can get any other fields from the node (both standard node fields and other modules provided).

All thoughts are very welcome.

I would really like to see stock levels editable in views, that would be extremely useful for us.

Hi guys,

I think supporting anything else than CCK fields is totally outside of the scope of this module. From my point of view this module should stay as simple as possible. CCK's API is already pretty convoluted: just look into the issue queue for editablefields and you'll see that we are barely supporting the basic CCK fields like userreferenceand and filefield.

You can always create a new module and support any other types of non-CCK fields like Ubercart attributes, or node's body/title, etc.

But, as I said, this module should just alter CCK fields (at least for now).

Please feel free to reopen this ticket if you think otherwise.

Cheers,
Andrei

ygerasimov, something is wrong with file editablefields_uc.tar_.gz

ygerasimov and can you explain me how to apply patch editablefields-174600.patch?

Subscribing. Need the ability to edit Ubercart Price and Ubercart Stock values.

Yes, I can see something gone wrong. I will take a look.

This is fast and dirty hack to support clickandedit for sell_price and stock level. It is based on 6.x-2.0 release. You need to install both editablefields and editablefields_uc modules. In views fields stock and sell_price you can find new formatters.

Please let me know whether it works not properly (I can have bugs in setting stock level as I never used it).

will it only edit the primary product price and stock, or the price/stock adjustment per sku?

Only primary price and stock. Please try and advise what is missing.

I have created ctools plugins system for editablefields. Please review attached patch. This will make possible other modules to write plugins for editablefields and add additional fields that can be editable.

Also I have recreated function editablefields_load_js(). The patch is against DRUPAL-6--3 branch.

You can review attached uc_editablefields for usage example. It makes list_price editable. But in similar way without changing main module we would be able to create other modules that will expand functionality.

@ygerasimov: thanks for your work. I like the idea of integrating with ctools.

I'll review it as soon as I have some spare time.

Thanks,
Andrei

Hello @ygerasimov -- editablefields_ctools_plugins.patch fails on latest 6.3 branch:

:~/httpdocs/sites/all/modules/editablefields$ patch < editablefields_ctools_plugins.patch 
patching file editablefields.module
Hunk #1 succeeded at 98 (offset 18 lines).
Hunk #2 FAILED at 122.
Hunk #3 succeeded at 203 (offset 48 lines).
Hunk #4 succeeded at 253 (offset 53 lines).
Hunk #5 succeeded at 281 (offset 53 lines).
Hunk #6 succeeded at 293 (offset 53 lines).
Hunk #7 succeeded at 332 (offset 53 lines).
Hunk #8 succeeded at 509 with fuzz 2 (offset 120 lines).
1 out of 8 hunks FAILED -- saving rejects to file editablefields.module.rej

#40 - I meant, if you have ubercart attributes enabled you might have a tshirt with 3 sizes. each size has a different price/stock number. could we edit those fields, assuming we have the http://drupal.org/project/uc_views module enabled?

Hello,

Are these new modules please?
I think that I may need something like that.

I see that my patch does not apply anymore. The problem I faced is that now even usual text fields don't work properly on latest DRUPAL-6--3 version without any patch.

To recreate:
create content type with text field (witget: textfield)
create view and add this field (select formatter Click to Edit)
go to this view and click on Edit
change the value and press Enter
get blank page with javascript variable printed (see attached screenshot example)

Can anyone reproduce this problem?

@ygerasimov: try and keep the javascript console opened, I think you might see an error appear. This might cause the browser to direct you to that page. I'm going to try and allocate some more time to editablefields soon.

@ygerasimo: regarding #46, I opened a new ticket which we can deal with it separately: #1002582: Form shouldn't be submitted on enter

Regarding ctools implementation for 6-3 branch, I'll update your patch to make it apply to 6--3.

This patch applies cleanly to 6--3.

Patch failed applying again. I have modified it. Now it can be applied. Please recheck.

Also I have modified uc_editablefields module (to show [edit] message for sell_price if it has not been modified).

Please review.

Is there anyway someone could create a UC_Attributes editable view?

subscribe

Can you convert patch for Drupal 7.x version of editablefields?

I don't want this in 7.x. Let's leave it for consideration in 6.x.

Will this patch make node title editable as well? It seems all the focus is on Ubercart fields...

Has anyone been able to apply this to Drupal 7 version for Ubercart?

Can this patch be applied to 6.2? (There´s this advice at the module´s page where it says that you should use 6.2 version for production sites).
Can this patch be applied to profile fields?
Thanks!

applied patch - #50. In views selected "click to edit" for the product sell price. In the view, I click on edit, and then nothing happens...is this working for anyone?

Is ther any uc_editablefields for drupal 7?

I could sure use uc_editablefields for Drupal 7.

+1 Support for attributes...

any progress on making pricefileds editable?

Can anybody please update the patch at #50 to the latest 6.x-dev? It failed so I tried to applied the patch manually but still getting errors.

Per https://drupal.org/node/2148735, 6.x is longer maintained so issue is closed. If you wish to be a maintainer of the 6.x branch please create a new issue.

I have found the easiest way for me at least to edit ubercart price fields is to use feeds with uc_feeds you can then change multiple prices in one go, I hope that helps.