AdvancedContent

[NaN]

Another idea (ow sweet lord...) "Allow on-the-fly resizing of uploaded images" would it be a good or bad idea to have that as param?

So many ways to resize an image... hm.
An option here a plugin there and params in the template... i believe it will result in a param chaos.
If you set in the preferences "Allow on-the-fly resizing of uploaded images" to true and additionally have a param when calling the content block in the template where this is set to false... hm, wich one do you think should be the one that finally (dis)allows the image resizing?
The preference or the param?

But your're right. It is no bad idea to define image resizing for each block. So one block may be resized to 10x10 the other block to 120x300 or whatever you need the image size for a certain block.
The reason why i don't want to add any further image transform stuff is ... that i just don't want to reinvent the wheel since there are some other ways to realize this much better than i would be able to integrate it into the module.

E.g.: Even the filepicker was unnecesary to be built in into the module. But there was no other solution yet. The projects FileBrowser or NeoFilePicker sound really promising and might be exactly what i needed here but there are no files released yet.
If there ever will be a release and the modules will fit the needs i will think about removing the fileicker and use the other modules instead.
(To keep the content type as small as possible and have some kind of general filebrowsing - at the moment there are 4 (four!!!) different ways to manage files: FileManager, ImageManager, TinyMCE FilePicker, AdvancedContent Filepicker ... and maybe some more  ::) it would be nice to have one unique browser that provides all necessary file operations no matter what module is used)

- thumb is nicely generated on upload, not displayed in picker
- icon /modules/FileManager/icons/themes/default/extensions/32px/jpg.png
or /modules/FileManager/icons/themes/default/extensions/32px/gif.png is shown
- more will follow

Yeah this is the default icon that will be displayed if a) filepicker style is set to "Filenames" or b) the thumbnail could not be found/created or c) the file is no image.

I had a similar problem with the portal software Liferay where it did not accept a file to be an image. (Although it was)
I had to convert the image with another image processor before it was accepted.

Since the filepicker uses mime-type functions to check if a file is an image or not it may be that the image contains faulty header information so the filepicker displays it as just a file. The reason why it although has the right filetype icon is because the filetype icon will be created by the FileManager. The FileManager only uses the file extension to determine the filetype. Therefore the filepicker dispays it as a file with filetype icon "gif-file" instead of the thumbnail.

Maybe your host has no mime-type libaries installed or they are just deactivated ... no, wait, in this case the filepicker would only check for the right file extension. And if type is set to image by default the allowed file extensions are 'jpg','jpeg','gif','png','tif','tiff'. So if mime-type is not available it should although work.

Only if mime-type settings of your server are not configured properly or if the image has a damaged or whatever faulty header it may result in what you have now.

So try the following: in your template set the param type to file, reload the edit page, browse to the dir where the image is and look what mime-type is shown in the filepicker for that image. Just to make sure that this is not a mime-type issue.

[jack4ya]

Another idea (ow sweet lord...) "Allow on-the-fly resizing of uploaded images" would it be a good or bad idea to have that as param?

So many ways to resize an image... hm.
An option here a plugin there and params in the template... i believe it will result in a param chaos.
If you set in the preferences "Allow on-the-fly resizing of uploaded images" to true and additionally have a param when calling the content block in the template where this is set to false... hm, wich one do you think should be the one that finally (dis)allows the image resizing?
The preference or the param?

It can contradict right now also, right? Which one is the dominant piece of code?

But your're right. It is no bad idea to define image resizing for each block. So one block may be resized to 10x10 the other block to 120x300 or whatever you need the image size for a certain block.
The reason why i don't want to add any further image transform stuff is ... that i just don't want to reinvent the wheel since there are some other ways to realize this much better than i would be able to integrate it into the module.

E.g.: Even the filepicker was unnecesary to be built in into the module. But there was no other solution yet. The projects FileBrowser or NeoFilePicker sound really promising and might be exactly what i needed here but there are no files released yet.
If there ever will be a release and the modules will fit the needs i will think about removing the fileicker and use the other modules instead.
(To keep the content type as small as possible and have some kind of general filebrowsing - at the moment there are 4 (four!!!) different ways to manage files: FileManager, ImageManager, TinyMCE FilePicker, AdvancedContent Filepicker ... and maybe some more  ::) it would be nice to have one unique browser that provides all necessary file operations no matter what module is used)

That's exactly my issue also. There are more... NeoUpload and there's one built-in the CTLModuleMaker (as part of an attribute, I could make a small demo to show it?), and the latter (CTLMM) seems most logical and intuitive. It scales aspect-ratio or not, crop or not, thumbnail or not, path direction or not. However it's part of an module and not stand alone.
NeoUpload is also promising (having some forced aspect ratio issues)

