Tag Plugin Problem?

[seraphyn]

Stimmt, ist es.
Danke Dir...

[seraphyn]

Also,

templates_c-Inhalt gelöscht.
Datenbankinhalt komplett gelöscht, vorher einen Dump mit mysql-workbench gemacht.
In dem Dump dann dann per sed alle latin1 in utf8 ( CHARSET=utf8) geändert.
Collation ist bei mir nun auch utf8_general_ci.
Trotzdem kommt es bei mir zu einem / COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'
Ein egrep brachte mir auch kein latin1. Suche mit phpmyadmin auch nicht.
Mit Datenbank-Zeichensatzkonvertierung aktivieren JA, habe ich die Umlaute etc im Eimer, aber es geht.
Soll ich nun noch den kompletten Zeichensatz konvertieren?
chris

EDIT: Moment, ich probiere es mal mit iconv

[Timbalu]

Schnell mal was geklaut...

Stand/steht dein Blog denn vorher auf "Nativer" Zeichensatz oder "UTF-8"?

Hast Du die Option "Datenbank-Zeichensätze aktivieren" aktiviert oder deaktiviert?

Von den beiden Einstellungen hängt s9y seitig alles ab. Ich würde es so einstellen, dass dann deine alten Beiträge korrekt dargestellt werden. Die neu eingepflegten werden dann falsch aussehen, aber wenn du dann neue einstellst, sind die wieder richtig.

[seraphyn]

Mein Blog steht von Anfang an auf UTF-8 in Zeichensatz-Auswahl.
Mit option meinst Du/Er Datenbank-Zeichensatzkonvertierung aktivieren?
Wenn ich das mache dann haben wir die netten ß Zeichen anstelle den Umlauten etc und Tags gehen.
Wenn ich Die Option ausschalte ist alles perfekt, aber die Tags sind der Meinung das Latin1 vorhanden wäre...
Deswegen ja mein Hänger...

Gruss

EDIT:
ps: iconv hat leider nicht funkioniert

[Timbalu]

Code: Select all

SELECT 
                    ep_sticky.value AS orderkey,

                    e.id,
                    e.title,
                    e.timestamp,
                    e.comments,
                    e.exflag,
                    e.authorid,
                    e.trackbacks,
                    e.isdraft,
                    e.allow_comments,
                    e.last_modified,

                    a.realname AS author,
                    a.username AS loginname,
                    a.email
                     , e.body, e.extended
                     
                FROM
                    serendipity_entries AS e
                    LEFT JOIN serendipity_authors a
                        ON e.authorid = a.authorid
                    LEFT JOIN serendipity_entrycat ec
                        ON e.id = ec.entryid
                    LEFT JOIN serendipity_category c
                        ON ec.categoryid = c.categoryid
                    INNER JOIN serendipity_entrytags AS entrytags ON (e.id = entrytags.entryid)  LEFT OUTER JOIN serendipity_entryproperties ep_access
                                              ON (e.id = ep_access.entryid AND ep_access.property = 'ep_access')
 LEFT JOIN serendipity_entryproperties ep_sticky
                                            ON (e.id = ep_sticky.entryid AND ep_sticky.property = 'ep_is_sticky') LEFT JOIN serendipity_authorgroups AS acl_a
                                   ON acl_a.authorid = 0
                            LEFT JOIN serendipity_access AS acl_acc
                                   ON (    acl_acc.artifact_mode = 'read'
                                       AND acl_acc.artifact_type = 'category'
                                       AND acl_acc.artifact_id   = c.categoryid
                                      )
                    WHERE isdraft = 'false' AND e.timestamp <= 1308754800 AND entrytags.tag = 'serendipity' COLLATE utf8_unicode_ci  AND  (ep_access.property IS NULL OR ep_access.value = 'public')  AND     (
                                 c.categoryid IS NULL
                                 OR ( acl_acc.groupid = 0)
                                 OR ( acl_acc.artifact_id IS NULL
                                      
                                    )
                               )
                     GROUP BY e.id
                     
                     ORDER BY orderkey DESC, timestamp DESC
                      LIMIT 5

funktioniert! Gerade in PhpMyAdmin getestet.
Kollation von Tabelle serendipity_entrytag bei mir ist utf8_general_ci und innerhalb der Tabelle von tag auch utf8_general_ci. Vielleicht liegts ja an _general_?!
Wenn ich das Query mit COLLATE utf8_general_ci suchen lassen geht es übrigens auch.

[Timbalu]

Probiere mal:

Code: Select all

ALTER TABLE `serendipity_entrytags` CONVERT TO CHARACTER SET utf8
COLLATE utf8_unicode_ci

Damit sollte das gehen...

[seraphyn]

Hat leider auch nicht geholfen.
Siehe http://seraphyn.teiko.org/plugin/tag/freebsd

Verstehe ich nicht, woher er auf Latin1 kommt....

