humanmade / local-vip Goto Github PK

View Code? Open in Web Editor NEW

6.0 19.0 4.0 1.71 MB

A Composer package providing a Docker-based local development environment for use with WordPress VIP projects.

Dockerfile 0.28% PHP 97.69% Shell 2.03%

local-vip's Introduction

Local Server for VIP

A local development environment for WordPress VIP projects, built on Docker.

Dependencies

Composer
Docker Desktop (you can install Docker Machine directly if preferred)

Installation

Local VIP can be installed as a dependency within a Composer-based WordPress project:

composer require --dev humanmade/local-vip

Getting Started

Fill out your project's composer.json to define the project name, domain, and subsites/subdomains you want to use:

  "extra": {
    "local-vip": {
      "name": "test-vip",
      "domain": "test.local",
      "subdomains": true,
      "db-image": "biarms/mysql:5.7"
      "sites": {
        "subdomain": "Subsite Name"
      }
    }
  }

Your local domains will need to be mapped within you hosts file. For example, if your domain is test.local, the following would need to be added to your hosts file.

# test.local
127.0.0.1 test.local

In your local server project you can run the following commands:

# Start the server cluster
composer server start

# Stop the server cluster
composer server stop

For full documentation click here.

Enterprise Search

Local VIP mimics VIP's Enterprise Search by using Elastic Search with mock variables to simulate a VIP environment.

Once the environment is created you can confirm the ES instances is running via Kibana at http://127.0.0.1:63917/kibana/app/kibana#/

In addition you can check the health of the environment in the Kibana console http://127.0.0.1:63917/kibana/app/kibana#/dev_tools/console?_g=() by executing GET _cluster/health?pretty.

In order to leverage ES, the data needs to be indexed. By default, there is no data indexed in the ES environment. To index the data, use WP CLI and execute wp vip-search index --setup.

local-vip's People

Stargazers

Watchers

Forkers

isabella232 hsiemon-globant usatoday-smb fairhopeweb

local-vip's Issues

Process signature conflict

A conflict between the version of Symfony's Process that's packaged with composer and the version of Process that local-vip expects results in a fatal Type Error that prevents a user from starting the server via the composer server start command. The specific error looks like this:

In Process.php line 143:                                                                                                                                                                      
                                                                                                                                                                                              
  [TypeError]                                                                                                                                                                                 
  Argument 1 passed to Symfony\Component\Process\Process::__construct() must be of the type array, string given, called in /project/path/vendor/humanmade/local-vip/   
  inc/composer/class-command.php on line 322

Steps to reproduce:

Use modern version of Composer (i.e. 2.3+)
Run composer server start
Observe error

Ideally the command completes without error, bringing up the server.

Acceptance criteria:

composer server start brings the docker server up without throwing a fatal error

Error when installed alongside PHPCS locally.

Hey,

When installed using composer in a project that also wants to use PHPCS from /vendor/phpcs, an error message is generated. This prevents PHPCS from executing.

We need this functionality so we can ship our code standards with the local development environment.

Steps to reproduce:

Create this composer.json:

    "name": "test/bowery",
    "description": "A local environment",
    "type": "project",
    "extra": {
        "installer-paths": {
            "wordpress": [ "johnpbloch/wordpress" ]
        },
        "local-vip": {
            "name": "test",
            "host": "example.test",
            "subdomains": true
        }
    },
    "require": {
        "johnpbloch/wordpress": "5.5.0"
    },
    "require-dev": {
        "humanmade/local-vip": "^1.3",
        "automattic/vipwpcs": "^2.3",
        "dealerdirect/phpcodesniffer-composer-installer": "^0.7.1"
    }
}

Run composer install
Run vendor/bin/phpcs -i

I expected to see a list of installed PHPCS standards but instead see this error:


Fatal error: Uncaught Error: Call to undefined function HM\Local_VIP\add_filter() in .../vendor/humanmade/local-vip/inc/namespace.php:15
Stack trace:
#0 .../vendor/humanmade/local-vip/local-vip.php(22): HM\Local_VIP\bootstrap()
#1 .../vendor/composer/autoload_real.php(69): require('...')
#2 .../vendor/composer/autoload_real.php(59): composerRequire2139e4122d477816d2a5e92e9c81091d('0d264f8699bc94d...', '...')
#3 .../vendor/autoload.php(7): ComposerAutoloaderInit2139e4122d477816d2a5e92e9c81091d::getLoader()
#4 .../vendor/squizlabs/php_codesniffer/autoload.php(79): include('...')
#5 [internal function]: PHP_CodeSniffer\Autoload::load('PHP_CodeSniffer...')
#6 .../vendor/squizlabs/php_codesniffer/bin/phpcs(17): spl_autoload_call('PHP_CodeSniffer...')
#7 {main}
   in .../vendor/humanmade/local-vip/inc/namespace.php on line 15

Acceptance criteria:

Allow PHP 8.0

Users should be able to select PHP 8.0 by specifying it like so:

    "extra": {
        "altis": {
			"modules": {
				"local-server": {
                    "php": "8.0"
				}
			}
		}
    }

Described in local-server docs.

SSL certificates can cause problems

In my case, after setting up local-vip and running the cert-build command as described in the README, I was unable to access my site: All browsers returned a ERR_SSL_UNRECOGNIZED_NAME_ALERT.

The altis-proxy docker container was also throwing errors like this:

21T19:54:25Z" level=error msg="Unable to add a certificate to the entryPoint \"https\" : unable to generate TLS certificate : tls: private key does not match public key"

time="2022-07-21T19:54:25Z" level=error msg="failed to load X509 key pair: tls: private key does not match public key"

Ultimately the following steps solved the problem for me but they are not really generalizable at this time:

edit vendor/humanmade/local-vip/.bin/build-cert.sh to remove the line mv ${DOMAIN}.crt ${PWD}/${DOMAIN}.crt because it attempts to move a file to itself, an action which fails and halts the entire script
run bash .bin/build-cert.sh nxs.local
import the resulting vendor/humanmade/local-vip/nxs.local.crt into my OS via Keychain Access, and then tell my system to trust it
stop and restart my server and the altis-proxy docker container

This was caused by a couple things:

The repo does not ship with any domain-specific keys
It has instructions for adding keys generated by the above bash command
This can lead to a situation where the wrong keys are imported (if the proxy isn't restarted)
This whole process is very messy if it needs to be done every time someone instantiates local-vip for a new project

local-server more or less "just works" and creates every project on altis.dev (from my recollection--I may be wrong) so potentially this should be modified to do the same, with instructions for how to deviate from that, if necessary (and ideally with a more streamlined process).

My understanding is that the proxy and traefik can be used for this, but my grasp of both those things is very limited.

Additionally, the script to build certs contains direct references to Nexstar. So far as I can tell these don't cause any problems on their own, but they should probably be removed.

Missing memcached on 5.0.0-beta.1

Branch 5.0.0-beta.1 is missing memcached

Enable Cron

This environment was derived from altis/local-server, which uses cavalcade for Cron management; after removing that, I've observed that Cron tasks are not running locally unless manually triggered. This appears to be due to a missing loopback to enable the cron task to resolve the hostname within the Docker container.

XDebug default doesn't work

The docs say that --xdebug will turn xdebug on, but in my experience this isn't the case. I need to pass --xdebug=debug (which is supposed to be the default) or the debug server doesn't work (i.e. PHPStorm never receives notification of an incoming XDebug thing).