Styx-Stand: 01.05.2020, 10:58

beats TEST blog

Sonntag, 15. Dezember 2019

Styx-Stand: 01.05.2020, 10:58

Trackback-URL für diesen Eintrag

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/2579-Styx-Stand-01.05.2020,-1058.html«

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

  1. Beat am :

    Stand: 19.12.2019, 12:10
    Habe den 503 Wartungsmodus aktiviert, um die neusten Files per FTP zu übertragen. Während dem Transfer besuchte ich den Blog (in einem anderen Fenster) und kriegte keine 503 Seite zu Gesicht. Ist diese Funktion in der Dev-Version deaktiviert?

    Edit im Backend: Emoji-Test CKEditor für Kommentare ? ? funzt tip top ?

  2. Ian Styx am :

    Das dürfe eigentlich gar nicht gehen, wenn man sich nicht cookie verschlüsselt einloggen kann.
    Du bekommst also tatsächlich den 503 Maintenance Button zu sehen und kannst ihn auf rot schalten?
    Hast du den Info Button gedrückt and the FM gelesen?

  3. Beat am :

    Ich habe mal gelesen, dass man irgendwas im Backend anwählen soll und danach wieder auf Wartung klickt, damit man die rote Schaltfläche "Wartungsmodus aktiv" (oder so ähnlich) sieht. Da bei mir die Fläche nach dem aktivieren nicht automatisch auf rot umspringt habe ich das gemacht und dann auch die rote Anzeige gesehen. Trotzdem konnte ich dann den Blog (in einem anderen Fenster besuchen und auch die einzelnen Seiten refreshen).

  4. Beat am :

    Ich kann ja mal für 5 Minuten den 503-Modus aktivieren, dann können wir das nochmal testen. Nenne eine genaue Uhrzeit und ich mach das.

  5. Ian Styx am :

    Natürlich kannst du das! Den Browser ist dann ja an dich gebunden und du kannst dich frei umherbewegen, Selbst das auslogen sollte verboten sein. Den 503 Modus kannst du nur mit einem anderen Browse testen.

  6. Beat am :

    O.K. Thema erledigt! War immer mit dem gleichen Browser, nur mit unterschiedlichen Fenstern unterwegs.

  7. Beat am :

    *Styx-Stand: 22.12.2019, 19:11*

    Jetzt können im Backend Kommentare umgehängt (zu anderen Beiträgen verschoben) werden. :th_up:

  8. Ian Styx am :

    Restbeobachtungen aus vorigen Backend-Besuchen:

    • Dem Sliver theme fehlen irgendwie die theme preview files, inkl webp. Hat dein FTP vergessen sie zu übertragen?
    • Das entryproperties event plugin muss immer an letzter Stelle in der Liste sitzen. Das geht normalerweise automatisch, aber mit gelegentlichen Ausnahmen, wo man dann per Hand nachjustieren und speichern muss.
    • In einigen deiner älteren Beiträge stimmen die images nicht.

     

  9. Beat am :

    • Dem Sliver theme fehlen irgendwie die theme preview files, inkl webp. Hat dein FTP vergessen sie zu übertragen?

    Nein. Die sind auf dem Server, am richtigen Ort. keine Ahnung, weshalb sie nicht angezeigt werden.

    • Das entryproperties event plugin muss immer an letzter Stelle in der Liste sitzen. Das geht normalerweise automatisch, aber mit gelegentlichen Ausnahmen, wo man dann per Hand nachjustieren und speichern muss.

    O.K. Verschiebe ich gleich. - Gemacht.

    • In einigen deiner älteren Beiträge stimmen die images nicht.

    Ich habe hier (zu Testzwecken) nur die Bilder ab 01.01.2019 hochgeladen. Ältere Bilder werden deshalb nicht angezeigt.

  10. Ian Styx am :

    OK

    Noch etwas:

    • Der Link "Versionsgeschichte" (Changelog) in den einzelnen Plugins will immer herunterladen (eigentlich ist es aber zum direkten Anschauen gedacht, also scheinen deine Permissions vielleicht nicht zu stimmen!).

    Vielleicht ist das auch ein Grund für gelegentliche Fehler beim Mediathek Upload und anderes. Überprüfe mal ob wirklich korrekte Schreib- und Leserechte auf /plugins, /uploads usw. vergeben sind. Siehe https://ophian.github.io/hc/en/faq/#docs-what-are-the-file-permissions-required-to-run-serendipity

    Dann habe ich deine Spamblock Options noch mal nachjustiert um dem komischen Jetlag auf die Spur zu kommen. Vielleicht musst du die Biene noch mal schnell davorhängen.

  11. Beat am :

    Das Hauptverzeichnis und alle Unterverzeichnisse (mit Ausnahme von /cache = 0771) haben die Berechtigung 0755

    Biene steht bereits zuoberst.

  12. Ian Styx am :

    Seltsam... Ist das für die in der FAQ genannten Ordner auch rekursiv gesetzt, so dass es auch für alle Dateien und Ordner unterhalb gilt?

  13. Beat Menzi am :

    Ähm... Jetzt wird's schwierig...

    Mit FileZilla kann ich einen Rechtsklick auf ein Verzeichnis ausführen und sehe da, dass ich "Unterverzeichnis miteinbeziehen" könnte. (Woran ich aber bisher nichts gemacht oder verändert habe).

    /archives enthält keine Unterverzeichnisse.
    /templates alle Unterverzeichnisse haben 0755
    /templates_c alle Unterverzeichnisse (mit Ausname /logs) haben 0755
    /uploads alle Unterverzeichnisse (mit Ausnahme /.v 0777) haben 0755
    /plugins alle Unterverzeichnisse haben 0755

  14. Ian Styx am :

    ..Eine der Vorteile wenn man Release versionen verwendet. Jene sind schon korrekt ausgezeichnet. :-)
    ZB /plugins Ordner 770, files 660 sollte gehen
    Welche perms haben denn die Hauptordner? zB /plugins ?
    Das ist auch von Server zu Server leicht verschieden, je nachdem wie restriktiv sie es absichern...

  15. Beat am :

    siehe meinen Kommentar von 14:42

  16. Ian Styx am :

    Nochmal Biene und Spamblock neu justiert

  17. Ian Styx am :

    • Dem Sliver theme fehlen irgendwie die theme preview files, inkl webp. Hat dein FTP vergessen sie zu übertragen?

    Nein. Die sind auf dem Server, am richtigen Ort. keine Ahnung, weshalb sie nicht angezeigt werden.

    Aber sie wurden mir selbst dann nicht angezeigt, wenn ich die URL aus dem Quelltext geklaubt habe und sie auf einer extra Seite anzeigen lassen wollte. Bist du dir echt sicher?

  18. Beat am :

    Ich habe den ganzen /templates/silver-Ordner vom letzten Download noch einmal per FTP hochgeladen. Leider keine Veränderung.

    Das ist übrigens drüben, auf www.styx.dokumenzi.ch, wo ich keinerlei Änderungen vorgenommen habe, gleich.

  19. Ian Styx am :

    Bei FileZilla Einstellungen - Übertragungen - FTP-Dateitypen stehen welche genauen Enstellungen?
    Automatisch ist gut und beide checkboxen aktiviert.

  20. Beat am :

    Ja, genau so steht es da (Standard nach Installation. Habe hier nie etwas verändert.)

    Ich vertraue Dir auch soweit, dass ich Dir die FTP-Zugangsdaten übermitteln würde... damit Du selber nachsehen kannst.

  21. Ian Styx am :

    Muss nicht!
    Ich habe das mit den Einstellungen nur erwähnt, weil FTP Programme manchmal zicken machen und Datei falsch hochladen. Aber FileZilla (in einer neuen Version) sollte damit kein Problem haben, ...normalerweise.

  22. Beat am :

    FileZilla und Notepad++ sind jeweils auf dem neusten Stand. (Auch sonst bemühe ich mich, keine veraltete SW einzusetzen.)

  23. Ian Styx am :

    Es geht ja um diese Dateien
    https://www.blog.dokumenzi.ch/templates/sliver/preview_fullsize.jpg
    https://www.blog.dokumenzi.ch/templates/sliver/preview_fullsize.webp
    https://www.blog.dokumenzi.ch/templates/sliver/preview.webp
    https://www.blog.dokumenzi.ch/templates/sliver/preview.png
    Dein Server zeigt sich hier ungewöhnlich zickig.

  24. Beat am :

    Zumindest bei dieser Sache habe ich sehr wohl verstanden, worum es geht. ;-) :grins:

    Ich sehe per FileZilla die Daten auf dem Server, habe sie (zur Sicherheit) aber erneut raufkopiert/überschrieben und trotzdem werden sie nicht angezeigt. Blöd :grrr: , doch ich weiss echt nicht, wie ich noch helfen könnte.

  25. Beat am :

    Muss jetzt weg (die nächste Weihnachtsfeier). Wünsche einen schönen Abend! :wave:

  26. Ian Styx am :

    Nicht mir! DIR! :-P

    Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator to inform of the time the error occurred and of anything you might have done that may have caused the error. More information about this error may be available in the server error log.

  27. Beat am :

    Öhm... war das hier? Oder bei Dir?

  28. Ian Styx am :

    Bei dir natürlich. Ist ja reproduzierbar. Öffne die Links mal über markieren und öffne in tabs. Result 500er Error.

  29. Beat am :

    Mein Server-error-log spuckt dazu zwei Fehler aus:

    Code 500
    GET /templates/sliver/preview_fullsize.jpg HTTP/1.0

    darunter, gleiche Zeit, ohne Code
    [core:alert] xxxBeatxeditxxx/styx-master/templates/sliver/.htaccess: FilterProvider takes three arguments, filter-name provider-name match-expression

    Es scheint also ein Problem mit der /silver/.htaccess zu geben. Wenn ich die umbenenne, werden die Bilder im Browser und auch im Backend/Themes richtig angezeigt.

  30. Ian Styx am :

    Sehr gut! Danke.
    An die habe ich überhaupt nicht (mehr) gedacht.
    Das die auf Nginx so ein Aufhebens macht ist ziemlich doof und nicht vorgesehen, außerdem müsste sie auch noch auf Apache 24 verifizeirt werden. Ingesamt also eher nur ein Vorschlag, daher *nun* disabled.

  31. Beat am :

    Habe in /templates/silver die Datei *.htaccess* in *.disabled-htaccess* umbenannt. Nun werden die Bilder im Backend und auch über obige Direktlinks angezeigt.

  32. Beat am :

    Habe die neusten Daten (25.12.2019, 19:32) komplett heruntergeladen und damit alle bisherigen Dateien überschrieben. Die Silver-Theme-Vorschaubilder werden leider immer noch nicht angezeigt.

  33. Ian Styx am :

    Ich finds nimmer...

    Für den comment pc-owner habe ich nochmal nachgedacht und würde gerne noch mal etwas testen.

    Ersetze
    https://github.com/ophian/styx/blob/master/templates/pure/style.css#L1271 ff
    mit

    .comment h4 .pc-owner,
.serendipity_comment_author_self h4 .pc-owner {
    background: #3e5f81e6;
    padding: .0075em .15em;
    border-radius: 3px;
    border: 1px solid #999;
    color: #efefef;
    font-style: normal;
    text-shadow: 1px 1px 2px #222;
}

    Damit sollte den pc-owner auch überall jetzt hervorgehoben werden. Ich glaube ich war an dieser Stelle einfach zu übervorsichtig.

    Für die Kommentar Abonniert Frontend Geschichte bräuchte ich auch noch mal etwas Unterstützung. Kannst du mir einen Fall zur Ansicht geben in dem tatsächlich auch Abonniert anzeigt wird (und den ich mir eingeloggt ansehen kann) ?!?

  34. Beat am :

    Also CSS-Teil in /templates/pure/style.css integriert und Kommentar mit Abo abgesetzt.

    https://www.blog.dokumenzi.ch/2571-Abonniert-Anzeige.html

  35. Ian Styx am :

    CSS bitte auch in beat theme ersetzen.

  36. Beat am :

    In meiner user.css gibt es keinen Eintrag beginnend mit *.comment h4*. Dieser sollte demzufolge aus pure/style.css übernommen werden. Für comments habe ich lediglich Farbveränderungen vorgenommen.

    "schäm"... habe die erste Zeile nicht kopiert... nun aber nachgereicht... :shame: macht den Unterschied...

  37. Ian Styx am :

    Der Teil ist ja auch neu...
    Du hast keine eigene style.css?
    Und hast in pure.style das ersetzt?

    Warum steht dann immer noch nur 

    .serendipity_comment_author_self h4 .pc-owner {
    im stylesheet?

  38. Ian Styx am :

    Ok da haben wir uns wohl überschnitten. Jetzt brauchen wir nur noch testen, ob jemand absichtlich den pc-owner intruieren bzw provozieren kann. Ich hatte, als ich diesen erfand, natürlich auch alte Kommentare in mind, die damals ja noch keinen integrierten Schutz gegen feindliche (Namens) Übernahmen hatten..

  39. Beat am :

    Nein, ich habe keine style.css und pflege in /pure-beat/user.css nur Abweichungen zur /pure/styles.css ein.

    In der /pure/style.css ist jetzt der Code genau so, wie Du ihn oben gezeigt hast.

  40. Ian Styx am :

    ??????? ?????? ????? ???? 2020 ???????

  41. Beat am :

    :wave: DANKE! Gleichfalls! :th_up:

    Habe ich einen Wunsch frei?

    Ich wünsche mir, dass die Smileys nicht nach 10 Bildern auf eine neue Zeile umbrechen (direkt unter diesem Frontend-Formular), sondern dass der Umbruch automatisch erfolgt. Ich möchte nämlich noch ein oder zwei neue Smileys aufnehmen. Das sieht aber super blöd aus, wenn dafür eine neue Zeile gebraucht wird. Die im Event-Plugin steckende serendipity_event_emoticonchooser.php sieht aber so kompliziert aus, dass ich a) den entsprechenden Eintrag für diesen Umbruch nicht finde und mich b) auch kaum getrauen würde, daran rumzuschrauben. ;-)

    Falls das aber eine doofe Idee ist, einfach sagen.

  42. Ian Styx am :

    #serendipity_emoticonchooser_comment br {
    display: none;
}

    So?

  43. Beat Menzi am :

    :th_up: BOAHH :heart: PERFEKT !

    Vielen Dank! (und das ganz einfach in der user.css) Wunderbar!

    Falls ich Dir einen Wunsch im neuen Jahr erfüllen könnte, dann hast Du somit einen frei. ;-)

  44. Ian Styx am :

    ? CSS ?

  45. Beat Menzi am :

    Kleine Anmerkung zur der Info-Anzeige des s9ymarkup. Da steht:

    Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.

    Eleganter (und klarer) fände ich:

    Umschließende Sterne heben ein Wort hervor (*Wort*), mit Tiefstrichen kann ein Wort unterstrichen werden (_Wort_).

    so erkennt man beides Mal Syntax und Effekt.

  46. Beat am :

    O.K. Nach den neuesten Anpassungen nehme ich an, dass fette und unterstrichene Schrift in den Hinweisen nicht geht. Schmunzeln musste ich wegen "Anderenfalls _."

    Diesen _anderen Fall_ will ich hier ausprobieren und hoffe, dass ich nicht zu doof dafür bin...

    Als unbescholtener Blogleser wüsste ich aber nicht, weshalb ich nun wort oder in welchem anderen Fall ich nun _wort_ benutzen sollte. :roll:

  47. Beat am :

    Der Backslash wird verschluckt.

    Ich will Dir ja nichts ausreden (in was Du schon viel Energie gesteckt hast), doch braucht es Unterstrichen wirklich??? Ich meine, ob fett oder unterstrichen ist doch gehüpft wie gesprungen. So oder so eine Hervorhebung.

    Die Unterstreicherei zickt herum und nur weil es das in Original S9Y gibt, braucht es das doch nicht unbedingt in der Styx Edition. Ich glaube, Du würdest Dir einen Gefallen tun, wenn Du hier den "Mut zum Weglassen" zeigen würdest und nur noch die Fett-Variante anbietest. Nach meiner bescheidenen Meinung reicht das völlig. Wie gesagt: In meinen >1'500 Kommentaren des Live-Blogs hat noch nie jemand etwas unterstrichen.

  48. Ian Styx am :

    "Der Backslash wird verschluckt."
    Genau! Dazu dient er. Er "escaped" den Unterstrich. Dies erkennt die markup Funktion, wandelt solche Vorkommen in etwas Temporäres und wandelt das dann, nach der Unterstrich Funktion, wieder in einen normalen Unterstrich zur Ausgabe.

  49. Beat am :

    Aha... das ist also "der andere Fall"...

    Und Du glaubst ernsthaft, dass dies (aufgrund der Info-Anzeige) jemand versteht? :roll:

    Ich weiss: Loslassen fällt oft sehr schwer, doch ich sag's nochmal: Hau weg den Unterstrichen-Scheiss! Das braucht kein Mensch und Du bist damit viele Probleme los.

  50. Ian Styx am :

    Abwarten... (ich habe schon Ideen dazu...)
    Es ist ein Relikt aus alter Zeit, sehr wohl. Doch hat es, wenn auch unvollkommen, bereits viele Jahre überstanden ohne je rausgeflogen zu sein. Man muss das so sehen: Man fängt klein und sehr simpel an und dann entdeckt man nach und nach die Mächtigkeiten von Serendipity.

  51. Ian Styx am :

    Bevor ich irgendwann zu meinen möglichen Ideen komme, habe ich aber - glaube ich - das beschriebene Problem gelöst.
    So schreibe ich noch einmal mein Beispiel mit dem serendipity_event entrypaging hier hinein (diesmal ohne das Backslash) und verweise auch noch einmal auf die beispielhafte $template_options.use_corenav Variable, so dass, wenn das Update dann erfolgt ist, wir hier den Erfolg meiner heutigen Maßnahme betrachten können.

  52. Beat am :

    never ever give up! 8-)

  53. Beat am :

    Habe soeben die neue serendipity_event_s9ymarkup.php hochgeladen. Ich denke, die dadurch erfolgten Änderungen entsprechen Deinen Vorstellungen. :applaus:

  54. Ian Styx am :

    So ist es! Danke der Ansicht.

  55. Ian Styx am :

    zb wenn du etwas über das serendipity_event_entrypaging Plugin schreibst, oder auf $template_options.use_corenav Variable verweist.
    Beides hier schon gehabt und selbst das verbesserte s9ymarkup für das Unterstreichen reißt an dieser Stelle Löcher auf, die, wenn es nur den Unterstrich beträfe, nicht ganz so schlimm wären, als sie es derzeit sind, denn es entfernt den letzten vor und den ersten Buchstaben nach dem Unterstrich bevor es diesen in ein u markup umwandelt.

  56. Ian Styx am :

    Ich habe gerade noch so eine kleine Merkwürdigkeit deines Blogs entdeckt. Die language Dateien deines freetag Plugins stimmen nicht. Hast du das durch Spartacus installiert? Oder per FTP?

    Version ist 4.26, wie es sein sollte, aber mit teils nicht übersetzten Optionsbechreibungen, die aber definitiv in 4.26 übersetzt vorliegen.

    Das ist jetzt nicht weiter schlimm, aber zeigt das beim Upload oder so irgendetwas nicht richtig stimmt und das Problem könnte damit potentiell mehr als nur diese Dateien betreffen.

    Welches FTP Programm und in welchem Upload Modus nutzt du es? (Übertragungstyp) Automatisch, Ascii, oder Binär?

  57. Ian Styx am :

    Gerade ist mir noch aufgefallen, dass es bei dir eine Kategorie mit dem Namen:

    PC, Blog
    4 - EDV, Internet, etc. (Alle Autoren)

    gibt. Frage:

    • Ist das wirklich so beabsichtigt?

    Potentiell ist das etwas, dass dem System gehörige Kopfschmerzen verursachen kann, da Array-Trennungen von solch "thematischen Organisationskonstrukten" bzw. keys codetechnisch oft nur durch ein Komma bewerkstelligt werden. Kategorien sind eigentlich dazu gedacht thematische Ein-Wort-Konstrukte zu sein, bei denen man aber Binde- bzw. glaube ich sogar Unterstriche verwenden kann. Kategorien kann man aber hierarchisch sinnvoll, in Familien oder Gruppen ordnen.

    Ich würde dir empfehlen, dass also, eigentlich wie schon durch das Komma impliziert, in 2 unterschiedliche bzw 2 verwandte Kategorien aufzulösen und das in deinen entries entsprechend anzupassen.

     

  58. Beat am :

    Ich verstehe Deine Argumentation völlig. Diese Kategorie gibt es schon seit 14 Jahren, ohne dass es je (von mir erkennbare) Probleme gegeben hat.

    Trotzdem habe ich sie nun von PC, Blog auf PC-Blog abgeändert und werde mal zusehen, ob Probleme damit auftauchen. Wenn nicht, kann ich das dann auf www.beatsblog.ch nachvollziehen.

  59. Ian Styx am :

    Guten Morgen

    Jeden Tag dasselbe Bild. Ein dickes gelbes footer Banner mit: Diese Website verwendet Cookies. Informationen dazu finden Sie in der Datenschutzerklärung (als Link) aber - dann ist da nix! Akzeptieren hilft nur für den Tag und ist nichts anderes als ein "dummes" Ärgernis für den Besucher. (Das ist jetzt allgemein gesprochen!)

    Ich weiß, das ist DSGVO.... aber entweder fügst du deine Datenschutzverordnung dann dort auch ein, bzw verlinkst auf eine statische Seite die jene enthält oder du läßt das komplett bleiben. Ich bin für letzteres aber mit einer statischen Seite über Datenschutz, Privacy etc. Ich erkläre mal warum:

    Denn wozu braucht man das wirklich? Nur dann, wenn Cookies wirklich zum Tracken eingesetzt werden. Das heißt wenn du damit zb google-analytics bedienst, oder gar facebook vertrackst oder allgemein Seiten- und Site-übergreifende trackings anlegst wie es shops, newsseiten, etc es gerne tun. Unterscheiden muss man natürlich auch noch private Seiten und rechtlich relevante Seiten (wie zb Bike Butler), aber das ist ja wohl klar.

    Das alles macht Serendipity/Styx nicht. Wenn der user zb wie "Daten merken" (Kommentar) nutzt, so ist das seine freie Entscheidung und dient allein dem persönlichen Komfort. Sonst gibt es nur Cookies wie Session Cookies die zum Betrieb der Seite erforderlich sind. Diese sind aber (ausdrücklich) ausgenommen in der DSGVO.

    Diese Angst vor obskuren Abmahnungen ist also eher irrational.

    Mach dir dazu mal ein paar Gedanken. ?

  60. Beat am :

    Ich mach das nur, um Dich zu ärgern/langweilen! ?

    DSGVO ist/war hier nie richtig implementiert. Das ist ja der Testblog, deshalb habe ich dem keine Beachtung geschenkt. Nun habe ich auf die richtige Seite verlinkt.

    Weshalb Du jeden Tag das gelbe Banner siehst, weiss ich nicht. Dieses Phänomen erlebe ich so nicht. Ich muss Dich ja wohl kaum fragen, ob Du den Browser so eingestellt hast, dass er beim Beenden alle Cookis löscht.

    Ganz grundsätzlich installierte ich das Plugin nur um anzugeben und um meinem Blog eine gewisse Relevanz zu verleihen, die er in Tat und Wahheit gar nicht hat... ?

  61. Ian Styx am :

    ...ich hätte jetzt gerne ein telegram sticker zb die "hahaha Banane"! ?

    Das darfst du ja - ich wollte es nur mal loswerden. Und mir war schon klar das das hier eigentlich unrelevant ist.

    Hmmm, Site cookies eigentlich nicht. Drittcookies werden gar nicht erst zugelassen.

    Nimm doch mal einen Browser mit dem du nicht eingeloggt bist.

  62. Ian Styx am :

    Hast du hier rumgespielt? Dein Banner passt nicht mehr...

  63. Beat am :

    Nö... Mit Banner meinst Du die Evolutionsgrafik im Header? Sieht bei mir ganz normal aus (auch nach Refresh)

  64. Ian Styx am :

    Ah shit - mein Browser stand auf 90% Ansicht. Hatte mich schon gewundert, dass auch die Kommentarschrift anders aussah. Nix für ungut! ?

  65. Beat am :

    imagesidebar-Plugin

    Habe hier das Plugin von 1.15 auf 1.16 upgedated. Aus irgendeinem Grund wird das CSS nun bei den Bildern 2 & 3 nicht mehr angewendet. Ist das ein Fehler oder muss ich in meiner user.css etwas anpassen/einfügen? Derzeit steht da lediglich:

    #mediasidebar img {
	border-left: 1px solid #eaeaf4;
	border-top: 1px solid #eaeaf4;
	box-shadow: 3px 3px 3px #b8b8da;
	box-sizing: border-box;
	border-radius: 4px;
	margin-bottom: .5rem;
	margin-left: auto;
	margin-right: auto;
}

     

  66. Beat am :

    Hmm... ?

    Jetzt sieht es (fast) wieder so aus wie vorher. Nun steht in der user.css:

    #serendipityRightSideBar img,
