Download the PHP package brightnucleus/dependencies without Composer
On this page you can find all versions of the php package brightnucleus/dependencies. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download brightnucleus/dependencies
More information about brightnucleus/dependencies
Files in brightnucleus/dependencies
Package dependencies
Short Description Config-driven WordPress dependencies.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package dependencies
Bright Nucleus Dependencies Component
This is a WordPress dependencies component that lets you define dependencies through a config file. The dependencies you define in this way will then get registered and enqueued automatically.
Table Of Contents
- Installation
- Basic Usage
- Configuration File
- Initialization
- Advanced Features
- Conditional Registration
- Localized Data
- Inline Scripts
- Custom Context Data
- Manual Enqueueing
- Contributing
- License
Installation
The best way to use this component is through Composer:
Basic Usage
Configuration File
To use the DependencyManager, you first need to create a config file ( see brightnucleus/config ), in which you define your dependencies. At the root level of the config that is passed into the DependencyManager's constructor, you'll have one key for each type of dependency, and a handlers key that defines the class that handles that specific type of dependency. As an example, here is the setup that the DependencyManager has out-of-the-box support for:
You can define arbitrary types of dependencies, as long as you also provide the corresponding class that implements the DependencyHandlerInterface for that dependency type.
The arguments you need to provide for each dependency depend on the implementation of the class that implements the DependencyHandlerInterface, with one important requirement: Each dependency needs a handle key to uniquely identify it.
For the two dependency handlers that are provided out-of-the-box, the arguments are passed through to the corresponding wp_register_* and wp_enqueue_* functions, so they accept the same arguments as these functions.
Scripts
-
handle: (string) (required) Unique name of the script. -
src: (string) (required) URL to the script resource. -
deps: (array) (optional) Array of the handles of all the registered scripts that this script depends on.Default:
array() -
ver: (string) (optional) String specifying the script version number. If false, WordPress version gets used.Default:
false -
__
in_footer__: (boolean) (optional) Whether to enqueue the script into the bottom section of the<body>section or not. If not, it gets enqueued into the<head>.Default:
false
Styles
-
handle: (string) (required) Unique name of the stylesheet. -
src: (string) (required) URL to the stylesheet resource. -
deps: (array) (optional) Array of the handles of all the registered stylesheets that this stylesheet depends on.Default:
array() -
ver: (string) (optional) String specifying the stylesheet version number. If false, WordPress version gets used.Default:
false -
media: (boolean) (optional) String specifying the media for which this stylesheet has been defined.Default:
'all'
Initialization
Initializing the DependencyManager and hooking it up to WordPress is straight-forward. DependencyManager's constructor takes a ConfigInterface implementation to do its work. In the following example, we are using the standard Config implementation and its ConfigTrait companion that come with the brightnucleus/config package.
You can then hook the DependencyManager::register() method to a WordPress action so that it is executed at the right moment.
Advanced Features
Conditional Registration
For each dependency, you can add an is_needed key that will be checked to decide whether the dependency should be loaded or not. is_needed can be any expression that gets evaluated as a boolean, or a closure ( callable ).
If is_needed contains a closure, the closure will be executed and gets an argument $context that it can use to make an informed decision. The code that calls the initial DependencyManager::register() can pass any useful value into $context and can thus communicate with these is_needed closures.
Example of an is_needed key in a config:
Localized Data
If you need to pass data from your PHP code to your JavaScript dependency, you can do this by adding a 'localize' key to the script configuration.
Example of passing dynamic PHP data to a JavaScript dependency:
When your bn-example-script.js file executes, it will have access to a global BNExampleData object to retrieve its data from. So, for example, console.log( BNExampleData.ajaxurl ); would print the AJAX URL for the current site to the console.
Inline Scripts
If you need to add inline scripts to your JavaScript dependency, you can do this by adding a 'add_inline' key to the script configuration.
Example of adding an inline script to a JavaScript dependency:
When your bn-example-script.js file executes, it will immediately be followed by the inline script snippet you provided.
Custom Context Data
Custom data can be passed through the DependencyManager using the $context argument. This can be used in your is_needed closures to control registeration and enqueueing.
If you call the DependencyManager::register() method directly, you can just add the $context argument to that call.
If you want to hook the register() method up to a WordPress action, however, you need to do this indirectly, like in the following example:
Manual Enqueueing
Default behavior of the DependencyManager is to automatically enqueue all of the dependencies once you've registered them. In some cases, you might want to override this and take care of the enqueueing yourself.
To override the default behavior, you need to set the second argument $enqueue to the DependencyManager constructor to false.
You can then enqueue individual dependencies by their handle by using the DependencyManager::enqueue_handle() method:
As with the register() method, you can pass in a $context that can be checked in the is_needed closure.
If you set the third argument $fallback to true, any $handle that has not been found in the collection of dependencies registered through DependencyManager will also be searched in the dependencies registered outside of DependencyManager. This is a convenient way to enqueue dependencies that come built-in with a WordPress install.
Contributing
All feedback / bug reports / pull requests are welcome.
License
This code is released under the MIT license.
For the full copyright and license information, please view the LICENSE file distributed with this source code.
All versions of dependencies with dependencies
brightnucleus/exceptions Version >=0.2
brightnucleus/invoker Version >=0.1
brightnucleus/contracts Version >=0.1