Search

@stuartgpalmer @iwyg I believe the error is in the stray ")" on line 146. Commenting out that line fixes it for me...

Scratch that: @stuartgpalmer: I looked too soon. Your solution is right: instead of a string it needs to be a Widget::Input()

@stuartgpalmer @iwyg I believe the error is in the stray ")" on line 146. Commenting out that line fixes it for me...

That worked for me too until I tried to edit the preferences (path to ImageMagick etc) when I got an error.

Exactly (see my 'scratch that' above ;) )

The issue is with the fact that appendChild expects an XML element object but is given a String. At the lines below you see the field is correctly given for the Maximum Image Height field.

I do have another question/suggestion. At the moment it is quite difficult to see if this field actually works… You would have to manually check the (hopefully processed) images in your /uploads folder.

Would it not be possible to have some simple error logging? Or, even better, check for ImageMagick support by something like shell_exec('which convert')

Hi there, nice to see someone is interested in this plugin. Well thanks for this great feedback. I'll try to keep up my response for all issues related to the resize-upload extension. Surely there are quite of issues that should be solved. Well this extension was some sort of a "fire and forget" weapon against a clients efforts to upload ridiculous large images which GD couldn't handle to scale down on his server.

Just uploaded a new file that hopefully fixes some of these issues. I will test them later, sorry for that … I'm kinda, well busy.

Fork this as you like and make something great.

ok, it kept me awake :D did test it… (didn't work… no errors though, lately installed OS X lion what apparently fuXXed up my convert, reinstalled it – worked).

// PHP Version 5.3.6 // Symphony v. 2.2.1

Resize Upload updated to version 1.0.4 on 19th of August 2011

Yes now it works!!! Thanks!

Also working for me (on Symphony version 2.2.3). Thanks Thomas :-)

Interestingly this doesn't work for images uploaded via front-end forms. Since the developer has even less control over these uploads (as they can't give a website's users the same guidelines they can give to CMS authors), I think it would be a welcome addition to the functionality.

can you post a test case?

Hi @iwyg. Sure...

I have members uploading a photo to their profile using a front end form. I assume their image processing skills to be pretty poor, so I can't tell them how small to make the photo.

In the website JIT will be resizing these images to Gravatar size in large batches, so I'd rather they were not 5MB images. If your image resizer could resize the images to (say) 800 x 800 on upload, the JIT processing requirement would be much lower.

This actually identifies another limitation which is that there is only one setting for uploads and though my front end uploads could actually be resized much smaller than 800 x 800, I wouldn't want to lower the settings any further as my client uses the back end to upload photos to a gallery.

Could there be different settings for front end and back end uploads?

I meant technically… the form markup etc. :D

I don't get the difference between backend and fronted uploads… I mean technically both are the same. For a fronted upload, you'd create an event which will populate a backend form.

So I was curious and set up a test frontend upload field. The Problem is, that I need to trigger the resizer by an frontend delegation. There are several, but I haven't found a way to hook up data necessary for the extension to work (upload path, filed id, etc).

In your case, wouldn't it be easier to set a strict upload file size restriction for the FE users?

Stu, extensions are built for back end operability (99.9% of the time), which unfortunately means that if you need to mimic a back-end fields behaviour, you're more than likely going to have to code that into your site yourself.

However, it's not too hard to do if you know how to build custom events... You can take a look at the code in the extension and kind of duplicate it markup wise into your site, and duplicate the php into the event somehow...

Any chance this plugin could be made to work without the exec() function? It has been disabled on the (shared) hosting of one of my clients. I guess it should be possible without since JIT works fine…

Hey Stu did you ever write a custom event for front end operation you could share?

@davidhund sure, you just have to replace the static convert method with a GD operation. You could also easily change the exec command with a corresponding imagick method, but this would rely on php compiled with imagick.

I chose imagemagick because in my case (client -> huge images + shared host) GD exceeded available memory and IM was playing nicely.

@jeffleeder no, I never did this. I'm afraid my PHP and Symphony skills are not up to scratch

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details