TYPO3 Core

Oh, yes. Very naughty behaviour...

Just saw, that I uploaded the complete class instead of only the diff.
Mea culpa!

And additionally we might want to skip CVS/.svn directories in that process too. :)

.svn directories are hidden ...

ok, but CVS not. :)

depends on the system you are aiming:

Windows: FAT/NTFS atrrib flags H and S are checked. CVS on WIN is hidden ;-)

Linux: any file or folder starting with '.' is hidden and therefore excluded. On .NIX the cvs folder is .cvs

;-)

False: on Unix the CVS folder is also "CVS" (at least in all versions I have worked with), so its not "hidden" and have to be considered separately.

That can be fixed and it will ;-)

Added support to exclude folders and files by extensions.
Therefore a general setup can be done in localconf.php. Further TSCONFIG on user base can be set:

Setup in localconf.php (Example)
$TYPO3_CONF_VARS['EXT']['uploadTer']['excludePath']='CVS,SVN';
$TYPO3_CONF_VARS['EXT']['uploadTer']['excludeExt']='bak,tmp';

Setup in User TSCONFIG (Example)
EXT{
uploadTer{
excludePath=
excludeExt=bak,sec
}
}

User TSCONFIG always overules general setting.
In this example excludePath is resetted and excludeExt is set to bak and sec

Attached 2 diff.
class.em_index.060804.org.diff is against fresh settup
class.em_index.060804.diff.diff is against diff provided Aug 03.

Please test and comment

I am having some little(!) trouble cleanly testing the patch 'class.em_index.060804.org.diff' due to the following lines:

- * $Id: class.em_index.php,v 1.1 2006/08/01 12:04:25 pruss Exp $
+ * $Id: class.em_index.php,v 1.2 2006/08/03 11:33:04 pruss Exp $

These ^ ^ lines from the diff won't apply. Other than that: looks nice and I will test it now....

hmm, just noticed it adds the 'hidden option' only to the "upload to TER" dialog.

However I would rather appreciate if it would also be considered in the regular "backup/delete" / ordinary "download extension as file" functions.

I expected that this would come up ;-)

But will take some time as I will be out of the office for one week.

Regs. Peter.

keyword:t3dd06

Maybe, we should include an optional paramter to
class.t3lib_div.php->getAllFilesAndFoldersInPath(...,$excludeDirs='')
and modify class.em_index.php to use this
with paramters getAllFilesAndFoldersInPath(...,'.svn,CVS')

This works on my Installation;
I include the diff-File 'patch_em_dot_svn_cvs.patch' (just for testing)

There is a bug in the patch:
Instead of
$fileArr=t3lib_div::getAllFilesAndFoldersInPath(...$regDirs,$recursivityLevels-1);
(in patch line 19) it must read
$fileArr=t3lib_div::getAllFilesAndFoldersInPath(...$regDirs,$recursivityLevels-1,$excludeDirs);

So that exludeDirs are also excluded in subdirectories

Hi, I just looked at those two approaches, and I think the simpler one is more likely to make it into the core. Peter (Russ), your patch doesn't follow the CGL at all, by the way...

I'll probably combine those two approaches somehow.

I uploaded exclude-in-EM.patch which changes t3lib_div to make exclusion possible, adds two settings to config_default.php and changes the EM exclude the configured files when packaging stuff.

• do we need those two separate settings?
• how strong is the need for wildcards?

I just did a test with the ADOdb extension. No files were missing that should have been there (i.e. only the .svn folders were gone). More interesting: the exported file was less than half in size, as SVN stores a local copy of the original for faster operation - so this isn't only about convenience!

One setting is enough, please merge them.
About wildcards: Yes these would probably be useful. Why not use a regular expression here?

The regex should search from the beginning (^) to till the end ($) of the strings. In this case the example below will filter all CVS directories, files beginning with a dot (hidden files) and temporary files (*~):

excludeForPackaging' => '(CVS|\..*|.*~)'

Ok, I'll merge the settings.

On wildcards: Of course I thought about using regexp, but since this can be considered as user input, it should run through preg_quote(). Then this escapes all the magic stuff, of course, rendering this useless. Do we consider the localconf.php file trusted?

Obviously we do, just to make sure...

localconf.php can contain any kind of PHP code, therefore it is of course trusted.

Ok, here is a new patch, one setting, preg-enabled, works here just fine.

The proposed patch is now on the core team for approval...

Has been committed to SVN on Dec 13th.