Joomla! Forum - community, help and support

1. Introduction
1.1 Scope
This document should describe a possible change to the Media Manager to enhance image processing.
1.2 Objective of the document
This document is aimed at providing a basis for a discussion about a change to the Media Manager to enhance image processing.
1.3 General remarks
1.4 Definitions
1.5 License
GNU GPL
2. What is the current issue?
The Media Manager can currently only be used to upload and delete a few select media files. It is quite complicated to keep a specific structure in the „images“ folder and also to handle different sizes of images, like a thumbnail and a „full“ picture.
3. What are the proposed improvements?
A lot of servers provide a graphics library, like GD or imagemagick. Joomla should support these and make it possible, to alter images with these. To allow other extensions to use these, too, Joomla should provide a wrapper class for these. This wrapper class should allow for conversion of image types, resizing and applying a watermark. This allows using different image libraries.
In the Media Manager itself, you can now define, if a thumbnail should be created and what the size of both the thumbnail and the real picture should be. These settings can also be made in the parameters of the component to provide a default value.
Thumbnails are not shown in the media manager, which is done through prepending all thumbnails with a „th_“ prefix and then filtering for these. In the screen to select an image in the editor, you can select if the thumbnail is inserted or the real image, in the first case, the image is automatically linked to the original, which is opened in a lightbox on click.
4. Possible uses
This allows site-designers to better control the design of articles and the images inside them.
5. Effects on...
5.1 Users
There is no negative effect to be expected on the user.
5.2 3P extensions
There is no negative effect to be expected on 3P extensions.
5.3 Performance
There is no negative effect to be expected on performance

I second this.

I would also recommend, it being more of a multimedia manager. Having the ability to manage audio (MP3, Wav), video (Divx, Flv, WMV, MPEG, AVI, MOV), and office documents within subcategories (Pictures, Audio, Video).

Would also be cool if you added support to move media to other folders

- Louis

Some people would say "This was easy". The whole resizing is really simple. Here is a really simple first example on how such a resizing could be done. This is of course way to simple to be commited to the core, but its a first draft on how to tackle this. Next to hide the thumbnails from the normal view and implement the lightbox feature. then the overrides when uploading.

Continuing my campaign to have language that makes sense, images is the wrong name for the default media manager folder and causes a lot of confusion. There's a regular forum question about how to upload pdfs, for example, and another one about mp3s. At this point I think virtually all of the hard coded paths to the images folder have been replaced, though I'm sure numerous extensions still use it. Also, stories does not make sense to people either, since that's a term that isn't used elsewhere. Articles is the term that is used in 1.5.

I want to expand this even further. Allow the option for media to be stored in the database. If your site has multiple authors or a large product base managing media outside the article is complicated. You might want some site wide media outside the database but if it relates to specific content then it should be a related object to that content. Even if you decide media over a given size has to be external to the database the CMS should manage this. Maybe looking at some of the major media sites would help flesh this out. Media manager now doesn't seem well integrated with the articles and cumbersome to use.

Here is an updated version. works already nice with GD2 and without lightbox. This one creates a thumbnail and can automatically insert the thumbnail instead of the actual image and then link that thumbnail to the original image.

Great initiative!

Is your solution based on phpThumb code or more simple custom library?

Maybe this White Paper should be moved to Accepted or Under Review forum?

Nice feat, would be cool to have Hackwar's modifications inside the next release.

Stasys wrote: Is your solution based on phpThumb code or more simple custom library?

This is a selfmade library.

a first look at phpthumb looks like its way to big for the task. The goal is not to provide a can-all-does-all image library, but a library that helps with some standard conversions. If you need more complex graphics functions, you are way better of to use the original graphics libraries instead of these simpler functions. On the other hand, if you only want to resize all images on upload to a given size and keep the ratio at all times, JImage should help you a lot.

as I already said its the Great initiative! and we all would be glad seeing it implemented as quick as humanly possible!

It also would be huge gift for all Joomla community if library that helps with some standard image conversions could be implemented in Joomla! 1.5.2

Do we need to upgrade (change) Data Base to implement your solution?

No database changes required.