.serendipitySideBarContent img {
	border-left: 1px solid #eaeaf4;
	border-top: 1px solid #eaeaf4;
	box-shadow: 3px 3px 3px #b8b8da;
	box-sizing: border-box;
	border-radius: 4px;
	margin-bottom: .5rem;
	margin-left: auto;
	margin-right: auto;
}

    ? wieso steht das erste Bild ganz minimal mehr rechts als die zwei darunter?

    ... ich werde das Plugin auf www.beatsblog.ch noch nicht updaten...

  67. Ian Styx am :

    Zur Erklärung. Vorher hat das Plugin id="mediasidebar" für jedes der angezeigten Bildercontainer geschrieben. Das ist nicht erlaubt. Ein Knoten (ID) muss unique sein.
    Ich habe also den Knoten #mediasidebar Container so verschoben, dass er nur noch einmal geschrieben wird und darin die 3 Bilder mit dem neuen container und der neuen Klasse mediasidebaritem aufbewahrt werden.

    <div id="mediasidebar">
    <div class="mediasidebaritem">
        <a href="/1131-abgebrochen.html" title="abgebrochen"><img style="border: 0px; width:200px;" src="/uploads/2008/20081109_03.styxThumb.jpg" alt=""></a>
    </div>
</div>

    Ich glaube du meinst:

    #mediasidebar {
    margin-left: .1rem;
}

    ...suchen, löschen und bestätigen. ? oder?

    Außerdem kannst du jetzt so schreiben

    #mediasidebar .mediasidebaritem img {
    border-left: 1px solid #eaeaf4 !important;
    border-top: 1px solid #eaeaf4 !important;
    box-shadow: 3px 3px 3px #b8b8da;
    box-sizing: border-box;
    border-radius: 4px;
    margin-bottom: .5rem;
    margin-left: auto;
    margin-right: auto;
    width: auto !important;
}

     

  68. Beat am :

    Danke für die Erklärungen.

    #mediasidebar {
    margin-left: .1rem;
}

    habe ich entfernt.

    Das mit:

    #mediasidebar .mediasidebaritem img

    hat leider nicht funktioniert. Wenn ich die Bildelemente untersuche, wird mir auch angezeigt, dass die Formatierung für folgende Klassen angewendet wird:

    #serendipityRightSideBar img,
