Mudanças incompatíveis com versões anteriores

Modificações na manipulação de erros e exceções

Alguns erros fatais e recuperáveis foram convertidos para exceções no PHP 7. Estas exceções herdam a classe Error, que implementa a interface Throwable (a interface base que todas as exceções herdam).

Isso significa que manipuladores de erros podem não ser ativados porque exceções estão sendo disparadas em seu lugar (causando novos erros fatais por exceções Error não capturadas)

Uma descrição completa de como tratar erros no PHP 7 pode ser encontrada na página de erros do PHP 7. Este guia de migração irá enumerar apenas as mudanças compatíveis com versões anteriores.

set_exception_handler() não têm mais garantias de receber um objeto do tipo Exception.

Códigos que implementam um manipulador de exceção registrado com set_exception_handler() usando a declaração de tipo Exception causará um erro fatal quando um objeto Error for lançado.

Se o manipulador precisa trabalhar com o PHP 5 e 7, você deve remover a declaração de tipo do manipulador, enquanto que o código a migrar para funcionar exclusivamente no PHP 7, pode simplesmente trocar a declaração de tipo Exception por Throwable.

<?php
// Código da era PHP 5 que não irá funcionar.
function handler(Exception $e) { ... }
set_exception_handler('handler');

// Compatível com PHP 5 e 7.
function handler($e) { ... }

// Somente PHP 7.
function handler(Throwable $e) { ... }
?>

Construtores internos sempre lançarão exceções em caso de falha

Anteriormente, algumas classes internas retornavam NULL ou um objeto inútil quando o construtor falhava. Todas as classes internas agora lançam Exception neste caso, da mesma forma que classes de usuário já faziam.

Erros de Parse lançam exceções ParseError

Erros de Parser agora lançam um objeto ParseError. Manipular erros da função eval() devem incluir um bloco catch que possa manipular este erro.

Mudanças na severidade de notificações E_STRICT

Todas as notificações E_STRICT foram reclassificadas para outros níveis. A constante E_STRICT foi mantida, então chamar error_reporting(E_ALL|E_STRICT) não causará um erro.

Mudanças na severidade de notificações E_STRICT
Situação Novo nível/Comportamento
Utilizar um recurso como índice E_NOTICE
Métodos estáticos abstratos Notificação removida, não dispara erro
"Redefinindo" um construtor Notificação removida, não dispara erro
Assinatura incompatível durante a herança E_WARNING
Mesmas propriedades(compatíveis) em duas traits utilizadas Notificação removida, não dispara erro
Acessando propriedades estáticas de forma não estática E_NOTICE
Somente variáveis devem ser ser atribuídas por referência E_NOTICE
Somente variáveis devem ser passadas por referência E_NOTICE
Chamando métodos não estáticos de forma estática E_DEPRECATED

Mudanças na manipulação de variáveis

O PHP 7 utiliza uma sintaxe abstrata de árvore para analisar os arquivos fonte. Isso permitiu diversas melhorias para a linguagem que eram impossíveis devido a limitações no analisador utilizado em versões anteriores do PHP, porém resultou na remoção de alguns casos especiais por razões de consistência, que resulta em quebras de compatibilidades com versões anteriores. Esses casos são detalhados nesta seção.

Mudanças na manipulação indireta de variáveis, propriedades e métodos

Acessar indiretamente variáveis, propriedades, e métodos, agora serão avaliados estritamente da esquerda para a direita, o oposto dos casos especiais em versões anteriores. A tabela a seguir mostra como a ordem de avaliação mudou.

Nova e antiga avaliação de expressões indiretas
Expressão Interpretação no PHP 5 Interpretação no PHP 7
$$foo['bar']['baz'] ${$foo['bar']['baz']} ($$foo)['bar']['baz']
$foo->$bar['baz'] $foo->{$bar['baz']} ($foo->$bar)['baz']
$foo->$bar['baz']() $foo->{$bar['baz']}() ($foo->$bar)['baz']()
Foo::$bar['baz']() Foo::{$bar['baz']}() (Foo::$bar)['baz']()

Códigos que usam a ordem de avaliação da direita para esquerda devem ser reescritos para o uso explícito da ordem de avaliação com chaves (veja a coluna do meio). Isso fará com que o código seja compatível com versões posteriores ao PHP 7.x e compatível com o PHP 5.x.

Mudanças na manipulação com a função list()

A função list() não faz mais atribuições em ordem reversa

A função list() agora irá atribuir valores as variáveis na ordem em que foram definidas, em vez de ordem reversa. De modo geral, isso só afeta casos onde a função list() é utilizada em conjunção com o operador de array [], como mostrado a seguir:

<?php
list($a[], $a[], $a[]) = [123];
var_dump($a);
?>

O exemplo acima irá imprimir no PHP 5:

array(3) {
  [0]=>
  int(3)
  [1]=>
  int(2)
  [2]=>
  int(1)
}

O exemplo acima irá imprimir no PHP 7:

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}

De modo geral, é recomendo não confiar na ordem em que as atribuições com que a função list() ocorrem, como sua implementação detalha, isso pode mudar novamente no futuro.

Atribuições de list() vazias foram removidas

Chamadas a função list() não podem mais ser vazias. O que é visto a seguir não é mais permitido:

<?php
list() = $a;
list(,,) = 
$a;
list(
$x, list(), $y) = $a;
?>
A função list() não podem desempacotar strings

A função list() não podem mais desempacotar variáveis do tipo string. Em vez disso, a função str_split() deve ser usada.

A ordenação de arrays quando elementos são criados durante atribuições por referência mudou

A ordem dos elementos no array foi modificada quando estes elementos foram automaticamente criados por referenciação em uma atribuição por referência. Por exemplo:

<?php
$array 
= [];
$array["a"] =& $array["b"];
$array["b"] = 1;
var_dump($array);
?>

O exemplo acima irá imprimir no PHP 5:

array(2) {
  ["b"]=>
  &int(1)
  ["a"]=>
  &int(1)
}

O exemplo acima irá imprimir no PHP 7:

array(2) {
  ["a"]=>
  &int(1)
  ["b"]=>
  &int(1)
}

global somente aceita variáveis simples

Variáveis Variáveis não podem mais ser utilizadas com a palavra-chave global. A sintaxe com chaves pode ser utilizada para emular o comportamento anterior, se necessário.

<?php
function f() {
    
// Válido somente no PHP 5.
    
global $$foo->bar;

    
// Válido no PHP 5 e 7.
    
global ${$foo->bar};
}
?>

Como princípio básico, usar qualquer coisa senão uma variável normal com a a palavra-chave global é desencorajado.

Parênteses em torno de parâmetros de função não afetam mais seu comportamento

No PHP 5, usar parenteses redundantes em torno de parâmetros de uma função podem disparar avisos de quebra de padrões quando os parâmetros da função fossem passados por referência. Agora, o aviso sempre será emitido.

<?php
function getArray() {
    return [
123];
}

function 
squareArray(array &$a) {
    foreach (
$a as &$v) {
        
$v **= 2;
    }
}

// Generates a warning in PHP 7.
squareArray((getArray()));
?>

O exemplo acima irá imprimir:

Notice: Only variables should be passed by reference in /tmp/test.php on line 13

Mudanças no foreach

Pequenas mudanças foram feitas no modo como a estrutura de controle foreach se comporta, principalmente na manipulação do ponteiro interno do array e modificações no array sendo iterado.

foreach não modifica mais o ponteiro interno do array

Antes do PHP 7, o ponteiro interno do array era modificado enquanto o array era iterado usando o foreach. Este não é mais o caso, como mostrado nos exemplos a seguir:

<?php
$array 
= [012];
foreach (
$array as &$val) {
    
var_dump(current($array));
}
?>

O exemplo acima irá imprimir no PHP 5:

int(1)
int(2)
bool(false)

O exemplo acima irá imprimir no PHP 7:

int(0)
int(0)
int(0)

foreach por valor opera em uma cópia do array

Quando usado no modo padrão, por valor, o foreach vai operar em uma cópia do array sendo iterado, ao invés do próprio array. Isso significa que mudanças feitas durante a iteração do array, não afetarão os valores iterados.

Melhora no comporatamento da iteração por referência com foreach

Quanto iterado por referencia, o foreach fará um melhor trabalho de controlar as alterações feitas ao array durante a iteração. Por exemplo, inclusões ao array enquanto iterado, agora resultam na inclusão de valores enquanto itera, como a seguir:

<?php
$array 
= [0];
foreach (
$array as &$val) {
    
var_dump($val);
    
$array[1] = 1;
}
?>

O exemplo acima irá imprimir no PHP 5:

int(0)

O exemplo acima irá imprimir no PHP 7:

int(0)
int(1)

Iteração de objetos não Traversable

Iterar objetos não Traversable agora têm o mesmo comportamento que iterar arrays por referência. Isso resulta na melhora do comportamento quando houver modificações no array durante a iteração também aplicado quando propriedades são adicionadas ou removidas do objeto.

Mudança na manipulação do inteiro

Octais literais inválidos

Antes, octais literais que continham números inválidos, eram silenciosamente truncados (0128 se tornaria 012). Agora, um octal literal inválido causará um erro de parse.

Deslocamento de bits negativos

Deslocamento de bits por números negativos agora lançarão uma exceção ArithmeticError:

<?php
var_dump
(>> -1);
?>

O exemplo acima irá imprimir no PHP 5:

int(0)

O exemplo acima irá imprimir no PHP 7:

Fatal error: Uncaught ArithmeticError: Bit shift by negative number in /tmp/test.php:2
Stack trace:
#0 {main}
  thrown in /tmp/test.php on line 2

Deslocamentos de bits fora do limite

Deslocamentos de bits (em ambas direções), além do tamanho de bits de um inteiro sempre resultará em 0. Antes, o comportamento do deslocamento dependia da arquitetura.

Mudanças na Divisão por Zero

Antes, quando 0 era usado como divisor tanto para a operador de divisão (/) quanto para o módulo, um E_WARNING era emitido e false era retornado. Agora, o operador de divisão retornará um float +INF, -INF ou NAN, conforme a especificação IEEE 754. O E_WARNING do operador módulo foi removido e irá lançar uma exceção DivisionByZeroError.

<?php
var_dump
(3/0);
var_dump(0/0);
var_dump(0%0);
?>

O exemplo acima irá imprimir no PHP 5:

Warning: Division by zero in %s on line %d
bool(false)

Warning: Division by zero in %s on line %d
bool(false)

Warning: Division by zero in %s on line %d
bool(false)

O exemplo acima irá imprimir no PHP 7:

Warning: Division by zero in %s on line %d
float(INF)

Warning: Division by zero in %s on line %d
float(NAN)

PHP Fatal error:  Uncaught DivisionByZeroError: Modulo by zero in %s line %d

Mudanças na manipulação de strings

Strings hexadecimais não são mais consideradas numéricas

Strings contendo números hexadecimais não são mais consideradas numéricas. Por exemplo:

<?php
var_dump
("0x123" == "291");
var_dump(is_numeric("0x123"));
var_dump("0xe" "0x1");
var_dump(substr("foo""0x1"));
?>

O exemplo acima irá imprimir no PHP 5:

bool(true)
bool(true)
int(15)
string(2) "oo"

O exemplo acima irá imprimir no PHP 7:

bool(false)
bool(false)
int(0)

Notice: A non well formed numeric value encountered in /tmp/test.php on line 5
string(3) "foo"

filter_var() pode ser usado se uma string contém um número hexadecimal, e também para converter uma string deste tipo para um inteiro:

<?php
$str 
"0xffff";
$int filter_var($strFILTER_VALIDATE_INTFILTER_FLAG_ALLOW_HEX);
if (
false === $int) {
    throw new 
Exception("Inteiro Inválido!");
}
var_dump($int); // int(65535)
?>