I don't know what the best approach would be. For me, anything that's complete and working would do. So a stand alone uploader with scaling/cropping would be fine. But the current ImageManager, although having those "after" functionalities, just doesn't 'feel' right. I would like it to be "on upload" functionalities...

- thumb is nicely generated on upload, not displayed in picker
- icon /modules/FileManager/icons/themes/default/extensions/32px/jpg.png
or /modules/FileManager/icons/themes/default/extensions/32px/gif.png is shown
- more will follow

Yeah this is the default icon that will be displayed if a) filepicker style is set to "Filenames" or b) the thumbnail could not be found/created or c) the file is no image.

I had a similar problem with the portal software Liferay where it did not accept a file to be an image. (Although it was)
I had to convert the image with another image processor before it was accepted.

Since the filepicker uses mime-type functions to check if a file is an image or not it may be that the image contains faulty header information so the filepicker displays it as just a file. The reason why it although has the right filetype icon is because the filetype icon will be created by the FileManager. The FileManager only uses the file extension to determine the filetype. Therefore the filepicker dispays it as a file with filetype icon "gif-file" instead of the thumbnail.

Maybe your host has no mime-type libaries installed or they are just deactivated ... no, wait, in this case the filepicker would only check for the right file extension. And if type is set to image by default the allowed file extensions are 'jpg','jpeg','gif','png','tif','tiff'. So if mime-type is not available it should although work.

Only if mime-type settings of your server are not configured properly or if the image has a damaged or whatever faulty header it may result in what you have now.

So try the following: in your template set the param type to file, reload the edit page, browse to the dir where the image is and look what mime-type is shown in the filepicker for that image. Just to make sure that this is not a mime-type issue.

Here's the code used in the template:
{AdvancedContent type="image" block="image1" mode="filepicker" filter="exclude:thumb_"}
{content type="file" block="file1" mode="filepicker" filter="exclude:thumb_"}
Both pickers show the default icons...
So I guess, my mime types are wrong? Either in the file itself or in the server handling part of it?
I've tried on our own server (tried on two domains) and on my local mac using mamp...
Need more info? (What setting do I need to check? Would you happen to know that?)

[jack4ya]

*goes googling for mime types*

[NaN]

And what mime type is shown in the filepicker of the second content block for the images?
It is right before the filesize in the filetable.
(I should be at least. If not ... hum, what version do you use?)

Hey, the module is also made on a mac
Using mamp 1.9 with php 5.2.15 / 5.3.2.
If you have the same trouble on your local machine i don't believe it is a mime-type issue of the server.
Maybe it is the header of the image.
Just try to save it again with any image processor.
I used the preview of mac osx when i had this issue with Liferay and it worked.

At the moment i'm about to fix this by adding a preference where you can define if mime-type functions or just file extensions will be used to check the filetype.

[jack4ya]

And what mime type is shown in the filepicker of the second content block for the images?
It is right before the filesize in the filetable.
(I should be at least. If not ... hum, what version do you use?)

Aah, crap! I looked at the wrong place. LOL.. it says gif or jpg and accordingly the gif or jpg icon

Hey, the module is also made on a mac
Using mamp 1.9 with php 5.2.15 / 5.3.2.
If you have the same trouble on your local machine i don't believe it is a mime-type issue of the server.
Maybe it is the header of the image.
Just try to save it again with any image processor.
I used the preview of mac osx when i had this issue with Liferay and it worked.

Using Photoshop, quite common off course, but also a screenshot (macos) gif, jpg and png

At the moment i'm about to fix this by adding a preference where you can define if mime-type functions or just file extensions will be used to check the filetype.

Intuitively? I would go for extension, but that's why I am a interaction/graphic designer and not a programmer.
What does imagepicker use actually? The extension?

[NaN]

Actually it uses the mime-type.
If no mime-type functions are available it uses the extension.
(Quite common)
But if mime-type functions are available but a wrong value (for whatever reason) is returned it won't work properly.
So i think an option to turn on/off the mime-type stuff completeley is needed here.

But i wonder why it says jpg/gif but does not find the thumbnails. (does it literaly say jpg or image/jpg ?)
We need to dig deeper i guess.
I will send you a file that prints out some debug messages for each file.

Stay tuned.

[jack4ya]

Aah... attachments  :-X
loading... This is a screenshot of 'your' picker...

[NaN]

First of all: mime-types should be "image/jpg" or "text/html".
So if there is only "jpg" or "html" displayed the filepicker was not able to get the mime-type and therefore it just takes the file extension.
(as you can see in the screenshot)

Regarding to your screenshot you set the type to file (i just believe so because you can browse above your image directory).
I just tried it out and ... yeah, my fault. When type is set to file no thumbnails will be shown at all.
So this is a minor issue that needs to be fixed.

But what if you set type to image?

