|Re: Regarding Project: Refactor Media Manager||TobsBobs||3/4/13 4:06 PM|
|Re: Regarding Project: Refactor Media Manager||elin||3/4/13 7:41 PM|
I would like to see this project done using a model of having image as a content type and all the standard data stored for each image.
Also i'd like to see use of JImage to automatically create standardized thumbnails with options for filters.
Also some consideration of non image media would be very helpful as would a way of interacting with CDNs.
|Re: Regarding Project: Refactor Media Manager||Bakual||3/4/13 11:58 PM|
I would like to use the Media Manager in my own extension as a way to manage audio and video files. I think currently every extension which deals with files has its own uploader and anything. It would be nice if the media manager would act as a central place for file uploads and file selects, be it an picture, audio, video, pdf or whatever.
It should be able to easily integrated and customized (like base folder, file extensions to show, ...) within 3rd party extensions.
That would be my dream :-)
Am Montag, 4. März 2013 20:25:32 UTC+1 schrieb Nguyen Tran Quan:
|Re: Regarding Project: Refactor Media Manager||piotr_cz||3/5/13 1:01 AM|
I'd like to have some sort of ACL implemented.
But I'm not sure exactly how and if it makes sense to use full Joomla
I've prepared a plugin so user groups are restricted to different
User groups 'editors,managers':
This fits my needs, but doesn't scale (subfolders, permissions, etc);
|Re: [jcms] Regarding Project: Refactor Media Manager||Chad Windnagle||3/5/13 5:07 AM|
Implementing the ACL system would be fantastic. It would be nice with the jform controls to be able to specify (programmatically) the file type, size, location, and folder restrictions. To do this currently I'm duplicating the media jform type, but it's not quite perfect as Ill probably end up needing to do more work to make the uploaded look the way I want.
|Re: [jcms] Regarding Project: Refactor Media Manager||Thomas PAPIN||3/5/13 7:50 AM|
+1 for Elin comments and for all points of this document https://github.com/jlleblanc/joomla-media-manager
2013/3/5 Chad Windnagle <drmm...@gmail.com>
|Re: Regarding Project: Refactor Media Manager||Janich Rasmussen||3/5/13 8:26 AM|
+1 for the initiative!!
The media manager really needs an extreme makeover.
Three wish'es (+ explanations) from me:
One thing I believe is very annoying to a lot of people, is that you use the direct paths to the images/media within the articles, etc.
That means you never really can't restructure or rename anything after it have been used.
If that could be turned into a reference to an entry instead, it would help many people.
Streaming is probably obvious to devs, but you asked for inputs. ;-)
It would help control caching, access, and maybe even rescaling etc. on-the-fly.
Perhaps it could use the joomla router (or a - performancewise - better alternative)?
And finally - whatever it turns out to be, just make sure fire a lot of events, so it will be possible to hook into every part of it from the dev's pov... ;-)
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Chad Windnagle||3/5/13 8:43 AM|
Great advice Janich! With your first suggestion I think you're basically saying have a database entry for the media, so 'media' can be accessed through the database, and updated with a query rather than directly accessing the media in the file system, is that right? If so I think thats a fantastic idea.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Janich Rasmussen||3/6/13 3:35 AM|
That's exactly my thought; A databasedriven library of [media] files.
I haven't tried Nic & Joe's mmmgr, but from the readme it looks to have many of the cool features too, like drag/drop, CDN, file rename/move!
That's definitly worth a look!
For me, personally, it is more about how I can use it in my extensions than the interface (I am a dev after all ;) ...
The Joomla profile plugin. It needs an upload button for an image, but it should be private (ie no other users should be able to see my image).
As I see it, the main "connector" that sits between com_media and the actual gui is (most often) jFormfieldMedia.
This profile image should be dead simple to do, but instead its impossible with the current state of com_media.
So - when extending (or rewriting com_media) my hope is, that this part gets a makeover as well (to support the new options and be much more flexible).
Yes, you could make a custom field, but it would be so much easier if the CMS just had these kinds of options you'd expect (I'd expect).
One solution could something like this (based on above problem):
That could correspond to: MEDIA_STORAGE_ROOT . [extension] . directory . [jailOn] . [ acl( filter - exclude ) ]
It would then match, and show, these files to pick one from:
And each image could have a corresponding thumb, like this:
This example is based on local files like com_media is today, without respect to any cdn or streaming.
Of course it needs much more thinking and planning, but I hope it illustrates a rather 'simple' issue.
This is merely meant as an example to get the braincells going. ;-)
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||elin||3/6/13 4:24 PM|
So the media upload field already is designed to write title, created by, date and so on to a table, but we have never implemented this.
This is why I really see this as fundamentally something that should be thought about as another albeit non standard, kind of content.
Especially with the move toward implementing partial layouts that we are in the middle of I would think we would want to be able to just pull up a media record from the database and for each record to have a unique id ... and yes it would be an asset so could have ACL or could also possibly (or possibly not) use the category system for ACL. Whether media should be in categories is something worth exploring.
Did you know the media manager already uses ACL? The two views (backend full view and the pop up used by the media field and image plugins) have different ACL and the ability to upload is also access controlled. By extending the ACL to items and categories we could really have something great.
Also as part of this I'd like to see some real htought about handling of non images and also embedded media. Currently as we all are painfully aware we have no good solution for this besides filter=raw.
|Re: Regarding Project: Refactor Media Manager||piotr_cz||3/7/13 3:27 AM|
I have a concept about file handling in refactored media manager: For
getting new format to work, you'd have to prepare a plugin.
New media manager is an engine/ container, consuming 'mediamanager'
type of plugins and firing events (it is firing some already).
By default it shows allowed media types and provides basic file
Let's say we want to add functionality to work with video files.
Prepare plugin alike editors-xtd buttons: plgMediamanagerVideo
Clicking on 'Insert video' in CMS will trigger modal with query
Plugin will decide, which video files and icons to show, what are the
possible and allowed actions and append a custom JForm (like it's now
when inserting image) where user may add custom things like video
title and so on.
Actually all of this is already possible by creating new component
which extends current Media manager classes but it's not much fun (I
can provide source files if anyone is interested).
> > ------------------------------
> > [image: Small Logo] <http://www.s-go.net/>
> > *Chad Windnagle*
> > s-go Consulting
> > *607-330-2574 x103
> > 607-229-6260 (Cell)
> > Website Design - SEO - Video <http://www.s-go.net/>*
> > Follow Me: [image: Facebook] <http://www.facebook.com/sgoconsulting> [image:
> > LinkedIn] <http://www.linkedin.com/in/drmmr763> [image: Twitter]<http://www.twitter.com/drmmr763>
> >> .
|Re: Regarding Project: Refactor Media Manager||piotr_cz||3/9/13 2:33 PM|
On Mar 7, 3:21 pm, Nguyen Tran Quan <nguyentranquan1...@gmail.com>
> Thanks everyone for your ideas. I am collecting them and researching how to
> apply it to the project.
> Chad told me I will have to build a new media manager from scratch so we
> don't have any restrictions from the old one anymore.
> @piotr_cz: please upload your source code here or send me to my email
> nguyentranquan1...@gmail.com. Thanks.
|Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||4/5/13 11:13 PM|
Thank you for supporting me from very first day and sorry for keeping you waiting for a long time. I need that time to get knowledge of Joomla Platform, the CMS as well as the needed techniques. I tried to read through the codes of current media component, extplorer and the codes of piotr_cz. That is very useful for me.
I think it's time to begin the development to finish most of the features before release of Joomla 3.2. If I fail for GSOC, I still want to continue to completely finish this media renewing so it can be included partly in Joomla 3.2 and completely in Joomla 3.5.
After that, expected in Joomla 3.5:
- Ajax interface, allow drag-and-drop copying and moving file.
- Integration with CDN.
- Support for creation of collections of media.
After brainstorming, this is my idea of solving the problem of database-driven media manager and renaming file as well as access control list.
Table: #_media contains information about medias including id, name, containing folder, created date, created by.
Table: #_folder contains information about folders including id, folder, created_user.
Table: #_sharing_folder contains information about sharing folder to other users. This table allows users can share specific folders to others (really similar to Dropbox) including folder, created_user, shared_to_user.
Access to media will be done through id like ?option=com_media&type=images&id=xxx. We can rename by changing the name field in #_media without changing any link. We show the folders to only created user and shared_to_user. Ofc, on the backend, the superusers can see all of images which now are put in created_user folder (for example all images of mrdl will be seen in folder mrdl if current user is superusers and will be seen by mrdl only in all other cases, mrdl can share his folder fruit/orange to kelvin and kelvin will see folder orange as well as all of his folder).
After a long time thinking about this kind of approach, I wonder why we need "real" folders in images folder. In my opinion, we can put all images
in image folder with name = (id of it in #_media table or anything which is convenient). By this way, all operations like delete, rename, copy, download and upload can be done much easier. Everything is managed in 1 folder and everything else is just making some queries. The real structure of images is also not revealed to visitors. Restructuring folder tree will have never been easier.
Any comments will really help and be appreciated. Thank you.
|Re: Regarding Project: Refactor Media Manager||Janich Rasmussen||4/6/13 12:28 AM|
This sounds really great!
Regarding the question about real folders and files, this would probably confuse people as they can't easily "manage" the images/files on ftp anymore.
Maybe this is not something we need anymore (manage-able files on ftp), but I believe the vast majority of Joomla is happy with this "feature".
Do you have (or plan on) a new working group for this project?
|Re: Regarding Project: Refactor Media Manager||Bakual||4/6/13 1:29 AM|
I'm not sure if we want access to the media hidden behind a ?option=com_media&type=images&id=xxx at all. I think the generated output should be a plain link to the file, not a dynamic created content. While it may work for the img tag in browsers, I'm not sure it will work for all possible medias (video, sound, binary) in all possible clients.
Also it just generates more request through the Joomla framework when all we need is a request to the server, which of course is faster and needs less ressources.
I would also still like the option of upload files through FTP. There are just to many cases where a server would fail a fileupload. PHP upload limits based on filesize are just the simplest case.
|Re: Regarding Project: Refactor Media Manager||dgt41||4/6/13 10:00 AM|
I would like to state one idea once you are talking about the media manager.
Kill it. Its old fashion.
Ok here are my thoughts on this: It will be very beneficial for the end user if he/she don't have to think about the storage of the media files, fotos, mp3, mp4 whatever...
It will make the cms very easy in par with the IOS (in terms of file management) which also doesn't bother the user with files.
And how this can happen?
In the UCM (or on any component that uses media files) there should be a logic on storing files, one idea might be Category/Year/Month/Day/inc id/[directory of fotos] or Category/id/[directory of fotos] or user selected specific scheme. [This must be core and every component, module have to follow the rule.]
So, whenever a user, manager, editor, admin, or whomever creates a new article or content of any kind, instead of selecting one image he/she have to upload it (or give an option to select from a given cat etc) and through plugin hook create all the thumbs or do whatever the developer wants to the files.
Also the scheme must be easily overridable through simple xml file.
This way all the files are happily organized, no folder with zillion files.
joomla should have the management of the uploaded files in a nice and very easy workflow on the content submission which doesn't includes the old style media manager way.
Maybe one close look on the default article creation on the new Seblod will give you a better view of what I am talking about.
This idea for me is the best approach and will be an advantage over other cms.
|Re: Regarding Project: Refactor Media Manager||elin||4/6/13 10:20 AM|
I think it would be good to think of media as a kind of content and do develop the media manager to integrate with general content handling.
THus it should have the standard field mappings and I don' think it will need any secondary table because media are not that complex that they need more than possibly some special json to map to the thumbnails. Thus the standard information can be in the core_body field (i.e. file name/uri), the metadata like licensing can go into the metadata, and so on.
To be honest I'm not sure what the usefulness of moving files around is, what is useful is tagging and assignment to categories in order to manage inheritance of access and crud privileges. The "physical" location in folders is not really as important to me as the pointing we do to the files.
|Re: Regarding Project: Refactor Media Manager||elin||4/6/13 10:24 AM|
About Janich's question ... what we need is a team of people willing to commit to mentoring the project if it is a summer of code project. Or iF there were a team working on the project they could help the student work within the larger project. But most important from our experience with Javier's hugely successful project last year is that there be a group of people really committed to helping the student to get the work done and done in a way that fits with the other new or updated features.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Rikaryo||4/6/13 11:29 AM|
Good think it would be very interesting to rethink the image manager that was always a problem for everyone! and another think that the admin user can create folders and editor at front end, this option can only be done by the back end ..
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||4/6/13 7:26 PM|
Thank you for your comments.
@Janish: If we want the database-driven manager and ftp support then we are going to add the records of medias when we first load the folder? Is this a problem if we use ftp to upload 1000 files in 1 folder then reload that folder? It will be really painful for the query I think. Do you have other approach for this?
@Bakual: We are going to check the number of downloads, maybe someone want to add something like number of uses or number of views.
Sooner or later we have to develop something like this? I am not sure about this, need someone to confirm.
I agree with you about ftp advantages anw.
@Dimitris: Actually we are going to kill it :D. We decided to change the content of this project is making a new media manager. I think what you are going to describe is very similar to Wordpress(?).
They have option to upload media and insert to post as well as upload to library to use too.
The idea of creating folder like category/.... to decrease size of folder is great when we are going to automatically make folders for medias. Actually with this kind of database-driven manager, we don't really care much about the physical folders but decreasing the size of media means faster operation.
But can the problem of using ftp be solved in this case ?
@elin: The second table is for sharing folders to other users( like dropbox). Do you have other approaches to keep all of that in 1 table?.
For the working team, do you know someone who has enough free time to begin the development faster in beginning of May? The GSOC project development is going to begin in June 17th. Is it too late?
@Rikaryo: We are going to think about it. We built the media manager completely new so it is really possible.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Bakual||4/7/13 12:22 AM|
Counting hits surely is nice and may be interesting for some files. However I think for things like images which are embedded into an article, it just doesn't make sense to count their hits. They will be the same as for the article containing it. I'd just include the link as a plain link to the file here.
If it's a file offered for download, then it could make sense to create a dynamic link which allows to count the download hits.
Just keep in mind when rebuilding that the needs may be very different depending on what the media is needed for. As an example: I have an extension which also builds a podcast and for iTunes the file extension of the link matters, a dynamically created URL fails for this reason here, except if you add something like "&ext=.mp3" as a workaround (which is awful).
Also keep in mind that access restrictions on files don't make much sense as long as the file itself is stored in a public readable folder. One could just guess the filename with trial/error system and get around the access restrictions. To truly secure the files, you would have to put them in a folder readable by PHP, but not directly accessible by an URL. So either outside the Joomla root directory (may cause issues with Joomla file functions / FTP layer) or in the database itself (blows up the database).
I'd say don't overkill the media manager when redoing it :-)
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||elin||4/7/13 1:36 AM|
Definitely simplifying and seamlessly integrating storage in locations besides the webroot of the CMS would be an important part of modernization. In our general theme of thinking about simplifying interaction with services integration of that with media management is an important. On the other hand, it is important to keep the scope of work realistic. In terms of counting hits, that is already built into the JTableContent api plus the go() method (which could be moved to a more accessible/useful location) and I'd look to a different kind of project to implement changes to that (such as moving the storage of hit data out of the content tables to a separate table for improved performance and flexibility).
A lot depends on what you really mean by "the media manager." Do you mean the system we have for inserting images into content? Or the system we have (currently in the back end only) for simply managing those assets. In terms of writing either an overall a plan or a specific plan for a GSoC project, you probably want to think of those as two separate but linked things (just as they are now). Does it really make sense to have users inserting media use a simplified view from the system of managing media assets? Maybe, maybe not, it might make sense to think of them as separate things (and notice that there is a separate project idea that deals with improving the plugins in editors. This project could definitely work on improving the editor plugin for image (and potentially other media) insertion as part of its scope but it could also be that it really focuses more on the management issues.
What if we started a wiki page to start planning out a scope of work for media management with prioritized features and so on. and that then might help you figure out how to make a project that is realistic for the summer (and usable we hope for 3.2) but that has the potential to be extended after that both in the CMS and by extension developers who might want to build more advanced systems by extending a media management api like JMediamanagement or maybe JHelperMedia.
Features are good but think about architecture.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||4/7/13 9:37 AM|
I believe everyone here has different ideas for the new media manager, about included features and prioritized features as well as the architecture.
I used the ideas from comments of everyone above to form the features and approach in my previous post. However, consider the importance of the media manager because of links to other parts of Joomla I do think the wiki page is really great!!! to collect all ideas and find out a uniform structure for this.
Thank you very much for your help :)
|Re: Regarding Project: Refactor Media Manager||piotr_cz||4/8/13 12:08 AM|
About the paths/ physical location of files:
I'd like if files would be accessible without the component:
- using ftp
- using uri
Because accessing each file/image trough the component could be
Last year we were facing a problem, when somebody was creating a
gallery extension and each image would come trough component ( like
<img src="index.php?option=com_gallery&id=1" /> ).
Joomla used to crash because of multiple requests in very short
period. The session table just was not being updated correctly. I'm
not sure if this is fixed now but I think this is something to be
What if the file address would resemble the section structure? each
item can be assigned to only one section so the same could work for
directory structure. Once an item would be moved, we would move it's
The question is how to handle ACL and other stuff in this case. It's
possible to set directory permissions on directory level but not to
manage user groups without admin account on the server.
On Apr 7, 4:26 am, Nguyen Tran Quan <nguyentranquan1...@gmail.com>
> Thank you for your comments.> @*Janish*: If we want the database-driven manager and ftp support then we
> are going to add the records of medias when we first load the folder? Is> @*elin: *The second table is for sharing folders to other users( like
> dropbox). Do you have other approaches to keep all of that in 1 table?.> > always a problem for everyone! and another think that the *admin user** **
> > can** **create folders** **and** **editor** **at** **front end*, this
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Janich Rasmussen||4/8/13 12:41 AM|
Just a short answer on the question:
In Kunena we previously had the same issue; One query for upgrading the whole forum, but that didn't work very well on larger forums - it kept dying (either the php or mysql of course).
We wanted it to work no matter the size of the forum, so we made it as an incremental updater so only xxx postings were processed in one session (pageview). This have worked fine ever since.
I do believe the same thing can become an issue here (with the default php settings in mind), but the answer could be rather simple...
Perhaps the same method will work (set a simple limit on how many items can be processed in one view, and then reload that until no more items are found) - or maybe run it in parallel as ajax requests (like Finder).
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||elin||4/8/13 9:57 PM|
Ever since we got categories+acl I've been wondering about making a folder structure for images map to a category structure for purposes of ACL as a concept.
Short term I think that it makes sense to use the file system, longer term though we may want to be using partials for embedding images/galleries/other media and I want to be able to manage that really well.
On Monday, April 8, 2013 3:41:54 AM UTC-4, Janich wrote:
Just a short answer on the question:
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||George Wilson||4/9/13 4:57 AM|
Of course a folder for each user group could mean large numbers of folders for people with a large number of usergroups!
Also I was thinking is there a plan to move the images file into the media folder in the future? It seems more logical to me to keep images in there - perhaps just as a subfolder.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Bakual||4/9/13 5:12 AM|
Actually, I think it's most logical to keep images in the images folder ;-)
But the other media would fit better into media probably.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||4/9/13 7:56 AM|
Thank you for your answers and information also.
I saw some of conflicts in ideas here. Could someone follow elin's idea in making a wiki page so all of us can finalize the uniformly backbone of this new media manager please?
One group chat on Skype is also really great if some of you can spend your valuable time on discussing this problem.
Thank you very much
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||George Wilson||4/9/13 9:23 AM|
Created a wiki page here:
If you disagree with stuff please either post here or on the talk page on the wiki rather than overwriting other peoples every time you disagree with them :)
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||elin||4/9/13 2:40 PM|
Well we never necessarily say one category per user group, I think that's a pretty unusual structure though certainly one that some users would adopt. Partly it is a question of whether you provide the ability to track image/media files as assets.
|unk...@googlegroups.com||4/17/13 6:43 AM||<This message has been deleted.>|
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||4/17/13 7:40 AM|
I see no one edited the wiki. I believe below is a good schedule for me :D
Firstly, we have to finalize the requirements and models of this project.
Next, I and hopefully with your help will complete the use case and sequence diagrams before starting implementing. Joomla is lacking diagrams about processes I think. We can put this on documentation
This is a core component so I hope everyone can help me to finish the requirements and the diagrams together. My proposal will be more fit and easily integrated in next release (3.2 I hope).
For anyone who are interested in this project and have time to give me valuable advices, please add me on Skype at mrdl9999.
I made an account on cacoo so we can together edit the diagrams. Currently I put it public here. Later please send me your id there so I can add you to team. We can have up to 30 members :)
If you want to add new diagram, click + at bottom.
I completed the back-end rename function (except the acl)
user: admin, password: admin.
This is just a show case. If we adopt the database-driven media then the operations are much different
Tell me any bugs you find so I can fix it.
Thank you everyone :)
|Re: Regarding Project: Refactor Media Manager||Amy Stephen||4/17/13 7:59 AM|
Linking categories and folders is not a great idea. That's adding yet another node based system to Joomla. Given the menu items, categories, ACL groups, etc., simplifying the nodes in use is a better direction than adding more.
Recommend treating each image - each video and audio file - each uploaded ppt file - each unit of media as a resource item. So, create a com_content record for it - use the existing ACL - and change the application interface to navigate those records when listing and retrieving data -- instead of using the file system directories.
In that manner, you position the application to store descriptions about images, associate it with tags, include it in categories, interface it with the menu system, because it's treated just like any other content.
Associating it with folders takes you further away from integration, more code must be written, more complexity put in place, more questions asked and answered (For example, if I give someone access to a folder, does that access ripple down?).
Best to avoid that and utilize the architecture already in place.
My 2 cents.
|Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||5/2/13 9:09 AM|
Hi everyone !!! Hope everyone remembers me :D
My proposal with a lot of efforts and a tremendous amount of helps from everyone here have received some positive feedback :) as well as suggested improvements.
The features are quite clear now, basically a database-driven media manager with json-based api to handle media.
One important thing now is the UI of the media manager.
Do you and your friends(especially non-tech) feel comfortable with the current UI? Do anything make you confused?
Any suggested improvements?
All advice and ideas on the UI are highly appreciated
|Re: Regarding Project: Refactor Media Manager||WP4J||5/5/13 6:56 PM|
>>>One important thing now is the UI of the media manager.Have a look at the way WordPress does it. Also the suggestions from both Elin and Amy in regards to having media items as content is basically what WordPress does as well. You can gain a lot of good ideas from looking at WordPress.
|Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||5/6/13 2:10 AM|
Thanks for your comment. Actually, the technical features(including media handler) are quite clear now, just need some discussions with Elin about the new UCM. I am currently having final examination then not able to spend time to discuss.
I received some comments about the familiarity of users of the current UI. If there is not anything confusing about this current UI, I will use reuse this with some MooTools translation to different library.
|Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||5/19/13 7:06 PM|
One small update, I put the demo of the new handler structure on melange. Please give a comment there or here.
|Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||5/22/13 10:04 PM|
One not-small updated,
The media manager now is supported the database with Jtable implemented and handlers modified to handle.
A cron is also implemented to check between database and real image folder in case people use ftp to upload or delete files.
Please give comment on meelange or here.
|Re: Regarding Project: Refactor Media Manager||George Wilson||5/22/13 11:53 PM|
With the decision made to use FOF as our RAD layer for Joomla which doesn't use JTable (it uses FOFTable instead) is this such a good idea? Note that it's already causing the FOF guys headaches with the tags processing for the same reasons (usage of JTable in JHelperTags). As FOF should be being implemented in 3.2 - would it be a better idea to use FOFTable in the Media Manager as the first component to implement our new RAD layer rather than JTable?
Just throwing it out there
|Re: Regarding Project: Refactor Media Manager||Nguyen Tran Quan||5/23/13 2:02 AM|
Thank you very much for your reply.
Currently I am quite lacking knowledge about FOF implementation. I will try to gain knowledge about it and get back to you later.
|Re: Regarding Project: Refactor Media Manager||Bakual||5/23/13 2:13 AM|
I would say first the RAD layer needs to be implemented and if that's done, one can see how to adjust other projects to use it.
Imho to much is still in discussion to really depend on it already.
If FoF has so much troubles with JTable, maybe that should be solved within FoF ;-)
|Re: Regarding Project: Refactor Media Manager||Roland Dalmulder||5/23/13 4:30 AM|
The implementation of FOF into Joomla was pulled a while ago. Has this topic been revisited?
|Re: Regarding Project: Refactor Media Manager||elin||5/23/13 4:34 AM|
I think you may be misunderstanding what the issue is for people who have chosen not to use the core architecture in their extensions when it comes to using the tags api (or many other apis). It has nothing to do with the tags table, it has to do with the fact that the tables in their extensions don't do what is expected. People know going into using an external framework that they are going to have issues like that, and they make rational calculations that it's worth the cost of having to do workarounds. Presumably any RAD from the project itself will work seamlessly with the present and future core apis.
I believe what is being looked for here is some feedback on code and structure and I hope people will take a look.
Also there was a question previously about what it is that people--and by that i mean users not developers-- do not like about the current UI in the media manager. Keeping in mind that the media manager really has two parts, first the actual full manager and second what content creators see, what are the improvements people are thinking about? I was looking the other day at the bootstrap thumbnails markup http://twitter.github.io/bootstrap/components.html#thumbnails and thinking that was pretty neat.
Can we not derail this thread, which has until remained pretty focused?
|Re: Regarding Project: Refactor Media Manager||Herman Peeren||5/23/13 4:36 AM|
On Thursday, 23 May 2013 13:30:14 UTC+2, rolandd wrote:The implementation of FOF into Joomla was pulled a while ago. Has this topic been revisited?
Yes!!! There is now a working group to implement a RAD-layer (FoF) into Joomla-CMS.
for discussion and links to documents.
|Re: Regarding Project: Refactor Media Manager||George Wilson||5/23/13 4:38 AM|
... But we will be using the FOF framework as a RAD layer in the Joomla core.
Thats my point - of course I understand there will always be issues. But if we're going to use JTable in the media manager it means that we're going to be recommending people to use the RAD layer in components (using FOF) whilst simultaneously using JTable in the media manager which isn't compatible with FOF.
Thats my point and I feel is very much on topic.
|Re: Regarding Project: Refactor Media Manager||elin||5/23/13 10:55 AM|
Does the fact that com_content uses JTableContent and com_users uses JTableUsers and com_weblinks uses WeblinksTableWeblink mean that FOF has never been able to work?
|Re: Regarding Project: Refactor Media Manager||George Wilson||5/24/13 10:06 AM|
Of course it can work at the moment. FOF have any interlinking to weblinks/content components - so it doesn't matter much. However the media component and tags have much more integration (i.e. their respective form fields used over many components) so it does matter more. Does that make more sense as to why I'm worrying?
Dragging back on topic here - my point is that we at least need to talk to Nic about how this is going to fit in with the new RAD layer (aka FOF) also coming in 3.2. We need the new media manager to at least be compatible with this RAD layer.
P.S. I'm not 100% clear as to where the incompatibilities lie - it's possible you can use JTable and be compatible! Read here for info about the Tags support in fof: https://github.com/akeeba/fof/issues/24 - as you wrote tags it might make some more sense to you :)
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Nick Savov||5/24/13 10:15 AM|
I don't think it's an issue in this case, but if it is, it would be FoF's
responsibility to fix the bug, since JTable is a core class. The RAD layer
has to work with the other components (which use the current core
Hope this helps!
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to joomla-dev-cm...@googlegroups.com.
> To post to this group, send an email to joomla-...@googlegroups.com.
> Visit this group at
> For more options, visit https://groups.google.com/groups/opt_out.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||George Wilson||5/24/13 10:30 AM|
I don't think it's an issue in this case,
Awesome :) That's what I wanted checked on - not sure if we should check this with Nic to be safe?
I don't disagree with this - but FOF's responsibility is now the RAD groups responsibility as well - so basically we are just giving ourselves more work and higher code complexity and I think we should factor that in against how useful JTable is actually going to be in the Media Manager! If JTable really is that useful that it's worth it then fine let's do it - but I think this should be factored in!
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Rikaryo||5/24/13 10:42 AM|
Visualized the idea and really a long time that we need a new media
manager, would welcome its implementation in Joomla! 3.2, if my
comprehension is correct, the remodeling of a new manager would only
images as we have today? bear or other audio formats such as mp3 and
mpeg are not viewed today by current media manager? Perhaps it would be
interesting to apply an idea that someone suggested here on the e-group,
which would be used instead of the folder "media" root Joomla to accept
both image files, audio and video?
Uploading files is current tormentor and mass mailing with falsh works
only when you want, but this is a weak point of the Joomla! a long time!
good work friends!
|Re: Regarding Project: Refactor Media Manager||Bakual||5/24/13 12:48 PM|
Actually, I think the RAD layer must be made compatible with the current code. It's strange to assume we need to change the core code (and maybe also 3rd party extensions?) to be compatible with a fully optional RAD layer.
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||Mark Dexter||5/24/13 2:29 PM|
One major advantage of incorporating RAD into the core is that, when it makes sense, we can change the core as well. For example, if there were new base methods we need for RAD tables, we could potentially add them to the base JTable class (obviously not creating any b/c issues). So I don't think it is necessarily RAD has to change for core, or core has to change for RAD. I think we can look at the specific issue at hand and make the best decision for that specific situation.
Alternatively, we could create a new set of core classes that extend the existing ones and add new stuff we need for RAD.
But imo we should not think of RAD (whether FOF or something else) as an extension. We should think of it as part of the base layer of the core libraries. So the approach could be a bit different than what was done for FOF (since they didn't have the option to modify core classes).
My .02. Mark
|Re: [jcms] Re: Regarding Project: Refactor Media Manager||elin||5/25/13 6:47 PM|
In some cases so-called RAD work is really just things that should be sent as pull requests to the core. The RAD should really focus on making it easy to build extensions which is something different than adding or improving core code.
Obviously a RAD must work perfectly with the core classes, and it is a bug if it isn't unless it's a result of a bug in the core, in which case there should be a PR to the core rather than a workaround. This is one of the key differences in doing something "official" ... you don't do workarounds you solve problems the problem one way or another.
One of the things about open source development especially with GPL is that you "write to the interface" or in our case "write to the apis and mvcs." In other words, you know what is coming and what you are expected to send, and you write your code to match that. In terms of the media manager, we know what apis people are expecting, and backward compatibility will require that those continue to be supported until J4 and probably beyond that given that they are pretty simple. Other than that, what goes on behind the scenes is up to the person or group working on the project and then to people doing the code review. So the RAD group knows what the APIs it is expected to work perfectly with are and that it needs to be able to support future apis that will be added meaning that it should not build internal dependencies that will mean it can't support whatever comes its way. The media manager knows what apis it needs to support but of course it can add many new ones. Same thing with ucm or services.
About the media manager, I think one of the main complaints people have now is that it doesn't really work so well with media that are not images and also that the insert image button really cannot work as an insert media button because of the input filters. So I hope that rebuilding the media manager will result in better handling of all media types. Do people think that types of media should be stored separately (the way a template or /media has css, js, and images folders)? Or does it not matter, since the types can be filtered using the database?
|Re: Regarding Project: Refactor Media Manager||Fedir||6/9/13 3:27 AM|
Do people think that types of media should be stored separately (the way a template or /media has css, js, and images folders)? Or does it not matter, since the types can be filtered using the database?
store files by type have no big sense,
I think the more interesting and more useful feature it possibility to store files by User, by Content, by Date ...
Субота, 8 червня 2013 р. 23:06:31 UTC+3 користувач Josh Weiss написав:
On Monday, March 4, 2013 11:25:32 AM UTC-8, Nguyen Tran Quan wrote:
|Re: Regarding Project: Refactor Media Manager||uzielweb||7/23/13 10:22 PM|
Hi, Thanks for interest... Continue programming, I look forward :)
|Re: Regarding Project: Refactor Media Manager||piotr_cz||7/31/13 6:49 AM|
|Re: Regarding Project: Refactor Media Manager||Adam Rifat||7/31/13 9:18 AM|
Is it possible to save images using JImage as progressive JPEG?
|Re: Regarding Project: Refactor Media Manager||piotr_cz||8/1/13 12:43 AM|
No and yes.
You have to apply imageinterlace($handle, 1); somehow on the image handle (it's a protected variable of JImage).
At the moment handling the handle is only possible using own JImageFilter (which may be part of your extension).
I think add that as an option to JImage->toFile('path.jpg', IMAGETYPE_JPEG, array('interlace' => true))
Progressive for JPEGs,
Interlaced for GIFs and PNGs.
|Re: Regarding Project: Refactor Media Manager||Dmitry Rekun||11/19/13 11:18 AM|
Any news on it? May be some repo with the current code?
|Re: Regarding Project: Refactor Media Manager||piotr_cz||11/20/13 1:44 AM|
|Re: Regarding Project: Refactor Media Manager||Dmitry Rekun||11/20/13 11:42 AM|