开发者 | wothke |
---|---|
更新时间 | 2017年1月16日 07:40 |
捐献地址: | 去捐款 |
PHP版本: | 4.1 及以上 |
WordPress版本: | 4.7 |
版权: | GPLv2 or later |
版权网址: | 版权信息 |
/wp-content/plugins/
directory, or install the plugin through the WordPress plugins screen directly.This is the URL to the folder where you are keeping your music files. By default the configured path points to a sample data folder that comes bundled with the plugin. You should define your own folder so that you do not need to put your data into the plugin directory. Note: The folder MUST be located on the same domain as your WordPress site otherwise the user's browser will typically refuse to load the files (see cross domain issues).
First of all, one playlist entry corresponds to one line in the playlist, i.e. a 'carrige return' starts a new entry. In its minimal variant a playlist entry contains the filename of the music file to be played, e.g. "foo.sid". (The referenced file must exist within the configured 'Music folder'.) Entries may then be extended (this is optional) to deal with two *.sid file format specific complications:
The playback time configuration explained above requires that a track number has been configured first, i.e. the track number here cannot be omitted even if the file only has one track. A respective entry to play a song for 5 minutes would look like this: "foo.sid;0;300"
Eventhough the playback starts with the track configured within the playlist, the end user might switch the track (multi-track sid files only) using the controls provided by the widget. To allow for a pleasant end user experience it consequently makes sense to provide playback-times for all the tracks (you can always use 0 for those tracks that you are really not interested in).
The checkbox controls if the music playback is automatically started as soon as the widget instance is shown or if the widget should rather wait for the end user to actually press the 'play' button. By default 'Autoplay' is enabled - such that a newly installed plugin can be tested more easily by first time users. However, end users may find it quite annoying when some web page starts to blare when they don't expect it. Consequently you might want to deactivate this feature when using the widget.
By default the widget shows a frequency spectrum of the played music. In order to use the widget on old / weak devices (if necessary) you might want to disable this feature to reduce CPU load.
Depending on where you use the widget, situations might be constructed where multiple instances are shown on the same web page (e.g. by using the widget in multiple posts and then showing an overview page of all posts, etc). One can imagine unpleasant user experiences where multiple music players are simultaneously starting to play on the same page. But due to the limitations of the current implementation this will not happen: Only one Tiny'R'Sid player can actually be used on one page. If more than one widget exist on a page, then they all use the same player. Since each widget configures the player upon startup, each additional widget will just overwrite the settings that a previous widget may have made, i.e. the last widget on the page wins. In addition the widget's GUI is currently NOT designed to differenciate multiple instances on the same page: The underlying HTML elements use fixed IDs, and duplicates will be introduced with each additional widget (depending on the respective HTML element the effect will be different, e.g. buttons may just work as copies but a graphics canvas will just be drawn in one place and the copy will stay blank, etc). This means that nothing bad will happen, but from the end user perspective the behavior of an affected page would be confusing. A respective scenario should therefore be avoided (e.g. when using the widget within some post you might try to position it such that it is not within the section displayed on an overview page).
Keep in mind that the music playback will stop/restart whenever an affected page is re-loaded. If you intend to just play single songs that may not be an issue. But some longer playlist can only be played to the end if the page that hosts the widget lives long enough (and each reload will restart with the first song in the playlist). Ideally a respective page should be started in a dedicated separate window, such that the browsing activities of the end user do not interfere with the playback. There may be better ways to achieve the effect but a separate/dedicated music player browser window could be realized like this: