zf-apigility-admin 1.5.6

Added

• Nothing.

Deprecated

• Nothing.

Removed

• Nothing.

Fixed

• #361 updates the ModuleModel to vary the contents of a generated module.config.php based on the short-array notation configuration setting.
• This release updates the following dependencies to the listed minimum supported versions:
  • zfcampus/zf-apigility-admin-ui: 1.3.7
  • zfcampus/zf-configuration: 1.2.1

zf-apigility-admin 1.5.5

Added

• #358 adds documentation for the zf-apigility-admin.path_spec configuration value to both the README and the module configuration file.

Deprecated

• Nothing.

Removed

• Nothing.

Fixed

• #360 fixes how the ModuleModel generates configuration, allowing it to generate short array syntax. The behavior is configurable using the zf-configuration.enable_short_array configuration value.

zf-apigility-admin 1.5.4

Added

• Nothing.

Deprecated

• Nothing.

Removed

• Nothing.

Fixed

• #357 fixes an issue with detection of module versions when using Apigility-generated PSR-4 modules.

zf-apigility-admin 1.5.3

Added

• Nothing.

Deprecated

• Nothing.

Removed

• Nothing.

Fixed

• #356 fixes a fatal error when calling the versioning API, due to providing the VersioningController with an incorrect versioning model factory.
• #356 fixes issues when versioning API modules that are in PSR-4 layout. The ModuleModel now autodiscovers which layout (PSR-0 or PSR-4) is used by a given module.

zf-apigility-admin 1.5.2

Added

• Nothing.

Deprecated

• Nothing.

Removed

• Nothing.

Fixed

• #354 updates the upgrade script to add dependencies required by Apigility 1.3 and earlier skeletons. These changes include:
  • adding zendframework/zend-mvc-i18n as a dependency
  • adding the Zend\I18n and Zend\Mvc\I18n modules to config/modules.config.php

zf-apigility-admin 1.5.1

Added

• #353 adds the apigility-version API, to allow reporting to the UI the current Apigility skeleton version. It returns the value of Apigility\VERSION if defined, and @dev if not.

Deprecated

• Nothing.

Removed

• Nothing.

Fixed

• Nothing.

zf-apigility-admin 1.5.0

This release provides a ton of new features, including the ability to use Apigility with v3 releases of Zend Framework components. While particular attention has been paid to the basic upgrading experience to ensure the Admin works with v2 releases, we also have provided documentation and tooling to get you upgraded to v3 releases. Please familiarize yourself with the upgrade notes.

Added

• #348 updates the component to be forwards compatible with Zend Framework component v3 releases, while retaining support for v2 releases. This includes supporting both v2 and v3 versions of factory invocation, and triggering event listeners using syntax that works on both v2 and v3 releases of zend-eventmanager, amonst other changes.

• #348 adds a script to assist users in updating existing Apigility applications to use Zend Framework component v3 releases:

  $ ./vendor/bin/apigility-upgrade-to-1.5 -h

  In most cases, you can call it without arguments. Running the script updates your composer.json to remove several entries, update others, and add some; it then updates your list of modules, and then installs dependencies for you.

  If you need to update manually for any reason, you will need to follow the steps in the README.

• #321 adds a patchList() stub to the REST resource class template, so that it's present by default.

• #327 adds support for working with modules that are in PSR-4 directory format. While the admin still does not create PSR-4 modules, it will now correctly interact with those that you manually convert to PSR-4.

• #348 extracts listeners previously defined in the Module class into their own classes. These include:

  • ZF\Apigility\Admin\DisableHttpCacheListener, which listens on the MvcEvent::EVENT_FINISH event at high priority in order to return cache busting headers in the returned response.
  • ZF\Apigility\Admin\EnableHalRenderCollectionsListener, which listens on the MvcEvent::EVENT_ROUTE event at low priority in order to set the "render collections" flag on zf-hal's Hal plugin if a controller from the module is matched.
  • ZF\Apigility\Admin\InjectModuleResourceLinksListener, which listens on the MvcEvent::EVENT_RENDER event at high priority in order to attach listeners to events on the zf-hal Hal plugin. These listeners were also previously defined in the Module class, and are now part of this new listener, as it aggregates some state used by each.
  • ZF\Apigility\Admin\NormalizeMatchedControllerServiceNameListener, which listens on the MvcEvent::EVENT_ROUTE at low priority in order to normalize the controller service name provided via the URI to a FQCN.
  • ZF\Apigility\Admin\NormalizeMatchedInputFilterNameListener, which listens on the MvcEvent::EVENT_ROUTE at low priority in order to normalize the input filter name provided via the URI to a FQCN.

