Installing media files when installing extension (1.6 feature)

[infograf768]

In 1.5 we have no choice if using the tag <media> when installing an
extension.
It will install any media file in the media folder.

The example on docs is
<media destination="com_test">
<filename>image.png</filename>
<filename>flash.swf</filename>
</media>
This would install the 2 files in media/com_test/
If no destination defined, then the files will go directly in the
media folder.

This due to the code in installer.php to install such files:
in function parsemedia(), line 780-781
we have
$folder = ($element->attributes('destination')) ? DS.$element-
>attributes('destination') : null;
$destination = JPath::clean(JPATH_ROOT.DS.'media'.$folder);

and to uninstall in function removeFiles() line 1002 +
case 'media':
if ($element->attributes('destination')) {
$folder = $element->attributes('destination');
} else {
$folder = '';
}
$source = $client->path.DS.'media'.DS.$folder;
break;

This has 2 drawbacks:
1. 3pd has no choice if they want use that <media> tag to install in
the "images" folder for example instead of "media"
2. Even when not using that tag, i.e. when the 3 pd wants to install
its media in the extension folder, these files are quite lost in the
long list of
<files>
<filename>index.html</filename>
<filename>images/image.png</filename>
etc.
</files>
Using the <media> tag would be cleaner.

One solution could be to force a "destination" in any install by
changing the paths above to
$destination = JPath::clean(JPATH_ROOT.DS.$folder);
and
$source = $client->path.DS.$folder;

If done then we may have to forbid the installation if the tag
"destination="whatever" is empty or absent.

The xmls would look like this
<media destination="images/stories/com_test"> // where "images" can be
"media" if desired.
<filename>image.png</filename>
<filename>flash.swf</filename>
</media>
or in the extension
<media destination="administrator/components/com_test/images">
<filename>image.png</filename>
<filename>flash.swf</filename>
</media>
or in Root
<media destination="comtestmedia">
<filename>image.png</filename>
<filename>flash.swf</filename>
</media>

[Rob Schley]

I believe part of the idea behind the media tag not allowing you to install things outside of the media folder was that we want to consolidate all media (images, JS, css, etc.) into the media folder (though probably broken out into subfolders from there). Obviously, we couldn't do this in 1.5 for a number of backwards compatibility reasons but things should be much more consolidated in 1.6 now that we've had the opportunity to remove the legacy media.

Rob

[elin]

Is the idea that extensions would normally put their media in the
media folder?

Elin

On Feb 19, 12:31 pm, Rob Schley <rob.sch...@community.joomla.org>
wrote:

> I believe part of the idea behind the media tag not allowing you to install
> things outside of the media folder was that we want to consolidate all media
> (images, JS, css, etc.) into the media folder (though probably broken out
> into subfolders from there). Obviously, we couldn't do this in 1.5 for a
> number of backwards compatibility reasons but things should be much more
> consolidated in 1.6 now that we've had the opportunity to remove the legacy
> media.
> Rob
>

[Louis Landry]

Yes.

This is a stepwise move towards a multi-site system where we have more centralized media folders for all media and can place code files underneath document root.  For example, you cannot place the components/ folder underneath document root right now because in a lot of cases it serves images or javascript files or css files.  If all of those media files were contained in the media folder then you could quite easily move the code folders out of the exposed web space thus creating a potentially safer environment.

Also, using a centralized media folder will allow us to more easily transition to a multi-site per code-base instance in the future.

That is the idea.  We aren't completely there yet, but that doesn't mean we shouldn't be making stepwise moves in that direction.

- Louis

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[infograf768]

Therefore some questions come to mind:
If media is the desired place to put all media files (logical indeed),
is it necessary to keep the images folder in 1.6?
Or is it considered that the media folder should only be used by 3pd
and core, and the images folder by the site users/admins through
mediamanager?
In this case, should mediamanager be allowed to access the media
folder?
What would be considered best practice by 3pds? Place their media in
their extension folder or in the media folder?

JM

[Sam Moffatt]

On Sun, Feb 22, 2009 at 4:38 PM, infograf768 <infog...@gmail.com> wrote:
> If media is the desired place to put all media files (logical indeed),
> is it necessary to keep the images folder in 1.6?
> Or is it considered that the media folder should only be used by 3pd
> and core, and the images folder by the site users/admins through
> mediamanager?

3PD put what ever they want web accessible in the media folder, images
is left the sole domain of the user/admin of the site. Mildly
confusing given we call the thing the manages the images directory the
"media manager" but such is life.

> In this case, should mediamanager be allowed to access the media
> folder?

Probably not, if a component is expecting something to do there and
some admin/user has decided to randomly delete it, this would not be
good.

> What would be considered best practice by 3pds? Place their media in
> their extension folder or in the media folder?

I thought this was clear from Louis' reply, 3PD should be using the
media folder not in their own extension folder. The 3PD extension
folder one day may not be web accessible (and yay a whole heap of
badly written components get a whole heap more secure!) so putting
them there is going to mean any resources there isn't directly web
accessible either.

Sam Moffatt
http://pasamio.id.au

