Kommentare von

beats TEST blog

Stand: 01.01.2020, 14:18

Ian Styx am |

Das kann also einfach eine interne PLESK Verbiegung sein. (hast DU Nginx eingestellt oder war das schon so?)
Zu den Mediathek Tabellen:
und können auch in
- accees
- references
vorkommen, je nachdem.

Beat Post author am |

Zu Nginx: Ich kann in PLESK einige Einstellungen vornehmen. Unter anderm versuchte ich einmal, alles was im Tab Nginx erscheint, zu deaktivieren. Doch dann funktioniert der Blog nicht mehr. Ich kann auch ein paar Apache-Parameter ändern, doch da habe ich nie etwas gemacht, weil ich keine Ahnung davon habe.

Beat Post author am |

[sortorder][ordermode] :think:
Könnte mein Upload-Problem auch daher kommen, dass ich hier nicht alle Mediathek-Verzeichnisse habe, auf die Bilder in der images-Tabelle referenzieren (und deshalb kann die Sortierung nicht durchgeführt werden)? In welcher DB-Tabelle werden denn die Verzeichnisse der Mediathek gespeichert?

Beat Post author am |

Den Inhalt von references habe ich exportiert, über 3'000x die Pfadangaben von bbbeat auf blog.dokumenzi geändert und dann wieder importiert. Das hat leider in Bezug auf die Fehlermeldung beim Upload nichts gebracht.

Beat Post author am |

Ne, daran liegt es auch nicht. Die Mediathek liest einfach alle Verzeichnisse von /Uploads.

Ich habe nun die über 3'000 Bilder von bbbeat hierhin kopiert. Nach "Mediathek: Vorschauen erneuern", "Behalte alle vorhandenen Vorschaubilder" werden alle Verzeichnisse in der Mediathek mit der richtigen Menge an Inhalt dargestellt.

Das Upload-Problem hat es jedoch auch nicht gelöst.

Ian Styx am |

Ich habe gerade ein Testbild hochgeladen. Kein Problem, außer das keine webP Variationen erstellt werden.
Ich habe das interne Debugging mal auf an gestellt. Vielleicht bekommen wir aussagekräftige Ausgaben in den Wartung Logfiles wenn der Fehler wieder einmal auftritt. Vielleicht aber auch gibt es an dieser Stelle nichts Erhellendes als Debugpoints, wobei ich gerade die Media handler ziemlich aufgebohrt hatte. Sonst muss du halt deine Browser Tools offen haben mit F12 und, wenn der Fehler auftritt, direkt nachschauen was im POST header als eventuell malformed vielleicht darinnen steht.

Ian Styx am |

Man könnte auch mal versuchen GZIP-Kompression verwenden auf NEIN zu stellen.
Ich kann mich dunkel daran erinnern, dass mir das lokal einmal ziemlichen Ärger verursachte und ich das seitdem immer auf AUS stelle.

Ian Styx am |

Als ein weíteres Testcase könnte man versuchen, da du ja Vor dem Upload Größe anpassen gar nicht erlaubt hast, die beiden Maximal Größen darüber wieder herauszunehmen. Die machen sonst gar keinen Sinn.

Beat Post author am |

Danke für all die wertvollen Ratschläge. :th_up: Bis vorhin klappte es wirklich nie und ich endete immer auf der 500-Seite. Dann habe ich GZIP deaktiviert und die beiden Grössenangaben entfernt. Und siehe da: Nun kann ich wieder Bilder hochladen! Verstehe das, wer will. :think:

In der Zwischenzeit bin ich jedoch daran, die mediaproperties-Tabelle zu bereinigen. Da hat es unzählige Doubletten drin, was sicher auch nicht zuträglich ist.

Ian Styx am |

Ging das dann nur mit beiden (Einzel).Vorschlägen oder war es Gzip speziell?

Ian Styx am |

Sind das echte Doubletten? Wo tatsächlich alles gleich ist?

Beat Post author am |

Das Problem ist gelöst. :bow:

Ursache war die Bildgrössen-Einstellung in der Konfiguration. Sobald ich ein Bild hochladen will, welches grösser als die eingestellten Werte ist, erzeugt das System diesen Fehler (ich versuchte ja die 1'296px breiten Header-Bilder hochzuladen und die konfigurierte Begrenzung lag bei 1'024px). :grrr:

GZIP an oder aus spielt keine Rolle (getestet).

Zu den Doubletten in der mediaproperties-Tabelle: Ja, es waren absolut identische Datensätze. Woher die kommen/kamen kann ich nicht sagen, vielleicht habe ich die bereits so importiert. Was ich aber wirklich nicht verstehe, ist die Anzahl der Datensätze. Was entspricht dem "VALUES" in einem Datensatz? Ich habe jetzt aktuell 1'172 Datensätze, pro VALUES deren zwei. die sich nur insofern unterscheiden, dass einmal die User-ID (1) und einmal der Login-Name (Beat oder neu BeatXXXXX) erwähnt wird. Das heisst, in meiner Tabelle sind aktuell 586 VALUES (Werte zwischen 4'879 und 9'438) enthalten. Ich habe aber über 2'500 Blogeinträge und über 3'000 Bilder... da macht die Zahl 586 für mich irgendwie gar keinen Sinn.

Es ist nicht wirklich so, dass ich das verstehen muss. Ich habe einfach kein Gefühl dafür, ob 586 richtig ist, oder zuviel, oder zuwenig.

Ian Styx am |

