Undefined Field inspection on imap_fetch_overview returned objects

PHPStorm 2.0 Preview

msgno is being marked as invalid, but it's not:

  $oMC   = imap_check($rMailbox);
  // Fetch an overview for all messages in INBOX
  $rOverView = imap_fetch_overview($rMailbox, '1:'.$oMC->Nmsgs, 0);
  $iMessageCount = 0;

  foreach($rOverView as $oOverView){

   $iMessageCount ++;
   $oOverView->subject = iconv_mime_decode($oOverView->subject);

   if(preg_match('(\*\*[0-9]*\*\*)', $oOverView->subject))
    self::CheckMailbox_Update($rMailbox, $oOverView);
   elseif(stristr($oOverView->subject, '**NEW**') ||
    stristr($oOverView->subject, 'Notifications from Spiceworks'))
    self::CheckMailbox_New($rMailbox, $oOverView);
   elseif(stristr($oOverView->subject, '**COMMANDS'))
    self::AddToTicketsCommands($rMailbox, $oOverView);
'root@rehabmgrnew.pridedallas.com') &&
    stristr(imap_body($rMailbox, $oOverView->
msgno), 'Starting nightly system backup'))
    self::CheckMailbox_RM5Backup($rMailbox, $oOverView);
   else self::AddToTicketsCommands($rMailbox, $oOverView, true);


Should I file a bug?


Nope, this is expected.

Function imap_fetch_overview returns array of untyped objects - support for this case requires development and addition of some metadata about these objects structure. These features are not yet supported but planned for next release (at least partially - not the meta for this specific extension but the mechanics to supply it)


Ok, so how do I get rid of the warnings? It's not very usable if I have to search through bad warnings to find the real ones.


Well, unfortunately suppressions are not yet available for PHP inspections. Please watch http://youtrack.jetbrains.net/issue/WI-348


Well, that just sucks. At least in Zend Studio where this is an issue, there are always workarounds. If I can't clear all warnings, that's a dealbreaker. We haven't purchased this product yet, but are looking to do so, but items like this are just not acceptable. With ZS we clear all warnings and errors before we allow commits. I'm going to email support and see if they have any input on this.


Didn't realize you were the project lead on this. Seriously, this is a deal breaker. To not have the ability to clear warnings complely, make this feature very unusable. We have a gigantic project and we need the ability to view this from a high level.


To be honest, I don't even like the suppression method as a solution. That means every developer will have to supresses the same items (or even if there was a way for that to transported to other developers, they could supress items they shouldn't.) As an example, in Zend Studio, we use wincache and since there is no support for wincache's functions, we wrote our own dummy file and just added to our project.


I'm the author of most relevant code - why email support?


The solution is a providing of relevant metadata, as I described first.
The suppression (basically a special comment directly in related code) is a good way to clear out warnings in cases where IDE can't grok the code properly and is clearly visible yet transparent. This proven mechanics used in all our IDEs during many years.


I was unaware of your role.

It may be a proven method with this company, but as I've stated, that method has issues that concern me. I don't like the idea that developers can arbitrarily supress warnings that might be valid.


Then you should wait until meta framework and and specific metadata will be available.


For those that need to supress this type of error temporarily, create a dummy class with those properties:

* placed here to remove warnings in PHPStorm
class Dummy {

public $msgno = null;


And they'll go away.

You may need to vdoc it as well (didn't have to do this everywhere for some reason):

   * @var $oOverView Dummy


Please sign in to leave a comment.