White screen in some cases, when submodules exists
| Project: | Translation template extractor |
| Version: | 6.x-2.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Potx module generate a white screen with zero output, when I try to extract strings from a module, which have submodules, but not in all cases. For example:
token: Extract from all in directory "sites/all/modules/token" - ok
After I opened the collapsed fieldgroup Directory "sites/all/modules/token"
Extract from token - failed, white screen, zero output.
Extract from token_actions - failed, white screen, zero output.
Another example, the cck module:
Extract from all in directory "sites/all/modules/cck" - ok
Open the collapsed fieldgroup Directory "sites/all/modules/token"
Extract from content - failed, white screen, zero output.
Extract from all in directory "sites/all/modules/cck/modules" - ok
Open the collapsed fieldgroup Directory "sites/all/modules/cck/modules"
Extract from content_copy in the sites/all/modules/cck/modules/content_copy directory - ok
Extract from content_permissions in the sites/all/modules/cck/modules/content_permissions directory - ok
Extract from ...etc. all submodule is ok.
Versions:
drupal 6.5 new, fresh install
potx: the current 6.x-2.2
That is sure, it is not a memory limit problem, because the current php setting is 64 MB. I not found any other error messages (no entry in the php error log, watchdog, or any other places)
#1
I also confirmed this issue.
This issue is caused by adding 2 dots to extension of output filename.
This patch fixes it.
#2
2 dots, how does that happen in this code?
#3
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.
#4
This patch may be better.
#5
I correct #1, this issue is caused by value of $filename ending with a dot.
#6
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
#7
@Roi: Your issue seems different from this issue, and it's by design probably.
#8
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.
#9
No, this patch does not change that behavior. Please review this one.
#10
Takafumi: well, Roi's tests prove otherwise. So looks like we need others testing this as well.
#11
@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...)
#12
Takafumi: Patch in #4 works fine. Thanks.
#13
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...
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).
#14
@Roi: It's feature request and is unrelated to this issue :(
You can submit it as feature request here.
#15
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.
#16
So, if nobody else comments this issue, then I mean, it is tested by the community, and works fine.
#17
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 :)
#18
Patch in #17 is also OK.
#19
Thanks zlyware, so status backs to #16.
#20
I had the same problem and applied patch_4 - it worked.
#21
Ok, I've just did a short test case for this issue:
<?php
$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.
#22
Well, $pathinfo['filename'] works only PHP 5.2.0 or later.
#23
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.
#24
Automatically closed -- issue fixed for 2 weeks with no activity.