Files should be loaded on user click. Huge amount of data is loaded on page load, especially if many audio instances are on page. This is temporary solution. Ultimately widget should support params to match html5 audio/video tags.
Lots of complicated stuff going on here, all elements are getting wiped out when a record is updated and the control is getting disposed at the same time. We've created a dedicated variable to store the datalocker name as a string, this represents a small memory leak but a necessary one it seems.
Fixes#2798
This is useful when you need to "boot" or "register" certain areas of the plugin itself, eg:
$plugin = $this->getPluginObject();
$plugin->registerSubscriptionEvents();
Calling boot() or register() may work too but not always, sometimes there can be things you don't want registered. Hence why it doesn't occur automatically.
There have been some small internal API changes that have been causing grief for some users. While all updates are technically "safe", user workarounds and custom implementations can never be predicted with certainty. This change will allow us to say with confidence, either
- Yep, no worries this is a safe update. Relax. Versus;
- Might want to watch this one, just in case.
- System dashboard now lists missing dependencies
- Installing a plugin with missing dependencies will also attempt to install those dependencies at the same time
Fixes#36
This should be considered experimental at this stage, however this component is used in every October website we've built thus far, it makes sense for it to be included in the core. Once tested we will look at documenting it with an accompanying screencast video.
This allows request elements external to the form to serialize a target form for use. An example might be a search form at the top of a page, list of results in the middle, then the pagination at the bottom. The pagination would need to target the search form with data-request-form to persist the search query value.
This should work with the JS API too, passed as an object, because $($()) is acceptable in jQuery
See #2749, #2750 & #2751 on notes for how to better handle this. Put simply, the control of disabled VS previewMode should be given to the individual form widget, as opposed to the spawning parent.
Adds support for the `disabled` property to FormWidgets so that they will match the behaviour present in regular FormFields. Fixes#2724 and a personal annoyance of mine :)
