Download the PHP package balbuf/composer-wp without Composer

On this page you can find all versions of the php package balbuf/composer-wp. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

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 PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • 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.
Please rate this library. Is it a good library?

Informations about the package composer-wp

Composer-WP: Composer for WordPress

Composer-WP is a composer plugin that helps manage dependencies for WordPress sites. Composer-WP enables you to handle WordPress core releases, plugins, and themes entirely through composer.

Installation

Composer-WP must be installed globally so that the plugin will be loaded before the project's dependencies are resolved.

As such, it is a good idea to include this as a build step for your project:

Alternatively, you can include this step as a script that composer will execute before installing or updating packages:

About

Similar to wpackagist, Composer-WP leverages the official WordPress SVN repositories to provide plugins and themes as composer packages. However, the packages which Composer-WP provides are "virtual"—Composer-WP creates the packages on-demand by directly referencing the SVN repos to gather a listing of available packages. Because of this, there is no third-party package repository to query and the listing is always up-to-date.

Additionally, virtual packages enable the package properties to be dynamic. This allows you to change the package type simply by adjusting the vendor name, for instance. Each vendor name maps to a package type, and the package type dictates where the package will be installed. For example, you can install a plugin as either "regular" or "must use" (wordpress-plugin or wordpress-muplugin, respectively) just by using the appropriate vendor name.

In addition to the official public WordPress repos, Composer-WP allows you to define your own plugin or theme repos that contain zipped packages. This type of repo can either reference a local directory or a remote directory accessible via SSH. The zipped packages are just the standard plugin or theme zip files that you would upload and install via the WP Admin panel. Composer-WP scans these zips and pulls out meta information from the file headers (e.g. plugin/theme name and version) to create virtual packages for these. This repo type is useful for managing packages that are not publicly listed, such as proprietary or paid plugins/themes.

Features

Built-in support for all official WordPress repositories

Manage proprietary/paid plugins and themes by simply dropping them in a directory

Composer-WP provides a new repo type that can contain standard zipped plugins or themes in a private directory. These zip files are scanned for meta information (e.g. plugin/theme name and version) to create virtual packages—no composer.json file necessary. These zip files can either be stored in a local directory or in a directory on a remote server that is accessible via SSH. This is especially useful for paid plugins or themes that composer cannot download from a public source.

Configurable "virtual vendors" which allow for dynamic package types

For example, you can install a plugin as either "regular" or "must use" just by swapping the vendor name (e.g. wordpress-plugin/my-plugin or wordpress-muplugin/my-plugin). To resolve conflicts with vendors from other repositories, each virtual vendor name can be aliased or disabled entirely via the extra property of your composer.json file.

Load packages automatically with the included mu-plugins autoloader

Any regular plugins installed as "must use" plugins will be automatically loaded in WordPress if the mu-plugins autoloader is enabled (the default setting). These "must use" plugins will be loaded in the order they appear in your composer.json, which allows you to explicitly specify a loading precedence in case certain plugins depend on others. The mu-plugins autoloader will also pull in composer's own autoloader, allowing you to easily make use of any non-WordPress packages within your WordPress project. The mu-plugin autoloader is inspired by and based upon the Bedrock autoloader.

Full text searching on package name and description

For WordPress repositories that have an accompanying API (WordPress.org Plugins and Themes and WordPress.com Themes), package discovery via composer search leverages the full text searching capabilities of the API to match packages based on their name, slug (composer package name), or description, in the same way that you would search these directories directly. For other WordPress repositories, packages are matched by slug or vendor name. Private zip repositories support full text searching based on the name, slug, and description pulled from the plugin or theme header information.

Built-in custom installer which helps you place packages where you need them

Composer supports custom installers that allow you to control where packages are installed to, e.g. plugins and themes go into your wp-content directory. For example, the composer-installers plugin is widely used and handles WordPress themes and plugins (but not core files). An additional installer plugin is not required as the Composer-WP installer handles all WordPress package types and is specifically catered towards WordPress projects.

Access to plugins and themes no longer listed in the WordPress directories

Packages that are no longer available in the public directories are usually still available from the underlying SVN repos. While it is not recommended to rely on these packages, this ensures composer doesn't suddenly fail if a package is removed from the public directory. Instead, composer will install the discontinued package and display an "abandoned" notice to alert you.

New releases are available immediately

Packages are discovered directly from the source, so there is no sync delay or possibility of downtime caused by a third-party mirror. New WordPress core releases, as well as plugin and theme updates, are available the moment they are released.

