OXID & Emojis in URL - utf8mb4_bin?

Moin!

Emojis kann man inzwischem im Thunderbird bei seinem Absendernamen einbauen und sind überall Standard.

Wenn man nach “emoji liste” googlet findet man einige Treffer mit Emojis im Title und Snippet. Finde ich sehr interessant, da genau diese Treffer hervorstechen. (ob seriös oder nicht ist eine andere Baustelle :wink:

Ich würde nun gerne zumindest in unseren Title und Kategorie-URL entsprechend den Artikeln Emojis einbauen. Nur leider läuft OXID unter UFT8 - Emjos benötigen aber utf8mb4_bin soweit ich weiß.

In der Datenbank habe ich es testhalber bei “OXSTARTTITLE_1” mal umgestellt. Ich kann die Emojis nun zwar in SQL speichern, aber im OXID Admin sehe ich statt den Emojis nur zwei Fragezeichen. :frowning:

Den ganzen OXID auf ein anderes charset umstellen will ich natürlich nicht. Aufwand wäre beim nächsten Update für die Tonne. Gibt es noch einen anderen Weg?

Danke
Heiko

nein, man muss dafür die Codierung der Verbindung zur Datenbank ändern, das ist eine Änderung am Core und geht afaik nicht in einem Modul.

OXID. 4.10.x

core/oxdb.php

/**
* Setting up connection parameters - sql mode, encoding, logging etc
*
* @param ADOConnection $oDb database connection instance
*/
protected function _setUp($oDb)
{
// @deprecated since v5.3.0 (2016-06-07).
// The SQL logging feature is deprecated. This feature will be removed.
$_iDebug = self::_getConfigParam(’_iDebug’);
if ($_iDebug == 2 || $_iDebug == 3 || $_iDebug == 4 || $_iDebug == 7) {
try {
$oDb->execute(‘truncate table adodb_logsql’);
} catch (ADODB_Exception $e) {
// nothing
}
if (method_exists($oDb, “logSQL”)) {
$oDb->logSQL(true);
}
}
// END deprecated

    $oDb->cacheSecs = 60 * 10; // 10 minute caching
    $oDb->execute('SET @@session.sql_mode = ""');

    if (self::_getConfigParam('_iUtfMode')) {
        $oDb->execute('SET NAMES "utf8mb4"');
        $oDb->execute('SET CHARACTER SET utf8mb4');
        $oDb->execute('SET CHARACTER_SET_CONNECTION = utf8mb4');
        $oDb->execute('SET CHARACTER_SET_DATABASE = utf8mb4');
        $oDb->execute('SET character_set_results = utf8mb4');
        $oDb->execute('SET character_set_server = utf8mb4');
    } elseif (($sConn = self::_getConfigParam('_sDefaultDatabaseConnection')) != '') {
        $oDb->execute('SET NAMES "' . $sConn . '"');
    }
}

so sollte das klappen, aber wie gesagt, ziemlicher hack…

wobei du recht hast, die utf8 codierung ist total kaputt und mb4 gehört dringend in den oxid.

1 Like

Danke. Dazu müsste ich aber wohl die gesamte DB auf uft8mb4 umstellen.
Wobei rein von der Logik utf8mb4 mit UTF8 zurecht kommen müsste - nur nicht anders herum!? :slight_smile:

utf8mb4 ist halt idiotensicher bzw. variabler.

Vielleicht kann das auf die to do Liste von den Entwicklern :wink:

ja, du kannst du die spalten die du brauchst auf utf8mb4 umstellen und den rest so lassen, is halt hässlich, v.a. der DB Connection hack.

Jetzt wird es interessant.
Ich habe dieses Emoji in die Meta Description eingebaut:
:white_check_mark:

Das speichert OXID ohne (!) Änderungen und wird so auch bei google angezeigt.
(www.sotel.de bei google falls es jemand nicht glaubt)

Wieso klappt es dann bei title und Menüs nicht!?

welche title und menüs meinst du?

Einmal Grundeinstellungen => Seo => Titel der Startseite und dann eben die Kategorienamen.

Hier würde es sich bei google glaube ich sehr gut machen, wenn das passende Emoji neben dem Kategorienamen in den Suchtreffern des Kunden auftaucht.

ALTER TABLE oxshops CHANGE OXNAME OXNAME VARCHAR( 255 ) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’ COMMENT ‘Shop name’;
ALTER TABLE oxshops CHANGE OXTITLEPREFIX OXTITLEPREFIX VARCHAR( 255 ) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’ COMMENT ‘Shop name’;

damit seh ich emojis im title

Titel der Startseite: ALTER TABLE oxshops CHANGE OXSTARTTITLE OXSTARTTITLE VARCHAR( 255 ) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’ COMMENT ‘Shop name’;

alles ohne gewähr :wink:

Danke - wird getestet und Rückmeldung kommt :slight_smile:

Eine Ergänzung zu dem Thema:

ALTER TABLE oxorderarticlesCHANGEOXPERSPARAM OXPERSPARAM TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT 'Serialized persistent parameters';

1 Like

Hallo @Jb123 danke für die ganzen Infos.

Wir würden ebenfalls, wie @Hisky es hier aufführt, Emojis in unseren Seitentitel verwenden.

Kurze Frage nur: In welcher Version wird dieser Code Change eingebaut? Und müssen wir die Datenbank dann selbstständig auf utf8mb4 umstellen? bzw. die betroffenen Felder selbst in der Datenbank umstellen?

An diesem Merge kann man erkennen, dass der Code Change im Master ist und es gibt ein Release Flag ab der Version v6.4.0 demnach ist es ab dieser Version verfügbar?

Könnt ihr mir noch einen kurzen Zusammenhang zwischen den GitHub Stand und den Stand bei OXIDforge erklären?
Im Release Plan gibt es diese Version nämlich noch nicht.

Sorry für diese Anfänger fragen, ich möchte gerne den Zusammenhang verstehen. Würde mich auch über eine Antwort per PM freuen, damit wir diesen Thread hier nicht sprengen. :slight_smile: :bomb:

Schau mal hier: OXID Forge – Die Knowledge Base rund um den OXID eShop

Der Shop, so wie er ausgeliefert wird, ist eine “Compilation” mit eigener Versionierung. Diese Compilation besteht aus mehreren Komponenten, die ebenfalls eigens versioniert werden. Die Compilation (aktuell) OXID eShop v6.2.1 EE besteht also aus den Komponenten OXID CE Komponente 6.5.3 + OXID PE Komponente 6.4.0 + OXID EE Kommponente 6.5.2 + Klarna 5.1.4 usw…
In den Release Notes wird das jeweils unter “Compilation” vermerkt: Releases — OXID eSales Documentation

1 Like

Also in der 6.2 wurde nun der Config Parameter für das Database Encoding eingebaut.
in der 4er Version muss man den DB Charset in der Connection anpassen (core/oxdb.php / ADOConnection). In der 6.0-6.1 muss man auch das Core File hacken:

DatabaseProvider.php:

/**
* Get all parameters needed to connect to the database.
*
* @return array
/
protected function getConnectionParameters()
{
/
* Collect the parameters, that are necessary to initialize the database connection: */

    /**
     * @var string $databaseDriver At the moment the database adapter uses always 'pdo_mysql'.
     */
    $databaseDriver = $this->getConfigParam('dbType');
    /**
     * @var string $databaseHost The database host to connect to.
     * Be aware, that the connection between the MySQL client and the server is unencrypted.
     */
    $databaseHost = $this->getConfigParam('dbHost');
    /**
     * @var integer $databasePort TCP port to connect to.
     */
    $databasePort = (int) $this->getConfigParam('dbPort');
    if (!$databasePort) {
        $databasePort = 3306;
    }
    /**
     * @var string $databaseName The name of the database or scheme to connect to.
     */
    $databaseName = $this->getConfigParam('dbName');
    /**
     * @var string $databaseUser The user id of the database user.
     */
    $databaseUser = $this->getConfigParam('dbUser');
    /**
     * @var string $databasePassword The password of the database user.
     */
    $databasePassword = $this->getConfigParam('dbPwd');

    $connectionParameters = [
        'default' => [
            'databaseDriver'    => $databaseDriver,
            'databaseHost'      => $databaseHost,
            'databasePort'      => $databasePort,
            'databaseName'      => $databaseName,
            'databaseUser'      => $databaseUser,
            'databasePassword'  => $databasePassword,
        ]
    ];

    /** The charset has to be set during the connection to the database */
    $charset = 'utf8mb4';
    $connectionParameters['default'] = array_merge($connectionParameters['default'], ['connectionCharset' => $charset]);

    return $connectionParameters;
}