\u{ pode causar erros

Por conta da adição da nova sintaxe de escape de códigos em Unicode, strings contendo um \u{ literal seguido de uma sequência inválida causará um erro fatal. Para evitar isso, você deve escapar a barra invertida.

Funções removidas

call_user_method() e call_user_method_array()

Estas funções foram depreciadas no PHP 4.1.0 em favor de call_user_func() e call_user_func_array(). Você também pode considerar o uso de funções variáveis e/ou o operador ... .

Todas as funções ereg*

Todas as funções ereg foram removidas. PCRE é uma alternativa recomendada.

Sinônimos do mcrypt

A função depreciada mcrypt_generic_end() foi removida em favor de mcrypt_generic_deinit().

Além disso, as funções depreciadas mcrypt_ecb(), mcrypt_cbc(), mcrypt_cfb() e mcrypt_ofb() foram removidas em favor do uso da função mcrypt_decrypt() com a constante MCRYPT_MODE_* apropriada.

Todas as funções ext/mysql

Todas as funções ext/mysql foram removidas. Para mais detalhes sobre a escolha de uma API MySQL diferente, veja a seção Escolhendo uma API MySQL.

Todas as funções ext/mssql

Todas as funções ext/mssql foram removidas. Para uma lista de alternativas, veja a Introdução ao MSSQL.

Sinônimos de intl

Os sinônimos depreciados datefmt_set_timezone_id() e IntlDateFormatter::setTimeZoneID() foram removidos em favor de datefmt_set_timezone() e IntlDateFormatter::setTimeZone(), respectivamente.

set_magic_quotes_runtime()

set_magic_quotes_runtime(), juntamente com seu sinônimo magic_quotes_runtime(), foram removidos. Eles foram depreciados no PHP 5.3.0 e se tornaram efetivamente não funcionais com a remoção das magic quotes no PHP 5.4.0.

set_socket_blocking()

O sinônimo depreciado set_socket_blocking() foi removido em favor de stream_set_blocking().

dl() no PHP-FPM

dl() não pode mais ser utilizado no PHP-FPM. Ela permanece funcional na interface CLI e SAPIs embarcadas.

Funções GD Type1

O suporte a fontes PostScript Type1 foi removido da extensão GD, resultando na remoção das seguintes funções:

O uso de fontes TruType e suas funções associadas é recomendado.

Diretivas INI removidas

Recursos removidos

As diretivas INI a seguir foram removidas, assim como os como seus recursos associados:

xsl.security_prefs

A diretiva xsl.security_prefs foi removida. Em substituição, o método XsltProcessor::setSecurityPrefs() deve ser chamado para controlar as preferências de segurança por processo base.

Outras mudanças incompatíveis com versões anteriores

Novos objetos não podem ser atribuídos por referência

O resultado da declaração new não pode mais ser atribuído a uma variável por referência:

<?php
class {}
$c =& new C;
?>

O exemplo acima irá imprimir no PHP 5:

Deprecated: Assigning the return value of new by reference is deprecated in /tmp/test.php on line 3

O exemplo acima irá imprimir no PHP 7:

Parse error: syntax error, unexpected 'new' (T_NEW) in /tmp/test.php on line 3

Nomes inválidos de classes, interfaces e traits

Os nomes a seguir não podem ser utilizados como nome de classes, interfaces ou traits:

Além disso, os seguintes nomes não devem ser usados. Embora eles não gerem um erro no PHP 7.0, eles são reservados para uso futuro e devem ser considerados depreciados.

Tags ASP e script removidas

O suporte ao uso das tags ASP e script para delimitar o código PHP foi removido. As tags afetadas são:

Tags ASP e script removidas
Tag de abertura Tag de fechamento
<% %>
<%= %>
<script language="php"> </script>

Chamadas de contextos incompatíveis foram removidas

Anteriormente depreciadas no PHP 5.6, chamadas estáticas feitas a métodos não-estáticos com um contexto incompatível agora resultarão no método chamado tendo uma variável $this indefinida e um aviso de depreciação será emitido.

<?php
class {
    public function 
test() { var_dump($this); }
}

// Nota: NÃO extende A
class {
    public function 
callNonStaticMethodOfA() { A::test(); }
}

(new 
B)->callNonStaticMethodOfA();
?>

O exemplo acima irá imprimir no PHP 5:

Deprecated: Non-static method A::test() should not be called statically, assuming $this from incompatible context in /tmp/test.php on line 8
object(B)#1 (0) {
}

O exemplo acima irá imprimir no PHP 7:

Deprecated: Non-static method A::test() should not be called statically in /tmp/test.php on line 8

Notice: Undefined variable: this in /tmp/test.php on line 3
NULL

yield agora é um operador associativo à direita

O construtor yield não requer mais o uso de parênteses e foi alterado para um operador associativo à direita com precedência entre print e =>. Isso pode resultar em um comportamento alterado:

<?php
echo yield -1;
// Era interpretado como
echo (yield) - 1;
// E agora é interpretado como
echo yield (-1);

yield $foo or die;
// Era interpretado como
yield ($foo or die);
// E agora é interpretado como
(yield $foo) or die;
?>

Parênteses podem ser utilizados para remover a ambiguidade nestes casos.

Funções não podem ter vários parâmetros com o mesmo nome

Não é mais possível definir dois ou mais parâmetros em uma função com o mesmo nome. Por exemplo, a função a seguir vai disparar um E_COMPILE_ERROR:

<?php
function foo($a$b$unused$unused) {
    
//
}
?>

Funções inspecionando argumentos informam o valor atual do parâmetro

func_get_arg(), func_get_args(), debug_backtrace() e backtraces de exceção não informam mais o valor original que foi passado para um parâmetro, mas ao invés disso, irão informar o valor atual (que pode ter sido modificado).

<?php
function foo($x) {
    
$x++;
    
var_dump(func_get_arg(0));
}
foo(1);?>

O exemplo acima irá imprimir no PHP 5:

1

O exemplo acima irá imprimir no PHP 7:

2

Declarações switch não podem ter vários blocos default

Não é mais possível definir dois ou mais blocos default em uma declaração switch. Por exemplo, a declaração switch a seguir irá disparar um E_COMPILE_ERROR:

<?php
switch (1) {
    default:
    break;
    default:
    break;
}
?>

$HTTP_RAW_POST_DATA removida

A variável $HTTP_RAW_POST_DATA não está mais disponível. Ao invés disso o stream php://input deve ser utilizado.

Comentários iniciados com # nos arquivos INI foram removidos

O suporte a comentários prefixados com # nos arquivos INI foi removido. Em vez disso, o ; (ponto-e-vírgula) deve ser usado. Esta mudança aplica-se ao php.ini, assim como aos arquivos manipulados pelas funções parse_ini_file() e parse_ini_string().

Substituição da extensão JSON por JSOND

A extensão JSON foi substituída por JSOND, causando três quebras menores de compatibilidade com versões anteriores. Em primeiro lugar, um número não pode ser terminado em um ponto decimal (isto é, 34. deve ser modificado para 34.0 ou 34). Em segundo lugar, ao usar notação científica, o expoente e não deve seguir imediatamente o ponto decimal (isto é, 3.e3 deve ser modificado para 3.0e3 ou 3e3). Finalmente, uma string vazia não é mais considerada JSON válido.

Função interna falha em caso de estouro

Antes, funções internas silenciosamente truncavam números produzidos por coerções de pontos flutuantes para inteiros quando o ponto flutuante era grande demais para ser representado como um inteiro. Agora um E_WARNING será emitido e NULL será retornado.

Ajustes nos valores retornados pelo manipulador de sessão customizado

Quaisquer funções de predicado implementadas por manipuladores de sessões customizados que retornem FALSE ou -1 resultarão em erros fatais. Se qualquer valor retornado destas funções não é um booleano, -1 ou 0, então ela irá falhar e um E_WARNING será emitido.

Ordenações de elementos iguais

O algoritmo interno de ordenação foi melhorado, o que pode resultar em diferentes ordenações de elementos, que são comparados como iguais, do que antes.

Nota:

Não confie na ordem de elementos que são comparados como iguais; ela pode mudar a qualquer momento.

Mhash não é mais uma extensão

A extensão Mhash foi completamente integrada na extensão Hash. Portanto, não é mais possível detectar o suporte à extensão Mhash com extension_loaded(); em vez disso use function_exists(). Além disso, Mhash não é mais informada por get_loaded_extensions() e recursos relacionados.

add a note add a note

User Contributed Notes 9 notes

up
153
me at fquff dot io
1 year ago
[Editor's note: fixed limit on user request]

As a mathematician, 3/0 == +INF IS JUST WRONG. You can't just assume 3/0 == lim_{x->0+} 3/x, which is +INF indeed, because division IS NOT A CONTINUOUS FUNCTION in x == 0.

Also, 3/0 == +INF ("positive" infinity) while -3/0 == -INF ("negative" infinity) requires the assumption that 0 is a positive number, which is just as illogical as it looks like.

The fact that a warning is emitted is good, but it should definitely equals to NaN. ±INF is just illogical (and arithmetically wrong).

Except for this "detail", looks an amazing update, can't wait to test it even further!

Cheers,
P.
up
69
mossy2100
1 year ago
Although $x/0 is technically not infinity in a purely mathematical sense, when you understand why the IEEE float includes a value for infinity, and returns infinity in this case, it makes sense that PHP would agree with this.

The reason is that programmers don't usually divide by 0 on purpose. A value of 0 as a divisor usually occurs due to underflow, i.e. a value which is too small to be represented as a float. So, for example, if you have values like:
$x = 1;
$y = 1e-15 * 1e-15;
$z = $x/$y;
Because $y will have underflowed to 0, the division operation will throw the division by zero warning, and $z will be set to INF. In a better computer, however, $y would not have the value 0 (it would be 1e-30) and $z would not have the value INF (it would be 1e30).

In other words, 0 is not only representative of an actual 0, but also a very small number which float cannot represent correctly (underflow), and INF does not only represent infinity, but also a very big number which float cannot represent correctly (overflow). We do the best we can within the limitations of floating point values, which are really just good approximations of the actual numbers being represented.

What does bother me is that division by zero is handled in two different ways depending on the operator. I would have preferred the new DivisionByZeroError exception to be thrown in all cases, for consistency and to enforce good programming practices.
up
89
tuxedobob
1 year ago
As a programmer, I don't care whether 3/0 is INF or NaN. Both answers are (probably) equally useless, and tell me that something somewhere else is screwed up.
up
4
maba at mb-systemhaus dot net
1 year ago
NOTE:
the new variable handling in PHP 7 also has side effects on the COM .NET extension. Numeric variants (in the Windows application space) now must be quoted when passed over from PHP. This is the case when the receiving application expects a variable of type variant.

Here is an example:

<?php
  $word
= new COM('Word.Application');

 
// now load a document, ...

  // the following works in PHP 5 but will throw an exception in PHP 7
 
$word->ActiveDocument->PrintOut(false, false, 0, $outfile);

 
// the following works in PHP 7 as well, please note the quotes around the '0'
 
$word->ActiveDocument->PrintOut(false, false, '0', $outfile);
?>
up
3
viktor dot csiky at nospam dot nospam dot eu
1 year ago
It is stated:

"foreach by-value operates on a copy of the array

When used in the default by-value mode, foreach will now operate on a copy of the array being iterated rather than the array itself. This means that changes to the array made during iteration will not affect the values that are iterated."

Please note that this is not exactly true. New foreach operates on a copy of the array, by-value or by-reference. It seems that in the latter case, the array copy is simply moved over (to) the original array before it is presumably destroyed.

As a consequence of this, you may not "dereference" an array containing values - e.g. for use with ReflectionMethod::invokeArgs() or the good ole' call_user_func().
Consider the snippet below:

<?php
function deref(Array $inputArray)
{
       
$retVal = [];
       
        foreach (
$inputArray as &$inputValue)
        {
           
$retVal[] = $inputValue;
        }

        return
$retVal;
}
?>

As of PHP 7.0, this *will no longer work*. You will get the usual suspect:

PHP Warning:  Parameter n to whatever() expected to be a reference, value given in baz.php on line x

You need to convert it to explicitly reference the original array:
<?php
function deref(Array $inputArray)
{
       
$retVal = [];
       
        foreach (
$inputArray as $inputKey => $inputValue)
        {
           
$retVal[$inputKey] = &$inputArray[$inputKey];
        }

        return
$retVal;
}
?>

PLEASE NOTE that this might have the unforeseen consequence of your code not working anymore in php versions less than 5.3 (that is, 5.2 and below).
up
4
Frank
1 year ago
[Editor's Note: that change is listed in the "Changed functions" section.]

The substr function has also been changed in a backward incompatible way.

<?php
substr
("test",4);  # false in PHP 5,  "" in PHP 7
?>

In fact, this is the only thing we had to change in a number of places for our code base to run on PHP 7. It's definitely an improvement though, as the old behavior tended to cause bugs in border cases.
up
-2
Ray.Paseur sometimes uses Gmail
7 months ago
In the section captioned "Changes to the handling of indirect variables, properties, and methods" there are parentheses used in the table directly beneath "PHP 7 interpretation." 

The parentheses are intended to show the evaluation order, but they are not part of the syntax, and should not be used in the variable definition or reference.  This juxtaposition confused one of my colleagues; hopefully this note will save someone else some time.

Examples of the correct curly-brace syntax is further down the page, in the section captioned "global only accepts simple variables."
up
-8
pablomartinrimoli2012 at gmail dot com
3 months ago
I have a question, the call to mysql conection, has changed?
To Top