I just realized when type ist set to image in the template and the file is actually shown in filepicker that means that it already has the right mime-type or file extension. Otherwise the file would not be shown in the filepicker. So it might be no mime-type issue here. (But i will add the preference anyway. Just in case )

So it also could due to a weird filename and/or weird file permissions.
The picker checks for each image (if he accept it as one) for a file [path to file]/thumb_[file name].[file extension]
If there is no such file it checks for the option "Create Thumbnails" and if set create the thumbnail. If the thumbnail could be created (or it already extis) it uses the thumbnail as image source to display it in the filepicker.

Since in your case the file is actually displayed even if type was set to image it can only be the path to the thumbnail that cannot be accessed for whatever reason. The picker is not able to create a thumbnail or even to check if the thumbnail exists. And this is why it decides to show a fileicon instead.

Strange...  :-[

[jack4ya]

First of all: mime-types should be "image/jpg" or "text/html".

I will test another picker as I can remember the double notation, now I just need to try them all out (tomorrow)
That would mean that that particular module can actually read out the mime type. Which would mean mime type would be okay on my server/site/setup. Ill need to dig though...

So if there is only "jpg" or "html" displayed the filepicker was not able to get the mime-type and therefore it just takes the file extension.
(as you can see in the screenshot)

Regarding to your screenshot you set the type to file (i just believe so because you can browse above your image directory).
I just tried it out and ... yeah, my fault. When type is set to file no thumbnails will be shown at all.
So this is a minor issue that needs to be fixed.

But what if you set type to image?

I wlll upload to screenshot, one of each...

I just realized when type ist set to image in the template and the file is actually shown in filepicker that means that it already has the right mime-type or file extension. Otherwise the file would not be shown in the filepicker. So it might be no mime-type issue here. (But i will add the preference anyway. Just in case )

So it also could due to a weird filename and/or weird file permissions.
The picker checks for each image (if he accept it as one) for a file [path to file]/thumb_[file name].[file extension]
If there is no such file it checks for the option "Create Thumbnails" and if set create the thumbnail. If the thumbnail could be created (or it already extis) it uses the thumbnail as image source to display it in the filepicker.

Since in your case the file is actually displayed even if type was set to image it can only be the path to the thumbnail that cannot be accessed for whatever reason. The picker is not able to create a thumbnail or even to check if the thumbnail exists. And this is why it decides to show a fileicon instead.

Strange...  :-[

I guess. But I need to point out (did I already?) that a proper thumbnail is generated on upload. I can see it perfectly via FileManager.

The code once again:
{AdvancedContent type="image" block="image1" mode="filepicker" filter="exclude:thumb_"}
{content type="file" block="file1" mode="filepicker" filter="exclude:thumb_"}
In both I navigated to the /uploads/images folder to be able to compare.

[NaN]

I think i got it. I hope at least.
As i thought it is a tiny path issue when checking for the thumbnail.
But it has nothing to do with your server (well... maybe... a bit at least - but anyway it is an issue in the module; the whole path/url filehandling stuff is not that perfect...  ::) )
For some reason the thumbnail path always contains two slashes: .../somepathhere//thumb_image.gif.
And this is up to the server how to handle this.

In my case it worked well.
In other cases it might fail.

This will be fixed soon.
(Is already fixed in SVN)

[NikNak]

Hi NaN

Im getting this when I try and upload images:

--Add Me - module:AdvancedContent string:noimagefile--
application/octet-stream

Any clues?  I do hope its not anything to do with the last few posts because I didnt understand any of that!!

Ta

Nik

[NaN]

I'm afraid it does.
If you get the message that the file you were uploading is not an image file but an "application/octet-stream" there might be a mime-type issue. That means the browser or the server does return the wrong mime-type of that file.
This is why i will add a preference to disable mime-type checking.

[NaN]

I hope i was able to fix the latest issues.
(The thumbnails and the mime-type stuff)
Before i'll release it in forge next week you might want to test the latest version: http://dev.cmsmadesimple.org/project/files/836

Changes:
- added a preference to use mime-type to check for file types (by default this is turned off)
- fixed a path issue where thumbnails could not be found (still needs some tests; should work fine with unix like servers but i don't know about windows ...)

Kind regards.

EDIT: link updated since the alpha release is no longer valid

[davemof]

Hi All,

I am desperate to use this module for a client site, but cannot get it to run for love nor money. I have it downloaded and installed - all apparently OK.

I have attempted to use:

1.) {content type="image" block="image1" mode="filepicker"}
2.) {AdvancedContent type="image" block="image1" mode="filepicker"}

But 1.) produces the standard wysiwyg editor and 2.) produces nothing at all.

I am running 1.7.1 "Escada", and any help would be greatly appreciated.

Many thanks

Dave

[jack4ya]

You have tried setting the content type of the page to advanced content (which i keep forgetting myself...)