• #348 extracts service factories previously defined in the Module class into their own classes. These include:

  • ZF\Apigility\Admin\Model\AuthenticationModelFactory
  • ZF\Apigility\Admin\Model\AuthorizationModelFactory
  • ZF\Apigility\Admin\Model\ContentNegotiationModelFactory
  • ZF\Apigility\Admin\Model\ContentNegotiationResourceFactory
  • ZF\Apigility\Admin\Model\DbAdapterModelFactory
  • ZF\Apigility\Admin\Model\DbAdapterResourceFactory
  • ZF\Apigility\Admin\Model\DbAutodiscoveryModelFactory
  • ZF\Apigility\Admin\Model\DoctrineAdapterModelFactory
  • ZF\Apigility\Admin\Model\DoctrineAdapterResourceFactory
  • ZF\Apigility\Admin\Model\DocumentationModelFactory
  • ZF\Apigility\Admin\Model\FiltersModelFactory
  • ZF\Apigility\Admin\Model\InputFilterModelFactory
  • ZF\Apigility\Admin\Model\ModuleModelFactory
  • ZF\Apigility\Admin\Model\ModulePathSpecFactory
  • ZF\Apigility\Admin\Model\ModuleResourceFactory
  • ZF\Apigility\Admin\Model\ModuleVersioningModelFactory
  • ZF\Apigility\Admin\Model\ModuleVersioningModelFactoryFactory
  • ZF\Apigility\Admin\Model\RestServiceModelFactory
  • ZF\Apigility\Admin\Model\RestServiceModelFactoryFactory
  • ZF\Apigility\Admin\Model\RestServiceResourceFactory
  • ZF\Apigility\Admin\Model\RpcServiceModelFactoryFactory
  • ZF\Apigility\Admin\Model\RpcServiceResourceFactory
  • ZF\Apigility\Admin\Model\ValidatorMetadataModelFactory
  • ZF\Apigility\Admin\Model\ValidatorsModelFactory
  • ZF\Apigility\Admin\Model\VersioningModelFactory
  • ZF\Apigility\Admin\Model\VersioningModelFactoryFactory

• #348 extracts controller factories previously defined in the Module class into their own classes, and updates several factories that already existed. Factories that existed were updated to follow both the zend-servicemanager v2 and v3 signatures, to allow compatibility with both versions; as such, if you were extending these previously, you may potentially experience breakage due to signatures. The new classes include:

  • ZF\Apigility\Admin\Controller\AuthenticationControllerFactory
  • ZF\Apigility\Admin\Controller\AuthenticationTypeControllerFactory
  • ZF\Apigility\Admin\Controller\AuthorizationControllerFactory
  • ZF\Apigility\Admin\Controller\ConfigControllerFactory
  • ZF\Apigility\Admin\Controller\DashboardControllerFactory
  • ZF\Apigility\Admin\Controller\DbAutodiscoveryControllerFactory
  • ZF\Apigility\Admin\Controller\DocumentationControllerFactory
  • ZF\Apigility\Admin\Controller\FiltersControllerFactory
  • ZF\Apigility\Admin\Controller\HydratorsControllerFactory
  • ZF\Apigility\Admin\Controller\InputFilterControllerFactory
  • ZF\Apigility\Admin\Controller\ModuleConfigControllerFactory
  • ZF\Apigility\Admin\Controller\ModuleCreationControllerFactory
  • ZF\Apigility\Admin\Controller\SourceControllerFactory
  • ZF\Apigility\Admin\Controller\StrategyControllerFactory
  • ZF\Apigility\Admin\Controller\ValidatorsControllerFactory
  • ZF\Apigility\Admin\Controller\VersioningControllerFactory