This will definitely not be included in the 1.5.x series. There will be no new features in 1.5 and all that is discussed in this forum is meant for 1.6 or later.

Would definitely like to second, 4th?, 10th? these ideas!

JImage is a great idea !

One big improvement would be Mass Upload with batch parameters (for all files uploaded), like :
- fit in X x Y pixels
- keep aspect ratio
- Jpeg quality
- gif conversion to jpg or png, so that PDF generation doesn't break... (FDPF has a bug with transparent images)
- Option NOT to store the original file on server (for smaller disk space usage, or if the original picture is not needed)
This would greatly help end-users.

Another possible fonctionnality is "watermarking" :
- Just adds a "picture tag" (logo or else) to your picture, blending it with the original (Zoom Gallery componant - not developped anymore - used to provide such a fonctionnality using gd2).
- Only 2 params : file name, and side/corner alignment (8 positions).
- Could be implemented either/both while uploading picture in Media manager or/and in image parameters when editing articles.

A nice wrapper for GD2 would surely help many extension developers to achieve their goals faster.

-Mato

Well why not include functions available in phpThumb? It's overkill and too big og a library?

On the other hand: Why settle for less than excellence? Why not use something that has been thoroughly testet and that we know will work?

torkil wrote:Well why not include functions available in phpThumb? It's overkill and too big og a library?

On the other hand: Why settle for less than excellence? Why not use something that has been thoroughly testet and that we know will work?

cause no one done it Why you think it will work? and is out of scope cause core haven't aproved it, or did they?

Well... you can never KNOW it will work, but you can be pretty sure it will be stable when...

• You have tried and tested it yourself. I have, how about you?
• You are dealing with mature software. phpThumb started in 2002 and has had stable and regular releases ever since.
• Lots of other people are using it already. phpThumb has averaged over 1500 downloads pr month since 2004.
• It is in use in alot of other projects already. Like in the JCE editor (editors pick too!) for Joomla for instance.

Some reasons for considering phpThumb:

• Stability, predictability, security: The software is tested and mature.
• No need to reinvent the wheel. And not to mention: You can avoid doing all the mistakes and having to correct all the bugs that the people behind phpThumb has already done.
• Save time: It is easy to implement and already ready for use. You do not have to write a single line of code.

Image scaling and editing will be a much needed feature in alot of Joomla Components, so in my eyes it could be worthwhile to include this in the Joomla framework. If not you could end up with having three different components that each implement their own image editing functions instead of using the framework to their advantage. In theory you could end up with three different phpThumb installations in the same website

It could however bloat the installation and, as you say, be deemed to be out of scope for the framework, but still...

I came recently upon an issue which I solved by a hack but is not a sensible one if upgrade.
A user wants to choose another folder than images/stories for the images representing his contacts in the contact component.
As this is harcoded in list.php, I had to create there a new function where another folder was defined, and then modified admin.contact.php to load the correct folder.

Would be good to think of an access there to media manager to be able to choose images all over the images/ folder or as defined in global config.

I would like the media folder settings in the global configuration to be used throughout Joomla.
Currently in Joomla 1.5.4, the "images/stories" is hard coded in about 30 different places (screen shot attached).

Not sure what the best name would be for a general purpose folder, I've named mine "media-bin" with sub folders such as "media-bin/pdfs" and "media-bin/images", etc...

You can already do this stuff with JCE using its internal extensions.

My wishlist for media management:

Joomla should be able to save media on any persistent storage medium and thus should have an abstract class for managing media, and events/hooks for plugins in order to save, update, edit media through the different protocols required by different storage mediums.

The abstract class methods would provide an API that allows access and management of the media by components. The media could be residing on a local disk, remote disk etc. and thus require different access protocols. Eg: file system, ftp, http, mysql, sqlite etc.
The API would then need to invoke the 3rd party plugin that is will carry out the requested operation over the correct protocol.

This architecture would also allow for multiple storage for the same media, and thus backups or mirrors to distribute load, if needed.

This can be first implemented by the media manager, and a plugin for the filesystem storage. Then when a 3rd party component is installed, it can install its own plugins for storing media on different storage systems, and thus implement its own storage, backup, load balancing etc. while still allowing its media to be accessible from media manager component through its plugin.

