I've tested with ezwebin and it's working fine here, with one or multiple files.

Hello Maxim,

I'm sorry your having trouble. I've been in the same position as you before (many years ago when this extension was first released), it just didn't work (but then again the installation problems were all my own ignorance). I've only ever seen the problems you describe when it was not installed correctly or if the hosting requirements where not being met...

Once I overcome those problems it has been clear sailing.

Have you read this pdf on requirements and installation of the extension? It's not been updated in a while but I still think it's a valuable resource, https://github.com/ezsystems/ezmultiupload/blob/master/doc/doc_eng.pdf

alternatively there is also the online docs, http://doc.ez.no/Extensions/eZ-Publish-extensions/eZ-Multiupload

http://doc.ez.no/Extensions/eZ-Publish-extensions/eZ-Multiupload/eZ-Multiupload-1.1.0-user-manual

I hope this helps ...

Cheers,

Heath

Hallo Heath,
 Thank you for your reply!
 I downloaded the latest version from github and fixed, but does not work either.
 Yes, I think the problem on the side of the host. What should I configure the hosting-server multiupload extention to work?

PHP Core

Does anyone have any ideas?

If the problem is hosting, where?

Modified on Monday 03 October 2011 9:05:11 pm by Maxim Kopytov

Have you checked the ez publish's log files?

Have you configured image.ini to use GD or ImageMagick, is GD or ImageMagick installed on your hosting?

Have you tried to upload an image that is coming from the internet? Try downloading the logo of eZ on this page and upload it. Some JPEG have broken EXIF and might fail the upload.

Hello Maxim,

I would use the Firefox or Chrome Browser and repeat your test upload process paying special attention to any javascript error console errors which may be occurring as well. It sounds like the file is not being uploaded at all (based on your first message). Also please be more verbose about what errors your experiencing as details here are key.

I don't see anything specifically wrong with the php configuration you've shared. Though I might turn on the display_errors = On for testing purposes ...

Also, I would listen to Quoc Huy Nguyen Dinh suggestion to review the latest entry to the eZ Publish log files (see ezpublishdir/var/logs/*.log files) as they very well could contain additional details which might help troubleshoot this problem.

I hope this helps...

Cheers,

Heath

Have you checked the ez publish's log files?

Have you configured image.ini to use GD or ImageMagick, is GD or ImageMagick installed on your hosting?

Have you tried to upload an image that is coming from the internet? Try downloading the logo of eZ on this page and upload it. Some JPEG have broken EXIF and might fail the upload.

Hi!

There are no problems when I add a file without using the ezmultiupload
Images are scaled, are aliases, then Image Magick works

There are no errors in var/log/error.log file.

I tried to upload different pictures in different formats.
 On the other hosting the module works!

 
 I just want to understand why it does not work here!
 I would like to solve this problem once and for all.

Here information about my hosting extentions:

date, libxml, openssl, pcre, zlib, bcmath, bz2, calendar, ctype, curl, dba, dom, hash, filter, ftp, gd, gettext, gmp, session, iconv, standard, interbase, json, mbstring, mcrypt, mhash, mssql, mysql, SimpleXML, SPL, PDO, pdo_mysql, pdo_sqlite, posix, pspell, Reflection, imap, shmop, mysqli, soap, sockets, SQLite, exif, sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, apache2handler, ffmpeg, pdf, imagick, dbase, tidy, geoip, pgsql, pdo_pgsql, ionCube Loader, Zend Optimizer

Apache mods:

core, mod_charset_lite, mod_cache, mod_disk_cache, mod_mem_cache, mod_proxy, proxy_connect, proxy_ftp, proxy_http, prefork, http_core, mod_status, mod_asis, mod_imap, mod_userdir, mod_so, mod_access, mod_auth, mod_auth_dbm, mod_include, mod_log_config, mod_env, mod_expires, mod_headers, mod_setenvif, mod_mime, mod_autoindex, mod_cgi, mod_negotiation, mod_dir, mod_actions, mod_alias, mod_rewrite, mod_ssl, mod_security, mod_dp20, mod_php5, mod_python, mod_ruby, mod_wsgi

GD

Imagic

My image.ini.append settings:

 <?php /* #?ini charset="utf-8"?
 
[ImageMagick]
IsEnabled=true
ExecutablePath=/usr/bin
Executable=convert
*/ ?>

Modified on Wednesday 05 October 2011 10:57:04 am by Maxim Kopytov

Some hosts might have installed convert in another path, such as /usr/local/bin, you might want to try that or use http://www.rubblewebs.co.uk/imagemagick/server/command.php to locate the path.

Also don't forget to test javascript as mentioned by Heath

Modified on Tuesday 04 October 2011 10:40:26 am by Quoc-Huy NGUYEN DINH

Some hosts might have installed convert in another path, such as /usr/local/bin, you might want to try that or use http://www.rubblewebs.co.uk/imagemagick/server/command.php to locate the path.

Also don't forget to test javascript as mentioned by Heath

Thank You for Your answer, but have you read my previous post?
 I wrote:

There are no problems when I add a file without using the ezmultiupload
Images are scaled, are aliases, then Image Magick works

For code:

 <?php
echo "<pre>";
system("type convert"); 
echo "</pre>";
?>

server answer me:

 convert is /usr/bin/convert

Where ezmultiupload stores the temporary files?
May be a problem in the directive open_basedir or upload_tmp_dir?

On the other hosting the extension ezmultiupload works!
I want to find out for yourself and for the community, which features host does not allow the ezmultiupload to work correctly.

Modified on Wednesday 05 October 2011 6:18:44 am by Maxim Kopytov

Hello Maxim,

Yes, we are all well aware of what you wrote.

Also open_basedir + eZ Publish is not supported (to my memory)

The default temp dir is /tmp I believe but this does not need to be set (but you could try)

The thing is, not all features of eZ Publish, works on all types of hosting. This varies greatly from each hosting provider uniquely and can be extension specific.

You your self uniquely hold the ability to compare the two different types of hosting better than any of us ever can through a forum. You should compare the two and report back here with any relevant differences (that you can discover).

Best wishes

Cheers,

Heath

Heath, I contacted the hosting company.
Technical support has found a solution.
They disabled the security module mod_security in the .htaccess file 

SecFilterEngine Off

In connection with disabling security module are advised to consult with the developers of eZ Publish CMS
Would not disabling mod_security module to cause problems?

If the work site scripts are used the vulnerabilities that are now suppressed by the use of the module
security, after disabling the sec. module, these vulnerabilities are available,
so attackers can hack the site.

What about it will tell the developers?

Modified on Wednesday 05 October 2011 10:36:39 am by Maxim Kopytov

Hello Maxim,

It comes as no surprise that eZ Publish ezmultiupload extension is not compatible (out of the box in your hosting env) with extra mod_security module. And no I do not think you are not more vulnerable by disabling the -not needed- mod_security module to to use the eZ Publish ezmultiupload extension or eZ Publish in general. eZ Publish built in security is very good.

Tell the developers the site is online end ready to use. Enjoy!

Cheers,

Heath

As Heath said, eZP security track record is quite good.

Most of the users of the CMS afaik just expose it to the internet (behind an ip-layer-firewall) without adding an extra application-level-firewall such as mod_security, and so far no one has sued us for their site having been hacked

If the site was working with mod_security on, it should not break (in functionality) with mod_security off, as mod_security is meant to be transparent, not to do any modifications on incoming requests.

It would be nice to know which one of the mod_security rules was getting triggered from ezmultiupload (and the version of mod_security in use), so that we can maybe replicate the error and fix it in the future.