Mittwoch, 22. Januar 2020
www.beatsblog.net ist geboren! -> .ch
So, der neue Webspace bei manitu ist eingerichtet und beatsblog.net ist zum Leben erwacht! (Betrieben mit Serendipity Styx 3.0-alpha4 und PHP 7.3.13). Ausser dem CKEditor Plus Plugin habe ich noch nichts installiert oder konfiguriert.
Leider funktioniert auch da utf8mb4_unicode.ci nicht "Out of the box". Die gelben Warnhinweise sind da und die Emojis werden nicht korrekt angezeigt. Ich muss also die alten Beiträge hier durchforsten um dies lauffähig zu kriegen. Hier der Link: www.beatsblog.net
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2627-www.beatsblog.net-ist-geboren!-.ch.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Geh mal in dein webhosting tool unter xyz.manitu.net blahblahblah und wähle PhpMyAdmin in der Seitenleiste. Die Datenbankseite des Hostingtools öffnet sich und es gibt darin weiter rechts einen weiteren Button zu PhpMyAdmin. Der erst öffnet das richtige phpmyadmin Paket auf dessen Startseite. (Das ist normalerweise gleich da wo das Haus ist / auch hin linkt).
Im bereits sichtbaren Block: Allgemeine Einstellungen siehst du sofort Zeichensatz/Kollation der MySQL-Verbindung zum einstellen. Da wählst du utf8mb4_unicode.ci aus und speicherst. Dann wählst du auf der Hosting Seite entweder eine neue DB aus und installierst Styx dann dahinein, oder du gehts in die bereits erstellte Datenbank db123 (auf der phpmydmin Seite) und löscht die darin befindlichen Tabellen deiner bereits erfolgten Styx Installation.
Danach gehts du und löscht die serendipity_config_local.inc.php Datei und kannst gleich die Installationsprozedur von Styx daraufhin neu starten. Jetzt sollte alles gleich richtig auf utf8mb4 installiert werden.
Beat Post author am :
Danke für die Anleitung. Habe alles genau so, Schritt für Schritt, durchgeführt. In der DB wird mir auch alles richtig angezeigt, doch im Frontend sind einfach keine Emojis zu sehen. Es ist zum heulen... ?
Ian Styx am :
Nach der default Zeichensatz/Kollation der MySQL-Verbindung auf utf8mb4_unicode.ci hast du die vorher erstellen Styx Tabellen in db123 gelöscht oder eine neue DB erzeugt?
Und Styx dann komplett neu installiert? Musstest du dafür die install_token Datei löschen und neu aufsetzen?
Was steht jetzt in der db123 Ansicht bei den neuen Styx Tabellen als Tabellen-Kollation?
Wenn dort überall nur utf8_general steht, ist es möglich, dass ein reload der Datenbank fehlt, oder ein weiterer Schritt notwendig ist, in dem du auf Operationen gehst und im Feld Kollation die Kollation auf mb4 blahblah änderst (vielleicht sogar erst einmal ohne die beiden Checkboxen für Tabellen und Spalten zu aktivieren). Trotzdem müsste man dann nochmal alle Tabellen löschen und vom Styx Installer neu aufspielen lassen, damit die Indizes neu gesetzt werden und überhaupt die mb4sql Installer Datei verwendet wird. Allerdings fehlt mir ein wenig die Vorstellungskraft warum diese ganzen Prozeduren so umständlich sein müssen.
Ich habe das selbst vor Jahren auch schon einmal dort gemacht und kann mich nicht (mehr) erinnern, mehr als nur die vorherige Gesamt Kollation auf utf8mb4_unicode.ci als Voreinstellung gemacht zu haben.
Styx Konfiguration Datenbank-Zeichensatzkonvertierung aktivieren muss JA sein.
Beat Post author am :
Tabellen in bestehender DB gelöscht.
2x Ja.
Es gibt eigentlich keinen wirklichen Grund, weshalb es nicht funktioniert. ?
Am Schluss fehlt mir vermutlich nur wieder der ominöse Datensatz in der config-Tabelle....
Beat Post author am :
STRIKE! ?
Ich glaub's ja nicht! Tatsächlich: Es fehlte eben nur dieser eine, ominöse Datensatz. Siehe: https://www.blog.dokumenzi.ch/2587-Verbindung-zur-SQL-DB.html#c5632
Ian Styx am :
Kann es denn sein, dass du immer wieder die vorherigen Inhalte, also auch inklusive dem "ominösen" Datensatz draufknallst, so dass selbst bei richtiger Installation immer wieder die dann korrekt erfolgte Einstellung überschrieben wird?
Wie sonst ist (es mir) zu erklären, dass deine paar Versuchsentries exakt (jetzt) so bestehen...?! (Wenn jetzt natürlich jetzt auch mit den richtigen Emojis)
Beat Post author am :
Ich erkenne gerade nicht, worauf Du hinaus willst. Sicher ist jedoch, dass auf beatsblog.net und auch auf styx.dokumenzi.ch NIE Datenbanktabellen (oder deren Inhalte) überschrieben wurden. Ich füllte lediglich hier auf blog.dokumenzi.ch Daten aus dem Live-Blog ein. Aber auch hier habe ich die config-Tabelle nie angefasst. So etwas ist mir zu heikel. Das machte ich erst auf Deine Anweisung. Hier sind alle DB-Tabellen aufgelistet, die ich befüllt habe: https://www.styx.dokumenzi.ch/archives/9-Migration-S9Y-Styx.html
Aus meiner Sicht solltest Du Dir überlegen, was der Triggerpunkt ist, welcher den Datensatz dbUtf8mb4_converted in die config-Tabelle schreibt. Der Datensatz ist ja überhaupt nicht vorhanden. Das heisst nicht, er ist vorhanden aber der Wert/Value steht auf false statt auf true. Dieser Datensatz fehlt als Ganzes. (Und das war bei jeder von mir installierten Styx-Edition so).
Ian Styx am :
Ja ich verstehe dass dir das merkwürdig vorkommt aber ich kann dazu nur sagen, dass das ja nun auch schon ein paar Jahre auf dem Puckel hat, und alle Installationen (sowie alle 3 zusätzlichen nur aufgrund deines Fehlers mit Styx3.0, erst gestern wieder) konnten dieses Problem nie reproduzieren. Es ist immer sofort da und gesetzt.
Irgendetwas musst du komplett anders machen. (Welche Installationsart verwendest du? Einfach oder Erweitert?)
Beat Post author am :
? ich war schon immer irgendwie anders...?
Ich verwende immer die "Einfache Installation"
Ian Styx am :
Siehst du..., kaum stellt man die richtige Frage löst sich alles in Wohlgefallen. ?
Ich nutze seitdem (und schon vorher) immer die "Vollständige Installation" und habe die überall auch so kommuniziert. (Nur bei dir nicht. Sorry!) Und mit der Zeit vergißt man es sogar es als besonders wichtig zu betonen, da man da so seine Routinen hat.
Diese "Vollständige" Installationsvariante hat den Vorteil, dass ganz bestimmte Dinge schon in der richtigen Form erkannt sind. Unter anderem, in diesem Zusammenhang, die ganz besonders wichige SQL_CHARSET Konstante und zwar aus dem lang/UTF-8 Ordner.
Die besagt nämlich entweder latin1 oder utf8. Latin1 ist ja auch das eigentliche Default einer MySQL Datenbank Installation. In der "Einfachen Installation" hat so wahrscheinlich noch kein db reconnect stattgefunden, so dass die SQL_CHARSET Konstante einfach noch gewissermaßen "jungfräulich" ist.
Es tut mir also wirklich leid um die Stunden, die du haareraufend damit verbracht hast, ohne den Grund für das Versagen zu kennen.
Das ist also eigentlich nicht so sehr ein bug, sondern ein Folge des erweiterten Installationsverlaufes.
Da das völlig Fremde aber nicht wissen können, muß ich mir wohl überlegen, wie ich das für die simple Installation verbessern bzw kommunizieren bzw umgehen kann.
Beat Post author am :
? Humor ist... wenn man trotzdem lacht! ?
In grauer Vorzeit, vor X Jahren, habe ich einmal eine "Vollständige Installation" durchgeführt und dabei festgestellt, dass ich nahezu keine Änderungen gegenüber der "Einfache Installation" vornehme. - Also wieso diesen Mehraufwand treiben?
Wenn das aber für Styx Edition v3.0 sssooooo wichtig ist, hätte mir das auch jemand sagen können... ?
Ian Styx am :
Nee, das war bzw ist für die 2.X schon seit "4" Jahren ebenso.. Dumm gelaufen halt. Ich hatte es einfach vergessen.
Ob ich das jetzt noch backporte, muss ich mir mal in einer sehr ruhigen Minute überlegen.
Wie du augenblicklich im neuen Changelog lesen kannst ist jetzt auch als Server Collation preset utf8mb4_unicode_520_ci empfohlen. Die Dinge entwickeln sich halt weiter.
Beat Post author am :
Mach mich nicht fertig! ?
Jetzt, wo alles soweit läuft, fange ich nicht schon wieder zu ändern an. Don't touch a running system! ?
Ian Styx am :
Naja, wie gesagt macht es eigentlich nur in sehr speziellen Situationen etwas aus. Das ist eine Suche mit Sortierung und die Platzierung der gefunden Variablen, geordnet nach dem charset, mehr nicht.
Die 520 ist einfach ein neueres Unicode lookup.
Was mich noch interessieren würde ist, wenn du die Styx Konfiguration noch nicht abgespeichert hast, was steht in der serendipity_config_local.inc.php unter/als:
Beat Post author am :
Hier: Ja, so wie Du geschrieben hast.
Von www.beatsblog.net kann ich es im Moment nicht sagen... Ich wollte das File mit FilZilla auf dem Server direkt öffnen. Das hat aber nicht funktioniert. Jetzt kann ich das File aber nicht downloaden, denn FileZilla sagt mir nun: /serendipity_config_local.inc.php: open for read: permission denied - grrr...
Ian Styx am :
Wie gesagt nur, wenn noch nie die globale Konfiguration gesichert!
Ach da war das... Ich sagte ja schon mal ich kenne Systeme auf denen das nicht geht. Eigentlich ist das ja gut, denn es ist eine default restricted permission. Doof halt nur, wenn man da unbedingt mal ran muss!
Man könnte ev. den Inhaber/Geschäftsführer Manuel Schmitt fragen, der ist selber Serendipianer.
Beat Post author am :
Wie meinst Du das? Wie gesichert? Bewusst habe ich soetwas noch nie gemacht.
Ian Styx am :
Das ist bedenklich ... ! ?
(Globale) Konfiguration aufmachen und speichern. Du musst nicht mal was ändern. Nur in dem Fall (außer der Installation und dem 503 Wartungsmodus natürlich) wird die local Datei neu aufgesetzt.
Hier ist das bestimmt schon erfolgt, deshalb als Auskunft nicht von Belang. Nur dort, wo du simple installed hast und nachträglich per Hand die converted Variable eingetragen hast. Da wäre es interessant (gewesen).
Beat Post author am :
www.beatsblog.net ist schon fast fertig! ?
Es fehlen noch Bilder (vor 2017), die Fotoalben und etwas Kleinkram. Grundsätzlich sieht es aber schon seeeehr gut aus! ?
Beat Post author am :
Hmmm... Leider habe ich auch da das Medien-Upload-Problem. Error 500. Bad header... blablabla...
Leider sind die Einstellungen gleich wie hier. Sollte also prinzipiell funktionieren. Tut es im Moment aber nicht...
Morgen... neuer Tag, neues Glück...
Beat Post author am :
Argh... Wenn ich Bilder manuell per FTP hochlade und danach unter Wartung Vorschaubilder erzeugen will, erhalte ich folgende Fehlermeldung:
Darunter zusätzlich:
Die Upload-Verzeichnisse und auch das include-Verzeichnis haben 775-Berechtigungen...
Ian Styx am :
Auch rekursiv? Wenn uploads nicht geht, muss man es auf 770 für alle Dateien und Verzeichnisse setzen. Das heißt Vollzugriff für Besitzer und Gruppe.
/include ist unnötig, da nur für das System lesend.
Beat Post author am :
Was meinst Du mit "rekursiv"?
Habe jetzt die Verzeichnisse und alle Daten auf 770 umgestellt. Resultat: Die Fehlermeldungen sind zwar weg, doch neue Vorschaubilder werden trotzdem keine erzeugt und die alten werden mir in der Mediathek nicht mehr angezeigt. ?
Ian Styx am :
Genau das. Alle Verzeichnisse und alle Dateien.
Im Webhosting Paket gibt es auch einen Berechtigungen Sidebar link. Was gibt der aus?
Ehrlichweise verstehe ich nicht was für Schwierigkeiten da vorliegen sollen - das müsste so eigentlich funktonieren... und du bist sicher, dass das nichts mit dem Kuddelmuddel .net -> .ch zu tun hat? Oder mit der Umstellung auf ImageMagick? Was wäre wenn du das auf GD zurückstellst? Um welches ImageMagick Binary handelt es sich?
Beat Post author am :
Der besagt bei Inhaber, Dateien, Verzeichnisse immer "keine Änderung vornehmen"
Ganz ehrlich.... im Moment bin ich von dieser ganzen Bilder/Medien-Geschichte etwas angepisst.
Ich verstehe den ganzen Trouble ja auch nicht und genau deshalb bin ich angepisst. ?
Ich will jetzt nichts behaupten was ich nicht sicher weiss, doch von net/ch-Knuddelmuddel kann man ja auch nicht wirklich sprechen. Das Installationsverzeichnis blieb unangetastet. Es ändert sich einzig, worauf Serendipity von aussen angesprochen wird und was es nach aussen anzeigt (also die URL). Dies wurde mit einer einzigen Umstellung in der Konfiguration gemacht. So etwas sollte das System durchaus vertragen ohne gleich Kopf zu stehen...
Weil ImageMagick nicht funktioniert, habe ich das in der Konfiguration wieder auf Nein gesetzt. GD sollte also wieder greifen. Trotzdem ändert sich rein gar nichts am Fehlermuster. ?
Laienfrage: Wäre es möglich, dass die DB-Tabelle styx_images aus irgendeinem Grund nicht beschrieben werden kann? Kann ich das irgendwie überprüfen? Werden die Thumbnails auch da abgespeichert/registriert?
Nachtrag: Daran liegt es auch nicht. Die neusten, per FTP hochgeladenen Bilder sind da registriert.
Ian Styx am :
Nur Geduld. Du bist jetzt schon so weit, dass es Unsinn wäre jetzt frustriert hinzuwerfen!
Das Blog ist aber immer noch unter beiden Domain extensions (net/ch) ansprechbar. Das verwirrt vielleicht nicht nur mich.
Am besten machts du mir da mal einen Zugang. (Wenn du willst!)
500er Fehler müssten in den error logs geloggt werden. Sie können Permission Probleme sein.
Am besten fragst du kurz mal nach und schilderst dein Problem, dass du kein Upload hinbekommst. Es muss an irgendetwas liegen und die Permissions sind eine beliebte Fehlerquelle (siehe unter /logs - oder gibt es gar ein webostingtool link dazu?).
Welche Perms hat denn der Oberordner von styx? Zb /web ? (und /logs,und /tmp ?)
PHPs iMagick extension ist - wie ich letztens gerade schon einmal schrieb - unabhängig vom binary, welches der Hoster nomalerweise unter soetwas wie "/usr/bin/convert" zur Verfügung stellt. Man kann also nicht kurzerhand vom einen auf das andere schließen. Styx kann z.Z., wie auch Serendipity origin, nur mit dem Binary umgehen.
Thumbnails werden natürlich nicht erstellt, wenn der upload nicht klappt. Macht man es per FTP, muss man wahrscheinlich danach die Mediathek Synchronisation im Wartungsbereich vornehmen. Aber Achtung, das kann dazu führen das er dir alles aus der DB rauskloppt was zur Zeit nicht physisch vorhanden ist (siehe deine Nach-Asien-Arbeiten). Insofern würde ich das erst dann versuchen, wenn alles wirklich an Board ist und keine Bilder-Link-Fehler mehr da sind.
Ich kann dir versichern, dass es sowohl mit GD als auch mit ImageMagick in einer frischen aktuellen (lokalen) Installation, sowohl mit dem empfohlenen 400px Thumb Size, wie auch mit deinem kleinen 160px Thumb Size klappt. Auch die WebP Varianten werden erstellt.
Beitragsbilder nicht zentriert? Du meinst:
https://www.beatsblog.ch/2584-sun,-fun-and-nothing-to-do....html ?
Hmmm! Moment... kannst du dich erinnern, anhand welchen besonderen Bildes und Ereignisses auf blog.dokumenzi ich diese Änderungen eingepflegt hatte. Ich muss das mal vergleichen zum sun-fun-Bild, aber weiß nicht mehr wo und welches das genau war.
Update: Ich weiß es jetzt wieder. Es ging um ein kleines (bis 400px width) (figure) Bild, so wie mein "blah blah blah" Kommentiertes Test Bild in https://www.blog.dokumenzi.ch/2612-Seitenleisten-links-rechts.html. Auf einmal ist das Verhalten genau umgekehrt, sowohl auf beatblog.ch als auch hier. Das heißt, dass mein ganzer schöner Würgaround für diesen Fall jetzt (auch mit seinen Auswirkungen auf größere Bilder) genau das Gegenteil bewirkt. (So als wenn inzwischen ein Browser Update dies verändert hätte... sehr ugewöhnlich..!) Wenn dir dazu nicht noch etwas einfällt was ich jetzt nicht bedacht habe muss ich es wohl rückgängig machen. Oder war das eventuell bevor du auf 2 Seitenleisten umgestellt hattest?
Beat Post author am :
In Kommentar #c6380 schrieb ich:
Die Upload-Fehler sind alte Bekannte. Du schriebst:
Ja, das werden sie auch. Es sind diese "bad header"-Dingsbums. Im errorlog steht (Beispiel):
Das gleiche hatten wir hier auch schon. Siehe ab diesem Kommentar: https://www.blog.dokumenzi.ch/2604-Stand-01.01.2020,-1418.html#c6016
Damals war die Lösung, dass in der Blog-Konfiguration/Bildkonvertierung eine maximale Bildbreite angegeben war, ohne jedoch die Verkleinerung zu erlauben (vor dem Upload Grösse anpassen). Diesen Fehler habe ich auf beatsblog.ch aber nicht wiederholt. Die Konfiguration ist dort absolut identisch mit derjenigen hier (welche jetzt ja problemlos funktioniert). Trotzdem erhalte ich die gleichlautenden 500er Fehler, wie damals.
Die zentrierten Bilder haben wir hier diskutiert; https://www.blog.dokumenzi.ch/2607-image-center.html
Interessant an beatsblog.ch ist, dass vereinzelte/wenige Beitragstitelbilder zentriert dargestellt werden, die Meisten sind jedoch linksbündig (auf den ersten 3 Seiten 3x zentriert, 27x linksbündig) -> wobei ich gerade festgestellt habe, dass es hier ab Seite 6 (wo die importierten Beiträge anfangen, also vor und bis https://www.blog.dokumenzi.ch/2550-Schutzblech.html) genau gleich ist.... obwohl im Quellcode "center" steht, werden die Bilder linksbündig dargestellt.
Mit ANGEPISST wollte ich sagen: Ich bin etwas enttäuscht/verärgert/genervt und brauche einen Moment Abstand vom Thema, bevor ich wieder daran setze. Ich schmeisse ganz sicher nicht hin. Diesen Weg bin ich nun zu geschätzten 80% gegangen und bekanntlich sind die letzten 20% immer die Schwierigsten. Das wird schon werden. Nur beschäftige ich mich im Moment lieber mit anderen Dingen als diesen Fehlern nachzurennen. Zumal meine PC-Internet-Umgebung ferienhalber auch eher suboptimal ist.
Ich habe im Arbeitsartikel alle Zugangsdaten hinterlegt. Du kannst Dich gerne austoben. Ich habe überhaupt keine Erwartungshaltung. Es sind meine Probleme und nicht Deine. Wenn Du Dir das ansiehst bin ich dankbar, wenn nicht dauert es einfach etwas länger......
Beat Post author am :
Das "image-center"-Problem konnte ich mit folgendem Eintrag in der user.css lösen:
Ian Styx am :
HEY!! ?
Das war eine ausgezeichnete Idee. Danke.
Ich habe das gerade nochmal sehr intensiv überprüft und das war tatsächlich etwas, dass in bestimmten Fällen fehlte. Sobald du den nächsten Sync machst, und ich war heute echt fleißig!, kannst du deins in der user.css voraussichtlich wieder entfernen. Überprüfe es dann lieber noch einmal.
Ian Styx am :
Zur Ergänzung:
Der ziemlich aufgebohrte Geschichte mit dem "display: contents" und dem figure inline "display: block" für kleinere images war und ist trotzdem nötig, denn es ging darum, in einem bestimmten media screen range, große, mittlere und kleine figurierte Bilder mit Kommentaren frei schwebend mittig im content Container zu bekommen, ohne denselben aus der fluidablen Balance mit den Seitenleisten und der Gesamtbreite zu bringen. Mit deiner Ergänzung ist das jetzt eine sehr runde Sache! Klasse!
Du kannst das Phänomen bei dir eben nicht wahrnehmen, weil du die figure image comment borders entfernt hast (Ich schreibe, um mich selbst daran zu erinnern bzw. erinnern zu können!) Ego ita scribo! ?
Beat Post author am :
Wenn ich im Backend auf "Einträge bearbeiten" klicke, erhalte ich 36x folgende Fehlermeldung:
Darunter folgen die bisherigen Einträge und ich kann diese ganz normal bearbeiten. Die 36 Warnhinweise haben soweit also keine nagativen Auswirkungen.
Ian Styx am :
Super! Vielen Dank.
Das war ein Bug und ich habe dazu gleich noch einen zweiten gefunden, den du noch gar nicht bemerkt hast ?
Commitet!
Es ist halt wichtig immer mit mehreren Menschen und ihren persönlichen Vorlieben und Einstellungen zu testen. Das kann man alleine gar nicht immer alles vorausahnen und als Testdata vorhalten.
Beat Post author am :
? Beruhigend, wenn's mal kein Benutzerfehler ist... ?
Beat Post author am :
Habe /include/admin/entries.inc.php ersetzt und kann bestätigen, dass die Warnhinweise verschwunden sind. Danke! ? ?
Ian Styx am :
Was mir ein wenig "Sorge" bereitet ist der fürchterliche delay von ~3.7x Sekunden beim load einer Seite auf bb.net, wovon ~3.63 Sekunden Wartezeit sind.
Das muss besser gehen! Bevor du dich damit an den Manitu Support wendest, solltest du gründlich überprüfen wie man deine Einstellungen optimieren kann. Was mir zB auffällt ist ein XHR request auf
Angefragte Adresse:https://www.beatsblog.ch/plugin/ctpure-beat_default
Das macht ja keinen Sinn. Entweder ist noch eine Einstellung des ehemaligen template Wechslers aktiv, oder irgendetwas anderes pointet auf beatsblog.ch. Check mal all deine Einstellungen und Plugin Einstellungen.
Vielleicht gibt es auch noch Weiteres, so zB eventuell Bilder in alten Enträgen die auf bb.ch zugreifen etc. oder Bilder die fehlen und die Wartezeit addieren, wie das fehlende ReCaptcha Bild in zB https://www.beatsblog.net/2574-Ich-bin-wirklich-kein-Roboter.html.
Auch scheint die Biene nicht zu funktionieren. Es wird immer das versteckte Captcha angezeigt. Speichere SPamblock und Biene mal erneut.
Ian Styx am :
Du kannst übrigens statt ?frontpage auch https://beatsblog.net/?souls oder https://beatsblog.net/?beatnik verwenden.. ?
Wenigstens könntest du wahrscheinlich den bee Fehler
mit einem zusätzlichen Eintag in der .htaccess oberhalb des s9y blocks lösen
oder vorher einmal untersuchen, ob nicht eventuell nur das s im https der url zu deinem Blog fehlt, unter:
Konfiguration - Pfade - URL zum Blog.
Beat Post author am :
Ich verwende /?frontpage nicht mehr. Weder auf www.beatsblog.ch noch hier. Ich linke auf die Oberkategorie Blog. Dies um eine konsistente Anzeige bei Homelink 1 & 2 zu erhalten und damit ich bei Beiträgen von Kategorien, die ich im Blog nicht anzeigen lassen will, nicht daran denken muss, die Checkbox "Nicht in der Artikelübersicht anzeigen" zu aktivieren.
Beat Post author am :
wie bist Du denn auf den Spambee-Fehler gestossen? Ich habe gerade einen Testkommentar abgeschickt. Ging ohne Probleme. (Habe Spambee & Spamblock in der Zwischenzeit geöffnet und wieder gespeichert).
Was die Geschwindigkeit/Wartezeit anbelangt, so hat dies im Moment keine Priorität für mich. Ich kann noch immer keine Bilder über das Backend hochladen und obwohl mir der Manitu-Support die Pfadangaben zu Imagemagick zugeschickt hat, kriege ich das nicht lauffähig. Ausserden fehlen noch alle Bilder vor 2017. Die werde ich dann erst nach den Ferien, aus der Schweiz, hochladen (genauso wie die Fotoalben). Das dauert per FTP von Thailand aus einfach viel zu lange. Und genau auch deshalb warte ich mit Anfragen betreffend der Geschwindigkeit beim Manitu-Support. Ich kann hier, knapp 10'000 Kilometer entfernt, nur sehr schlecht abschätzen, woher der Delay kommt.
Ian Styx am :
Ja jetzt ist er auch weg, seit du ch aktiviert hattest. (Mit Chrome und natürlich nicht eingeloggt)
Das mit dem Warten verstehe ich gut.
Es ist auch so eine Mischung würde ich behaupten, zb die Seitenleisten Zufallsbilder sind schon mal ~1000 ms
Dann kann es mit DNS Anfragen zusammenhängen, oder mir der Festplatte/SSD, oder mit der Anbindung des Servers, etc. Jedenfalls hast du das hier nicht und es geht ratz-fatz, vielleicht auch weil der NGINX irgendeine Art Cache verwendet, siehe den 502 Bad Gateway error.
Beat Post author am :
Ja, nginx verwendet einen Cache und ich muss wirklich sagen: Die hosttech-Server sind schnell. Auch ein Grund, weshalb mir der Wechsel etwas schwerfällt...
Aber: Es gibt ja noch einiges an Pulver, was man verschiessen kann. So habe ich z.B. auf www.bbbeat.ch serverseitigen APC-Cache via -htaccess aktiviert und im Blog auch die GZIP-Kompression eingeschaltet. Das könnte man auf dem Manitu-Server alles auch noch nutzen.
Ian Styx am :
ick bün gespannt...
Ich muss auch dringend mal in die Wärme .. deine Leckereien machen richtig Appetit und ich wolte schon immer mal mit dem A350 fliegen. ?
Beat Post author am :
Ich glaube, wir sind jetzt zum 5. oder 6. Mal in Thailand. Kann ich absolut empfehlen! Sehr liebe Menschen, tolle Natur, meist super Wetter und eben Klasse-Essen! ? (und alles äusserst günstig)
Ich denke Du meinst den doppelstöckigen A380-✈... Unsere Freunde sind damit nach Singapur geflogen und dann von da nach Phuket mit einer Regional-Airline.
In den nächsten Tagen werde ich noch ein paar Thailand-Impressionen in meinen Blog hochladen...
Ian Styx am :
Ich auch. Letztes Mal war es auch auf Phuket. Sehr netter kleiner Strand im Norden zur Erholung, nach einer Reise durch Laos und Kambodscha.
Nee ich meinte den relativ neuen A350 neo oder so ähnlich. Fliegt locker 10 Stunden durch.
Ian Styx am :
Kannst du mir das mal im Backend hinterlegen, bitte?!
Beat Post author am :
Gemacht ?
Beat Post author am :
Also: Als ich die Styx Edition installierte war erst die Domaine www.beatsblog.net verfügbar. Das habe ich dann auch so in die Styx-Konfiguration eingetragen.
Meine Ziel ist jedoch als Hauptadresse www.beatsblog.ch a) zu kommunizieren und b) anzuzeigen.
In der Zwischenzeit wurde beatsblog.ch und www.beatsblog.ch aktiviert und mit Let's encrypt zu https verschlüsselt.
Serendipity-Styx installierte ich in das Verzeichnis /web/styx-master/ . Nun linken alle Domains auf dieses Verzeichnis (beatsblog.net & beatsblog.ch, sowie deren Subdomains mit www.)
Also hielt ich es heute für angbracht, die Anzeige www.beatsblog.ch zu aktivieren, in dem ich in der Blog-Konfiguration die Adresse von .net auf .ch gewechselt habe. Was mir jedoch jetzt in den Sinn kommt ist, dass ich wohl auch alle Einträge in der DB-Tabelle "styx_references" anpassen sollte. Das ist meines Wissens die einzige Tabelle, in der absolute und nicht realtive Pfadangaben verwendet werden. (in der Zwischenzeit erledigt).
Ian Styx am :
Nur zur Info:
Das hat sich später übrigens aufgelöst, als ich irgendwann bemerkte, dass mein Firefox mit strikten individuellen Einstellungen in "Verbesserter Schutz vor Aktivitätenverfolgung" eine Ausnahme für deinen Blog brauchte.
Beat Post author am :
Upload-Problem gelöst (vorerst).
Als Laie probiert man vieles aus nur um zu sehen, ob es etwas bewirkt oder nicht. So kam ich heute auf die Idee, dass ich /uploads/ und alle Unterverzeichnisse volle Berechtigung erteile (also 777). Und siehe da.... der Bilder-Upload funktioniert genauso wie die Erstellung von Thumbnails.
Nur... das kann wohl nicht die definitve Lösung sein.
Ian Styx am :
Den Vorschlag hätte ich bestimmt auch noch gemacht. Ich meiner ganzen Serendipity Historie (im Forum) ist das X-Mal die nur einzige Lösung gewesen.
Ich würde trotzdem nochmal nachfragen, ob das nicht besser und damit sicherer geht. Das kann mit dem User und auch mit der 4. (bzw ersten von 4) Stellen zusammenhängen,so dass die Oktalzahl 0 auf 1 oder 2 oder was auch immer präzisiert werden muss.
Auf alle Fälle ist es schön das es erstmal läuft und kein Styx Problem an sich ist!