ps: war eben ein wenig Off haben hier ein nettes Unwetter

[Timbalu]

Bei mir ging das. Damit habe ich den table von utf8_general_ci auf unicode gestellt.

Code: Select all

CREATE TABLE IF NOT EXISTS `serendipity_entrytags` (
  `entryid` int(10) NOT NULL,
  `tag` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`entryid`,`tag`),
  KEY `tagsentryindex` (`entryid`),
  KEY `tagsTagIndex` (`tag`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Sonst kipp deine entrytags Daten mal hier rein (vorher backup und table löschen).

[seraphyn]

Schau Dir mal den Screenshot an:

2011-06-22-183527_1024x600_scrot.png (132.83 KiB) Viewed 5748 times

Also es sollte ja nun UTF sein.
Da hänge ich an dem Punkt.
Sehr nervig.. und ka warum.

[seraphyn]

Also ich habe nun die Tabelle serendipity_entrytags gelöscht.
Vorher ein Backup gemacht.
Dann in die SQL das Statement zum erstellen geändert auf Deines:

Code: Select all

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `serendipity_entrytags`
--

CREATE TABLE IF NOT EXISTS `serendipity_entrytags` (
`entryid` int( 10 ) NOT NULL ,
`tag` varchar( 50 ) COLLATE utf8_unicode_ci NOT NULL ,
PRIMARY KEY ( `entryid` , `tag` ) ,
KEY `tagsentryindex` ( `entryid` ) ,
KEY `tagsTagIndex` ( `tag` ) 
) ENGINE = MYISAM DEFAULT CHARSET = utf8 COLLATE = utf8_unicode_ci;


--
-- Daten für Tabelle `serendipity_entrytags`
--

INSERT INTO `serendipity_entrytags` (`entryid`, `tag`) VALUES
(1, 'Blog'),
(2, 'RealLife'),

BLABLABLA

Fehler ist immer noch der Selbe.
Also er muss an einer ganz anderen Stelle hängen.

[Timbalu]

Hmmm,
und wenn du auf Datenbank:teikoa_db2 drückst und dir deine Tabllen anschaust, steht by entrytags ausdrücklich auch MyISAM utf8_unicode_ci?
Was macht ein nochmaliger ALTER TABLE `serendipity_entrytags` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci?

Das ist auch wirklich die benutzte Datenbank?

[seraphyn]

Hmmm,
und wenn du auf Datenbank:teikoa_db2 drückst und dir deine Tabllen anschaust, steht by entrytags ausdrücklich auch MyISAM utf8_unicode_ci?

serendipity_entrytags 2,743 MyISAM utf8_unicode_ci 140,0 KiB

Was macht ein nochmaliger ALTER TABLE `serendipity_entrytags` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci?

Das ist auch wirklich die benutzte Datenbank?

Ja ist es wirklich, ich habe nur zwei, eine alte Drupal 7 die ich noch mitschleppe, weil ich Jemanden dort geholfen habe und jene.
Mehr gibt es nicht-
Nochmaliges brachte wie vorher ein Ihr SQL-Befehl wurde erfolgreich ausgeführt. (die Abfrage dauerte 0.0692 sek.)
Und mir immer noch die gleiche Fehlermeldung bei dem anklicken eines Tags.
Das ist ja genau jenes was ich nicht verstehe.

[Timbalu]

Bald haben wir alles ausprobiert ...

Lösche mal alle KEYS

CONVERTiere nochmal und setze sie neu

Code: Select all

ALTER TABLE `serendipity_entrytags` ADD PRIMARY KEY ( `entryid` , `tag` );
CREATE INDEX tagsentryindex ON serendipity_entrytags (entryid);
CREATE INDEX tagsTagIndex ON serendipity_entrytags (tag);

[seraphyn]

Fehler

SQL-Befehl:

ALTER TABLE `serendipity_entrytags` ADD PRIMARY KEY ( `entryid` , `tag` ) ;


MySQL meldet:
#1068 - Multiple primary key defined

Hmmmm.
Ich habe mal Alles von dem Cronjob gelöscht und somit nur noch 10MB als DB im DBMS.
Im Moment setze ich alles per Hand und vim richtig um, sprich Umlaute etc...
Denke dann mal alles löschen und alle neu bauen zu lassen, sprich per Import des SQL-files.
Da werde ich dann auch gleich die richtige Kollation mit einfügen etc.
Also wenn es Morgen dann nicht geht, bin ich mit meinem Latein am Ende.
Dann verstehe ich es nicht mehr.
IMHO glaube ich nicht, dass es nur an den entrytags liegt.

Chris

[Timbalu]

Dann hast du den PRIMARY KEY vorher auch nicht gelöscht, würde ich sagen.
Keys gelöscht - Daten convertiert - Keys eingefügt, ja?
Von was für einem Cronjob redest du?