[elin]

So does that mean that to show best practices in the 1.6 core, that
the template images, css and js should get moved to the media folder
(maybe /media/templates/rhuk_milkyway/css . .. media/templates/khepri/
images etc? ) and someone could take on the project of changing all of
the references?

[Rob Schley]

Before we go down the road of moving everything around we should probably sort out some of the other issues like how to organize the media folder properly. For example, sometimes we want to share resources between the site and admin media but other times they don't. How should we handle those situations? Should media be namespaced and if so, how should it be namespaced? 

I tend to agree with Sam though. The media folder is for programatic media resources whereas the images folder is for user space resources. So, an extension would put icons used in its interface in the media folder but images that are part of the sample data in the images folder. Allowing the user to dig through the media manager seems like a recipe for disaster to me.

Best,

Rob

[elin]

I have two questions related to this.

First, back in late RC2 I think, the media manager folder was made
configurable in global configuration, I believe with the intention of
making the media folder accessible. This was kind of half way
completed and as a result created a ton of issues in various
components because of the hard coding in the images folder and the
images/stories or images/M_images folders especially in the xml for
things like category description images or weblinks icons (some were
fixed at PBF, some by JBS, some were ultimately reverted). At the
same time, I could definitely see that someone might want to use an
external to the joomla site repository for their images if they have a
lot or their needs are complex, but I think that could be done with an
override. I think a decision needs to be made about whether the
images folder is configurable and, if it is, the refactoring needs to
include dealing with the ramifications of that.

The second issue relates to why I asked about templates specifically.
One of the first things that new users often want to do is to change
an image in the template. So from a UI point of view it's confusing
that they can't see the template images and they either have to ftp
(defeats the purpose of having an easy to use one click install
application) or they go create a templates folder we hope at the same
level as the banners folder. so that front end users can't mess with
the template images. Therefore I wonder if it doesn't actually make
more sense to put template images in an images/templates folder.
Also the DTD for templates currently excludes media tags. (see issues
15047 and 15048 in the 1.5 tracker for discussion of this.)

Elin

On Feb 26, 3:59 am, Rob Schley <rob.sch...@community.joomla.org>
wrote:

> Before we go down the road of moving everything around we should probably
> sort out some of the other issues like how to organize the media folder
> properly. For example, sometimes we want to share resources between the site
> and admin media but other times they don't. How should we handle those
> situations? Should media be namespaced and if so, how should it be
> namespaced?
> I tend to agree with Sam though. The media folder is for programatic media
> resources whereas the images folder is for user space resources. So, an
> extension would put icons used in its interface in the media folder but
> images that are part of the sample data in the images folder. Allowing the
> user to dig through the media manager seems like a recipe for disaster to
> me.
>
> Best,
> Rob
>

[Rob Schley]

The media manager root folder setting was made configurable. In 1.0 it always defaulted to /images/stories/, the option was added so people could make it default to /images/ or /images/whatever/. I do not believe there was any intention to make that configurable to use the /media/ folder.

Rob

[elin]

Actually,.you can currently configure it to any folder, it does not
need to be inside the images folder. It doesn't have to be the media
folder; it can be anywhere. The whole UI is extremely confusing if you
actually try to read it. In factl JBS added a massive warning tool
tip telling people not to delete the images folder even if they
configure it to point to another folder.
We know that users are doing this because we get issue reports when it
conflicts with the hard coding of the images folder.
Just as one example, in com_contact the contact image selection drop
down list was/is hard coded to images and when people would have the
media manager configured to point to other folders the image of course
the image selected woule not be displayed in the front end.

Actually, I will say that in some ways the current set up addresses
the issue I raised.
"Path to Media Folder" sets the backend image path for the media
manager.
"Path to Images Folder" sets the image path for the media manager
when the Image button is used. when editing content.
That means you can actually give your administrators access to the
media folder and they could upload a new template image or whatever.
Which addresses my concern, so nevermind.
Both are completely configurable; there is no requirement to be in the
images or media folders.


See
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=11521
http://forum.joomla.org/viewtopic.php?f=199&t=236219&start=0
http://groups.google.com/group/joomlabugsquad/browse_thread/thread/ba8481f2c9fb465b/c1e96abcae09238a?lnk=gst&q=com_contact#c1e96abcae09238a


Elin


On Feb 27, 4:33 pm, Rob Schley <rob.sch...@community.joomla.org>
wrote:

> The media manager root folder setting was made configurable. In 1.0 it
> always defaulted to /images/stories/, the option was added so people could
> make it default to /images/ or /images/whatever/. I do not believe there was
> any intention to make that configurable to use the /media/ folder.
>
> Rob
>

[Amy Stephen]

Fo sho. Not good design.

Stuff (images, folders, JS, whatever) required by core should be placed out of easy reach.

By placing essential core files into a "working end user folder" and by suggesting that folder for can be located elsewhere has caused trouble.

It's been almost like a dirty trick ;-).

Would like to see any core essential moved out of that location, if possible.

Yes, I will be happy to help with a patch if it's decided what to do - just not before SXSW - eek!

Thanks!