Dann kannst du die *Log Level* Option jetzt wieder zurücksetzen.
Ich musste im Laufe der Styx Versionen verschiedentlich alte Bugs fixen, die mediaproperties betrafen. Suche mal im changelog nach "mediaprop" um davon eine Ahnung zu bekommen.
Allgemein wird mediaproperties angelaufen und geschrieben, wenn du du die media properties änderst, also über den Medien-Eigenschaften Button das media properties form aufrufst und submittest.

Beat Post author am |

O.K. Habe "Log Level" wieder auf Nein gestellt.

Phua... Diese 4 Std. Aktion hat mich jetzt doch ermüdet... Und dann ist die Lösung so simpel... Software-Entwicklung wäre nichts für mich. Dafür gebührt Dir mein vollster :resp:

Beat Post author am |

Eine, nein zwei Fragen hinsichtlich der mediaproperties-Tabelle habe ich noch:
1. Könnte ich die gefahrlos leeren?
2. Muss ich den (alten) Inhalt bei der Blog-Migration in die neue DB importieren? Dies vor dem Hintergrund, dass ich die Tabelle aus meinem S9Y-Live-Blog dann wohl auch erst noch auf Doubletten prüfen müsste.

Ian Styx am |

Ich mag das. Das ist wie Puzzeln! :-D

Ian Styx am |

Zu 1.) Eher nicht.!
Zu 2.) Besser, Ja! Das mit den Doubletten würde ich dem Programm selbst überlassen, denn als Laie kann man oft nicht so einfach sagen welches Duplette die eigentlich Wesentliche zu behalten ist. Besser nach und nach all jene Medien, die hier verzeichnet sind, über das Media properties Form aufrufen und erneut speichern. Da das ja gefixt wurde, sollten dann die alten Doubletten auch korrekt entfernt werden.

Beat Post author am |

:grins: Genau puzzeln mag ich auch nicht! :grins:

Ian Styx am |

...in dem Fall solltest du beim Radfahrn bleiben :grins:
Wiewohl du eine erstaunliche Ausdauer beim zusammenpuzzeln deines Blogs zeigst! :resp:

Beat Post author am |

Ich liebe meinen Blog :love: fast so sehr, wie meine Fahrräder :heart: :wave:

Post author

Ian Styx am |

Wie hier https://www.blog.dokumenzi.ch/2571-Abonniert-Anzeige.html#c5946 bereits versucht zu beschreiben, sind die Kommentar Post Author Ansichten (summary/single) für den eingeloggten User und den normalen Besucher unterschiedlich, da für beide unterschiedliche Quellen "der Erleuchtung" zur Verfügung stehen.

Wir nehmen folgendermaßen erst einmal Abstand von der CSS Frage/Tatsache, ob diese Auszeichnungen blaugeboxed ist oder nicht.

  1. Stimmt diese Aussage wirklich?
  2. Wird "comment_author self" im parent selector als Möglichkeit in beiden Fällen (Seitentypen) überhaupt generiert? Ich meine JA.
  3. In welchem Fall kommt es genau vor? Überprüfe die Bedingungen der nun folgenden Aussage.

Zu beachten ist:

  • Der entry author und der comment author müssen dieselben sein. Das (und ihre Email) ist Bedingung zur Darstellung von (post_comment) "pc-owner", mit der Beschriftung "Post author", sowie für dessen parent selectors "comment_author self" Klasse. Siehe:
    $entry.author == $comment.author AND $entry.email == $comment.clear_email

4. Gibt es Fälle, in denen entry Author und comment Author und ihre Emails wirklich gleich sind und wo sie im jetzigen Zustand auf beiden Seiten unterschiedlich ausgezeichnet werden?

Zur Überprüfung von 1-4 musst du am besten über PhpMyAdmin die beiden Tabellen entries und comments für die zu Ansicht stehenden Kommentar IDs vergleichen.

5. Um die ganze Sache nach der Abklärung dieser Fragen noch komplizierter zu machen, ist es erforderlich zu überprüfen, ob die unterschiedlichen Formulare alle dasselbe Ergebnis zeitigen (immer für sich selbst und mit frischem Browser für einen normalen Besucher), je nachdem auf welche Weise man eingeloggt ist (Session, Session Fallback bei Merken, echtes MERKEN über verschlüsseltes Cookie - was, wie wir wissen, bei dir nicht geht..) oder auch nicht und ob es im Frontend oder über das Backend (mit den beiden Möglichkeitsformen der Admin Antwort und der Bearbeitungsform des Kommentars) geschieht.

Wenn all das bedacht und überprüft ist, kann man sagen es wäre so oder so und wir haben unsere Denksportaufgabe erfüllt um dann das CSS der bluebox entsprechend zu verändern/belassen.  ?

Beat Menzi am |

Ich habe je einen SQL-Auszug der entries- und der comments-Tabelle in die Mediathek hochgeladen. Diese Dateien habe ich dann im erweiterten Beitrag (hier) eingesetzt, doch man kann sie nicht downloaden (habe wohl was falsch gemacht). Um die Dateien zu erhalten, musst Du Dich wohl kurz einloggen und diese von der Mediathek downloaden.

Ian Styx am |

Gott sei Dank geht das auch nicht... :-D (warum auch immer...)
Denn ich hatte mir ja extra Mühe gemacht diesen schönen Text zu schreiben, damit du die Arbeit damit hast! (Weil ich heute und morgen wenig bis keine Zeit dafür habe. Und du unter deinen Bedingungen viel schneller und besser schauen kannst.)

Beat am |

Heute habe ich auch nicht wirklich Zeit dafür. Vielleicht morgen.

Ich muss aber gestehen, dass Dein "schöner langer Text" für mich ziemlich Fach-Chinesisch ist. Vieles davon verstehe ich nicht. :-P