v2.0.x Probleme mit PHP 5.4....

Ich habe mir einen neuen Rechner gegönnt (mit Core I5 3. Generation, 8GB Speicher, SSD Systwmlauferk: das rockt!), und da das aktuellste XAMPP mit PHP 5.4.4 und MySQL 5.5.25a installiert.

Und da gibt es einige Probleme.

MySQL versteht "TYPE=" im "CREATE DATABASE"-Statement nicht mehr, das muss jetzt "ENGINE=" sein (betrifft das Backup und z.B. MySQLDumper/PHPMyAdmin).

Bei PHP sind jetzt einige Dinge nicht mehr nur "DEPRECATED", sondern schlicht weg!

z.B. die "session_is_registered" und "session_register" und "session_unregister" in "includes/functions/sessions.php". (http://php.net/manual/en/function.session-register.php)

Lösung:

in "includes/functions/sessions.php"

nach

PHP:

if (STORE_SESSIONS == 'mysql') {

einfügen:

PHP:

  //Avenger
  if (!function_exists('session_register')) 
  {
    function session_register()
    {
      $args = func_get_args();
      foreach ($args as $key)
      {
        $_SESSION[$key]=$GLOBALS[$key];
      }
    }
    function session_is_registered($key)
    {
      return isset($_SESSION[$key]);
    }
    function session_unregister($key)
    {
      unset($_SESSION[$key]);
    }
  };
  //Avenger

Da werden sicher noch einige Dinge mehr kommen....

 

Ein weiteres Problem:

Die "htmlspecialchars"-Funktion liefert bei Strings mit Umlauten einen leeren String zurück!

Grund: UTF-8 ist jetzt der Standard-Zeichensatz.....

 

Und das ist noch nicht mal ein Widerspruch....

Das erste Problem bemerkt man, wenn man die Sessions in der DB führt, das zweite, wenn der DB-Zeichensatz nicht UTF-8 ist....

 

Dazu gehört auch "Call time pass by reference"....

Also so was:

Und davon gibt es jede Menge in Gambio.

 

Da habe ich lange 'rumgebastelt:

Um auch in Shops mit nicht UTF-8-Zeichensatz Strings mit Sonderzeichen richtig zu konvertieren, muss man "htmlspecialchars" wie folgt aufrufen:

PHP:

htmlspecialchars($string,ENT_SUBSTITUTE,$_SESSION['language_charset']),

$_SESSION['language_charset'] sollte bei der Initialisierung in eine Konstante konvertiert werden

PHP:

define('LANGUAGE_CHARSET',$_SESSION['language_charset']);

damit nicht jedesmal "$_SESSION['language_charset']" ausgewertet werden muss, so dass man die Funktion dann so aufruft:

PHP:

htmlspecialchars($string,ENT_SUBSTITUTE,LANGUAGE_CHARSET),

Ohne das wird in einem solchen Fall ab PHP 5.4 ein leerer String zurückgeliefert.

Also, liebe Gambioner, frisch an's Werk, es gibt viel zu tun....

 

Die einfachere Lösung dürfte sein, eine eigene "htmlspecialchars"-Funktion zu definieren ("pt_htmlspecialchars"), die die neuen Gegebenheiten berücksichtigt.

Dann kann man nämlich im Shop-Code einfach global "htmlspecialchars" in "pt_htmlspecialchars" ändern, und muss nicht jedes einzelne Auftreten von "htmlspecialchars" anpacken.

PHP:

//Adjust for different "htmlspecialchars" handling from PHP 5.4. onwards
//Default charset is then "UTF-8", so that empty strings are returned in different charsets
//if the string contains special characters 

define('LANGUAGE_CHARSET',strtoupper($_SESSION['language_charset']));
if (!defined('ENT_SUBSTITUTE')) 
{
  define('ENT_SUBSTITUTE', 0);
}

function pt_htmlspecialchars($string)
{
  return htmlspecialchars($string,ENT_QUOTES | ENT_SUBSTITUTE,LANGUAGE_CHARSET);
}

Ich habe die Routine in meine "ApplicationTopExtender"-Overloads im Shop und Admin gepackt.

Gambio kann das sicher in direkt in die "application_top.php" packen....

 

Diese Implementierung war nicht ausreichend, da teilweise im Gambio-Code auch optionale Parameter mitgegeben werden.

Das ist das, was ich derzeit verwende:

PHP:

$s='LANGUAGE_CHARSET';
if (!defined($s))
{
  define($s,strtoupper($_SESSION['language_charset']));
  if (!defined('ENT_SUBSTITUTE')) 
  {
    define('ENT_SUBSTITUTE', 0);
  }

  function pt_htmlspecialchars($string, $flags = 0, $encoding = '', $double_encode = false)
  {
    $flags=$flags | ENT_QUOTES | ENT_SUBSTITUTE;
    if (!$encoding)
    {
      $encoding=LANGUAGE_CHARSET;
    }
    return htmlspecialchars($string, $flags, $encoding, $double_encode);
  }
}

Diesen Code habe ich in meine "AdminApplicationTopExtenderComponent"- und "ApplicationTopExtenderComponent"-Overloads eingebaut.

 

Ein großes Problem ist, dass man normalerweise Fehler erst bemerkt, wenn man im Rahmen der Shop-Ausführung darauf stößt.

Was natürlich sehr unbefriedigend ist.

Und den Code systematisch aufgrund der PHP 5.4-Restriktionen danach zu durchsuchen, ist kaum möglich.

Ich habe aber eine Lösung für dieses Problem gefunden: IonCube!

IonCube ist ja eigentlich dazu gedacht, PHP-Programme zu verschlüsseln, aber vor der Verschlüsselung macht IonCube eine komplette Syntax-Prüfung der Module!

Und gibt eine wunderbare Fehlerliste aus, wo es Fehler entdeckt hat...

Problem im Moment ist, dass es erst bei Version PHP 5.3.x steht, aber eine PHP 5.4 basierende Version ist angekündigt.

Das dürfte die Code-Bereinigung enorm erleichtern.

 

Das "htmlspecialchars"-Problem kann man auch dadurch lösen, dass man die Datenbank-Daten zu UTF-8 kopiert (was ja künftig sowieso der Gambio-Standard werden soll).

Ich habe mir dazu ein Proggy entwickelt, das eine DB zu dem gewünschten "charset" und der gewünschten "collation" konvertiert.

Das Programm "convert_db_charset.php" aus anhängendem Archiv in die Shop-Root kopieren,

Am Anfang des Programms findet man die folgenden Befehle, mit denen man die Zieldaten wählen kann:

PHP:

$target_charset='utf8';
$target_collation='utf8_general_ci';

Als Admin einloggen, und dann in der Adresszeile aufrufen.

Es gibt keinerlei Gewährleistung, Anwendung auf eigenes Risiko.

Datenbank vor Anwendung sichern.

Am besten auf Kopie der Datenbank anwenden.

 

MySQL ist per se nicht case-sensitive...

Die "case-sensitive" Suche wird in GMSeoboost aber (bei alten MySQL-Versionen) durch das Vorsetzen von 'BINARY ' vor dem Suchbegriff erzwungen....

PHP:

    function set_binary_string()
    {
        if($this->is_collation_supported() === false)
        {
            $this->v_binary_string = 'BINARY ';
        }
        else
        {
            $this->v_binary_string = '';
        }
    }

Wenn man das immer erzwingt, dann hat man das Problem los.

 

Nein.

Es löst ein Problem....

Und bringt die DB auf einen modernen Character-Set-Stand.