.serendipitySideBarContent img

  69. Ian Styx am :

    Natürlich, das war ja die Ersetzung von

    #serendipityRightSideBar img,
.serendipitySideBarContent img

    da dass ja von dir stammte (user.css).

  70. Ian Styx am :

    Ich habe gerade gesehen, dass ich einen dummen closing Fehler eingebaut habe. Neue Version ist online!
    Ich habe zusätzlich eine Option eingebaut um die styles abzuschalten. Die styles sollte man besser in seine user.css setzen. Aus Kompatibilitätsgründen steht die Option aber per default auf yes. Man muss sie also explizit abschalten.

  71. Beat am :

    Unter Plugins > Updates wird keine neue Version des imagesidebar-Plugins angezeigt. Muss ich die neuen Daten manuell downloaden und an die richtige Stelle hochladen?

  72. Ian Styx am :

    Sehr merkwürdig. Ich bin gerade etwas ratlos was da wohl passiert ist... Habe nochmal einen version bump auf 1.18 gemacht.

    Aber auch der geht nicht. Ich meine die xml Dateien sind in Ordnung.
    Vielleicht ein Infekt, ein coronaler ? Wir müssen mal auf morgen hoffen.

  73. Beat am :

    Heute hat es geklappt. ?

    Nachtrag: Komisch, auf www.beatsblog.ch wird mir das neue Plugin nicht angeboten. Werde es morgen nocheinmal versuchen.

  74. Ian Styx am :

    Ich bin auch wirklich erstaunt. Ich habe/hatte das Verhalten hier auch, in 2 Blogs sogar. Einer ging gestern nicht, aber heute.
    Der andere - gerade entdeckt - steht auf Version 1.14. und wird nicht zum Update angezeigt. Vielleicht muss ich ZARATHUSTRA als Upgrade task mal wieder aktivieren. Es passiert manchmal, und ist damit nicht wirklich transparent "warum eigentlich" (*), dass lokale Plugin Einträge in der pluginlist Tabelle mit der ihrer upgrade_version nicht korrekt eingetragen werden, obwohl die remote Version des Plugins aus der XML Datei korrekt erfasst ist. Und so bleiben sie als Zombies unbeachtet. In dem Fall hilft nur: - manuelles Eintragen in der DB (*), - oder eben Zarathustra, - oder löschen per Spartacus und physikalisches löschen des Plugins per FTP (o.Ä.) und dann eine Neuinstallation über Spartacus.

    (*) Wenn man die Datei aufruft und eventuell sogar speichert, wird ein modified date generiert, dass zum Aus-checken über Spartacus auch eine Rolle spielt. Dies Phänomen hatte ich hier lokal im Verdacht, als ich das mit dem "Warte bis Morgen" sagte.

    (*) phpmyadmin sql tab

    SELECT * FROM `styx_pluginlist` WHERE class_name LIKE '%imagesidebar'

     

  75. Ian Styx am :

    Manchmal (oder immer) ist v.e.r.s.t.e.h.e.n einfach nur g.e.n.a.u.e.s Hinsehen! (Und dann ein Versuch es zu beschreiben, was ich hiermit einfach mal ins Blaue hinein tue...)
    Ich habe inzwischen den Verdacht dass es sich hier um einen grundsätzlichen bzw sogar 2 oder mehr Bugs handelt.

    Früher wurde das Spartacus Plugin Update handling fein säuberlich getrennt, zwischen event und sidebar Plugins. Mit Serendipity (S9y) 2.1-dev kam ein  Add "update all"-button to plugin update page commit hinzu, der diese Trennung gewissermaßen aufhob. Irgendwo ist da vergessen worden (lokale) sidebar plugin Einträge explizit auch als solche wieder auszuweisen, denn die lokalen stehen, bei mir (und das ist möglicherweise speziell, denn ich arbeite als Developer naturgegebenermaßen viel mit lokalen Plugins), soweit ich sehe, alle auf event, was definitiv falsch ist.

    SELECT * FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local' AND plugintype = 'event'

    Warum tritt dieses Verhalten aber nur manchmal auf?
    Weil es u.a. auch viele Kombiplugins gibt, deren update eben auch mir dem falschen Eintrag funktioniert.

    Noch früher in 2.0 wurden interne (unechte) Plugins zu echten (physikalischen) Plugins und dann auch noch umbenannt. Diese hatten - soweit ich mich recht erinnere - keinen Eintrag als plugintype. In der Folge wanderten ein paar davon auch noch nach remote, also additional_plugins. Leute, die nie mit Plugins im physischen Sinne (touch) zu tun haben, werden vielleicht auch nie mit diesem Problem behelligt werden. Irgendwo in diesem Zusammenhang kommt es also zu einem Fehleintrag, ob dann individuell oder generell für alle diesbezüglichen ist da noch die Frage, oder sogar mehreren Folgebugs.

    Interessant nun aber ist, installiert man ein echtes und neues Sidebar Plugin (zb sidebarlogo) über Spartacus, so ändern sich sofort alle eben noch als 'event' plugintype ausgewiesen lokalen sidebar Plugins in die richtige Form 'sidebar'. Ich würde deshalb raten, dies einmal zu tun. Danach kann man das Plugin auch wieder über Spartacus löschen und sicherheitshalber auch physikalisch per FTP. Nun müsste bei nächsten run des XML files oder sogar schon jetzt das imagesidebar update erscheinen, oder es liegt noch ein weiterer Bug vor (ich vermute letzteres).

    Mit dem Infekt hatte ich also gar nicht mal so unrecht! ?
    Es ist etwas hakelig schon jetzt ein Updateversuch zu wagen, da ich noch mehr die Aktiionsbeziehungen zwischen Synchronisierungen, Spartacus- und Pluginlist-Aktionen und Updates hinterfragen muss.

  76. Beat am :

    Interessant nun aber ist, installiert man ein echtes und neues Sidebar Plugin (zb sidebarlogo) über Spartacus, so ändern sich sofort alle eben noch als 'event' plugintype ausgewiesen lokalen sidebar Plugins in die richtige Form 'sidebar'. Ich würde deshalb raten, dies einmal zu tun. Danach kann man das Plugin auch wieder über Spartacus löschen und sicherheitshalber auch physikalisch per FTP. Nun müsste bei nächsten run des XML files oder sogar schon jetzt das imagesidebar update erscheinen, oder es liegt noch ein weiterer Bug vor (ich vermute letzteres).

    1. Ich habe auf www.beatbsblog.ch das sidebarlogo-Plugin installiert. Danach wurde mir bei "Plugins updaten" kein Plugin vorgeschlagen (auch das imagesidebar nicht).
    2. Dann löschte ich das sidebarlogo-Plugin wieder (via S9Y). Auch dann kein Update-Vorschlag.
    3. Dann löschte ich per FTP das Verzeichnis "serendipity_plugin_sidebarlogo". Noch immer kein Update-Vorschlag.

    Ich stütze also Deine Vermutung, dass noch ein anderer Bug vorliegt.

  77. Ian Styx am :

    Tja, das war leider zu erwarten... Noch dümmer ist, das nach der "Plugins updaten" Synchronisierung mit dem aktuellen XML File wieder 'event' eingetragen wird, wie ich inzwischen herausgefunden habe und was jedenfalls die Geographie des Bugs sehr viel näher bestimmt.

    Wenn du nicht warten kannst musst du imagesidebar in Spartacus löschen und dann ebenfalls den physischen Ordner und dann einfach neu über Spartacus installieren. Dann sollte es gehen.

  78. Beat am :

    Öm, Nein. Im Vordergrund (Frontend) funktioniert es auch auf www.beatsblog.ch wie es soll und das ist für mich wichtig. Im Hintergrund mag es vielleicht noch nicht so gut sein, wie die aktuelle Version. Ich kann locker zuwarten, bis Du alles aussortiert und geradegebogen hast. ?

  79. Beat am :

    Heute hat der Update von serendipity_plugin_imagesidebar auf V1.19 sowohl hier, wie auch auf www.beatsblog.ch, einwandfrei funktioniert. ?

  80. Ian Styx am :

    Strange strange und das bei den Fehlern. ... Selbst die verhalten sich nicht konsequent logisch! ?

    Bis du sicher? Denn die imageshaben immer noch "border: 0px; width:200px;" als inline style. Das müsste bei der no styles option eigentlich weg sein.

  81. Ian Styx am :

    Gerade noch eins gefunden; die 1.20 ist unterwegs. ?

  82. Beat am :

    Bis du sicher? Denn die imageshaben immer noch "border: 0px; width:200px;" als inline style. Das müsste bei der no styles option eigentlich weg sein.

    Habe gerade kontrolliert. Version ist 1.19, Set #mediasidebar and image inline styles steht auf Nein. Drei Zeilen weiter unten habe ich aber Image width auf 200px eingestellt.

    In meiner user.css gibt es keine Einträge zu #mediasidebar. Wie oben geschrieben style ich die Bilder über:

    #serendipityRightSideBar img,