Um das Update safe zu gestalten habe ich einen Composer Post Hook der mir die Datei immer wieder restored. Aber Hacky isses allemal.

1 Like

Vielen Dank euch beiden!

@marco.steinhaeuser der Link ist grandios, schön runtergebrochen! Eigentlich muss nur die Datenbankverbindung auf utf8mb4 umgestellt werden, und die relevanten Spalten in der Datenbank. Also für uns konkret die Spalte die den Seitentitel speichert!

Wir werden dann mal intern klären ob wir auf Version 6.x.x updaten oder erstmal mit einer “hacky” Lösung arbeiten unter der Version 4.10.3 - Ähnlich wie @Jb123 es vorgeschlagen hat.

@marco.steinhaeuser danke für die Erläuterung mit der “Compilation”, eine Frage stellt sich mir dabei allerdings noch. Ich kenne es von anderen Systemen, dass es eine “Core” gibt und dann viele weitere Module/Komponenten die dazu gehören. Gibt es hier auch eine Core? Auf den Blick hätte ich jetzt gedacht ist es die OXID CE component bzw. alle drei zusammen? Oder nur eine von den dreien?

Und überhaupt, was ist der Unterschied zwischen CE und PE und EE? Ich hab im GitHub Projekt nur die CE-Version gefunden (Community Edition)

sind dann PE = Professional Edition? und EE = Enterprise Edition?

Okay ich hab diesen Blog Post dazu gefunden.

Zitat:

CONTRIBUTIONS
As of OXID eShop series 6, NDA signees can optionally apply for GitHub access to the repositories of Professional and Enterprise Edition.

Deshalb finde ich nichts bei GitHub :smiley:

So ganz habe ich aber noch nicht verstanden warum es diese Unterschiede zwischen diesen drei Komponenten gibt, und vorallem warum alle drei in einen Paket sind.

Sind das evtl. Überbleibsel von früher? Gab es früher drei Entwicklungsstränge? Und diese wurden jetzt zusammen geführt? Und es ist einfacher alle drei als Modul zusammen einzubinden?

was man aber beachten muss, das man beim Datebankbackup (mysqldump) das Encoding bedenkt…

OXID-eSales/oxideshop_ce ist der Core. Nur dieser wird für die Compilation der Community Edition benötigt. Bei einer Professional Edition kommt noch die Komponente OXID-eSales/oxideshop_pe (private) oben drauf; analog bei einer Enterprise Edition die Komponente OXID-eSales/oxideshop_ee (ebenfalls private) on top :wink:

2 Likes

Super Dankeschön @marco.steinhaeuser!

Und hier gibt es eine schöne Gegenüberstellung was die verschiedenen Editions von OXID voneinander unterscheidet: