Download the PHP package wpsmith/plugin without Composer

On this page you can find all versions of the php package wpsmith/plugin. 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 plugin

Plugin

Code Climate

A class to use in your WordPress plugin to prevent updates to the plugin, ensure dependency plugin(s) is/are active, and to hide specific plugin(s).

Description

These classes solve three (3) particular problems:

  1. Preventing plugins from updating

    Plugins and themes are automatically checked by WordPress for updates in the WordPress repository. This poses a special problem for private plugins if the plugin slug happens to match.

  2. Hiding Plugins

    It is a best practice to move specific functionality to a core functionality plugin. One could use a mu-plugin but most use a standard plugin. However, the client could easily deactivate or delete the plugin. Therefore, hiding the plugin from the plugins page becomes very important.

  3. Extending Plugins

    Many core functionality plugins extend/modify other plugins. If the dependency plugin that is being extended is deactivated, then the plugin makes the WordPress instance unstable and breaks the whole site.

  4. Uninstalling Plugins

    It is a best practice to always uninstall your plugin data and files. However, an interface to determine what should be uninstalled needs to be built. This uses WP Pointers to create such an interface giving the user the choice to uninstall just the plugin files or everything.

  5. Building Plugins

    When building a plugin, this library provides a base class to be extended as the new plugins core class.

Installation

This isn't a WordPress plugin on its own, so the usual instructions don't apply. Instead you can install manually or using composer.

Manually install class

Copy Plugin/src folder into your plugin for basic usage. Be sure to require the various files accordingly.

or:

Install class via Composer

  1. Tell Composer to install this class as a dependency: composer require wpsmith/plugin
  2. Recommended: Install the Mozart package: composer require coenjacobs/mozart --dev and configure it.
  3. The class is now renamed to use your own prefix to prevent collisions with other plugins bundling this class.

Implementation & Usage

Update Prevention

To prevent the current plugin from updating:

To prevent another plugin (e.g., ACF) from updating:

Hiding Plugin(s)

To hide the current plugin:

To hide another plugin (e.g., ACF):

Extending Plugin(s)

To extend ACF, you would do something like this:

Uninstalling Plugin(s)

To use the UninstallManager, you would do something like this at the plugin's root:

Simple example

Within the plugin's main file:

A Better Example

Within the main plugin file:

Then in uninstall.php:

Building a Plugin

For all my plugins, I build a base class for the main plugin. Out of the box, PluginBase does three things:

  1. Loads plugin's text domain accordingly.
  2. Implements Singleton so there can only be one.
  3. Provides the following methods:
    • Plugin::doing_ajax() or PluginBase::doing_ajax() - determines whether WP is processing an AJAX request.
    • Plugin::get_version() - gets the plugin's version. Defaults to 0.0.0.
    • Plugin::get_plugin_name() - gets the plugin's name. Defaults to wps.~~~~
    • $this->get_template_loader() - gets the plugin's template loader. See TemplateLoader.
    • $this->add_action() - Either adds the action to the correct hook or performs the action if the hook has already been done or is being done.

Generally speaking, it goes something like this:

Change Log

See the change log.

License

GPL 2.0 or later.

Contributions

Contributions are welcome - fork, fix and send pull requests against the master branch please.

Credits

Built by Travis Smith
Copyright 2013-2020 Travis Smith


All versions of plugin with dependencies

PHP Build Version
Package Version
Requires php Version >=7.4.0
wpsmith/templates Version dev-master
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 wpsmith/plugin contains the following files

Loading the files please wait ....