Posted by zapple on July 30, 2009 at 2:17pm
Jump to:
Issue Summary
Having looked at the WYSIWYG API module, it would be really useful if SWFTOOLS (and any other module that uses libraries) stored additional elements such as Javascript libraries and players in a central location outside of the SWFTOOLS folder. For example sites/all/libraries.
This would mean that when updating the module things don't get deleted and would make version control much better.
Just a thought.
Zap
Comments
#1
agreed.
#2
Subscribe.
#3
Note that at this point you can manually specify sites/all/libraries as the directory for 1pixelout, flow player etc. However, in doing so there will be errors if you don't copy over the generic audio and video players. There also isn't support for putting 1 library in profiles/profile-name/libraries while others live in sites/all/libraries or sites/default/libraries. See how WYSIWYG is handling libraries as well as http://drupal.org/project/libraries for better examples.
#4
It seems like it would be best to default to a all/libraries location.
#5
I like this, and would propose to shift libraries to
sites/all/libraries/swftools/[library_name / player_name]Reading the thread it would seem simply defaulting to
sites/all/librariesin the short term would be a good first step, and if more clever stuff comes along later the files are at least ready!I'm doing a lot of work on SWF Tools 6.3-3.x at the moment, and as part of fixing the name space collision the easiest instruction for end users will be to delete the entire SWF Tools directory. So moving what is currently called
sharednow would be good.Also solves problems for me when I accidentally commit a media player because I forget to .cvsignore it in Eclipse!
#6
It also occurred to me as I was updating all of the swftools configs on my sites (in a multi-site config) that the mediaplayers should have generic filenames. For example, I renamed flowplayer-3.1.5.swf to flowplayer.swf and examples/flowplayer-3.1.4.min.js to flowplayer.js so that when I want to update to a bew release I can just upload the new files and rename them once ratther than logging in to 15 different sites to update the swftools configuration.
I don't know if others will agree but for 3.x it would be nice if the defaults were like that, sites/all/libraries/swftools/flowplayer3/flowplayer.swf, etc.
#7
Hmm, I had never really thought of that but I can see your point. I'm actually in the process right now of working out the structure of the new library location, and toying with different naming approaches.
With the 6.x-3.x release there are going to be a few "behind the scenes" changes, one of which will be to move the players and script libraries to their new home, so renaming them NOW would be the best time.
The original logic was to not need to change the name of the file when you upload it, but I can see that for a multi-site config it would be simpler to rename the file than manually change the setting on each site.
That said, I've got caught with FlowPlayer where new releases cause SWF Tools to not work "out of the box" because there's been a point release of the player which means SWF Tools fails. Requiring a player rename would mean that doesn't happen.
Does anyone else have a view before I finalise this?
#8
I've thought about that, too, with the player not working. But people still can just install an incompatible player either way (which I've done before myself!). Maybe the readme should warn against anything newer than whatever the latest tested version is.
#9
Thinking about this some more,
sites/all/libraries/swftools/[library_name / player_name]is probably not quite right. One point of the libraries is to allow multiple modules to share them, so the libraries don't "belong" to SWF Tools.So maybe the proper place is simply
sites/all/libraries/[library_name / player_name]I've also been looking at Libraries API and the way that code is developing it looks like it assumes that libraries sit in directories just off of
sites/all/libraries.#10
That makes sense to me.
#11
On branch DRUPAL-6--3 all player and support files are now expected to be under sites/all/libraries/[library_name]
As far as possible I've set it so that the [library_name] is simply the name of the directory when you unpack the library from its archive. JW and FP are slightly different since there are multiple versions of the player.
So we have...
Onepixelout -> audio-player/audio-player [1]
FlowPlayer 2 -> flowplayer
FlowPlayer 3 -> flowplayer3
JW Image Rotator -> imagerotator
JW Player 4 -> mediaplayer4
SimpleViewer -> simpleviewer
SWF Object 2 -> swfobject (if not installed SWF Tools will access it directly from Google)
WordPress Audio -> audio-player [1]
[1] OnePixelOut and WordPress audio player are variants of the same player. You can install both in to the same directory as when you download the OnePixelOut package it's files are in a sub-directory also called audio-player. WordPress audio drops its files directly under audio-player. If that makes sense!
The change is actually very effective - it's much easier to try new versions of the SWF Tools code without having to reset the support files.
#12
I like the idea of keeping libraries in sites/*/libraries, for sure. But requiring sites/all/ libraries can be a problem. I'm implementing audio on a site today that's built on a multi-site platform where I cannot put the libraries in sites/all/*.
Requiring sites/all/* will be a problem for some sites. I suggest something more flexible, so we can put libraries in sites/all or sites/my_site.
#13
To echo jensimmons, this change is good step but there should be support for profiles/profile-name/libraries and sites/example.com/libraries. This is consistent with what other modules are doing these days. Also, sites/all should override install profiles and individual sites should override sites/all or the profile.
#14
How about taking advantage of Libraries API to do this.
It would be fairly easy to code so that if the API is present it is used and libraries can reside in profiles//libraries, sites/all/libraries or sites//libraries, with files taking precedence as you move through that list?
Only question would be in what cases might having the library in sites/all be an issue? Most players come in only one version?
I suppose if you were hosting multiple sites and some had customised players, or versions that excluded particular branding, then that might happen.
As Libraries API is only at alpha, and for many they will never need this, I'm not sure about making it a necessary dependency since for many (most?) users sites/all will be fine, but I'm happy to accommodate an either/or scenario. I,e, "out the box" you use sites/all, if you want more power you add on libraries API and SWF Tools reacts accordingly.
Does that sound reasonable?
#15
SWF Tools now implements Libraries API, so you can place support files in any of the three locations.
LIbraries API is not a dependency - if you don't need this functionality don't bother with Libraries API, just put the support files under sites/all/libraries as before.
If you need site specific versions of the libraries then install Libraries API and SWF Tools will automatically use it to locate the "most appropriate" library.
#16
What to do with JW player 5? Why not the same naming as the module folders?
#17
#18
JW5 can go in the same folder as JW4 - the existing SWF Tools module will use it and work with no problem as the key features are all the same.
The library names don't follow the module name as the libraries describe the media players NOT the modules that refer to them. The purpose of the library is to provide a common place to put files that all modules can access.
#19
This doesn't seem to support placing libraries in profiles/[profilename]/libraries.
EDIT, I take it back - with Libraries API installed, it does handle it
#20
#21
I am so glad to find this thread, as I was tearing my hair out trying to figure out where all/libraries was for my site, which is hosted on a multi-site platform .
I installed SWF Tools 6.x-3.0-beta4 and enabled the module and was able to get the generic player to work. I then enabled FlowPlayer 3.
According to the above thread, it seems I need to install Libraries API so I can put the SWF files from flowplayer.org in my site.
So, I installed Libraries API 6.x-1.0-alpha1 and enabled it.
I then tried to follow rickvug's "sites/example.com/libraries" by creating the folders libraries/flowplayer3 and adding the flowplayer file. I now have the path:
/mysite.com/drupal/sites/mysite.com/libraries/flowplayer3/flowplayer-3.2.5.swf .
However, I am still getting the error message: "Download the required supporting file and upload it to sites/all/libraries/flowplayer3/flowplayer-3.2.5.swf".
Did I do something wrong? I have a feeling that there are many of us that have some sort of multi-platform environment who need to figure out how to install the video/audio players.
Thanks!
Andey
#22
OK - answering my own question here:
I had the SWF Tools 6.x-3.0-beta4 April 14th, 2010 version installed. After investigating, it seems that the Library API feature was added after this version.
SO - given the fact that 1) I was working with a SWF Tools Beta version AND 2) I needed to do a version beyond the recommended Beta version AND 3) Library API is an alpha version AND 4) I have no strong PHP skills, I decided that I should just go to SWF Tools 6.x-2.5 version where I can add the SWF files to my "modules" folder.
But - thanks for upgrading this. I would definitely say that, for those using multi-platform Drupal environments, the Libraries API feature will be needed for the new file changes for the SWF files.
Thanks much!
Andey
#23
Since there is no "shared" folder distributed in the beta 4 download, this affects the Reports, SWF Tools Reports, which is looking for swftools_test_file.swf in the shared folder, and so the report seems to have a problem - the test flash does not run on admin/reports/swftools.
It's not in the sites/all/libraries folder either, so I do not what the next step would be.
#24
Is this module deprecated, or will libraries be supported in some future version?