View gist:e3eef5f0ff6e03ab982260f10e46d8ac
diff --git a/src/humans.txt b/src/humans.txt
index 5af7e71a4..6306ece57 100644
--- a/src/humans.txt
+++ b/src/humans.txt
@@ -99,6 +99,10 @@ Title: Core Developer
Twitter: slaFFik
Favorite Food: Cakes
+Name: Venutius
+Title: Community Support
View test.yml
default:
suites:
default:
contexts:
- PaulGibbs\WordpressBehatExtension\Context\SiteContext
- PaulGibbs\WordpressBehatExtension\Context\WordpressContext
- Behat\MinkExtension\Context\MinkContext
- PaulGibbs\WordpressBehatExtension\Context\ContentContext
- PaulGibbs\WordpressBehatExtension\Context\DashboardContext
- PaulGibbs\WordpressBehatExtension\Context\UserContext
View gist:a33e1905a60eb1dc5b66421d59cebedb
* Use a Post Type for email templates.
* The intention is to use the standard wp-admin interface to allow people to change the contents of the email.
* Mustache-like token syntax.
* Use the WP Customiser to visually customise those emails.
* Use a Taxonomy to store the distinct types of emails we send (e.g. new_user, new_site, new_activity_mention, etc).
* Add a HTML email template for the post type.
Direct calls to `wp_mail()` replaced with custom function `bp_send_mail()` that, basically, wraps `wp_mail`:
* I surveyed all the mail replacement plugins I could find (like Mandrill's), and they all re-declare `wp_mail` to implement support for their custom service. Therefore, if `wp_mail()` is redeclared, *or* something has been filtered to get WP to send HTML emails, I'm assuming there's some dark voodoo at work -- and for reasons of trying to be compatible as possible, BP will treat emails the same way it does today (we'll pass it straight through to whatever `wp_mail()` is).
* `bp_send_mail` does three
View phpcs.xml.dist
<?xml version="1.0"?>
<ruleset name="WordPress Coding Standards">
<description>Apply WordPress Coding Standards to all Core files</description>
<rule ref="WordPress-Core">
<exclude name="WordPress.PHP.YodaConditions.NotYoda" />
<exclude name="WordPress.WP.I18n.MissingTranslatorsComment" />
<exclude name="WordPress.Files.FileName.InvalidClassFileName" />
<exclude name="PEAR.NamingConventions.ValidClassName.Invalid" />
<exclude name="WordPress.WP.PreparedSQL.NotPrepared" />
View gist:8b45ec1edfa0dc724e7a0819896299f8
<?php
/**
* Remove bbPress script/style from non-bbPress pages.
*
* @param \BBP_Theme_Compat $bbpress_theme bbPress' theme object.
*/
add_action( 'bbp_theme_compat_actions', function( $bbpress_theme ) {
if ( is_bbpress() ) {
return;
}
View gist:f4a172bd27943a78e5671ea8272aae92
$ vagrant up --provider=virtualbox
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Cloning VM...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/ubuntu-16.04' is up to date...
==> default: Setting the name of the VM: bporg_default_1500458217639_11998
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
View gist:43412103156420508445adcf87ce348b
$ composer require wp-cli/wp-cli
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
Using version ^1.2 for wp-cli/wp-cli
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- wp-cli/wp-cli v1.2.0 requires wp-cli/autoload-splitter ^0.1 -> satisfiable by wp-cli/autoload-splitter[v0.1.0, v0.1.1, v0.1.2, v0.1.3].
View gist:a90e68501cd7e735aef08a5a32945c76
$ uname -a
Darwin Pauls-MacBook-Air.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64
$ which -a php
/usr/local/php5/bin/php
/usr/bin/php
$ php -v
PHP 7.1.1 (cli) (built: Feb 13 2017 10:05:49) ( NTS )
Copyright (c) 1997-2017 The PHP Group