commerce_product_autocomplete throws PHP warning when no arguments are passed

How does it get called with no arguments for you?

Ok, great - thanks for the info. We modeled this after the taxonomy autocomplete menu item, so I wonder if core has since implemented a fix for the similar issue. At the very least we can kill those warnings just by including default values in the function parameters and testing them for validity in the page callback.

Had the same errors reported on a site I manage. Will try the change suggested in #5 as it looks simple enough to resolve.

@rszrama should commerce_product/autocomplete get some kind of access control?

@blasthaus I think that I good start, here a patch for at least that.

RE#8 Regarding the coding standards 80 character wrapping on that same function, I'd rather leave that in unless the maintainer has a problem with it.

Thanks for the point about the parameter defaults, I missed. that.

#9 patch works.. thanks

While this doesn't affect commerce, commerce_discount is (ab-)using these autocompletes.

commerce_product/autocomplete/commerce_product/0/0

Maybe we can let the bundle go to default, or possibly better the default for the field will allow?

It could definitely use some work, here's the leading snippet from the page callback in taxonomy module

function taxonomy_autocomplete($field_name = '', $tags_typed = '') {
  // If the request has a '/' in the search text, then the menu system will have
  // split it into multiple arguments, recover the intended $tags_typed.
  $args = func_get_args();
  // Shift off the $field_name argument.
  array_shift($args);
  $tags_typed = implode('/', $args);

  // Make sure the field exists and is a taxonomy field.
  if (!($field = field_info_field($field_name)) || $field['type'] !== 'taxonomy_term_reference') {
    // Error string. The JavaScript handler will realize this is not JSON and
    // will display it as debugging information.
    print t('Taxonomy field @field_name not found.', array('@field_name' => $field_name));
    exit;
  }

#9 works. Thank you. Hoping that they'll commit this patch.

Let's go with this more specific approach so it doesn't break commerce_discount.

@mglaman what is #12 refering to?

It would be nice to remove the first parameter but that would break some BC, silly the entity_type is an option as it's for commerce_product autocomplete.

Looks good to me, I talked to @mglaman and he just posted the taxonomy function in #12 for reference.

Light bulb came on in the sprint room - default arguments will be sufficient, but we can really move the calls to the field info API later on in the function to also improve performance and avoid requiring the isset() checks anyways thanks to the argument count check. Patch attached.

Committed.

@rszrama the early return in #14 was intended in my case to avoid giving any chance for bots hiting that page and getting any further than needed into that function and avoiding processing (and in my case causing notices in logs for no good reason).

I may re-open this if the logs start showing bots stuff again.

Oh, no worries, I tested it quite a bit to make sure there'd be no notices in the logs from it. Even as it was before, if you browsed to commerce_product/autocomplete/1/1/1 it would've proceeded through the function past your early exit.