Conversation
Should it be a CLI argument or an environment variable? |
|
As this is meant to extract code from a WordPress plugin or theme, I wonder whether it wouldn't be preferable to use a WordPress filter to make the exclusions customizable from within a plugin/theme... |
Good question! An env var might be easier when dealing with multiple projects. That way you don't have to add the same exclusions over and over again. I also wonder whether this option should just extend default exclusions like |
|
Here's some prior art: https://github.com/wp-cli/find-command#using |
Ah, right, it uses I'm not sure using environment variables is useful in this case. A parameter would allow for immediate configuration, and you can still configure it per-user or per-site through the |
|
I'm sticking with an extra argument for now. Wondering though if I should rename |
features/makepot.feature
Outdated
| """ | ||
|
|
||
| When I run `wp i18n make-pot foo-plugin foo-plugin.pot` | ||
| And the foo-plugin.pot file should not contain: |
There was a problem hiding this comment.
Should be Then ... for readability.
features/makepot.feature
Outdated
| """ | ||
|
|
||
| When I run `wp i18n make-pot foo-plugin foo-plugin.pot --exclude=foo,bar` | ||
| And the foo-plugin.pot file should not contain: |
There was a problem hiding this comment.
Should be Then ... for readability.
src/WordPressCodeExtractor.php
Outdated
| /** @var SplFileInfo $file */ | ||
| foreach ( $files as $file ) { | ||
| if ( $file->isFile() && 'php' === $file->getExtension()) { | ||
| if ( $file->isFile() ) { |
src/WordPressCodeExtractor.php
Outdated
|
|
||
| return $filtered_files; | ||
| } | ||
|
|
| new RecursiveDirectoryIterator( $dir, RecursiveDirectoryIterator::SKIP_DOTS ), | ||
| function ( $file, $key, $iterator ) use ( $exclude ) { | ||
| /** @var SplFileInfo $file */ | ||
| if ( in_array( $file->getBasename(), $exclude, true ) ) { |
There was a problem hiding this comment.
This will fail if a path is returned with a trailing slash. Using trailing slashes is often done for avoiding partial matches. This either needs specific handling of trailing slashes, or an explicit mention in the argument documentation.
There was a problem hiding this comment.
I don't think getBasename() ever returns a path with a trailing slash. The values in $exclude could have indeed have trailing slashes, yes.
I guess I can safely add a change to remove any slashes at the beginning and the end of the excluded directories/files and document this.
| I am being ignored | ||
| """ | ||
|
|
||
| Scenario: Skips additionally excluded folders |
There was a problem hiding this comment.
Tests should cover these as well to make sure they work (and continue to do so):
- subfolder (deeper than in immediate root)
- file
- file in subfolder (deeper than in immediate root)
- partial match (NOT being excluded)
There was a problem hiding this comment.
Agreed. Will add these in a spare moment.
Also, I was just wondering whether glob-like patterns should be supported using something like fnmatch, but that's probably something for a future iteration.
| I am being ignored | ||
| """ | ||
|
|
||
| Scenario: Skips excluded subfolders |
There was a problem hiding this comment.
For this scenario, I was thinking more along the lines of adding an exclude that contains a subfolder, like this:
wp i18n make-pot foo-plugin foo-plugin.pot --exclude=some/sub/folder
I don't think testing the other way around (omitting a subfolder that was part of parent folder being excluded) is needed, as all files within a parent folder would have the same problem then.
src/WordPressCodeExtractor.php
Outdated
|
|
||
| // Check for more complex paths, e.g. /some/sub/folder. | ||
| foreach( $exclude as $path_or_file ) { | ||
| if ( substr( $file->getPathname(), - strlen( $path_or_file ) ) === $path_or_file ) { |
There was a problem hiding this comment.
There's probably a better way to do this, but I couldn't think of one right now.
src/WordPressCodeExtractor.php
Outdated
|
|
||
| // Check for more complex paths, e.g. /some/sub/folder. | ||
| foreach( $exclude as $path_or_file ) { | ||
| if ( substr( $file->getPathname(), - strlen( '/' . $path_or_file ) ) === '/' . $path_or_file ) { |
There was a problem hiding this comment.
You should use substr_compare instead as it is optimized towards the comparison:
$substring = '/' . $path_or_file;
if ( substr_compare( $file->getPathname(), $substring, - strlen( $substring ) ) === 0 ) { }
There was a problem hiding this comment.
Also, I'm wondering how safe this is when using multibyte strings. Off the top of my head, I can't think of a scenario where the comparison would fail to produce the correct result, but I'm not 100% sure. Do you think this might be an issue?
There was a problem hiding this comment.
Good call.
I can't think of a scenario either right now, but you never know :-)
We could use mb_ereg in this case:
if ( false !== mb_ereg( preg_quote( '/' . $path_or_file ) . '$', $file->getPathname() ) ) {
return false;
}Feels more readable anyway.
|
Merged now. Good work, @swissspidy! |
Exclude some common directories
Does not yet contain a CLI argument to extend/override exclusions.
See #27.