WordPress.org Plugin and Theme repositories are cached efficiently

The WordPress.org plugin and theme directories are massive, each containing thousands of packages. Composer-WP uses a smart caching technique to obtain incremental updates to the package listing. The first time a repository is used, Composer-WP obtains the entire package listing that exists at that point in time. On subsequent requests for that repository, Composer-WP checks only for new packages and determines a "package delta" with which to update the cached package list. This means dependency resolving is noticably faster than with wpackagist, whose cache is invalidated approximately every hour and requires the entire package listing to be downloaded again.

Package listings are only downloaded when needed

Repositories are auto-loaded as necessary based on the project's composer.json requirements and/or arguments passed to composer via the command line. For example, this means that if your project only requires plugins from the WordPress.org directory, no time is wasted by downloading a list of available themes that you don't care about.

Graceful handling of packages that use non-standard version identifiers

Versioning standards are not enforced for packages in the WordPress plugin repo. Instead of ignoring these packages, Composer-WP will try to normalize the version identifier so that it is parsable by composer. If all else fails, the package is still provided as a generic 'dev' version.

Documentation

Requirements

Basic Usage

First, make sure Composer-WP is installed globally:

Without any additional configuration, packages from the official WordPress directories are ready to be used:

Determining a Package Name

The package names used by Composer-WP are formed using a vendor name specific to the particular repo and the package "slug":

The vendor names and package naming conventions for each built-in WordPress repo can be found below.

Plugins and Themes

For plugins and themes in the WordPress directories, the slug is the sanitized name of the package that appears in its URL.

For example, suppose you want to install the Contact Form 7 plugin: https://wordpress.org/plugins/contact-form-7/. The slug of the plugin would be contact-form-7, and the default vendor name for the WordPress.org Plugin Directory is wordpress-plugin. The full package name would be wordpress-plugin/contact-form-7.

Package Name Bookmarklet

For convenience in determining the proper package name for a plugin or theme, you can add the following JavaScript snippet as a bookmarklet in your browser. If you are on the detail page for a plugin or theme on wordpress.org, theme.wordpress.com, or vip.wordpress.com, this bookmarklet will present you with the package name using the default vendor name for that repo:

WordPress Core

WordPress core releases use wordpress as both the vendor and slug:

Find Packages with Composer Commands

composer search and composer show are useful commands for finding and verifying packages.

You can use composer search to find a package name:

Where possible, Composer-WP uses full text searching to match against names and descriptions.

You can use composer show -a to get more information about a package or simply verify that it exists:

If the package exists, composer will provide additional details such as available versions.

composer.json Example

A simple composer.json file for a WordPress site might look like:

Further Reading

Please refer to the official composer documentation for more information on general usage.

Additional Configuration

Composer-WP has additional configuration options that can be specified in the "composer-wp" section of the "extra" property of your composer.json file. The default settings are configured with a typical WordPress project in mind, so you may not need to alter these options for basic use.

Repositories

The "repositories" property is an array of repository configurations that affect the built-in repos or define new custom repos.

Built-In Repositories

The most simple use for the repositories property is specifying built-in repos to either enable or disable:

This configuration would disable the WordPress.org Themes Directory and enable the WordPress core development repository. The repositories are referenced by their repo names which can be found below. All built-in repos (except for the core development repository) are automatically loaded when packages that they handle are requested via composer.json or command line arguments, so generally, built-in repos do not need to be enabled here. However, you can use this to disable repos that you don't want to use (for instance to speed up certain commands such as composer search). If you wish to use the WordPress core development repo, you must explicitly enable it as shown above. Enabling or disabling built-in repos can also be combined into a single object:

Custom Repositories

You can also define new repositories here:

Composer-WP supports two repository types: wp-zip and wp-svn. Each have their own properties, but share the following:

Properties specific to repo type:

Vendors

The "vendors" property allows you to create vendor aliases and disable existing vendor names. This property is a simple object that maps a new vendor name to an existing name, or maps an existing vendor name to false to disable its use:

The above would configuration would allow plugins to be required as if they came from wpackagist and would replace the default WordPress.com Themes repo vendor name of wordpress-com with wpcom-themes. Note that the original vendor name of wordpress-com will no longer be recognized, but both wpackagist-plugin and wordpress-plugin will be recognized.

Installer

