White screen in some cases, when submodules exists

I also confirmed this issue.
This issue is caused by adding 2 dots to extension of output filename.

This patch fixes it.

2 dots, how does that happen in this code?

The pathinfo() returns extension without a dot. Therefore, in the following codes, $filename(==$outputname) contains a dot.

  if (isset($pathinfo['extension'])) {
    // A specific module or theme file was requested (otherwise there should be no extension). 
    $filename = preg_replace('!^(.+)'. preg_quote($pathinfo['extension'], '!') .'$!', '\1', $pathinfo['basename']);
    $files = _potx_explore_dir($pathinfo['dirname'] .'/', $filename);
    $strip_prefix = 1 + strlen($pathinfo['dirname']);
    $outputname = $filename;
  }

Then '.po|.pot|.LANGCODE' is added in continuing code.

  if (isset($form_state['values']['langcode']) && ($form_state['values']['langcode'] != 'n/a')) {
    $template_langcode = $form_state['values']['langcode'];
    $outputname .= '.'. $template_langcode;
    if (!empty($form_state['values']['translations'])) {
      $translation_langcode = $template_langcode;
      $outputname .= '.po';
    }
    else {
      $outputname .= '.pot';
    }
  }
  else {
    $outputname .= '.pot';
  }

Therefore, finally $outputname contains 2 consecutive dots.

This patch may be better.

I correct #1, this issue is caused by value of $filename ending with a dot.

I do have this problem with an own modul which has one submodule located in my_module/modules/my_submodule. Though deactivating the submodule helped, the submodule was included in the translation, too (see example below). It shouldn't be that way.

With the patch of post #4 the extraction works with the submodule enabled, but "included files" were not translated, only the modules' .info and .module files.

Example:

Without patch and submodule disabled:

# Generated from files:
#  linodef.module: n/a
#  linodef.info: n/a
#  modules/linodef_bueditor/linodef_bueditor.info: n/a
#  includes/linodef-editorbuttons.inc: n/a
#  includes/linodef-filter.inc: n/a
#  modules/linodef_bueditor/linodef_bueditor.module: n/a

With patch and submodule enabled:

# Generated from files:
#  linodef.module: n/a
#  linodef.info: n/a

@Roi: Your issue seems different from this issue, and it's by design probably.

Takafumi, Roi: if this patch changes how normal submodules are parsed then it is a definite problem. Roi, the expected behavior is the first for submodules. If the patch changes it, then we are in trouble.

No, this patch does not change that behavior. Please review this one.

Takafumi: well, Roi's tests prove otherwise. So looks like we need others testing this as well.

@Gábor: It seems that Roi has confuse 'Extract from all in directory' and 'Extract from MODULE_NAME.*'. Therefore, that test is unrelated to this issue.

@Roi: When 'Extract from MODULE_NAME' option is used, translation is extracted only from files with same filename. (e.g. foo.module => foo.module, foo.info, foo.inc...)

if this patch changes how normal submodules are parsed then it is a definite problem.

With patch of post #4 potx works better as without patch because separate pot files for each submodule are created (and the white screen doesn't occur anymore). That means I can choose first my module - 'Extract from ModuleName' (and not 'Extract from all in directory') - and then my submodules.
Unfortunately the patch as it is isn't usable for all cases since...

When 'Extract from MODULE_NAME' option is used, translation is extracted only from files with same filename. (e.g. foo.module => foo.module, foo.info, foo.inc...)

Is it possible to include other named include files, too? E.g. files that are included with include_once() inside foo.module, foo.inc. Currently the patch is only usable for those modules that have no include files named different (which many modules have).

So this patch needs work regarding the handling of include files but not regarding the handling of submodules (this is better than unpatched potx behavior).

@Roi: It's feature request and is unrelated to this issue :(
You can submit it as feature request here.

EDIT: You're right, I didn't heed the difference between "Extract from all in directory" and "Extract from". Sorry for the confusion! :/ The patch works fine.

Wrong/original text:
It's a bug report for this patch (not for potx).
In that case I have to say the patch doesn't work: It fixes the error though but it breaks the work of potx since it doesn't heed all necessary include files.

I'm not sure about naming rules of Drupal module. May be module with name containing a dot.
This patch took it into consideration.

@zlyware : Please review this once again :)

Thanks zlyware, so status backs to #16.

I had the same problem and applied patch_4 - it worked.

Ok, I've just did a short test case for this issue:

$pathinfo = pathinfo('modulename/modulename.admin.inc');                                                      
var_dump($pathinfo);                                                                                          
$filename = preg_replace('!(.+)'. preg_quote($pathinfo['extension'], '!') .'$!', '\1', $pathinfo['basename']);
var_dump($filename);    

The output on my machine is:

array(4) {
  ["dirname"]=>
  string(10) "modulename"
  ["basename"]=>
  string(20) "modulename.admin.inc"
  ["extension"]=>
  string(3) "inc"
  ["filename"]=>
  string(16) "modulename.admin"
}
string(17) "modulename.admin."

Which makes it look quite foolish to do the whole preg_match(preg_quote()) fun. Looks like we just get back the $pathinfo['filename'] appended with a dot with that (the pattern says "whatever is from the start to the extension, including the ending dot before the extension).

This is used later in both the $files = _potx_explore_dir($pathinfo['dirname'] .'/', $filename); call and to construct the output filename. In both cases, the $filename is assumed not to have a dot at the end, and more extensions are added as going forward.

So looks like we just need $pathinfo['filename'] after all. Let's review this patch, which also remove some cruft.

Well, $pathinfo['filename'] works only PHP 5.2.0 or later.

Ok, looks like I made the mistake to commit the patch in #21 with another patch: http://drupal.org/cvs?commit=182456 Sorry. So, to fix the code for PHP before 5.2.0, I've just added this snippet. It is more correct then the explode() suggestions above, since it does not take the first part before the first dot, but the whole string before the last dot.