.serendipitySideBarContent img

  83. Ian Styx am :

    Es dreht(e) sich um inline styles ?

    <img style="border: 0px; width:200px;" src="/uploads/2011/20110721_01.styxThumb.jpg" alt="">

     

  84. Beat am :

    Habe soeben auf V1.20 upgedated. Nun sind die inline-styles weg. ?

    Nur: Jetzt hängt mein 3px Bild-Schatten rechts aus dem Plugin raus und ich schaffe es einfach nicht mit margin-right das zu korrigieren. Liegt das daran, dass ich eben nicht die Klasse #mediasidebaritem anspreche? Das habe ich zwar auch probiert...

  85. Ian Styx am :

    .mediasidebaritem img {
  width: 98%; // oder
  width: 200px; // o.so
}

    Du weiißt aber, dass du mit #serendipityRightSideBar img, .serendipitySideBarContent img jedes Bild in der sidebar bestimmst, nicht wahr?! Auch zb die xml feed Bilder oder das Logo. Deshalb musstest du die rules für letzteres auch wieder zurückrufen, mit #serendipityRightSideBar .serendipity_image_center. Einfacher, simpler und klarer ist es eine CSS Anweisung nur für das eigentliche Ziel bzw Zielguppe zu schreiben.

    Belässt du es aber so wie jetzt, so musst du die Prioritäten beachten, wenn du eine generelle Anweisung mit einer detailierteren überschreibst:

    #serendipityRightSideBar .mediasidebaritem img,