The "installer" property allows you to configure the built-in installer. The installer is designed to play nicely with other custom installers you may be using. That is, if there are no other custom installers, Composer-WP will handle WordPress packages by default. However, if there is another custom installer (such as composer-installers-extender) that is configured to handle WordPress packages, Composer-WP will allow that installer to handle the packages unless explicitly instructed to do so (by specifying install paths).

The built-in installer has the following properties:

The installer can be disabled entirely by setting this property to false:

Built-in WordPress Repositories

Composer-WP has several built-in repositories that are automatically loaded when you request packages from them. Each repo has its own set of vendor names which are used to determine which repos to load for the request packages. The repo name can be used to explicitly enable or disable the given repo via your composer.json file (see below).

WordPress.org Plugins (https://wordpress.org/plugins/)

Plugins developed by the WordPress community.

Details
Repo Name plugins
Vendor Names wordpress-plugin (package type: wordpress-plugin) and wordpress-muplugin (package type: wordpress-muplugin)
Package Names Package names match the slug found in the plugin's URL, e.g. https://wordpress.org/plugins/oomph-clone-widgets/ is oomph-clone-widgets.
Versions Version releases as well as dev-trunk.
SVN Source https://plugins.svn.wordpress.org/
Caching The package listing is cached for as long as composer config cache-ttl if it doesn't change. However, each time the repo is used, a "package delta" is obtained to update this cached list with new package names, so the cache is likely to change regularly.

WordPress.org Themes (https://wordpress.org/themes/)

Themes developed by the WordPress community.

Details
Repo Name themes
Vendor Names wordpress-theme (package type: wordpress-theme)
Package Names Package names match the slug found in the theme's URL, e.g. https://wordpress.org/themes/twentyfourteen/ is twentyfourteen.
Versions Version releases only; no dev-trunk.
SVN Source https://themes.svn.wordpress.org/
Caching The package listing is cached for as long as composer config cache-ttl if it doesn't change. However, each time the repo is used, a "package delta" is obtained to update this cached list with new package names, so the cache is likely to change regularly.

WordPress Core (https://wordpress.org/download/)

WordPress core releases, including major versions and security/bugfix updates.

Details
Repo Name core
Vendor Names wordpress or wordpress-core (package type: wordpress-core)
Package Names wordpress is the only package.
Versions Version releases as well as dev-trunk.
SVN Source https://core.svn.wordpress.org/
Caching This package listing is not cached by default to ensure updates are available immediately.

WordPress.com Themes (https://theme.wordpress.com/)

Free themes that are offered for WordPress.com hosted sites but may also be used on self-hosted sites.

Details
Repo Name wpcom-themes
Vendor Names wordpress-com (package type: wordpress-theme)
Package Names Package names match the slug found in the theme's URL, e.g. https://theme.wordpress.com/themes/balloons/ is balloons.
Versions dev-master only; no individual version releases.
SVN Source https://wpcom-themes.svn.automattic.com/
Caching This package listing is cached for 1 week by default as the list changes infrequently.

WordPress VIP Plugins (https://vip.wordpress.com/plugins/)

Plugins that are sanctioned for use on WordPress VIP hosted sites. Note: These plugins may not work correctly outside of the WordPress VIP environment. See the VIP Quickstart documentation for more information about replicating the WordPress VIP environment.

Details
Repo Name vip-plugins
Vendor Names wordpress-vip (package type: wordpress-plugin)
Package Names Package names generally match the slug found in the plugin's URL, e.g. https://vip.wordpress.com/plugins/ooyala/ is ooyala. WordPress VIP also has a "release candidate" process to evaluate plugins before they are officially released. These package names are appended with -rc.
Versions dev-master only; no individual version releases.
SVN Source https://vip-svn.wordpress.com/plugins/
Caching This package listing is cached for 1 week by default as the list changes infrequently.

WordPress Core - Development Version (https://develop.svn.wordpress.org/)

The WordPress core development repo stays in sync with the main core repo but also includes the unit test framework and additional tools for internationalization. Note: Unlike the the other built-in repos, the develop repo must be explicitly enabled to use as a dependency, as it shares a vendor namespace with the regular core repo.

Details
Repo Name develop
Vendor Names wordpress or wordpress-core (package type: wordpress-develop)
Package Names develop is the only package.
Versions Version releases as well as dev-trunk.
SVN Source https://develop.svn.wordpress.org/
Caching This package listing is not cached by default to ensure updates are available immediately.

All versions of composer-wp with dependencies

PHP Build Version
Package Version
Requires php Version >=5.4
composer-plugin-api Version ^1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package balbuf/composer-wp contains the following files

Loading the files please wait ....