API für modified

[loaded]

Moin,
Also ich würde die api für Wawi machen und soweit ausbauen das Produkte,Bestellungen, Kunden ausgelesen werden.

Die nächste Frage wäre mit welchen Programmen wird die api ausgelesen ?
Web-Interface-Server?

Wenn ich jetzt mal anfange zu übertreiben würde ich die api so bauen das die ganze Datenbank ausgelesen werden kann bzw. Ein Tutorial wie es erweitert werden kann falls was gebraucht wird.

Das ganze so machen das die api von einer App für das Handy ausgelesen werden kann.

Es gibt da ein Russen der hat xtc auch geforkt und auch eine App für den
Shop.

https://play.google.com/store/apps/details?id=xyz.appmaker.aqckvs&hl=de

[hpzeller]

Off-topic:

[...]
"Rest Api für modified" im Anschluss noch einen "Module Installer für modified" und die DB von utf-8 auf utf-8mb4, konsequent InnoDB das wären so meine ersten Wünsche.
[...]

Sofern der Shop mit Charset UTF-8 läuft, sollte man meiner Meinung nach die Shop-Datenbank, unabhängig davon ob man eine API einführt oder nicht, von utf8 nach utf8mb4 umbauen.

Die folgenden Links erläutern das Problem, und insbesondere der zweite Linke enthält auch eine Anleitung wie man das bei einer MySQL-Datenbank durchführen kann und worauf es dabei ankommt.

• utf8 vs. utf8mb4
• How to support full Unicode in MySQL databases

P.S.: Im Shopsystem müssen dann noch ein paar Scripte geringfügig angepasst werden.
Beispielsweise in "/includes/external/smarty/smarty_3/Smarty.class.php" folgender Code:

Code: PHP  [Auswählen]

/**
 * define smarty charset
 */
if (isset($_SESSION['language_charset'])) {
  $charset = $_SESSION['language_charset'];
} else {
  $charset = 'ISO-8859-1';
  if (defined('DB_SERVER_CHARSET')
      && DB_SERVER_CHARSET == 'utf8'
      )
  {
    $charset = 'UTF-8';
  }
}

Gruss
Hanspeter

[snocer]

@hpzeller, das Problem hatte ich auch schon mehrfach angesprochen. Weil utf-8_general etc. eben die genannten Probleme hat und nur 3bitig ist statt 4bitig. Ich wäre da auch für dass das schnellstens geändert wird. Das sollte ja nicht das Problem sein, sollte eben auch für alle neu installierten modified Shops automatisch eingestellt sein und wenn möglich sollte das modified Team gleich noch ein Convert_Script für alle bestehenden UTF-8 Shops bereit stellen. Auch sollte darauf geachtet werden, das nur noch InnoDB verwendet wird. Und die Hard Codierung des Bilder Uploads aus dem Backend heraus mit dem chown 0777 sollte auch in dem Zuge entfernt werden. So etwas regeln die Server selber. Und wenn dann noch in zukünftigen Versionen die Maskierung der Umlaute entfällt bei UTF-8 (HTML Entitäten) weil nicht notwendig, eher sogar schädlich weil beim XML Export / Import das auch wieder mit Codiert werden muss bisher, wäre ich schon mehr als Happy. Eventuell noch die Reste in modified von ANSII auf UTF-8 ohne BOM stellen und dann wären wir fast perfekt.

Dafür müssen aber auch viele Standard Module noch angepasst werden. Magnalister etc.

Hier mal so eine mini schnell Umstellung, bitte darauf achten das vorher varchar verkleinert werden muss, damit eine vollständige Konvertierung gelingt.

Wer mit phpMyAdmin arbeitet kann über die SQL Eingabe folgendes machen.  Bitte aber vorher DB sichern falls etwas schief geht. Beispiel nachfolgend.

Code: SQL  [Auswählen]

ALTER DATABASE
    database_name
    CHARACTER SET = utf8mb4
    COLLATE = utf8mb4_general_ci;

cu snocer

[Timm]

@snocer

Wenn du gute Ideen hast, dann schreib doch bitte Tickets dafür. Da haben wir am Ende alle was von. Und das Team wird hier nicht mitlesen.

Gruß Timm

[noRiddle (revilonetz)]

@snocer

Was hast du immer mit InnoDB ?
Man kann nicht pauschal sagen, daß InnoDB besser als MyISAM ist. Beide haben Vor- und Nachteile und die Vorteile von MyISAM überwiegen für viele DB-Tabellen die modified benutzt.

Auch verwechselst du offensichtlich Collation mit Character Encoding, utf-8_general, wie du schreibst, wäre korrekt so utf_8_general_ci eine Collation.

VARCHAR muß man auch nur dann runtersetzen wenn man mehr als 191 Zeichen, z.B. 255 als Index hat (bei InnoDB, MyISAM dürfte aber ähnlich sein).