• #348 exposes the module to zend-component-installer.

Deprecated

• ZF\Apigility\Model\VersioningModel; please use ZF\Apigility\Model\ModuleVersioningModel instead.
• ZF\Apigility\Model\VersioningModelFactory; please use ZF\Apigility\Model\ModuleVersioningModelFactory instead.
• ZF\Apigility\Model\VersioningModelFactoryFactory; please use ZF\Apigility\Model\ModuleVersioningModelFactoryFactory instead.

Removed

• #348 removes support for PHP 5.5.
• #348 removes the dependency on rwoverdijk/assetmanager, allowing usage of any tool that understands the same configuration (and, specifically, the asset_manager.resolver_configs.paths configuration directive). However, this means that for those upgrading via simple composer update, you will also need to execute composer require rwoverdijk/assetmanager immediately for your application to continue to work.

Fixed

• #348 updates ZF\Apigility\Admin\Controller\StrategyController to accept a ContainerInterface to its constructor, instead of relying on auto-injection of a zend-servicemanager instance via an initializer; this change removes deprecation notices from its usage of getServiceLocator() (it no longer calls that method), and documents the dependency explicitly. If you were extending this class previously, you may need to update your factory.
• #348 updates ZF\Apigility\Admin\Model\DoctrineAdapterResource's contructor to make the second argument, $loadedModules, optional. If you were extending the class previously, you may need to update your signature.

zf-apigility-admin 1.4.3

Added

• Nothing.

Deprecated

• Nothing.

Removed

• Nothing.

Fixed

• #350 updates the Module class to pull entities composed in ZF\Hal\Entity instances via the getEntity() method of that class, if it exists (introduced in zf-hal 1.4). This change prevents zf-hal 1.4+ versions from emitting deprecation notices, and thus breaking usage of the admin API.

ServiceLocatorAware drop

DB Autodiscovery is no longer ServiceLocatorAware

Apigility Version 1.0.0beta1

Apigility 1.0.0beta1

This is the first beta release for Apigility. From this point forward, we will be keeping backwards compatibility between versions. New features will be targetted for version 1.1.0, with bugfixes and security fixes targetted for the upcoming stable release and any subsequent maintenance releases.

New Features

All Apigility modules were updated to use a PSR-4 structure and autoloader. This flattens the packages significantly, and also allows simplification of the PHPUnit test runner. A PSR-4 variant of the ZF2 StandardAutoloader, ZF\Apigility\Autoloader, was created to provide true PSR-4 autoloading, including the ability to have underscores (_) in class names, which has been a common feature request. ZF2 Module classes created for new API modules now use the new autoloader for loading classes inside the module.

All modules were added to Travis-CI, giving us continuous integration going forward.

With the release of Zend Framework 2.3.0, we were able to update the ZF2 dependency to remove the -dev stability marker; this also means that packages should start to be smaller, as we'll be able to use distribution versions of ZF2 going forward instead of git clones.

Additionally, the following features were added:

• zfcampus/zf-content-validation#8 adds the ability to provide HTTP method-specific input filters. This feature is not yet integrated into the Apigility Admin UI, but can be configured manually. To do so, add method/input filter service name pairs for the given controller service name; if no method-specific input filter exists, zf-content-validation will fallback to the input_filter key, if defined. As an example:

    'zf-content-validation' => array(
        'Example\V1\Rest\Status\Controller' => array(
            // This is the fallback input filter, and the one the UI
            // can define and manipulate:
            'input_filter' => 'Example\V1\Rest\Status\Validator',
            // This one will be used on POST requests only:
            'POST' => 'Example\V1\Rest\Status\NewStatusValidator',
        ),
    ),