3rd party components would find it easier to manage media, as they would only need to invoke the methods defined in the API and not need to implement file system functions or FTP functions etc.

BTW: this could be implemented below the already existing FTP layer and/or Database Layer to really unify persistent storage in Joomla. It could also provide an interface to integrating cache solutions such as APC, Memcached etc. for the less persistent storage similar to what Query Cache is for the database but with a native Interface that 3PD can use.

Batch Upload is a necessity. JUpload (SourceForge link) is a good free library (not to be confused with the commercial JUpload). Writing Java Upload from scratch is not something I recommend. Unfortunately JUpload Demo is broken at the moment.

We need to be able to set Allowed Filetypes from a control panel. Right now it is hard-coded. I had to hack files to add docx, zip, gzip, etc.

Allow hooks for virus scanning.

I agree with the idea of changing the folder from /images/stories/ to something else. It is confusing to have /images/ writeable but people don't really know what to put there. Perhaps /attachments (graphics and other items embedded in articles, saved into folders by article # -- can be used in multiple articles thru linking**), /documents (PDF, etc. which are not embedded but linked, not sorted by article ID), /sitegraphics (used by templates, site banners, etc.), etc.

I do understand that some add-ons like the excellent Joomla Content Editor have taken the initiative and allow the Site Admin to create folders inside /images/stories/ and grant people access to those folders. This will have to coordinate with ACL coming in Joomla 1.6. Do we create author shared folders, or do we create per-article folders and if the author has access to edit an article, then they have access to edit the associated attachments folder?

** If you delete an article which has attached graphics linked to from another article, then we need some code here, potentially tricky, failure code. If we are deleting article # 279, then we can't just delete /images/attachments/279/ folder if there are other articles using those graphics. Complex batch solution:

• Query database for first article (i.e. ID #102) that links to that graphic
• Copy graphic to /images/attachments/102/
• Find and Replace all references to /images/attachments/279/ to /images/attachments/102/

Of course there are many potential fail situations this could bring up.

At the very least, we should get a prompt when we delete an article with linked attachments suggesting that we should "Keep attachments related to this article as they are used in other articles?" and then let people manage their own attachments.

Thanks for explaining about the ownership. I've overwritten the files in admin/components/com_media but it doesn't seem to work

I don't know if this topic is still going on or continued somewhere else or it has already been integrated in some alpha. If so, please point my pecker, if not:

I wonder if it's not advised to include some basic image handling in the base joomla classes (and not in the media component).

Why?
Because, for example image resizing, is something that is not only used in the "media management", but also in a lot of content. Content (with thumbs and other uses of smaller images) such as blog lists, articles lists, database lists, news, galleries, etc..
I, for one, know a lot of extensions that write their own image resizing php (or don't write it out of lack of time; e.g. some requests I read on forums from users to extension writers).

And as a tip: Maybe we can program it like the database class (mysqli, mysql etc..) so that we have the same function names, but depending on the user's preference a custom library GD2, Imagemick,.. or a library-less code (Joomla's own?) can be used?
(I guess Hackwar kind of started to code it that way a bit, then left only is my first idea above: some of it in the main joomla library.

[quote="e-builds"]
I wonder if it's not advised to include some basic image handling in the base joomla classes (and not in the media component).

Great idea!
Several extensions add all sorts of layers of redundancy with their favorite image resizing tool.
Some use http://trac.gxdlabs.com/projects/phpthumb or others.

I've probably got 5-6 directories containing classes that do the same thing.
Unnecessary bloat!

netstepinc wrote:

e-builds wrote: I wonder if it's not advised to include some basic image handling in the base joomla classes (and not in the media component).

Great idea!
Several extensions add all sorts of layers of redundancy with their favorite image resizing tool.
Some use http://trac.gxdlabs.com/projects/phpthumb or others.

I've probably got 5-6 directories containing classes that do the same thing.
Unnecessary bloat!

Check or vote for this: FEATURE REQUEST (+ code) - Cached Thumbs