.serendipitySideBarContent .mediasidebaritem img {
  width: 98%; // oder
  width: 200px; // o.so
}

    Auch ist beides ziemlich doppelt gemoppelt, also entweder .serendipitySideBarContent img (für alle images in allen sidebars) oder #serendipityRightSideBar img nur für rechte occurences. Du siehst also, dass die schon einmal angemerkte Konzentration (#mediasidebar .mediasidebaritem img) auf dein eigentliches Ziel wesentlich besser wäre.

  86. Ian Styx am :

    Noch besser wäre aber

    .mediasidebaritem img {
    width: auto;
    max-width: 98%;
}

    da du ja nicht nur gleichformatige Bilder anzeigen lässt.

  87. Beat am :

    Tja, machmal brauche ich etwas länger, bis ich es verstehe... ?

    Habe nun das "rightsidebar img"-Zeug aus der user.css geschmissen und .mediasidebaritem img verwendet. Und siehe da... es funktioniert, wie gewünscht. ?

    Danke für die Geduld! ?

  88. Ian Styx am :

    Jetzt musst du nur noch das " !important" in "border: 1px solid #b8b8da !important;" entfernen.?

  89. Beat am :

    Gemacht! Danke! ?

  90. Ian Styx am :

    und #serendipityRightSideBar .serendipity_image_center {....} in

    .serendipity_plugin_html_nugget .serendipity_image_center {
    border: 0 none;
    box-shadow: none;
}

    ändern.

  91. Beat am :

    Sauber aufgeräumt! So mag ich das. Danke! ?

  92. Ian Styx am :

    Kurze Frage: War der Styx-Stand: 24.03.2020, 10:22 auf ein frisches Zip (oder vom vorigen Tag) zurückzuführen?

  93. Beat am :

    Du kannst davon ausgehen, dass ich die ganze Styx Edition als zip-File heruntergeladen habe. Ich entpacke die Datei lokal und schaue mir den Zeitstempel der Dateien an. Diese Angaben übertrage ich nach dem Upload dann hier in die Titelzeile.

    Nur in ganz seltenen Fällen ändere/erneuere ich lediglich einzelne Dateien. Dann ändere ich hier jedoch den Zeitstempel nicht.

  94. Ian Styx am :

    ???

  95. Ian Styx am :

    Hast du letzthin schon mal auf deine sidebar RSS Beiträge geklickt?

  96. Beat am :

    Du meinst hier? Ne, mache ich eigentlich nie... Aha, es verweist auf einen ungültigen Feedburner-Feed. Ja, da gab es noch Altlasten in der Konfiguration. Jetzt sollte es "normal" aussehen. Danke für den Hinweis.

  97. Ian Styx am :

    Kannst du hier bitte mal

        $serendipity['CBAfetchLimit'] = 20;

    in die serendipity_config_local.inc.php Datei setzen (oder vielleicht sogar 24) ..., dann muss ich nicht so ellenlang blättern wenn ich in unseren Kommentaren etwas nachschauen möchte.

  98. Beat am :

    Gemacht (mit 24)

  99. Ian Styx am :

    wunderbar! ?

  100. Ian Styx am :

    Die CBA fetch Limit scheint nicht mehr gesetzt zu sein. Hattest du sie in den unteren Teil hineingeschrieben?

    	// End of Serendipity configuration file
	// You can place your own special variables after here:
    $serendipity['useWebPFormat'] = true;
    $serendipity['CBAfetchLimit'] = 24;

    Dort sollten solche Variablen eigentlich automatisch erhalten bleiben, wenn die config neu geschrieben wird.

  101. Beat am :

    Nein, ich habe das Fetch-Limit oben eingesetzt. Nun jedoch die zwei genannten Zeilen unten eingefügt. Es werden also wieder 24 Kommentare pro Seite angezeigt.

  102. Ian Styx am :

    Entferne bitte mal das

    $serendipity['useWebPFormat'] = true;

    falls du es einfach übernommen hast. Ich habe immer wieder vergessen darauf hinzuweisen, dass das eigentlich nur eine temporäre Variable für die local.inc war, die während der (frühen) Enwicklung hin zu webp nötig war, damit man mit Vor-Versionen bereits testen konnte. (Ist in den NEWS erklärt.) Als ich dir dann das Beispiel für die CBA fetch Limit gezeigt habe, war die einfach da noch drin, ist aber mit 3.0 als explizite USER Variable unnötig geworden

  103. Beat am :

    Das habe ich erledigt.

    Sehr strange war, dass ich nach dem Klick auf den Admin-Link eine Updateschleife zu 3.0.beta1 durchlaufen musste (ohne mich vorher anzumelden). Nach diesem Quasi-Update sehe ich jedoch nicht die geringste Veränderung. In der Backend-Fusszeile steht immer noch 3.0.0 und auch das Cahngelog zeigt gar nichts von einer neuen Beta-Version. ?

    Übrigens: Ich wollte das Serendipity_config_local.inc.php auf www.beatsblog.ch ebenfalls überprüfen. Dort habe ich jedoch keine Berechtigung dazu. Ich finde das irgendwie komisch glaube aber, dass ich das schon einmal bemerkt habe. Kann mir das egal sein oder soll ich deswegen den Manitu-Support anschreiben?

  104. Ian Styx am :

    Das mit dem beta Ding hat eventuell (bzw sicherlich) mit deinen Downgrades zu tun.

    Ja das ist ein bekanntes und bewußt gesetztes Verhalten bei Manitu und es ist eher unnötig dies als "Fehler" zu deklarieren. Sie versprechen sich davon mehr Sicherheit. Dumm ist nur, wenn man ganz dringend da rein muss, zb weil man sein 503 maintenance mode verbockt hat, oder gerne mit USER Variablen arbeitet.

    Für solche Fälle gibt es glaube ich ein Script names fixperm, siehe
    https://ophian.github.io/hc/en/faq/#docs-my-upgrade-failed-or-i-cannot-change-permissions-of-my-files
    Ich habe es allerfings noch nie für den Manitu Fall angewendet.

  105. Beat am :

    Ach nee... das hat damit zu tun, dass ich eine alte Version des serendipity_config_local.inc.php abgeändert und hochgeladen habe. Darin steht nämlich:

    $serendipity['versionInstalled']  = '3.0-alpha4';

    Was muss ich denn nun da reinschreiben? Wenn ich es auf '3.0.0' ändere, erhalte ich eine leere, weisse Frontendseite. Und ich kann ja eben nicht mal rasch auf beatsblog nachsehen. So doof. ?

    Nachtrag: Hat sich erledigt. Nach dem "Update" steht da nun:

    $serendipity['versionInstalled']  = '3.0.0';

  106. Ian Styx am :

    Das file heißt serendipity_config_local.inc.php. '3.0.0' wäre schon richtig, aber eigentlich jetzt doch unnötig, da du ja den upgrade task bekommen und abgeschlossen hast. Damit schreibt sich diese dann von selbst neu.

  107. Beat am :

    Ja, hab's auch grad gemerkt und den Kommentar oben abgeändert.?. Scheint nicht mein Tag zu sein. Ich lasse heute wohl besser die Finger von der Konfiguration...

  108. Ian Styx am :

    ?

    Ich habe übrigens die pure Solution committet mit einigen Änderungen.... ?

  109. Beat am :

    Ich schulde Dir noch eine Antwort von wegen Kommentieren per iPhone. Das funktioniert sowohl bei www.beatsblog.ch (mit js) und auch bei www.styx.beatsblog.ch (ohne js).

    Was man aber nicht tun sollte: Den Blog mit einem iPad und Safari im Hochformat betrachten Die statische Titelseite und die Blogdarstellung (/frontpage) sieht noch o.k. aus, doch die Single-Entry-View ist zum ? heulen. Da wird in der linken SL der Content dargestellt und umgekehrt. Die rechte Seitenleiste stimmt zwar, doch sollten bei der Auflösung ja generell keine SL angezeigt werden.

    Sobald man etwas nach unten scrollt, korrigiert sich SL und Content, doch die Seitenbreite ist viel zu breit. Dies liegt vermutlich am entrypaging-Plugin, welches weit rechts, ausserhalb allem noch dargestellt wird (und deshalb wird wohl auch die Seite incl. SL dargestellt, weil eine bedeutend grössere Bilschirmbreite angenommen wird).

    Ich habe dann das entrypaging-Plugin deaktiviert und siehe da: nun stimmt auch die Darstellung auf dem iPad (ohne SL)

    Tja: Das entrypaging-Plugin bremst nicht nur die Single-Entry-View, sondern es zerschiesst auch die Darstellung in einem Safari-Browser. Ich muss das wohl -schweren Herzens- killen. ☠

  110. Ian Styx am :

    Könntest du mir mal einen Gefallen tun und bitte in der Datei functions_rss.inc.php in den Zeilen 164/165 das hier

                serendipity_plugin_api::hook_event($entry_hook, $entry);
