Download the PHP package padilla-digital/wp-template without Composer

On this page you can find all versions of the php package padilla-digital/wp-template. 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 wp-template

Example WordPress Composer

CircleCI

This repository is a reference implementation and start state for a modern WordPress workflow utilizing Composer, Continuous Integration (CI), Automated Testing, and Pantheon. Even though this is a good starting point, you will need to customize and maintain the CI/testing set up for your projects.

This repository is meant to be copied one-time by the the Terminus Build Tools Plugin but can also be used as a template. It should not be cloned or forked directly.

The Terminus Build Tools plugin will scaffold a new project, including:

For more details and instructions on creating a new project, see the Terminus Build Tools Plugin.

Important files and directories

/web

Pantheon will serve the site from the /web subdirectory due to the configuration in pantheon.yml. This is necessary for a Composer based workflow. Having your website in this subdirectory also allows for tests, scripts, and other files related to your project to be stored in your repo without polluting your web document root or being web accessible from Pantheon. They may still be accessible from your version control project if it is public. See the pantheon.yml documentation for details.

/web/wp

Even within the /web directory you may notice that other directories and files are in different places compared to a default WordPress installation. WordPress allows installing WordPress core in its own directory, which is necessary when installing WordPress with Composer.

See /web/wp-config.php for key settings, such as WP_SITEURL, which must be updated so that WordPress core functions properly in the relocated /web/wp directory. The overall layout of directories in the repo is inspired by, but doesn't exactly mirror, Bedrock.

composer.json

This project uses Composer to manage third-party PHP dependencies.

The require section of composer.json should be used for any dependencies your web project needs, even those that might only be used on non-Live environments. All dependencies in require will be pushed to Pantheon.

The require-dev section should be used for dependencies that are not a part of the web application but are necesarry to build or test the project. Some example are php_codesniffer and phpunit. Dev dependencies will not be deployed to Pantheon.

If you are just browsing this repository on GitHub, you may not see some of the directories mentioned above, such as web/wp. That is because WordPress core and its plugins are installed via Composer and ignored in the .gitignore file.

A custom, Composer version of WordPress for Pantheon is used as the source for WordPress core.

Third party WordPress dependencies, such as plugins and themes, are added to the project via composer.json. The composer.lock file keeps track of the exact version of dependency. Composer installer-paths are used to ensure the WordPress dependencies are downloaded into the appropriate directory.

Non-WordPress dependencies are downloaded to the /vendor directory.

.ci

This .ci directory is where all of the scripts that run on Continuous Integration are stored. Provider specific configuration files, such as .circle/config.yml and .gitlab-ci.yml, make use of these scripts.

The scripts are organized into subdirectories of .ci according to their function: build, deploy, or test.

Build Scripts .ci/build

Steps for building an artifact suitable for deployment. Feel free to add other build scripts here, such as installing Node dependencies, depending on your needs.

Build Scripts .ci/deploy

Scripts for facilitating code deployment to Pantheon.

Automated Test Scripts .ci/tests

Scripts that run automated tests. Feel free to add or remove scripts here depending on your testing needs.

Github Actions Workflows .ci/.github

This folder should be copied to .github folder in root to enable Github Actions. Also, some secrets need to be added to Github Actions configuration.

Static Testing .ci/test/static and tests/unit Static tests analyze code without executing it. It is good at detecting syntax error but not functionality.

Visual Regression Testing .ci/test/visual-regression Visual regression testing uses a headless browser to take screenshots of web pages and compare them for visual differences.

Behat Testing .ci/test/behat and tests/behat Behat is an acceptance/end-to-end testing framework written in PHP. It faciliates testing the fully built WordPress site on Pantheon infrastucture. WordHat is used to help with integrating Behat and WordPress.

Github Actions

If you need to enable Github Actions for an existing project, you should copy .ci/.github to .github and then add the following secrets to Github Actions configuration:

Working locally with Lando

To get started using Lando to develop locally complete these one-time steps. Please note than Lando is an independent product and is not supported by Pantheon. For further assistance please refer to the Lando documentation.

You should now be able to edit your site locally. The steps above do not need to be completed on subsequent starts. You can stop Lando with lando stop and start it again with lando start.

Warning: do NOT push/pull code between Lando and Pantheon directly. All code should be pushed to GitHub and deployed to Pantheon through a continuous integration service, such as CircleCI.

Composer, Terminus and wp-cli commands should be run in Lando rather than on the host machine. This is done by prefixing the desired command with lando. For example, after a change to composer.json run lando composer update rather than composer update.

All versions of wp-template with dependencies

PHP Build Version
Package Version
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 padilla-digital/wp-template contains the following files

Loading the files please wait ....