Posts by Christopher Walz

    Das funktioniert aber irgendwie nicht wie gewünscht.


    Input:

    Code
    [tt]TEST[/tt]
    [event]1[/event]

    ergibt mit dem Code

    PHP
    $htmlInputProcessor = new HtmlInputProcessor();
    $htmlInputProcessor->process($content, 'foo.bar', 0, true);
    $content = $htmlInputProcessor->getHtml();

    das Ergebnis

    Code
    <kbd>TEST</kbd><br><woltlab-metacode data-name="event" data-attributes="WyIxIl0="></woltlab-metacode>

    Dabei ist es aber egal, ob ich den 4. Parameter von process auf true setze oder nicht. Mein alter Code

    Code
    MessageParser::getInstance()->parse($text, false, false, true);

    liefert bei dem Input das richtige Ergebnis aus (Event wird als Link dargestellt).


    Funktioniert die Umwandlung, so wie ich sie mir wünsche, nicht mehr direkt, ohne den Inhalt erst per HtmlInputProcessor zu speichern und per HtmlOutputProcessor auszugeben?


    Edit:


    So funktioniert es. Erscheint mir aber irgendwie komisch :|

    PHP
    $htmlInputProcessor = new HtmlInputProcessor();
    $htmlInputProcessor->process($content, 'foo.bar');
    $content = $htmlInputProcessor->getHtml();
    
    $htmlOutputProcessor = new HtmlOutputProcessor();
    $htmlOutputProcessor->process($content, 'foo.bar', 0);
    $content = $htmlOutputProcessor->getHtml();


    Kennt jmd. eine Möglichkeit per JS zu ermitteln, welche Menüpunkte aktuell für den Benutzer tatsächlich sichtbar sind und nicht erst durch den Klick auf den Pfeil sichtbar werden? Teils sichtbare Menüpunkte wie "Artikel" sollten auch als sichtbar erkannt werden.


    Danke!

    Weiß jmd. wie so ein Aufruf zustande kommt und welche URL da versucht wird aufzurufen?


    Code
    x.x.x.x.x - - [18/Jun/2021:00:21:48 +0200] "GET /../board/1337-leet/ HTTP/1.1" 400 3642 "-" "Buck/2.2; (+https://app.hypefactors.com/media-monitoring/about.html)"

    Error log sagt:

    Code
    [Fri Jun 18 00:21:48 2021] [core:error] [pid 30911:tid x] [client x.x.x.x.x:38886] AH00126: Invalid URI in request GET /../board/1337-leet/ HTTP/1.1

    Die Aufrufzahlen klingen mehr nach einem Webspace / vServer.

    Webspace ist uns aktuell bei all-inkl manchmal leider zu langsam, da hängen dann die Requests ein paar Sekunden. Das kann natürlich auch Pech sein, weil man jmd. auf dem Server hat, der viele Lastspitzen hat, jedoch wollen wir das genau verhindern.


    SSH-Zugang wird bspw. benötigt, um HeidiSQL nutzen zu können, da PHPMyAdmin leider nervt.


    Ein reiner vServer wäre eine Alternative, jedoch bin ich weit weg davon ein Serveradministrator zu sein und wenn es dann mal bei einem PHP/Maria/MySQL-Update zu Problemen kommt, wäre ich wohl etwas aufgeschmissen. Da es sich nicht um eine private Webseite handelt, muss die Erreichbarkeit gewährleistet sein und dann sind 50-100 Euro mehr im Monat für einen Managed Server auch kein Problem.

    Hat jmd. gute Erfahrungen mit Managed Server gemacht?


    Voraussetzungen:


    - Eher wenige Besucher (1000 Besucher / 5000-10000 Seitenaufrufe pro Tag)

    - Erreichbarkeit und Geschwindigkeit sehr wichtig!

    - ssh Zugriff soll vorhanden sein, root wird es vermutlich auf einem Managed nie geben?

    - kompetenter, schneller Support, der jede Anwendung installiert und entsprechende Einstellungen vornehmen kann

    - Standort Deutschland

    Das Problem saß mal wieder vor dem PC: ich hatte 2 Tage vorher aus Versehen in der Live DB in der Tabelle wcf1_application die urls zur Dev URL geändert und dadurch kam beim Update der Rescue-Mode :D


    Das ist vorher nicht aufgefallen, da der Cache zwischenzeitlich nicht geleert wurde.

    Ich hatte gerade ein seltsames Phänomen, was ich so vorher noch nie gesehen hatte.


    Ausgangssituation: Heute stand, wie jede Woche, ein Update meines Projektes an. Es war eigentlich kein Update mit großen Änderungen, jedoch führte es zu einem Fehler: Bei der Installation ging der Fortschrittsbalken bis 96% und danach öffnete sich neben dem Installations-Dialog ein weiterer Dialog mit dem Rescue-Modue.


    In den Inputs des Rescue-Formulars war die korrekte URL, jedoch ohne "www" eingetragen. Aus Panik habe ich dann etwas zu schnell bestätigt und das Formular abgesendet. Danach war die Seite in einem Loop, da in der Datenbank in wcf1_application die URL nun ohne "www" eingetragen war, per .htaccess aber "www" forciert wurde. Nach Ändern der URL in der DB zu "www" (wie es laut DB-Backups) auch vor dem Update war, lief wieder alles.


    Nach Absenden des Rescue-Formulars war die Plugin-Version übrigens nicht korrekt geupdated, ich musste das Update nochmals durchführen, dieses mal aber ohne das sql und script-PIP => hier gab es keine Probleme.


    Nun folgende offene Fragen:

    1. Wieso hat sich ein weiterer Dialog mit dem Rescue-Formular geöffnet?
    2. Wieso war die URL im Rescue-Formular ohne "www" eingetragen (vernachlässigbar)


    Die package.xml zum Update:



    Da der Fehler erst bei 96% auftrat, habe ich den Verdacht, dass es mit dem instruction type="script" zusammenhängt. Auch deswegen, weil ich den Fehler vorher noch nie hatte und die Script-Anweisung meines Wissens nach auch das erste Mal genutzt habe.


    access.log zum Zeitpunkt des Problems:



    wcf1_package_installation_node:



    Edit: update_1_0_250.php

    Der Script lief auch ohne "Fehler" durch. Das einzige Auffällige hier ist, dass er keine newline hat.

    Die aufgerufene Methode Agency:getLogoPath wurde erst mit diesem Update hinzugefügt, aber das sollte ja eigentlich keine Rolle spielen, da das file-pip vorher schon durchlief.


    Würde mich freuen, wenn jmd. mehr weiß als ich :)


    Grüße

    Wieso gibt es bei den WSC-Artikel eigl. kein Status wie "Nur mit Vorschaulink", wo man auf den unveröffentlichen Artikel nur zugreifen kann, wenn man in der URL einen korrekten Hash dran hat, der automatisch generiert wird :(


    Das wäre so hilfreich. Oder kennt jmd. ein Plugin dafür?