Und was du mit

[...] Reste in modified von ANSII auf UTF-8 ohne BOM stellen [...]

genau meinst ist mir auch nicht klar.
Wenn du die Kodierung meinen solltest in welcher die Programm-Dateien abgespeichert sind, kannst du das begründen ?
Ich weiß , daß es (Fach-)Leute gibt die empfehlen alle Dateien immer in UTF-8 ohne BOM abzuspeichern, aber warum genau ?

Gruß,
noRiddle

[snocer]

@noRiddle, ich werde dir mal antworten, aber nicht so vermessen wie Deine Antwort / Frage rüberkam.

zu 1. was hast Du immer mit InnoDB nachfolgend einige hoffentlich auch für Dich schlagende Elemente.

InnoDB hat Sperren auf Zeilenebene. MyISAM verfügt nur über vollständige Sperren auf Verzeichnisebene.
InnoDB verfügt über eine sogenannte referenzielle Integrität, welche die Unterstützung von Fremdschlüsseln (RDBMS) und Beziehungsbeschränkungen beinhaltet, MyISAM nicht (DMBS).
InnoDB unterstützt Transaktionen, das heißt du kannst einen Commit und einen Rollback ausführen. MyISAM tut das nicht.
InnoDB ist zuverlässiger, da es Transaktionsprotokolle für die automatische Wiederherstellung verwendet. MyISAM tut das nicht.

InnoDB hat eine bessere Performance und sich als zuverlässiger erwiesen, als MyIsam. Alleine das solle schon ein Grund sein InnoDB statt MyISAM zu verwenden. Ein weiterer starker Grund das MyIsam nur über eine vollständige Sperrung auf Verzeichnisebene verfügt wogegen InnoDB Sperrung auf Zeilen Ebene unterstützt. Dadurch können Abfragen schneller verarbeitet werden.

Mehr dazu nicht mehr, den Rest kann jeder selbst rausfinden.

Zu Punkt zwei ich verwechsele nichts, war nur zu faul das alles auszuschreiben, weil nicht erforderlich.

Zu 3 kann ich nur sagen, das eben Standard bei modified für Artikelbezeichnung eben varchar verwendet wird und das mit 255 Zeichen. Daher mein Hinweis. Trifft auch noch auf Newsletter u. a. zu.

Zu 4 bekommst Du auch eine Antwort von mir.
Der Grund für für viele Probleme beim speichern von UTF-8 Dateien mit BOM ist, dass beim Speichern als UTF-8 am Anfang der Datei ein “Byte Order Mark” (kurz: BOM) geschrieben wird. Der BOM für UTF-8 lautet U+FEFF und ist drei Bytes groß – 0xEF, 0xBB und 0xBF. Die drei Bytes werden nach Windows-1252 als “” dargestellt. Für UTF-16 und UTF-32 wird das BOM für die Byte-Reihenfolge verwendet, welches bei UTF-8 nicht wirklich notwendig ist.

Leider interpretieren Browser bzw. PHP den BOM nicht richtig. Insbesondere PHP denkt, dass bereits eine Ausgabe stattgefunden hat, sodass es zu spät ist, den Header zu verändern. Der Fehler tritt bei ANSI nicht auf, weil dieser keinen BOM besitzt.

Lösung und Antwort für noRiddle und andere Interessierte.
Die Lösung ist einfach: Die Datei muss mit der Kodierung “UTF-8 ohne BOM” gespeichert werden.

Und bitte in Zukunft weniger Agro. Ich habe keinen Groll auf jemanden von Haus aus.

cu snocer

[snocer]

@snocer

Wenn du gute Ideen hast, dann schreib doch bitte Tickets dafür. Da haben wir am Ende alle was von. Und das Team wird hier nicht mitlesen.
[...]

Hallo Tim,

warum hier keiner vom Team mitlesen sollte, erschließt sich mir nicht ganz. Ich dachte bisher das Forum ist die Plattform um Ideen zu diskutieren und anzusprechen. Oder ist das Team ein Team für sich und die restlichen Mitglieder etc. interessiert das Team nicht? Hatte eigentlich nicht den Eindruck. Aber man kann sich auch täuschen. Ein Ticket erstelle ich nur wenn ich der Meinung bin das es sich um ein Fehlverhalten in modified handeln könnte. Für einen Vorschlag von mir (müssen andere noch lange nicht gut finden), sehe ich noch keinen Grund ein Ticket zu eröffnen.

cu snocer

[Tomcraft]

Wir lesen hier mit, aber dennoch hat Timm Recht, wenn er sagt, dass für Ideen bitte Tickets abgelegt werden, denn dann geht die Idee nicht unter. Das Forum ist primär dafür gedacht Hilfe zu geben und zu diskutieren. Es ist keine Plattform, wo wir alle Beiträge mitlesen können. Das ist zeitlich nicht mehr zu stemmen.

