By sectornitad on
Hello -
I have now thoroughly explored the Media module. It is a worthy addition but there appears to be one glaring omission. All the uploaded media files sit in one folder. There is no way to create sub-folders to better organize the media. Surely the developers wouldn't go to all the trouble to create the module and then fail at the final hurdle! I would have thought that having folders would be the first requirement.
Am I missing something here? Is there an add-on module to achieve this?
Many thanks
Comments
On the media module page,
On the media module page, they list a bunch of optional modules that you should probably go through.
This one is adding tagging and folders though it has been a while since I last tried it so I don't know if both of those features are currently working. http://drupal.org/project/media_browser_plus
(Media Browser Plus) Code is
(Media Browser Plus) Code is moving to the file_entity module and part of it is being obsolete as media integrates with views.
http://drupal.org/node/1290924#comment-5061790
Still not a part of Media module
Interesting to see this was posted in 2011.
Having just installed Media module, I'm not sure what the point of it is. I'm sure there must be one given the experienced developers behind it, I just don't see it. Without folder organisation, I do not see what benefit a visual library has (as that seems to be the only benefit rather than simply using the Image field).
I guess this is looking at the framework only approach, in the hope other modules add such functionality.
I get this, but I'm not sure it's the way to go. For example, Drupal Commerce is suffering (in my opinion) from the various bits of important functionality that are not all getting regularly updated or improved along with the Commerce core. And when DC depends on that, I think it becomes a problem for DC. Plus if everyone goes in this direction, are we looking at a full-blown Drupal site needing 100s of modules? Is that really what we want?
=-=
I've always been curious as to what exactly the argument is against having to install/use multiple modules. Code whether packaged in sub-modules within a single package or packaged separately doesn't make a difference does it? If the concept is maintenance, I'm not sure that matters much either. I've seen single packages where sub-modules included within fell behind the core of the package as well due to lack of usage on the part of the developers/maintainer.
Fair point. Here's my view,
Fair point. Here's my view, as a list.
1) Each module brings a bit of overhead and repetition. I'm not claiming to be an expert in how much that is, but there must be overhead of a number of different modules being used at once rather than one (each module at least will need code to identify it as a module).
2) Modules developed as a framework means maintenance of a particular aspect of a module may not be continued (the core module may be updated, but a connected module not). And often key features for many users become dependent on a single developer who may not have the time / backing to keep up with the core changes (a good example here are a number of the Drupal Commerce modules).
3) Unprofessional. This, I think is that key point. Giving a site to a client that depends on many different developers work, and is impossible for the client to maintain is not professional.
I think framework modules simply lose a direction. Kind of trying to do the impossible. I would rather work around limitations (and I know my clients would) rather than having 10 modules for one feature.
3) Unprofessional. This, I
Clients shouldn't be maintaining sites on their own anyways, that's asking for troubles. I have given clients that option in the past, but I always tell them that it's their own risk, and that I will bill them for any problems they need me to fix as a result.
It sounds like maybe you need to start learning custom module development. This will allow you to add the functionality yourself, instead of using 10 modules to do so. It also means less modules (since you can put all your customizations into a single, or a minimal number of modules), and you can customize it exactly to the specifications of the site.
Contact me to contract me for D7 -> D10/11 migrations.
I've always been curious as
Each module on a site has a .module file, and every .module file is loaded on every page load. So the more modules on the site, the more files that need to be aggregated for every page load. The aggregation process is one of the biggest time consumers of each page load. This can drastically slow down a site if/when enough modules are added, and leads to many people's complaints that Drupal is slow.
Also, using many modules means that they all have to interact with each other. The more modules you add, the more variance there is as compared to other people's configurations, which means the larger a potential for conflicts/errors.
Contact me to contract me for D7 -> D10/11 migrations.
=-=
The same would hold true whether individually downloaded and installed or contained in a single download and installed under the concept of sub-modules (which is what my question hinged on).
Which part are you referring
Which part are you referring to by "the same"?
Contact me to contract me for D7 -> D10/11 migrations.
=-=
both. .module files loaded regardless of how they are distributed. multiple developers are multiple developers whether in a single package or in sub-modules. integration issues can occur whether distributed individually or in a single package. The point may hold water if the division is whether or not the features are in core but even at that if they are included as separate modules, then the .module is still loaded.
as an aside, the questioner still didn't provide a list of these so called 'must have' modules. Which is where my question comes from, since 'must have' are different for nearly every site and the most utilized are D7 ready. Said user seems focused on e-commerce which isn't a must have for all sites and is also newer as compared to its counterpart (ubercart). fair to say ubercart also had/has issues with many submodules that were required some of which fell through the cracks. I attribute those types of things to maintainers recognizing their own resource limits and/or non-need for the feature provided by those separate projects as well as that a specific feature is not needed by all sites using a specific 'base' module.
Any one person or group can only maintain so much code. I'm astounded every year by the amount of contributors that manage to move core from version to version. I just don't see how the same can occur for contrib without more resources. Over the years the pattern I've seen emerge from most users frustrated by the obstacles in contrib is an inability or unwillingness to aid in the maintenance of the modules they utilize and in many cases generate income from. Where else are these resources (whether in funds or in code) going to come from to maintain code (whether in a single module or in submodules) if not from the community?
The #1 puts users in a position to have to have features they wouldn't otherwise need within their install and wouldn't be able to leave uninstalled.
Perhaps I'm biased in that I prefer to use as little code or as few modules as needed for a given site. sure, I need ctools to run views and in most cases I don't use most of the features contained in ctools. In fact, rarely are any of the submodules enabled beyond the ctools core. If that code wasn't in ctools it would be still be in views and need to be run.
both. .module files loaded
I agree. A .module file is loaded regardless of where the module came from. But on that note, I always build my sites with a single custom module to handle all the custom development for that site. So whereas I may need to install 2 contributed modules in order to get a certain functionality, by keeping the code in my custom module, I don't need to install either of these modules. I do try to find a balance, it's not like I don't use contributed modules. But my overall goal is to find a balance of a low number of modules, combined with a high amount of functionality, and when possible I use modules that have many sites using them, so that there are many people handling bug fixes and additional functionality.
Contact me to contract me for D7 -> D10/11 migrations.
=-=
agreed which is directly related to an ability (at least in some form) to maintain the 'code' of the site whether for yourself or a client.
It doesn't matter what script someone installs. If said user is completely dependent on others to perform the heavy lifting (maintenance/development) then it is that dependence that is the larger issue and not module dependence.
sure in a perfect world, a script could be installed, run fast, use few resources, and have near zero compatibility issues. That nirvana has been being sought since the first line of code was written. It's not that drupal isn't there yet, no software is there. Personally, I don't see that nirvana being reached until machines can think for and correct code on their own with little to no human interaction.
@jaypan
@jaypan
I take your point about custom module development enabling client requirements to be match precisely. Really that is a given for the people here I think. But it was not really my point, although I'm not disagreeing with yours.
It depends what a client expects with a CMS. My clients are generally e-commerce focused small business owners, and generally very net savy. They know how it is. They know that accepting a certain limitation means less custom coding, less cost and the potential benefits of using well-tested contributed modules.
I disagree that we should only be building sites that need continuous developer maintenance due to the complexity taking it out of the site owners hands. That is actually not in keeping with many site owners view of CMS (even Drupal has an infrastructure based on use by non-developers. It would be an entirely different thing if it was a developer tool only).
Of course, I believe a sensible client will look at a business website like a company car - requiring on-going maintenance and cost. But, in my opinion, as a conscientious developer, I want to give my clients something that enables as much self-maintenance as possible, so they have the choice, rather than being forced to employ me or someone to maintain the site.
@VM
I agree about as little code as possible. And I have noticed a recent trend of certain developers moving away from CMS for smaller projects (where the client really doesn't need such an extensive admin, and the resulting site is a lot less resource intensive and faster). There was one Drupal dev in particular that I will try to find the link to who wrote an article on this with examples.
And your ctools example is a good one. I probably use ctools and views in every site I create. But I don't like the overhead. If I could justify the cost to a client to produce custom templates to not use views, I would. But generally that's not practical. So I try, as much as possible, to minimize code use but at the same time keep to well-tested modules where possible.
I used Drupal Commerce as an example, because I think it's dependency on many smaller modules is seriously limiting its progress, and making production sites less stable due to the dependence on less well maintained modules. It does not have one clear direction, and with all the competition out there, I think it needs one.
Most clients I have worked with would much rather work around certain limitations and have a more reliable, more easily maintained site than the other way round.
=-=
On the flip side, I've witnessed projects start off this way and within a short amount of time grow/expand into something larger that then requires a more complex set of admin tools and/or other features.
I'm not sure what templates have to do with the views/ctools discussion. However, if its just a matter of a db query it can be thrown into a custom module without much hassle. In fact, more often then not I export my views into custom modules.
Realistically though, if your clients are eCommerce heavy, i'm not sure why Drupal is the jumping point for those sites. e-commerce in drupal I view as a proof of concept at this stage. It can be accomplished but whether or not it should be for a given site is a different discussion but does pose the question of why you aren't working with a commerce specific script where the focus is solely in the commerce space.
On the flip side, I've
Yes, sure, me too. It's what has brought some clients in. But I still think there is a responsibility on the developers part to keep module use and overhead to a minimum, even for larger sites. I say this because I have seen a number of sites where the initial developer has just thrown modules at it until it became a monster (and more often than not, these were relatively small businesses). Sure it got me work, but not in the way I would want to get work.
Templates was a bit of a blanket term. I only meant that Views has it obvious uses, although I would say considering the markup and overhead it brings, if I have the chance (as in funding) to not use it, I wouldn't (as I think any responsible developer shouldn't).
Absolutely, and I don't only work with Drupal (although another system I use more often than pure e-commerce is Virtuemart. It's still a CMS linked system, but much more full-on e-commerce than Drupal Commerce or Ubercart). This mainly came from clients already having Joomla.
But the other side of that is the issues that come from pure e-commerce systems. One is lack of flexibility. The other more important one is almost all small businesses need much more than a pure e-commerce site if their business depends on the web. I should also say I'm probably more skilled in the consulting (particularly user experience and business-critical functionality) than pure development (which I think is getting rustier buy the day).
=-=
bitching about what other developers do hasn't ever fixed a thing. Core/Contrib Drupal/some other software require resources. If you have a vision of where drupal should go, supply those resources to take it in that direction. Otherwise, you are dependent on where others take it that are supplying the resources. I don't see drupal getting away from the lego concept. It's part of its popularity for others.
No need for negativity
Bitching? Thought it was an adult conversation. And I didn't question the lego concept of Drupal. With respect, avoid forums if you don't like opinions rather than waste people's time responding to you.
=-=
I pose that an adult would have thick enough skin to handle lightly salted language such as "bitching" and infer complaining in its place rather than get their panties in a knot.
With respect, the same can be said of you no? avoid using a software platform that you or "your clients" perceive as unprofessional.
The changes you seek aren't driven in the forums in a near three year old thread that you decided was worth resurrection to vent your frustrations. Change is initiated and driven in the issue queues.
No idea what's driving you to
I was simply giving opinions, without malice, about Drupal because this is a forum. You are quoting things, continuously, that I did not say or imply. No idea what's driving you to want to be rude and this trolling. Enough space used for this nonsense already.
=-=
really? and continuously huh? You're just full of exaggerated blanket claims aren't ya? Perhaps you forget what you type from comment to comment. No worries, I'll help you out. After all this is a support forum ;)
My guess is that your adverse reaction is to my previous comment thatt included the following:
My inference is supported by the following quoted from: https://drupal.org/comment/8574281#comment-8574281 in which you stated:
In spite if your charge that I'm a fabricator of your words, I'll be more than happy to review any other comments with you. I presume there must be others considering your use 'continuously' within the aforementioned charge.
Metrics
I see this claim occasionally, but never any metrics to back it up. Do you have any? My expectation would be that the loading of multiple files is simply not a serious issue on a properly configured server (example: PHP with an opcode cache). All that ought to be in memory.
I've never seen the metrics,
I've never seen the metrics, but I've read a few times that it averages half the page generation time.
Which makes sense to me considering that the more modules a site has, the slower the site gets - more modules = more files to aggregate.
Contact me to contract me for D7 -> D10/11 migrations.
Further research.....
Interesting posts. Suggests research in this is needed. If what you ware saying is correct, it really does put the emphasis on less modules, or perhaps simply a common knowledge about this that guides developers in good directions. If I find anything, I'll post it here.
Just use a taxonomy
I'd say the simplest way to achieve this is to go at it from a slight different tack to achieve the same goal of organized files.
Instead of a folder hierarchy just add a Taxonomy, populate the taxonomy, add a term reference to the file type you want to associate it with (maybe all of them) then modify the view for the Media Browser by adding an exposed filter on your new term reference field. Done. Now you can filter by whatever arbitrary terms you'd like which is very similar to the folder metaphor without mucking with the actual file system which users/editors don't care about.
Also, I want to say a big thank you to the developers who create, maintain, update, help out in the issue queue and so on. It's all to easy to dismiss these efforts as not good enough, but I hope they know that there are countless individuals in our community that are very grateful for their free work, including myself.
-cdmo
Thank you for the great advice and comments
Everyone in the programming industry get's blamed and blames others. Software Engineering is a tough gig to get right and to get buy-in from everyone on the team - let alone understanding / patience.
Thank you for your suggestion cdmo, and I can couldn't have put it any better myself - these programmers are sacrificing their time to give back to others.