• zfcampus/zf-mvc-auth#20 provides a patch that injects the MvcEvent with a new key, ZF\MvcAuth\Identity. You can pull the discovered identity from this event parameter now. Additionally, in REST resources, calling $this->getIdentity() will retrieve the identity.
• zfcampus/zf-apigility-admin#124 and zfcampus/zf-apigility-admin#129 provide initial input filters for all Apigility Admin API services, as well as UI integration for reporting errors. All validation errors are caught and reported in a single dialog within the form that raises them.
• The "edit settings" screen for REST services now allows editing the entity class and collection class names.
• The "API Overview" page now links services to their overviews. The service description is displayed beneath each service; if not yet defined, a link to the "edit documentation" tab for the service is provided.
• A new modal will be displayed to users of the Apigility Admin UI if the API detects that the filesystem is not writable. The modal details what changes need to be made in order for the UI and API to work correctly.
• zfcampus/zf-oauth2#30 splits out initialization of the oauth2-server-php server from the zf-oauth2 controller, allowing the ability to replace it, write a delegator for it, etc.

Breaking Changes

• zfcampus/zf-content-validation#10 changes the key used by the InputFilterAbstractServiceFactory from input_filters to input_filter_specs. This is due to the fact that ZF 2.3.0 introduces an InputFilterManager, which is already consuming the key input_filters. Wrapped in this change is the fact that the InputFilterAbstractServiceFactory is now registered as an abstract service factory with the InputFilterManager, instead of with the application service manager instance.

  For those updating their Apigility libraries to 1.0.0beta1, edit your module.config.php files to rename the input_filters key to input_filter_specs.

• The zf-configuration controller ZF\Configuration\Controller was moved into zf-apigility-admin. This URI for the service remains the same, but the controller itself has moved. (This change was done to consolidate all Admin API controllers in the same module, as well as to reduce the dependencies needed in the zf-configuration component.)

Fixes

• zfcampus/zf-apigility-admin#115 - Ensures that non-SQLite PDO OAuth2 adapters may be provided without error.

• zfcampus/zf-apigility-admin#117 - Ensure that the route_match is passed to the API when saving an RPC service.

• zfcampus/zf-apigility-admin#118 - Ensure that the Content Negotiation selector is passed to the API correctly when saving an RPC service.

• zfcampus/zf-apigility-admin#120 - Remove duplicate call to initialize the ServerUrl helper.

• zfcampus/zf-apigility-admin#122 and zfcampus/zf-apigility-admin#123 - Add checks for array keys before accessing them when building the documentation graph for a given service operation.

• zfcampus/zf-apigility-admin#126 - Updates the admin to pass the X-UA-Compatible meta tag in order to provide Internet Explorer compatibility.

• zfcampus/zf-apigility-admin#132 - Ensures that authorization data is fetched each time a new service is created, a service is updated, or a service is deleted, ensuring the table reflects the current list of available services and HTTP methods.

• zfcampus/zf-apigility-admin#133 - Updates the "angular-flash" functionality to anchor flash messages to the bottom of the window. Additionally, any error flash messages now have a "close" button, requiring user intervention for dismissal.

• Many fixes were made to the UI to improve performance, remove UI refresh errors, provide more consistent color schemes, ensure tabs stay focussed between state transitions, etc.

• The Apigility Admin API was updated to break the authentication service into more granular sub-services, one for each type of authentication supported. This simplifies validation, and allows for future expansion.

• Work was done to ensure opcode cache detection is as solid as possible. We now properly distinguish between APC and APCu, allowing the latter to be enabled when using the Admin API.

• zf-apigility-documentation was not correctly aggregating RPC documentation; this has been fixed.

• We reviewed the various events triggered to ensure that they were happening in the correct order, which we defined as:

  • Authentication
  • HTTP method negotiation (is the method called allowed for the service?)
  • Authorization (is the discovered identity allowed to perform the requested
    action?)
  • Content Negotiation (determine incoming Content-Type and marshal data from
    request body; determine if Accept and/or Content-Type are valid for the
    request)
  • Content Validation

  Several event listener priorities were updated to fit the above requirements. A new listener, ZF\Rest\Listener\OptionsListener, was introduced to handle HTTP method negotiation for REST services, and is registered at the same priority as the RPC OptionsListener (which previously existed).

• zf-configuration was updated to never write configuration using short-array notation; this was done to ensure compatibility of generated configuration with PHP 5.3 (as developers may use the admin API via 5.4, but deploy to 5.3).