Repository: zfcampus/zf-apigility-skeleton Branch: master Commit: fd7fc27169e3 Files: 40 Total size: 49.7 KB Directory structure: gitextract_1rl9e0ja/ ├── .dockerignore ├── .gitignore ├── CHANGELOG.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── Dockerfile ├── LICENSE.md ├── README.md ├── SUPPORT.md ├── Vagrantfile ├── composer.json ├── config/ │ ├── application.config.php │ ├── autoload/ │ │ ├── .gitignore │ │ ├── README.md │ │ ├── global-development.php │ │ ├── global.php │ │ ├── local.php.dist │ │ ├── user.global.php │ │ ├── zf-mvc-auth-oauth2-override.global.php │ │ └── zfconfig.global.php │ ├── development.config.php.dist │ └── modules.config.php ├── data/ │ └── cache/ │ └── .gitkeep ├── docker-compose.yml ├── module/ │ └── Application/ │ ├── config/ │ │ └── module.config.php │ ├── src/ │ │ ├── Controller/ │ │ │ └── IndexController.php │ │ └── Module.php │ ├── test/ │ │ └── Controller/ │ │ ├── IndexControllerTest.php │ │ └── ZZIndexControllerDevModeTest.php │ └── view/ │ ├── application/ │ │ └── index/ │ │ └── index.phtml │ ├── error/ │ │ ├── 404.phtml │ │ └── index.phtml │ └── layout/ │ └── layout.phtml ├── phpcs.xml ├── phpunit.xml.dist ├── public/ │ ├── .gitignore │ ├── .htaccess │ ├── index.php │ └── web.config └── src/ └── Apigility/ └── constants.php ================================================ FILE CONTENTS ================================================ ================================================ FILE: .dockerignore ================================================ nbproject ._* .~lock.* .buildpath .DS_Store .idea .project .settings vendor/ public/vendor/ config/development.config.php config/autoload/local.php config/autoload/*.local.php !public/vendor/README.md data/cache/* !data/cache/.gitkeep ================================================ FILE: .gitignore ================================================ .vagrant/ vendor/ config/development.config.php data/cache/* !data/cache/.gitkeep phpunit.xml ================================================ FILE: CHANGELOG.md ================================================ # Changelog All notable changes to this project will be documented in this file, in reverse chronological order by release. ## 1.5.3 - TBD ### Added - Nothing. ### Changed - Nothing. ### Deprecated - Nothing. ### Removed - Nothing. ### Fixed - Nothing. ## 1.5.2 - 2019-01-09 ### Added - Nothing. ### Changed - Nothing. ### Deprecated - Nothing. ### Removed - Nothing. ### Fixed - [#168](https://github.com/zfcampus/zf-apigility-skeleton/pull/168) fixes file permissions of the `/var/www` folder when using Vagrant, setting them to the `www-data` user. ## 1.5.1 - 2018-08-15 ### Added - Nothing. ### Changed - Nothing. ### Deprecated - Nothing. ### Removed - Nothing. ### Fixed - [#165](https://github.com/zfcampus/zf-apigility-skeleton/pull/165) updates the `composer.lock` by running `composer install` using a PHP 5.6 release. This was done as the 1.5.0 release was made using a PHP 7.1+ binary, and thus installed versions of dependencies that were compatible with those release - but not with 5.6. Once a release is made with this patch, users on PHP 5.6 will be able to install the skeleton again. However, this means that PHP 7.1+ users will need to execute the following after an initial skeleton install in order to get newer versions of libraries compatible with 7.1: ```bash $ rm -Rf composer.lock vendor $ composer install ``` ## 1.5.0 - 2018-05-08 ### Added - [#159](https://github.com/zfcampus/zf-apigility-skeleton/pull/159) adds a development requirement on zendframework/zend-test, ensuring users have the ability to run existing unit tests, as well as write and execute new ones out of the box. ### Changed - [#164](https://github.com/zfcampus/zf-apigility-skeleton/pull/164) updates all dependencies to versions that will work with PHP 7.2, where possible. - [#154](https://github.com/zfcampus/zf-apigility-skeleton/pull/154) modifies the `config/autoload/.gitignore` rules to omit `*.local-development.php` files. ### Deprecated - Nothing. ### Removed - Nothing. ### Fixed - Nothing. ================================================ FILE: CODE_OF_CONDUCT.md ================================================ # Contributor Code of Conduct This project adheres to [The Code Manifesto](http://codemanifesto.com) as its guidelines for contributor interactions. ## The Code Manifesto We want to work in an ecosystem that empowers developers to reach their potential — one that encourages growth and effective collaboration. A space that is safe for all. A space such as this benefits everyone that participates in it. It encourages new developers to enter our field. It is through discussion and collaboration that we grow, and through growth that we improve. In the effort to create such a place, we hold to these values: 1. **Discrimination limits us.** This includes discrimination on the basis of race, gender, sexual orientation, gender identity, age, nationality, technology and any other arbitrary exclusion of a group of people. 2. **Boundaries honor us.** Your comfort levels are not everyone’s comfort levels. Remember that, and if brought to your attention, heed it. 3. **We are our biggest assets.** None of us were born masters of our trade. Each of us has been helped along the way. Return that favor, when and where you can. 4. **We are resources for the future.** As an extension of #3, share what you know. Make yourself a resource to help those that come after you. 5. **Respect defines us.** Treat others as you wish to be treated. Make your discussions, criticisms and debates from a position of respectfulness. Ask yourself, is it true? Is it necessary? Is it constructive? Anything less is unacceptable. 6. **Reactions require grace.** Angry responses are valid, but abusive language and vindictive actions are toxic. When something happens that offends you, handle it assertively, but be respectful. Escalate reasonably, and try to allow the offender an opportunity to explain themselves, and possibly correct the issue. 7. **Opinions are just that: opinions.** Each and every one of us, due to our background and upbringing, have varying opinions. The fact of the matter, is that is perfectly acceptable. Remember this: if you respect your own opinions, you should respect the opinions of others. 8. **To err is human.** You might not intend it, but mistakes do happen and contribute to build experience. Tolerate honest mistakes, and don't hesitate to apologize if you make one yourself. ================================================ FILE: CONTRIBUTING.md ================================================ # CONTRIBUTING ## RESOURCES If you wish to contribute to this project, please be sure to read/subscribe to the following resources: - [Coding Standards](https://github.com/zendframework/zend-coding-standard) - [Forums](https://discourse.zendframework.com/c/contributors) - [Chat](https://zendframework-slack.herokuapp.com) - [Code of Conduct](CODE_OF_CONDUCT.md) If you are working on new features or refactoring [create a proposal](https://github.com/zfcampus/zf-api-problem/issues/new). ## RUNNING TESTS To run tests: - Clone the repository: ```console $ git clone git://github.com/zfcampus/zf-api-problem.git $ cd zf-api-problem ``` - Install dependencies via composer: ```console $ composer install ``` If you don't have `composer` installed, please download it from https://getcomposer.org/download/ - Make sure that `zendframework/zend-test` is installed: ```console $ composer require --dev zendframework/zend-test ``` - Run the tests using the "test" command shipped in the `composer.json`: ```console $ composer test ``` You can turn on conditional tests with the `phpunit.xml` file. To do so: - Copy `phpunit.xml.dist` file to `phpunit.xml` - Edit `phpunit.xml` to enable any specific functionality you want to test, as well as to provide test values to utilize. ## Running Coding Standards Checks First, ensure you've installed dependencies via composer, per the previous section on running tests. Make sure that `squizlabs/php_codesniffer` is installed: ```console $ composer require --dev squizlabs/php_codesniffer ``` To run CS checks only: ```console $ composer cs-check ``` To attempt to automatically fix common CS issues: ```console $ composer cs-fix ``` If the above fixes any CS issues, please re-run the tests to ensure they pass, and make sure you add and commit the changes after verification. ## Recommended Workflow for Contributions Your first step is to establish a public repository from which we can pull your work into the master repository. We recommend using [GitHub](https://github.com), as that is where the component is already hosted. 1. Setup a [GitHub account](https://github.com/), if you haven't yet 2. Fork the repository (https://github.com/zfcampus/zf-api-problem) 3. Clone the canonical repository locally and enter it. ```console $ git clone git://github.com/zfcampus/zf-api-problem.git $ cd zf-api-problem ``` 4. Add a remote to your fork; substitute your GitHub username in the command below. ```console $ git remote add {username} git@github.com:{username}/zf-api-problem.git $ git fetch {username} ``` ### Keeping Up-to-Date Periodically, you should update your fork or personal repository to match the canonical ZF repository. Assuming you have setup your local repository per the instructions above, you can do the following: ```console $ git checkout master $ git fetch origin $ git rebase origin/master # OPTIONALLY, to keep your remote up-to-date - $ git push {username} master:master ``` If you're tracking other branches -- for example, the "develop" branch, where new feature development occurs -- you'll want to do the same operations for that branch; simply substitute "develop" for "master". ### Working on a patch We recommend you do each new feature or bugfix in a new branch. This simplifies the task of code review as well as the task of merging your changes into the canonical repository. A typical workflow will then consist of the following: 1. Create a new local branch based off either your master or develop branch. 2. Switch to your new local branch. (This step can be combined with the previous step with the use of `git checkout -b`.) 3. Do some work, commit, repeat as necessary. 4. Push the local branch to your remote repository. 5. Send a pull request. The mechanics of this process are actually quite trivial. Below, we will create a branch for fixing an issue in the tracker. ```console $ git checkout -b hotfix/9295 Switched to a new branch 'hotfix/9295' ``` ... do some work ... ```console $ git commit ``` ... write your log message ... ```console $ git push {username} hotfix/9295:hotfix/9295 Counting objects: 38, done. Delta compression using up to 2 threads. Compression objects: 100% (18/18), done. Writing objects: 100% (20/20), 8.19KiB, done. Total 20 (delta 12), reused 0 (delta 0) To ssh://git@github.com/{username}/zf-api-problem.git b5583aa..4f51698 HEAD -> master ``` To send a pull request, you have two options. If using GitHub, you can do the pull request from there. Navigate to your repository, select the branch you just created, and then select the "Pull Request" button in the upper right. Select the user/organization "zfcampus" (or whatever the upstream organization is) as the recipient. #### What branch to issue the pull request against? Which branch should you issue a pull request against? - For fixes against the stable release, issue the pull request against the "master" branch. - For new features, or fixes that introduce new elements to the public API (such as new public methods or properties), issue the pull request against the "develop" branch. ### Branch Cleanup As you might imagine, if you are a frequent contributor, you'll start to get a ton of branches both locally and on your remote. Once you know that your changes have been accepted to the master repository, we suggest doing some cleanup of these branches. - Local branch cleanup ```console $ git branch -d ``` - Remote branch removal ```console $ git push {username} : ``` ================================================ FILE: Dockerfile ================================================ # # Use this dockerfile to run apigility. # # Start the server using docker-compose: # # docker-compose build # docker-compose up # # You can install dependencies via the container: # # docker-compose run apigility composer install # # You can manipulate dev mode from the container: # # docker-compose run apigility composer development-enable # docker-compose run apigility composer development-disable # docker-compose run apigility composer development-status # # OR use plain old docker # # docker build -f Dockerfile-dev -t apigility . # docker run -it -p "8080:80" -v $PWD:/var/www apigility # FROM php:7.2-apache RUN apt-get update \ && apt-get install -y git zlib1g-dev \ && docker-php-ext-install zip \ && a2enmod rewrite \ && sed -i 's!/var/www/html!/var/www/public!g' /etc/apache2/sites-available/000-default.conf \ && mv /var/www/html /var/www/public \ && curl -sS https://getcomposer.org/installer \ | php -- --install-dir=/usr/local/bin --filename=composer \ && echo "AllowEncodedSlashes On" >> /etc/apache2/apache2.conf WORKDIR /var/www ================================================ FILE: LICENSE.md ================================================ Copyright (c) 2013-2018, Zend Technologies USA, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Zend Technologies USA, Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ================================================ FILE: README.md ================================================ Apigility Skeleton Application ============================== > ## Repository abandoned 2019-12-31 > > This repository has moved to [laminas-api-tools/api-tools-skeleton](https://github.com/laminas-api-tools/api-tools-skeleton). Requirements ------------ Please see the [composer.json](composer.json) file. Installation ------------ ### Via release tarball Grab the latest release via the [Apigility website](http://apigility.org/) and/or the [releases page](https://github.com/zfcampus/zf-apigility-skeleton/releases); each release has distribution tarballs and zipballs available. Untar it: ```bash $ tar xzf zf-apigility-skeleton-{version}.tgz ``` (Where `{version}` is the version you downloaded.) Or unzip, if you chose the zipball: ```bash $ unzip zf-apigility-skeleton-{version}.zip ``` (Where `{version}` is the version you downloaded.) ### Via Composer (create-project) You can use the `create-project` command from [Composer](http://getcomposer.org/) to create the project in one go (you need to install [composer](https://getcomposer.org/doc/00-intro.md#downloading-the-composer-executable)): ```bash $ curl -s https://getcomposer.org/installer | php -- --filename=composer $ composer create-project -sdev zfcampus/zf-apigility-skeleton path/to/install ``` ### Via Git (clone) First, clone the repository: ```bash # git clone https://github.com/zfcampus/zf-apigility-skeleton.git # optionally, specify the directory in which to clone $ cd path/to/install ``` At this point, you need to use [Composer](https://getcomposer.org/) to install dependencies. Assuming you already have Composer: ```bash $ composer install ``` ### All methods Once you have the basic installation, you need to put it in development mode: ```bash $ cd path/to/install $ composer development-enable ``` Now, fire it up! Do one of the following: - Create a vhost in your web server that points the DocumentRoot to the `public/` directory of the project - Fire up the built-in web server in PHP(**note**: do not use this for production!) In the latter case, do the following: ```bash $ cd path/to/install $ php -S 0.0.0.0:8080 -ddisplay_errors=0 -t public public/index.php # OR use the composer alias: $ composer serve ``` You can then visit the site at http://localhost:8080/ - which will bring up a welcome page and the ability to visit the dashboard in order to create and inspect your APIs. ### NOTE ABOUT USING APACHE Apache forbids the character sequences `%2F` and `%5C` in URI paths. However, the Apigility Admin API uses these characters for a number of service endpoints. As such, if you wish to use the Admin UI and/or Admin API with Apache, you will need to configure your Apache vhost/project to allow encoded slashes: ```apacheconf AllowEncodedSlashes On ``` This change will need to be made in your server's vhost file (it cannot be added to `.htaccess`). ### NOTE ABOUT OPCACHE **Disable all opcode caches when running the admin!** The admin cannot and will not run correctly when an opcode cache, such as APC or OpCache, is enabled. Apigility does not use a database to store configuration; instead, it uses PHP configuration files. Opcode caches will cache these files on first load, leading to inconsistencies as you write to them, and will typically lead to a state where the admin API and code become unusable. The admin is a **development** tool, and intended for use a development environment. As such, you should likely disable opcode caching, regardless. When you are ready to deploy your API to **production**, however, you can disable development mode, thus disabling the admin interface, and safely run an opcode cache again. Doing so is recommended for production due to the tremendous performance benefits opcode caches provide. ### NOTE ABOUT DISPLAY_ERRORS The `display_errors` `php.ini` setting is useful in development to understand what warnings, notices, and error conditions are affecting your application. However, they cause problems for APIs: APIs are typically a specific serialization format, and error reporting is usually in either plain text, or, with extensions like XDebug, in HTML. This breaks the response payload, making it unusable by clients. For this reason, we recommend disabling `display_errors` when using the Apigility admin interface. This can be done using the `-ddisplay_errors=0` flag when using the built-in PHP web server, or you can set it in your virtual host or server definition. If you disable it, make sure you have reasonable error log settings in place. For the built-in PHP web server, errors will be reported in the console itself; otherwise, ensure you have an error log file specified in your configuration. `display_errors` should *never* be enabled in production, regardless. ### Vagrant If you prefer to develop with Vagrant, there is a basic vagrant recipe included with this project. This recipe assumes that you already have Vagrant installed. The virtual machine will try to use localhost:8080 by default, so if you already have a server on this port of your host machine, you need to shut down the conflicting server first, or if you know how, you can reconfigure the ports in Vagrantfile. Assuming you have Vagrant installed and assuming you have no port conflicts, you can bring up the Vagrant machine with the standard `up` command: ```bash $ vagrant up ``` When the machine comes up, you can ssh to it with the standard ssh forward agent: ```bash $ vagrant ssh ``` The web root is inside the shared directory, which is at `/var/www`; this is also the home directory for the vagrant issue, which will be the initial directory you land in once you connect via SSH. The image installs composer during provisioning, meaning you can use it to install and update dependencies: ```bash # Install dependencies: $ vagrant ssh -c 'composer install' # Update dependencies: $ vagrant ssh -c 'composer update' ``` You can also manipulate development mode: ```bash $ vagrant ssh -c 'composer development-enable' $ vagrant ssh -c 'composer development-disable' $ vagrant ssh -c 'composer development-status' ``` > #### Vagrant and VirtualBox > > The vagrant image is based on `bento/ubuntu-16.04`. If you are using VirtualBox as > a provider, you will need: > > - Vagrant 1.8.5 or later > - VirtualBox 5.0.26 or later For vagrant documentation, please refer to [vagrantup.com](https://www.vagrantup.com/) ### Docker If you develop or deploy using Docker, we provide configuration for you. Prepare your development environment using [docker compose](https://docs.docker.com/compose/install/): ```bash $ git clone https://github.com/zfcampus/zf-apigility-skeleton $ cd zf-apigility-skeleton $ docker-compose build # Install dependencies via composer, if you haven't already: $ docker-compose run apigility composer install # Enable development mode: $ docker-compose run apigility composer development-enable ``` Start the container: ```bash $ docker-compose up ``` Access Apigility from `http://localhost:8080/` or `http://:8080/` if on Windows or Mac. You may also use the provided `Dockerfile` directly if desired. Once installed, you can use the container to update dependencies: ```bash $ docker-compose run apigility composer update ``` Or to manipulate development mode: ```bash $ docker-compose run apigility composer development-enable $ docker-compose run apigility composer development-disable $ docker-compose run apigility composer development-status ``` QA Tools -------- The skeleton ships with minimal QA tooling by default, including zendframework/zend-test. We supply basic tests for the shipped `Application\Controller\IndexController`. We also ship with configuration for [phpcs](https://github.com/squizlabs/php_codesniffer). If you wish to add this QA tool, execute the following: ```bash $ composer require --dev squizlabs/php_codesniffer ``` We provide aliases for each of these tools in the Composer configuration: ```bash # Run CS checks: $ composer cs-check # Fix CS errors: $ composer cs-fix # Run PHPUnit tests: $ composer test ``` ================================================ FILE: SUPPORT.md ================================================ # Getting Support Zend Framework offers three support channels: - For real-time questions, use our [chat](https://zendframework-slack.herokuapp.com) - For detailed questions (e.g., those requiring examples) use our [forums](https://discourse.zendframework.com/c/questions/apigility) - To report issues, use this repository's [issue tracker](https://github.com/zfcampus/zf-apigility-skeleton/issues/new) **DO NOT** use the issue tracker to ask questions; use chat or the forums for that. Questions posed to the issue tracker will be closed. When reporting an issue, please include the following details: - A narrative description of what you are trying to accomplish. - The minimum code necessary to reproduce the issue. - The expected results of exercising that code. - The actual results received. We may ask for additional details: what version of the library you are using, and what PHP version was used to reproduce the issue. You may also submit a failing test case as a pull request. ================================================ FILE: Vagrantfile ================================================ # -*- mode: ruby -*- # vi: set ft=ruby : VAGRANTFILE_API_VERSION = '2' @script = <