{"id":14235870,"url":"https://github.com/xwp/wp-dev-lib","last_synced_at":"2025-09-27T02:32:07.815Z","repository":{"id":10694287,"uuid":"12936631","full_name":"xwp/wp-dev-lib","owner":"xwp","description":"DEPRECATED. Common code used during development of WordPress plugins and themes","archived":true,"fork":false,"pushed_at":"2022-11-10T10:40:19.000Z","size":599,"stargazers_count":277,"open_issues_count":52,"forks_count":58,"subscribers_count":71,"default_branch":"master","last_synced_at":"2025-05-29T10:13:26.179Z","etag":null,"topics":["phpunit","shell","travis-ci","wordpress"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/xwp.png","metadata":{"files":{"readme":"readme.md","changelog":null,"contributing":"contributing.md","funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2013-09-18T23:05:37.000Z","updated_at":"2025-05-09T09:15:55.000Z","dependencies_parsed_at":"2023-01-13T16:05:59.442Z","dependency_job_id":null,"html_url":"https://github.com/xwp/wp-dev-lib","commit_stats":null,"previous_names":[],"tags_count":23,"template":false,"template_full_name":null,"purl":"pkg:github/xwp/wp-dev-lib","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xwp%2Fwp-dev-lib","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xwp%2Fwp-dev-lib/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xwp%2Fwp-dev-lib/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xwp%2Fwp-dev-lib/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/xwp","download_url":"https://codeload.github.com/xwp/wp-dev-lib/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/xwp%2Fwp-dev-lib/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":277171569,"owners_count":25773244,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-09-27T02:00:08.978Z","response_time":73,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["phpunit","shell","travis-ci","wordpress"],"created_at":"2024-08-20T21:02:26.522Z","updated_at":"2025-09-27T02:32:07.545Z","avatar_url":"https://github.com/xwp.png","language":"Shell","readme":"# ![wp-dev-lib](assets/logo.svg)\n\n**⚠️ This project is no longer maintained or supported!**\n\nThis toolset was created before there were reliable ways of pulling in developer tools using Composer and npm. We now recommend adding linting and testing support by adding each tool as a developer dependency.\n\n---\n\n**Common tools to facilitate the development and testing of WordPress themes and plugins.**\n\nGreat for adding coding standards, linting and automated testing even to legacy projects since checks are applied to new code only by default.\n\n[![Build Status](https://travis-ci.org/xwp/wp-dev-lib.svg?branch=master)](https://travis-ci.org/xwp/wp-dev-lib)\n\n\u003c!-- START doctoc generated TOC please keep comment here to allow auto update --\u003e\n\u003c!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --\u003e\n\n\n- [Install](#install)\n  - [Using Composer](#using-composer)\n  - [Using npm](#using-npm)\n  - [As Git Submodule](#as-git-submodule)\n- [Configure](#configure)\n  - [Suggested Composer Packages](#suggested-composer-packages)\n- [Automate](#automate)\n  - [Locally with Git Hooks](#locally-with-git-hooks)\n  - [Travis CI](#travis-ci)\n- [Pre-commit Tips](#pre-commit-tips)\n  - [Skipping Checks](#skipping-checks)\n  - [Running Specific Checks](#running-specific-checks)\n  - [Manually Invoking Pre-commit](#manually-invoking-pre-commit)\n  - [Limiting Scope of Checks](#limiting-scope-of-checks)\n- [Environment Variables](#environment-variables)\n- [PHPUnit Code Coverage](#phpunit-code-coverage)\n- [Codeception](#codeception)\n- [Gitter](#gitter)\n- [Plugin Helpers](#plugin-helpers)\n- [Contribute](#contribute)\n- [Credits](#credits)\n\n\u003c!-- END doctoc generated TOC please keep comment here to allow auto update --\u003e\n\n\n## Install\n\n### Using [Composer](https://getcomposer.org)\n\n```bash\ncomposer require --dev xwp/wp-dev-lib\n```\n\nwhich will place it under `vendor/xwp/wp-dev-lib`.\n\n### Using [npm](https://www.npmjs.com)\n\n```bash\nnpm install --save-dev xwp/wp-dev-lib\n```\n\nwhich will place it under `node_modules/xwp/wp-dev-lib`. Lock it to a specific [release version number](https://github.com/xwp/wp-dev-lib/releases) by appending it to the package name `xwp/wp-dev-lib#1.2.3` where `1.2.3` is the version number.\n\n### As [Git Submodule](https://git-scm.com/docs/git-submodule)\n\n```bash\ngit submodule add -b master https://github.com/xwp/wp-dev-lib.git dev-lib\n```\n\nTo update the library with the latest changes:\n\n```bash\ngit submodule update --remote dev-lib\ngit add dev-lib\ngit commit -m \"Update dev-lib\"\n```\n\n\n## Configure\n\nThis tool comes with sample configuration files for the following linters:\n\n- [`phpunit-plugin.xml`](sample-config/phpunit-plugin.xml) for [PHPUnit](https://phpunit.de)\n- [`phpcs.xml`](sample-config/phpcs.xml) for [phpcs](https://github.com/squizlabs/PHP_CodeSniffer)\n- [`.jshintrc`](sample-config/.jshintrc) and [`.jshintignore`](sample-config/.jshintignore) for [JSHint](http://jshint.com)\n- [`.jscsrc`](sample-config/.jscsrc) for [JSCS](http://jscs.info)\n- [`.eslintrc`](sample-config/.eslintrc) and [`.eslintignore`](sample-config/.eslintignore) for [ESLint](https://eslint.org)\n- [`.editorconfig`](sample-config/.editorconfig) for [EditorConfig](http://editorconfig.org/).\n\nCopy the files you need to the root directory of your project.\n\nIt is a best practice to install the various tools as dependencies in the project itself, pegging them at specific versions as required. This will ensure that the the tools will be repeatably installed across environments. When a tool is installed locally, it will be used instead of any globally-installed version.\n\n\n### Suggested Composer Packages\n\nAdd these as development dependencies to your project:\n\n```bash\ncomposer require --dev package/name\n```\n\n- [`wp-coding-standards/wpcs`](https://packagist.org/packages/wp-coding-standards/wpcs) for adding [WordPress Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/) checks. Use together with the sample [`phpcs.xml`](sample-config/phpcs.xml) configuration.\n\n- [`phpcompatibility/phpcompatibility-wp`](https://packagist.org/packages/phpcompatibility/phpcompatibility-wp) for checking PHP compatibility. Uses the [PHP version required](https://getcomposer.org/doc/04-schema.md#package-links) in the `composer.json` file. For example `composer require php '\u003e=5.2'`.\n\n- [`dealerdirect/phpcodesniffer-composer-installer`](https://packagist.org/packages/dealerdirect/phpcodesniffer-composer-installer) for automatically configuring the [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer) coding sniffers.\n\n\n## Automate\n\n### Locally with Git Hooks\n\nThis tool comes with a [`pre-commit` hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#_committing_workflow_hooks) which runs all linters, tests and checks before every commit to your project.\n\nTo add the hook with Composer we suggest to use [brainmaestro/composer-git-hooks](https://github.com/BrainMaestro/composer-git-hooks):\n\n```bash\ncomposer require --dev brainmaestro/composer-git-hooks\n```\n\nwith the following configuration added to `composer.json`:\n\n```json\n{\n  \"extra\": {\n    \"hooks\": {\n      \"pre-commit\": \"./vendor/xwp/wp-dev-lib/scripts/pre-commit\"\n    }\n  }\n}\n```\n\nand two additional scripts that automatically setup the hooks during `composer install`:\n\n```json\n{\n  \"scripts\": {\n    \"post-install-cmd\": [\n      \"vendor/bin/cghooks add --no-lock\"\n    ],\n    \"post-update-cmd\": [\n      \"vendor/bin/cghooks update\"\n    ],\n  }\n}\n```\n\nWith `npm` we suggest to use [husky](https://www.npmjs.com/package/husky):\n\n```bash\nnpm install husky --save-dev\n```\n\nwith the following script added to your `package.json`:\n\n```json\n{\n  \"scripts\": {\n    \"precommit\": \"./node_modules/wp-dev-lib/scripts/pre-commit\"\n  }\n}\n```\n\nAlternatively, create a symlink at `.git/hooks/pre-commit` pointing to [`pre-commit`](scripts/pre-commit) using the bundled script:\n\n```bash\n./vendor/xwp/wp-dev-lib/scripts/install-pre-commit-hook.sh\n```\n\nTo ensure that everyone on your team has the `pre-commit` hook added automatically, we recommend using the Composer or npm scripts as described above as the package managers will set up the `pre-commit` hook during the install phase.\n\n\n### Travis CI\n\nCopy the [`sample-config/.travis.yml`](sample-config/.travis.yml) file into the root of your repo:\n\n```bash\ncp ./vendor/xwp/wp-dev-lib/sample-config/.travis.yml .\n```\n\nNote that the bulk of the logic in this config file is located in [`travis.install.sh`](scripts/travis.install.sh), [`travis.script.sh`](scripts/travis.script.sh), and [`travis.after_script.sh`](scripts/travis.after_script.sh).\n\nEdit the `.travis.yml` to change the target PHP version(s) and WordPress version(s) you need to test for and also whether you need to test on multisite or not:\n\n```yml\nphp:\n  - 5.3\n  - 7.0\n\nenv:\n  - WP_VERSION=latest WP_MULTISITE=0\n  - WP_VERSION=latest WP_MULTISITE=1\n  - WP_VERSION=trunk WP_MULTISITE=0\n  - WP_VERSION=trunk WP_MULTISITE=1\n```\n\nHaving more variations here is good for open source plugins, which are free for Travis CI. However, if you are using Travis CI with a private repo you probably want to limit the jobs necessary to complete a build. So if your production environment is running PHP 5.5, is on the latest stable version of WordPress, and is not multisite, then your `.travis.yml` could just be:\n\n```yml\nphp:\n  - 5.5\n\nenv:\n  - WP_VERSION=4.0 WP_MULTISITE=0\n```\n\nThis will greatly speed up the time build time, giving you quicker feedback on your pull request status, and prevent your Travis build queue from getting too backlogged.\n\n\n## Pre-commit Tips\n\nThe default behaviour for the linters is to only report errors on lines that are within actual staged changes being committed. So remember to selectively stage the files (via `git add ...`) or better the patches (via `git add -p ...`).\n\n### Skipping Checks\n\nIf you do need to disable the `pre-commit` hook for an extenuating circumstance (e.g. to commit a work in progress to share), you can use the `--no-verify` argument:\n\n```bash\ngit commit --no-verify -m \"WIP\"\n```\n\nAlternatively, you can also selectively disable certain aspects of the `pre-commit` hook from being run via the `DEV_LIB_SKIP` environment variable. For example, when there is a change to a PHP file and there are PHPUnit tests included in a repo, but you've just changed a PHP comment or something that certainly won't cause tests to fail, you can make a commit and run all checks _except_ for PHPUnit via:\n\n```bash\nDEV_LIB_SKIP=phpunit git commit\n```\n\nYou can string along multiple checks to skip via commas:\n\n```bash\nDEV_LIB_SKIP=composer,phpunit,phpcs,yuicompressor,jscs,jshint,codeception,executebit git commit\n```\n\nNaturally you'd want to create a Git alias for whatever you use most often, for example:\n\n```bash\ngit config --global alias.commit-without-phpunit '!DEV_LIB_SKIP=\"$DEV_LIB_SKIP,phpunit\" git commit'\n```\n\nWhich would allow you to then do the following (with Bash [tab completion](https://git-scm.com/book/en/v1/Git-Basics-Tips-and-Tricks#Auto-Completion) even):\n\n```bash\ngit commit-without-phpunit\n```\n\nAside, you can [skip Travis CI builds](https://docs.travis-ci.com/user/customizing-the-build/#Skipping-a-build) by including `[ci skip]` in the commit message.\n\n### Running Specific Checks\n\nIf you would like to run a specific check and ignore all other checks, then you can use `DEV_LIB_ONLY` environment variable. For example, you may want to only run PHPUnit before a commit:\n\n```bash\nDEV_LIB_ONLY=phpunit git commit\n```\n\n### Manually Invoking Pre-commit\n\nSometimes you may want to run the `pre-commit` checks manually to compare changes (`patches`) between branches much in the same way that Travis CI runs its checks. To compare the current staged changes against `master`, do:\n\n```bash\nDIFF_BASE=master ./vendor/xwp/wp-dev-lib/scripts/pre-commit\n```\n\nTo compare the committed changes between `master` and the current branch:\n\n```bash\nDIFF_BASE=master DIFF_HEAD=HEAD ./vendor/xwp/wp-dev-lib/scripts/pre-commit\n```\n\n### Limiting Scope of Checks\n\nA barrier of entry for adding automated code quality checks to an existing project is that there may be _a lot_ of issues in your codebase that get reported initially. So to get passing builds you would then have a major effort to clean up your codebase to make it conforming to PHP_CodeSniffer, JSHint, and other tools. This is not ideal and can be problematic in projects with a lot of activity since these changes will add lots of conflicts with others' pull requests.\n\nTo get around this issue, there is now an environment variable available for configuration: `CHECK_SCOPE`. By default its value is `patches` which means that when a `pre-commit` runs or Travis runs a build on a pull request or commit, the checks will be restricted in their scope to _only report on issues occurring in the changed lines (patches)_. Checking patches is the most useful, but `CHECK_SCOPE=changed-files` can be added in the project config so that the checks will be limited to the entirety of any file that has been modified.\n\nAlso important to note that when the the `pre-commit` check runs, it will run the linters (PHPCS, JSHint, JSCS, etc) on the _staged changes_, not the files as they exist in the working tree. This means that you can use `git add -p` to interactively select changes to stage (which is a good general best practice in contrast to `git commit -a`), and _any code excluded from being staged will be ignored by the linter_. This is very helpful when you have some debug statements which you weren't intending to commit anyway (e.g. `print_r()` or `console.log()`).\n\nWith `CHECK_SCOPE=patches` and `CHECK_SCOPE=changed-files` available, it is much easier to integrate automated checks on existing projects that may have a lot of nonconforming legacy code. You can fix up a codebase incrementally line-by-line or file-by-file in the normal course of fixing bugs and adding new features.\n\nIf you want to disable the scope-limiting behavior, you can define `CHECK_SCOPE=all`.\n\n\n## Environment Variables\n\nYou may customize the behavior of the `.travis.yml` and `pre-commit` hook by specifying a `.dev-lib` (formerly `.ci-env.sh`) Bash script in the root of the repo, for example:\n\n```bash\nDEFAULT_BASE_BRANCH=develop\nPHPCS_GITHUB_SRC=xwp/PHP_CodeSniffer\nPHPCS_GIT_TREE=phpcs-patch\nPHPCS_IGNORE='tests/*,includes/vendor/*' # See also PATH_INCLUDES below\nWPCS_GIT_TREE=develop\nWPCS_STANDARD=WordPress-Extra\nDISALLOW_EXECUTE_BIT=1\nYUI_COMPRESSOR_CHECK=1\nPATH_INCLUDES=\"docroot/wp-content/plugins/acme-* docroot/wp-content/themes/acme-*\"\nCHECK_SCOPE=patches\n```\n\nSet `DEFAULT_BASE_BRANCH` to be whatever your default branch is in GitHub; this is use when doing diff-checks on changes in a branch build on Travis CI. The `PATH_INCLUDES` is especially useful when the dev-lib is used in the context of an entire site, so you can target just the themes and plugins that you're responsible for. For _excludes_, you can specify a `PHPCS_IGNORE` var and override the `.jshintignore`; there is a `PATH_EXCLUDES_PATTERN` as well.\n\n\n## PHPUnit Code Coverage\n\nThe plugin-tailored [`phpunit.xml`](sample-config/phpunit-plugin.xml) has a `filter` in place to restrict PHPUnit's code coverage reporting to only look at the plugin's own PHP code, omitting the PHP from WordPress Core and other places that shouldn't be included. The `filter` greatly speeds up PHPUnit's execution. To get the code coverage report written out to a `code-coverage-report` directory:\n\n```bash\nphpunit --coverage-html code-coverage-report/\n```\n\nThen you can open up the `index.html` in that directory to learn about your plugin's code coverage.\n\n## Codeception\n\nBootstrap Codeception by:\n\n```bash\nwget -O /tmp/codecept.phar http://codeception.com/codecept.phar\nphp /tmp/codecept.phar bootstrap\n```\n\nThen update Acceptance tests configuration to reflect your own environment settings:\n\n```bash\nvim tests/acceptance.suite.yml\n```\n\nYou can generate your first test, saved to `tests/acceptance/WelcomeCept.php` by:\n\n```bash\nphp /tmp/codecept.phar generate:cept acceptance Welcome\n```\n\n## Gitter\n\nCreate an empty `.gitter` file in the root of your repo and a [Gitter](https://gitter.im) chat badge will be added to your project's README.\n\n## Plugin Helpers\n\nThe library includes a WordPress README [parser](scripts/class-wordpress-readme-parser.php) and [converter](scripts/generate-markdown-readme) to Markdown, so you don't have to manually keep your `readme.txt` on WordPress.org in sync with the `readme.md` you have on GitHub. The converter will also automatically recognize the presence of projects with Travis CI and include the status image in the markdown. Screenshots and banner images for WordPress.org are also automatically incorporated into the `readme.md`.\n\nWhat is also included in this repo is an [`svn-push`](svn-push) to push commits from a GitHub repo to the WordPress.org SVN repo for the plugin. The `/assets/` directory in the root of the project will get automatically moved one directory above in the SVN repo (alongside `trunk`, `branches`, and `tags`). To use, include an `svn-url` file in the root of your repo and let this file contains he full root URL to the WordPress.org repo for plugin (don't include `trunk`).\n\n\n## Contribute\n\nSee the [contributor documentation](contributing.md).\n\n\n## Credits\n\nSee [all contributors](https://github.com/xwp/wp-dev-lib/graphs/contributors).\n\nThe utilities in this project were first developed to facilitate development of [XWP](https://xwp.co/)'s [plugins](https://profiles.wordpress.org/xwp/).\n","funding_links":[],"categories":["Shell"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxwp%2Fwp-dev-lib","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fxwp%2Fwp-dev-lib","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fxwp%2Fwp-dev-lib/lists"}