mboynes

Preparing Plugins for Term Splitting

Historically, two terms in different taxonomies with the same slug (for instance, a tag and a category sharing the slug "news") have shared a single term ID. Beginning in WordPress 4.2, when one of these shared terms is updated, it will be split: the updated term will be assigned a new term ID.

In the vast majority of situations, this update will be seamless and uneventful. However, some plugins and themes store term IDs in options, post meta, user meta, or elsewhere. WP 4.2 will include two different tools to help authors of these plugins and themes with the transition.

The 'split_shared_term' action

When a shared term is assigned a new term ID, a new 'split_shared_term' action is fired. Plugins and themes that store term IDs should hook to this action to perform necessary migrations. The documentation for the hook is as follows:

rfvcorreia

add_action("init", "clear_crons_left");
function clear_crons_left() {
wp_clear_scheduled_hook("cron_name");
}

rubemlrm

before_script:
    - composer install --prefer-dist > /dev/null
    - export APP_ENV=testing

unitTesting:
    script:
        - echo "Running PHP Unit tet"
        - php vendor/bin/phpunit --colors --debug  --coverage-text
codeSniffer:
    script:

miziomon

{
    "require": {
        "monolog/monolog": "1.1.*"
    }
}

pdewouters

# This is a template .gitignore file for git-managed WordPress projects.
#
# Fact: you don't want WordPress core files, or your server-specific
# configuration files etc., in your project's repository. You just don't.
#
# Solution: stick this file up your repository root (which it assumes is
# also the WordPress root directory) and add exceptions for any plugins,
# themes, and other directories that should be under version control.
#
# See the comments below for more info on how to add exceptions for your

adampatterson

<?php

namespace App\Exceptions;

use Exception;
use Illuminate\Auth\AuthenticationException;
use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler;

class Handler extends ExceptionHandler
{

mhedges1

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;

/**
 * Class SeedResource
 * @package App\Console\Commands\Resource
 */

iolson

# Before Script
before_script:
  - composer self-update
  - composer install --prefer-dist > /dev/null
  - cp .env.example .env
  - php artisan key:generate
  - php artisan migrate:refresh

# Services
services:

jrmadsen67

Quick tip for handling CSRF Token Expiration - common issue is when you use csrf protection is that if 
a form sits there for a while (like a login form, but any the same) the csrf token in the form will 
expire & throw a strange error.

Handling it is simple, and is a good lesson for dealing with other types of errors in a custom manner.

In Middleware you will see a file VerifyCsrfToken.php and be tempted to handle things there. DON'T! 
Instead, look at your app/Exceptions/Handler.php, at the render($request, Exception $e) function.

All of your exceptions go through here, unless you have excluded them in the $dontReport array at the 

anthonny

// ...
const dotenv = require("dotenv");

// ...

    console.log(`Bundling application for entryPath ${entryPath}...`);

    dotenv.config()
    const isUppercase = key => key.toUpperCase() === key;
    const envKeys = Object.keys(env);