P.S.: Ich kann am Beitrag von noRiddle nichts vermessenes feststellen? Und aggressiv auch nicht. War doch einfach nur seine Sichtweise nieder geschrieben.

Grüße

Torsten

[noRiddle (revilonetz)]

@snocer
Nett was du mir alles erklärst. Danke.
Ich frage mich allerdings wer von Dateien mit BOM abspeichern geredet hat...
...und wo ich "agro" war..., da muß ich mal nachdenken...

Gruß,
noRiddle

[snocer]

@noRiddle, alles OK ich muss mich eben auch erst an Deinen Schreibstil gewöhnen, so wie Du Dich wahrscheinlich auch erst an meinen gewöhnen musst.. Von BOM speichern hat keiner gesprochen, ich wollte nur darauf hinweisen, dass beim speichern von php Dateien eben genau drauf zu achten ist, weil es sonst häufig zu unerwartetem Verhalten führen kann.

@Torsten, ich wusste es doch das Ihr hier mitlest.
Bevor ich hier nicht mehr Meinungen zu bestimmten Meinungen von mir höre, will ich niemanden mit Tickets belästigen. Wenn die Masse zufrieden ist wie es ist, ist es eben wie bei jeder Software, dann besteht auch kein Bedarf. Aber gerne könnt Ihr meine Meinung wenn Ihr diese für vernünftig haltet auch in Eure Entwicklung einfließen lassen.

cu snocer

[RobinTheHood]

+1 für alle Dateien in UTF8 ohne BOM
+1 für echte Sonderzeichen und keine HTML Entities in Dateien (weil UTF8 machts möglich)
+1 für echtes UFT8 (mb4) in der Datenbank

MyISAM vs. InnoDB - in die Thematik bin ich leider nicht gut genug eingearbeitet

Mit besten Grüßen
Robin

[Q]

[...]
Bevor ich hier nicht mehr Meinungen zu bestimmten Meinungen von mir höre, will ich niemanden mit Tickets belästigen. Wenn die Masse zufrieden ist wie es ist, ist es eben wie bei jeder Software, dann besteht auch kein Bedarf. Aber gerne könnt Ihr meine Meinung wenn Ihr diese für vernünftig haltet auch in Eure Entwicklung einfließen lassen.
[...]

Wieso nicht mit einem Einzelvorschlag etwas besser machen was gut ist? Stillstand ist schnell Rückstand. Das Ticket wird schlimmstenfalls mit "wontfix" geschlossen. 

*edit* im zweitschlimmsten Fall wird der Meilenstein entfernt und das Ticket auf unbestimmte Zeit "zurückgestellt"

[Timm]

@snocer
Das Trac ist nicht nur für Bugs gedacht. Du kannst deine Vorschläge ja als neues Feature markieren. Wenn nur Bugs bearbeitet würden, würde die Shopsoftware nur unwesentlich besser werden. Manchmal gibt es auch Wissen einzelner, wo man kein Feedback im Forum bekommt, weil zB kein anderer in dem Thema drin. Das ist ja nicht unbedingt schlimm - Im besten Fall hätten wir hier zu jedem Thema einen Experten genau für ein Spezialgebiet. Schlimm wäre nur, wenn dieses Wissen untergeht, weil kein Ticket erstellt wurde nur weil es kein Feedback im Forum gab.

Du hast hier ja von mindestens 2 Forenmitgliedern Zuspruch für einige deiner Themen bekommen. Also mach da Tickets draus. Am Ende entscheidet das Team, was es mit dem Ticket macht. Wenn es  ein Ticket gibt wird sich das Team mit dem Thema beschäftigen auch wenn sie es selbst vielleicht nie auf dem Schirm hatten. Wenn du kein Ticket erstellst, wird sich auch keiner damit beschäftigen.

Ich als Nichtprogrammierer hab ne Menge Tickets erstellt. Oft auch zu Themen die ich selbst nicht mal erstellt habe damit sie nicht untergehen. Und meist wurden diese dann auch gelöst oder auf eine spätere Shopversion verschoben. Und wenn von 10 Tickets 1 auf "wontfix" oder "invalid" geändert wurde, dann hab ich immer noch einen kleinen Anteil an 9 Verbesserungen.

Gruss Timm

P.S. @RobinTheHood du bist gerne auch eingeladen 

[Timm]

Hmmm... ich kann noch kein neues Ticket zu den Themen finden.

Gruss Timm

[snocer]

Hallo Timm

ich denke das Team hat das bereits auf dem Schirm mit der Api. Ich denke da wird etwas kommen wenn sie Zeit dafür finden. Daher erst einmal von mir die abwartende Haltung. Zur generellen DB Umstellung auf UFT8mb4 werde ich eventuell mal eins aufmachen, geht aber auch fix so erst einmal wie bereits geschrieben.

cu snocer