Hello out there,

I've found the following hack that works for me at the moment.
It does not work for images created in the backend gui (no node at this point 
of code), but this is no problem for me at the moment.
I don't know which other sideeffects this hack will have, so it would be 
interesting for me what you think about it.

Please go to eZImageAliasHandler-->imagePath(..)
My objects are already published and have a mainnode.

if ( !$mainNode )
            {
        ...
            }
            else
            {
                $ini = eZINI::instance( 'image.ini' );
                $contentImageSubtree = $ini->variable( 'FileSettings', 
'PublishedImages' );
                $pathString = $mainNode->pathWithNames();
                $pathString = function_exists( 'mb_strtolower' ) ? 
mb_strtolower( $pathString ) : strtolower( $pathString );

                //TNE HACK to respect DirDepth setting in site.ini
                /*
                 * pathWithNames will give us the path of a node in the 
contentstructure of ez publish.
                 * eZ uses this path to create the folder structure on the hard 
disk to store images to, if it is configured to store binaries on the harddisk.
                 * The problem arises when there are more nodes on one level 
than php or the file system can handle.
                 *
                 * example: original version will create the following on the 
harddsik
                 * 
storage/images/mainnodepath/mainnodename/attributeid-version-locale/imagename.extension
                 *
                 * the hack will create:
                 * 
storage/images/i/m/a/g/e/n/a/m/e/attributeid-version-locale/imagename.extension
                 * to split up the imagename we use a method already provided 
by eZ but never used 'eZDir::getPathFromFilename()'.
                 * The amount of subdirectories created depends on the DirDepth 
setting in site.ini
                 */
                eZDebug::writeDebug("[email protected]<mailto:[email protected]>: 
manipulating dirpath to respect DirDepth Setting of site.ini (mainNode 
exists)","eZImageAliasHandler.imagePath.php");
                $fileStorageDir = function_exists( 'mb_strtolower' ) ? 
mb_strtolower( $mainNode->attribute('name') ) : strtolower( 
$mainNode->attribute('name') );
eZDebug::writeDebug("File storage dir: ".$fileStorageDir, 
"eZImageAliasHandler.imagePath.php");
$pathString = eZDir::getPathFromFilename($fileStorageDir);
                //TNE HACK to respect DirDepth setting in site.ini

                $pathString = $contentImageSubtree . '/' . $pathString;
            }


Am 01.10.2010 um 09:54 schrieb Thomas Negeli [celum]:

Hi List members,

I'm wondering about the DirDepth parameter in the site ini.
The methods which are evaluating this parameter are never called.

Currently I'm testing eZ 4.3 on how many nodes it can store in one container 
and how the amount of nodes affects the browsing speed.
For this I'm using an eZ certified plattform:
Apache/2.2.9 (Debian 5) PHP/5.2.6-1+lenny9 with Suhosin-Patch
MySQL 5.0.51a

When it comes to about 40000 nodes in one container, eZ (or lets better say PHP 
:-) ) seems to have a problem when storing images (error opening directory for 
writing).
The DirDepth parameter says, that the images should be stored in subfolders. 
The amount of created subfolders depends on the DirDepth parameter.

It is per default set to 3, but there are no subfolders created in my 
installation (see the attached screenshot of my local installation on my mac).
If I understand it the right way (from the code eZDir --> getPathFromFilename), 
in my case there should be the following folder structure (I don't write the 
images):
images
- 1
-- 2
--- 3
-- 4
--- 4
- 2
-- 6
--- 4
-- 9
--- 0
- 3
-- 4
--- 2

Is this correct?
I uploaded the images via the gui, so there should be no influence from my 
created modules.

[cid:[email protected]]
Thomas Negeli
Project Consultant

Celum - Always Ahead
Software to automate marketing,
sales & communication processes

--------------------------------------------------------------
celum gmbh
europaplatz 4
a - 4020 linz, austria

telephone: +43 (0) 732 71 65 29 128
fax: +43 (0) 732 71 65 29 3

[email protected]<mailto:[email protected]>
http://www.celum.com<http://www.celum.com/>

---------------------------------------------------------------
celum gmbh is registered at Landesgericht Linz/Austria
commercial register sub folio No. FN 246117m

<Bildschirmfoto 2010-10-01 um 09.34.04.png><ATT00001..txt>

Thomas Negeli
Project Consultant

Celum - Always Ahead
Software to automate marketing,
sales & communication processes

--------------------------------------------------------------
celum gmbh
europaplatz 4
a - 4020 linz, austria

telephone: +43 (0) 732 71 65 29 128
fax: +43 (0) 732 71 65 29 3

[email protected]<mailto:[email protected]>
http://www.celum.com<http://www.celum.com/>

---------------------------------------------------------------
celum gmbh is registered at Landesgericht Linz/Austria
commercial register sub folio No. FN 246117m

-- 
Sdk-public mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/sdk-public

Reply via email to