jmcameron / attachments

Attachments Extension for Joomla 3, 4, and 5
GNU General Public License v3.0
12 stars 19 forks source link

Attachments problems after Joomla updated to 3.4.4 #4

Open Klipper opened 8 years ago

Klipper commented 8 years ago

Hi, Since the update of Joomla 3.4.4 we have problems with attachments extension.

1.) Adding a new attachment fails from within the article editor screen (button below JCE). The button is present. Pushing the button shows the 'add attachments form', in which you can enter all properties and file to upload. Pushing the upload button, closes the page in the modal box, but no attachment appears below the article. When I look within the directory structure: after pushing the upload button, a directory with the name of the articleID has been created, but no uploaded files is in the directory (except the index.html). So something goes wrong with uploading of the attachment from within the article editor. Same problem when trying to upload from the category editor. Directory gets created, but no uploaded files in the directory. The only way I manage to add attachments to articles or categories is by opening the attachments componentscreen and choose the new button. Pushing the uploadbutton in the presented upload-form finally add the attachment to the chosen article or category.

2.) It seems there is a new safety feature within Joomla 3.4 which test uploaded files for malicious code. It test if the string '<?php' is within the file. When it's present the upload get canceled for security reasons. But the problem we have now that we cannot upload extensions as attachments anymore. Like a module or a plugin. Zips are extracted and the files are searched through and of course there are php files in an extensions .zip. I think we need a setting in attachments to overrule this security check. At least for administrators and super users from the backend.

3.) When I load an article in my browser containing one or more attachments a piece of Jquery script is added to the head of the page: jQuery(function($) { SqueezeBox.initialize({}); SqueezeBox.assign($('a.modal-button').get(), { parse: 'rel' }); }); function jModalClose() { SqueezeBox.close(); }

Firebug reports an error: ReferenceError: SqueezeBox is not defined SqueezeBox.initialize({});

Hope you can fix these issues, Regards, Klipper

jmcameron commented 8 years ago

Please try this update (but unreleased) version:

http://jmcameron.net/attachments/downloads/attachments-3.2.4-Beta4.zip

Let me know that helps.

-Jonathan

On Sat, Sep 26, 2015 at 5:31 PM, Klipper notifications@github.com wrote:

Hi, Since the update of Joomla 3.4.4 we have problems with attachments extension.

1.) Adding a new attachment fails from within the article editor screen (button below JCE). The button is present. Pushing the button shows the 'add attachments form', in which you can enter all properties and file to upload. Pushing the upload button, closes the page in the modal box, but no attachment appears below the article. When I look within the directory structure: after pushing the upload button, a directory with the name of the articleID has been created, but no uploaded files is in the directory (except the index.html). So something goes wrong with uploading of the attachment from within the article editor. Same problem when trying to upload from the category editor. Directory gets created, but no uploaded files in the directory. The only way I manage to add attachments to articles or categories is by opening the attachments componentscreen and choose the new button. Pushing the uploadbutton in the presented upload-form finally add the attachment to the chosen article or category.

2.) It seems there is a new safety feature within Joomla 3.4 which test uploaded files for malicious code. It test if the string '<?php' is within the file. When it's present the upload get canceled for security reasons. But the problem we have now that we cannot upload extensions as attachments anymore. Like a module or a plugin. Zips are extracted and the files are searched through and of course there are php files in an extensions .zip. I think we need a setting in attachments to overrule this security check. At least for administrators and super users from the backend.

3.) When I load an article in my browser containing one or more attachments a piece of Jquery script is added to the head of the page: jQuery(function($) { SqueezeBox.initialize({}); SqueezeBox.assign($('a.modal-button').get(), { parse: 'rel' }); }); function jModalClose() { SqueezeBox.close(); }

Firebug reports an error: ReferenceError: SqueezeBox is not defined SqueezeBox.initialize({});

Hope you can fix these issues, Regards, Klipper

— Reply to this email directly or view it on GitHub https://github.com/jmcameron/attachments/issues/4.

Klipper commented 8 years ago

Wow, you are fast. I will test the beta tomorrow on a backup of our site.

Klipper commented 8 years ago

I tested your attachments-3.2.4-Beta4.zip:

Unfortunately issue 2 and 3 I reported are not fixed with the install of attachments-3.2.4-Beta4.zip. Also Issue 1 is still present on our online website. I tested the 3.2.3 version and after that the 3.2.4beta on my localhost Xampp box (php 5.4.22) and on our online website, hosted at Siteground (php 5.6.12).

