Inspections that conflict with Drupal

I'm looking into using PhpStorm 2.1.2 with Drupal.This is quite promising (after adding the global.php file), but there are a number of inspections that give false positives for common Drupal constructs:

1. "Function name must be a string. Closure or class implementing __invoke, currently" in
           $name_of_my_function();
I could not find the relevant Inspection to turn off.


2. "Expected array got NULL" in
            $unlisteds = variable_get('myvariable', array());
            if (isset($object->type) && !in_array($object->type, $unlisteds)) {
$unlisteds is never NULL. variable_get() is defined as

/**
* Returns a persistent variable.
*
* Case-sensitivity of the variable_* functions depends on the database
* collation used. To avoid problems, always use lower case for persistent
* variable names.
*
* @param $name
*   The name of the variable to return.
* @param $default
*   The default value to use if this variable has never been set.
*
* @return
*   The value of the variable.
*
* @see variable_del()
* @see variable_set()
*/
function variable_get($name, $default = NULL) {
  global $conf;

  return isset($conf[$name]) ? $conf[$name] : $default;
}


3. "Undefined function ..." in
          if (function_exists('myfunc')) {
            myfunc();
          }
This can probably be turned off, but it would be nice to have a smarter solution, because that Inspection is very useful to catch typos.


4. "Variable $rid0 might not have been defined" in
  if (!empty($rid0)) {
    if ($rid0 != DRUPAL_AUTHENTICATED_RID) {
      $form_state['redirect'] .= '/' . $rid0;
    }
  }
Not Drupal-specific, just a bug.


There will probably be more later.

Generally, it's a pain to find the right Inspection items to turn off, because their text does not necessarily correspond to their name. It would be very helpful to have a button or link in the message to turn the corresponding Inspection off.


Even with these issues, PhpStorm is a very nice tool and it has already shown me a number of bugs in a module that I'm porting from Drupal 6 to Drupal 7.

9 comments
Comment actions Permalink

Many thanks for sharing your experience.

We do plan to work on end user experience when working on Drupal codebase.

I'll investigate each problem you reported here and post an update later.

BTW the better place to posting this is "Drupal support" meta ticket @ http://youtrack.jetbrains.net/issue/WI-6404

0
Comment actions Permalink

1. Closure check is an "annotation" level error and it can't be turned off unless all error checking is turned off.
Please invoke Quick Doc (Ctrl+Q) on "$name_of_my_function" and check the type info. How variable is defined/initialised?
Probably you just need to add a type annotation somewhere :)

2. Well, the type inference analyser was able to ectract the possibility of returning NULL if theres no default and variable unset.
Unless you can add "@return mixed" to the variable_get source you need to add annotation /** @var $unlisteds TYPE_NAME */ right before or after the initialiser.

3. Please file a feature request to the tracker.

4. There's a relevant issue in the tracker (i.e. if-isset-use) with lots of votes - but tracker is rebuilding indexes and I can't link it now..

0
Comment actions Permalink

Thank you for your replies, Alexey, and sorry for not coming back sooner.

1. Here's a full function taken from Drupal core that triggers the "Function name must be a string. Closure or class implementing __invoke, currently" error:

function field_get_default_value($entity_type, $entity, $field, $instance, $langcode = NULL) {
  $items = array();
  if (!empty($instance['default_value_function'])) {
    $function = $instance['default_value_function'];
    if (function_exists($function)) {
      $items = $function($entity_type, $entity, $field, $instance, $langcode);
    }
  }
  elseif (!empty($instance['default_value'])) {
    $items = $instance['default_value'];
  }
  return $items;
}

Hitting Ctrl-Q shows this:


closure_error.png

Abstractions like this one are typical for Drupal. Having that core module flagged in red is quite irritating.


3. I just found that the function_exists() issue is already in the Tracker: http://youtrack.jetbrains.net/issue/WI-5722 and has been marked fixed two weeks ago. Can't wait to get the next update...

4. Seems to have been fixed as well -- can't wait...


I'm not sure how to work with ""Drupal support" meta ticket" -- do you mean to post anything Drupal-related as a comment to that issue?

0
Comment actions Permalink

Fragment provided does not produce any highlights on current sources. Go grab next eap (will be published today or tomorrow) and try it.

Regarding ""Drupal support" meta ticket" - yes, please aggregate all stuff there.

0
Comment actions Permalink

I have build number PS-107.658 and I'm not getting any EAP updates.

$function is still not accepted.

0
Comment actions Permalink

release builds can't "update" to Early Access Program builds.

http://confluence.jetbrains.net/display/WI/Web+IDE+EAP

0
Comment actions Permalink

All items that I mentioned are fixed in the current EAP, thanks!

I would have liked to register my license but Help|Register is grayed out. There's no information about this, neither on the EAP page nor the FAQ page.

0
Comment actions Permalink

Each EAP build has bundled 30 days license, you don't need enter your license in EAP builds.


0

Please sign in to leave a comment.