$entry['body'] = serendipity_entity_decode($entry['body'], ENT_COMPAT | ENT_HTML401, LANG_CHARSET); // testing atom feed error with entities
            $entry['per_entry_display_dat'] = !empty($entry['display_dat']) ? $entry['display_dat'] : '';

    einfügen, also die mittlere Zeile. mit dem // testing ..., denn mein feedreader bekommt seit https://www.blog.dokumenzi.ch/2635-kuerzlich-aufgefallen.html#c6821 keine kommentar feeds mehr aufgrund von umgewandelten Spnderzeichen wie Umlauten. Ich muss nur mal sehen ob dies die richtge Stelle für eine Korrektur der Ausgabe wäre...

  111. Beat am :

    Gemacht. Hoffe, es hilft.

    PS: Aus Interesse: Welchen Feedreader nutzt Du denn?

  112. Ian Styx am :

    Nee, das war es nicht. Bitte wieder weg machen. Danke.
    Ich nehme jetzt einfach .rss2 statt .atom10.
    Vielleicht hattest du da ja was umgestellt, oder die neueren FF sind noch atom unfreundlicher, ... wer weiß.

    Eigentlich keinen. Früher nur mit Boardmitteln. Heutzutage über feedbro.

  113. Beat am :

    O.K. Habe die Originaldatei wieder eingesetzt.

    Feedbro nutze ich auch. Habe zwar wenig/keine Vergleichsmöglichkeiten doch ich finde, Feedbro macht, was es soll.

  114. Ian Styx am :

    Ich gebe jetzt bald den RC der 3.0 heraus.
    Hast du alles vorbereitet, siehe autoupdate Plugin installiert und Update-Hinweis: beta ?

    Ich habe im Übrigens die pure/modernizr.js gelöscht. Wir haben bereits zweitausendzwanzig und eventuelle Rücksichtnahmen per modernizr sind hinfällig!
    Du solltest den head deiner beat index.tpl entsprechend anpassen.

  115. Beat am :

    Hast du alles vorbereitet, siehe autoupdate Plugin installiert und Update-Hinweis: beta ?

    Ja und Ja

     

    Du solltest den head deiner beat index.tpl entsprechend anpassen.

    das heisst: Ich muss diese Zeile aus der index.tpl löschen?

    <script src="{serendipity_getFile file="modernizr.min.js"}"></script>

     

  116. Ian Styx am :

    ja

  117. Ian Styx am :

    Thank you Be@t! ?

    https://github.com/ophian/styx/releases/tag/3.0-rc1

  118. Beat am :

    Hätte mir nun automatisch ein Update angeboten werden sollen?

  119. Ian Styx am :

    Ja. Möglicherweise ist da noch ein RELEASE check cache aktiv und es wird dir erst in den nächsten Stunden oder so angeboten. Ich weiß das es funktioniert.

  120. Beat am :

    Dann wart ich mal ab... ?

    (und datiere in der Zwischenzeit auf www.beatsblog.ch Beiträge zurück... ?)

  121. Ian Styx am :

    Mach dir da mal nicht allzuviel Mühe ... es geht um Einträge die zwischen 23:00 und 00:00 als timestamp eingetragen wurden! Ich versuche mich gerade als Houdini, aber mache das auch nicht alle Tage, so dass das etwas dauern kann.

    Select id, timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time from styx_entries WHERE timestamp <= 1572732840 ORDER BY time DESC

    Dies mal als Happen vorweg um zu zeigen wieviele Einträge es eigentlich betrifft.

    Wenn man also alle 23 Uhr entries ausfiltern kann, dann kann man auch nur diese um 1 Stunde zurücksetzen.

  122. Ian Styx am :

    Ist ja doch relativ einfach, ob hübsch sei dahingestellt...

    SELECT id, timestamp, title, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time from styx_entries WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23' ORDER BY time ASC

    Untersuche die mal Stichprobenartig.

    Sollte es die gewünschte Liste sein, kann man ein einfaches PHP script schreiben das die Resultate im timestamp korrekt um eine Stunde zurückrechnet und dies in die DB einträgt, also die alten entry Einträge updated.

    Das WHERE timestamp soll den letzten entry bestimmen der noch auf dem alten +1 offset Blog geschrieben wurde. Check mal ob ich den richtigen erwischt habe.

  123. Ian Styx am :

    OK mache dir vorher mal ein Backup der entries Tabelle, sicherheitshalber.

    Alles in einem Rutsch!

    Dann:

    UPDATE styx_entries AS T1,
      (SELECT id, timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time
        FROM styx_entries 
        WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23') AS T2 
  SET T1.timestamp=(T2.timestamp - 3600)
WHERE T1.id = T2.id;

    661 Datensätze betroffen.
    Überprüfe mit

    SELECT id, timestamp, DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H:%m' ) AS time from styx_entries WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23' ORDER BY time ASC

    müsste jetzt leer sein.

  124. Ian Styx am :

    Nur der Einfachheit halber sei es noch gesagt, dass man das erste date_format weglassen kann da man ja nix angezeigt bekommt. im Update sub select. Also:

    UPDATE styx_entries AS T1,
      (SELECT id, timestamp
         FROM styx_entries 
        WHERE timestamp <= 1572732840 AND DATE_FORMAT( FROM_UNIXTIME( timestamp ) , '%H' ) = '23') AS T2 
  SET T1.timestamp = (T2.timestamp - 3600)
WHERE T1.id = T2.id;

     

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
▲