There was one new thing I discovered. The first issue only exist on our online site at Siteground. Adding new attachments from the article editor succeeded on my localhost version (= fresh backup from the online version) with Attachments 3.2.3 and also with the 3.2.4beta. Then I tested if lowering the php version at Siteground would solve the first issue. I changed the php version of the online site from 5.6.12 to 5.4.44. Allas, this php version change did not solve the first issue.

So finally none of the issues online are solved. :-(

jmcameron commented 8 years ago

Ok, I'll take a look. My time for this is limited,so please be patient.

-Jonathan

On Sun, Sep 27, 2015 at 7:42 AM, Klipper notifications@github.com wrote:

Unfortunately issue 2 and 3 I reported are not fixed with the install of attachments-3.2.4-Beta4.zip. Also Issue 1 is still present on our online website. I tested the 3.2.3 version and after that the 3.2.4beta on my localhost Xampp box (php 5.4.22) and on our online website, hosted at Siteground (php 5.6.12).

There was one new thing I discovered. The first issue only exist on our online site at Siteground. Adding new attachments from the article editor succeeded on my localhost version (= fresh backup from the online version) with Atachments 3.2.3 and also with the 3.2.4beta. Then I tested if lowering the php version at Siteground would solve the first issue. I changed the php version of the online site from 5.6.12 to 5.4.44. Allas, this php version change did not solve the first issue.

So finally none of the issues online are solved. :-(

— Reply to this email directly or view it on GitHub https://github.com/jmcameron/attachments/issues/4#issuecomment-143563521 .

Klipper commented 8 years ago

Hi, I have solved the first issue. On our site with Siteground we added a long time ago a php directive in our custom php.ini. It was: 'upload_tmp_dir' pointing to /tmp directory of our Joomla site, because we had problems with installing extensions in previous php version. But we now using php 5.6 in which there was a bug fixed concerning the upload_tmp_dir. (Fixed bug #67551) So since using php 5.6 this upload_tmp_dir was not necessary anymore and even triggered this problem.

For the second issue I found a workaround, but it's not really a nice one. I've put the zip file, containing php files of an Joomla! extension, into a rar archive with a high compression. I could upload the rar file as an attachment now. But this cannot be a final solution of course.

The third issue is still there.

jmcameron commented 8 years ago

Thanks for the update. I hope to get a look at these issues this weekend.

-Jonathan

On Wed, Sep 30, 2015 at 1:27 PM, Klipper notifications@github.com wrote:

Hi, I have solved the first issue. On our site with Siteground we added a long time ago a php directive in our custom php.ini. It was: 'upload_tmp_dir' pointing to /tmp directory of our Joomla site, because we had problems with installing extensions in previous php version. But we now using php 5.6 in which there was a bug fixed concerning the upload_tmp_dir. (Fixed bug #67551) So since using php 5.6 this upload_tmp_dir was not necessary anymore and even triggered this problem.

For the second issue I found a workaround, but it's not really a nice one. I've put the zip file, containing php files of an Joomla! extension, into a rar archive with a high compression. I could upload the rar file as an attachment now. But this cannot be a final solution of course.

The third issue is still there.

— Reply to this email directly or view it on GitHub https://github.com/jmcameron/attachments/issues/4#issuecomment-144532209 .

Klipper commented 8 years ago

I also found reason of issue 3. It's triggered in the file 'javacript.php' at line 63 and 67, where you force to load the Mootools file 'modal.js' (JHtml::_('behavior.modal', 'a.modal-button');) on pages in the frontend containing attachments. Since we live in the Joomla! 3.4 time, we do not want to load Mootools anymore in our frontend. Because we only upload Attachments from within the Administrator we do not use any Attachments modalscreens in the frontend. So simply commenting out line 63 an 67 of javascript.php is currently my workaround to fix (but a non-wished core-hack).

I think it would be very nice if you change all Mootools dependencies to jQuery/Bootstrap dependecies within the Attachments extension, to get a better future-proof behavior of Attachments. Hope you can arrange that.

Anyway, Attachments stay one of my favorite extensions! Thanks for creating and maintaining Attachments!

jmcameron commented 8 years ago

Klipper,

Ok. I think I have a fix to the upload problem (2). Please try this version:

http://jmcameron.net/attachments/downloads/attachments-3.2.4-Beta5.zip

Just install it over the old version (although I strongly encourage backing up your site first...)

Please let me know if that helps.

By the way, Joomla 3.4.0 added an option to the Joomla upload function to check on safe file uploads. This was broken and was not fixed until 3.4.4. What happens now is the safety of the upload file is now checked, including making sure that zip files do not contain any php files, etc. What I have done is disabled this security check for Attachments uploads. In a future version of Attachments, I will add an option allowing the administrator to select whether they want this safety scanning done. Now it behaves like it has in the past -- no safety check is done.

It make take a while to address the 3rd issue. Just changing from Mootools to JQuery is not trivial.

-Jonathan

On Thu, Oct 1, 2015 at 4:17 AM, Klipper notifications@github.com wrote:

I also found reason of issue 3. It's triggered in the file 'javacript.php' at line 63 and 67, where you force to load the Mootools file 'modal.js' (JHtml::_('behavior.modal', 'a.modal-button');) on pages in the frontend containing attachments. Since we live in the Joomla! 3.4 time, we do not want to load Mootools anymore in our frontend. Because we only upload Attachments from within the Administrator we do not use any Attachments modalscreens in the frontend. So simply commenting out line 63 an 67 of javascript.php is currently my workaround to fix (but a non-wished core-hack).

I think it would be very nice if you change all Mootools dependencies to jQuery/Bootstrap dependecies within the Attachments extension, to get a better future-proof behavior of Attachments. Hope you can arrange that.

Anyway, Attachments stay one of my favorite extensions! Thanks for creating and maintaining Attachments!

— Reply to this email directly or view it on GitHub https://github.com/jmcameron/attachments/issues/4#issuecomment-144700081 .

Klipper commented 8 years ago

Sorry for the delay with testing your update of attachments 3.2.4-beta. I just tested it and yes, I can now upload zip files again containing php files e.g. a module or plugin zipcontainer. I think it would be very wise to let the administrator choose if the safety check should be bypassed or not, and also if this should be possible at the front-end, back-end or both.

I hope, you also can remove the Mootools dependency as soon as possible (change to jQuery). It's very annoying all these javascript errors because of conflicts between Mootools and jQuery.

jmcameron commented 8 years ago

Ok!

Glad that got one issue fixed.

Yes, I do plan to convert to JQuery soon. Unfortunately, my time is very limited at the moment and that kind of fix is one that needs a concentrated chunk of time to implement!

So please be patient...

-Jonathan

On Wed, Oct 28, 2015 at 6:41 PM, Klipper notifications@github.com wrote:

Sorry for the delay with testing your update of attachments 3.2.4-beta. I just tested it and yes, I can now upload zip files again containing php files e.g. a module or plugin zipcontainer. I think it would be very wise to let the administrator choose if the safety check should be bypassed, and also if this should be possible at the frontend, backend or both.

I hope you also can remove the mootools dependancy as soon as possible (change to jQuery). It's very annoying all these javascript errors because of conflicts between Mootools and jQuery.

— Reply to this email directly or view it on GitHub https://github.com/jmcameron/attachments/issues/4#issuecomment-152048741 .

gyvermac commented 7 years ago

Hi, I just tried Attachments a few days ago. It is a great extension that I think will do exactly that I need. But when I discovered that it loads mootools I gave away. Will you change to JQuery in a near futur ? May be you already have a beta (even alpha) version ? I'll test it with pleasure :-)

mediaDESIGN-SK commented 5 years ago

I'm afraid the problem is still not really solved. I am building a new project for a customer (geravital.mediadesign-gera.de). The project uses Joomla 3.9.6 and Attachments 3.2.6. As soon as a page containing Joomla contributions is called, "Attachments" is executed. The following error is still displayed in the console, which then prevents further script executions:

ReferenceError: Hash is not definedmodal.js:7:7444
    <anonymous> http://geravital.mediadesign-gera.de/media/system/js/modal.js
TypeError: SqueezeBox is undefined

As soon as I comment out line 31 in the script "javascript.php" // JHtml::_('behavior.modal', 'a.modal');) the error disappears because the script modal.js is not loaded and squeezeBox is not initialized.

Is there still no solution to the problem? Possibly a configuration option would help to disable this line depending on the project. I don't want to have to modify the core script.