Posts by Christopher Walz

    Ich habe das Problem, das eines meiner Inputs mit dem Datum aus meinem anderen <input> ausgefüllt wird, wenn man die Seite verlässt und per Zurück-Knopf auf der Maus zur Seite zurückkehrt.. Es scheint irgendwie damit zusammen zu hängen, dass das betroffene Input kein name-Attribut hat (ist in meinem Fall nicht notwendig, da es nur für JS benötigt wird).


    Demo-Video im Anhang.


    Ggf. kann man das in einer der nächsten Versionen beheben. Nach kurzem Debugging, scheint das Problem an dieser Stelle aufzutreten. Es passiert auch nicht immer. Was hilft, ist das öffnen der Entwicklerkonsole mit der Netzwerkoption "Disable cache", dann funktioniert das Reproduzieren bei mir immer.


    Getestet in Chrome im WSC 3.1 und 5.4.


    Live-Demo: https://cwalz.de/qedfwqeferheh/


    Demo-Code:

    Code
    <script data-relocate="true">
        require(['WoltLabSuite/Core/Ui/User/Search/Input'], function(UiUserSearchInput) {
            new UiUserSearchInput(elById('userSearch'));
        });
    </script>
    
    <input id="userSearch" type="text"{* name="userSearch"*}>
    <input type="date" name="time" id="time" value="{TIME_NOW|date:'c'}">
    
    <a href="{link}{/link}">index<a>

    Hallo,


    ich nutze Guzzle in einem eigenem Plugin per Composers autoload und erhalte seit WSC 5.4 diesen Fehler. Das liegt anscheinend daran, dass Guzzle nun 2x geladen wird (vom WSC und meinem Plugin).


    Einbindung bei mir:

    PHP
    require_once WCF_DIR . 'lib/system/api/cdn/autoload.php';
    
    use Google\Cloud\Core\Exception\NotFoundException;
    use Google\Cloud\Core\Exception\ServiceException;
    use Google\Cloud\Storage\StorageClient;
    use GuzzleHttp\Client;
    use Psr\Http\Message\RequestInterface;


    Kann ich den Fehler irgendwie unterbinden bzw. das Autoloading von Guzzle im WSC irgendwie an dieser Stelle verhindern?


    Ganze Fehlermeldung:




    Edit: Okay, wenn ich meine composer libs aktualisiere und die neue Guzzle Version genutzt wird, scheint es zu funktionieren.

    Sieht bei mir so aus:





    Sorry wegen des Bilds, ich bekomms über PHPMyAdmin nicht korrekt formatiert :X

    ja, und genau das ist der Fehler. Die Tabelle soll während des Upgrades gelöscht werden, ist aus irgendeinem Grund in wcf13_package_installation_sql_log nicht bekannt.

    Was genau heißt "nicht bekannt"? Sie ist dort auf jeden Fall mit dem richtigen Paket gelistet:



    Mit welcher Version wurde die Community initial installiert? Wurden womöglich irgendwann mal manuelle Änderungen an der Datenbank und insbesondere dem SQL-Log vorgenommen?

    Puh, das kann ich dir gar nicht mehr sagen. Das wcf13_package.installDate des Frameworks steht auf 2017-02-17 05:51:06. Ich bin mir nicht sicher, welche Version damals aktuell war, aber bestimmt 3.0 oder älter.


    Änderungen im SQL-Log wurden möglicherweise irgendwann mal vorgenommen, kann ich aber nicht 100% sagen.

    Update von WSC 5.3.11/WSF 5.3.10 auf 5.4


    Requested URL
    POST /acp/index.php?install-package/&t=x
    Referrer
    https://foo.de/acp/index.php?package-update/
    Error Message
    Das Datenbanklayout konnte aufgrund folgender Fehler nicht aktualisiert werden: Die unbekannte Tabelle wcf13_acp_session_virtual kann nicht gelöscht werden.
    Type
    RuntimeException
    File (Line)
    /www/htdocs/foo/bar/lib/system/database/table/DatabaseTableChangeProcessor.class.php (1116)
    Stacktrace
    1. /www/htdocs/foo/bar/lib/system/package/plugin/DatabasePackageInstallationPlugin.class.php (78): wcf\system\database\table\DatabaseTableChangeProcessor->process(…)
    2. /www/htdocs/foo/bar/lib/system/package/plugin/DatabasePackageInstallationPlugin.class.php (48): wcf\system\package\plugin\DatabasePackageInstallationPlugin->updateDatabase(…)
    3. /www/htdocs/foo/bar/lib/system/package/plugin/AbstractPackageInstallationPlugin.class.php (76): wcf\system\package\plugin\DatabasePackageInstallationPlugin->install(…)
    4. /www/htdocs/foo/bar/lib/system/package/PackageInstallationDispatcher.class.php (792): wcf\system\package\plugin\AbstractPackageInstallationPlugin->update(…)
    5. /www/htdocs/foo/bar/lib/system/package/PackageInstallationDispatcher.class.php (153): wcf\system\package\PackageInstallationDispatcher->executePIP(…)
    6. /www/htdocs/foo/bar/lib/acp/action/InstallPackageAction.class.php (82): wcf\system\package\PackageInstallationDispatcher->install(…)
    7. /www/htdocs/foo/bar/lib/action/AbstractDialogAction.class.php (73): wcf\acp\action\InstallPackageAction->stepInstall(…)
    8. /www/htdocs/foo/bar/lib/action/AbstractAction.class.php (53): wcf\action\AbstractDialogAction->execute(…)
    9. /www/htdocs/foo/bar/lib/system/request/Request.class.php (89): wcf\action\AbstractAction->__run(…)
    10. /www/htdocs/foo/bar/lib/system/request/RequestHandler.class.php (119): wcf\system\request\Request->execute(…)
    11. /www/htdocs/foo/bar/acp/index.php (11): wcf\system\request\RequestHandler->handle(…)

    Die Tabelle existiert.

    Wie geht ihr eigentlich mit einem DatabaseObject um, das bspw. ein Feld status hat, welches ein Wert von 1-5 in der DB haben kann. Wie fragt ihr dieses (speziell im Template) ab?


    Bsp. in PHP, wo es sauber funktioniert:


    PHP
    const STATUS_CANCELED = 1;
    const STATUS_FINISHED = 2;
    const STATUS_OPEN = 3;
    const STATUS_NEW = 4;
    const STATUS_UNKNOWN = 5;
    
    if ($foo->status === self::STATUS_OPEN) {
    ...
    }

    Im Template hingegen, müsste ich eine "Magic number" nutzen, was ja eher unsauber ist.

    Smarty
    {if $foo->status === 3}
    ...
    {/if}

    Meine aktuelle Lösung ist es pro Status eine Methode zu implementieren

    Foo::isStatusOpen, Foo::isStatusNew... wobei das bei vielen Stati den Code etwas aufbläht.


    Auf die Konstanten kann man im Template ja nicht zugreifen, oder habe ich da was verpasst?

    Ich würde mich über eine neue Methode DatabaseObject::refresh freuen.


    Statt

    PHP
    $foo = new Foo($fooID);
    $foo->changeStatus($newStatus);
    
    // we need a fresh foo with updated status
    $foo = new Foo($fooID);

    kann man dann

    PHP
    $foo = new Foo($fooID);
    $foo->changeStatus($newStatus);
    
    // we need a fresh foo with updated status
    $foo->refresh();

    schreiben. Andere große Frameworks haben auch einen solche Methode, z.B. Laravel.


    Ersterer Code wird auch öfters im Framework genutzt und könnte dann etwas gekürzt/vereinfacht werden:

    WoltLab/WCF
    WoltLab Suite Core (previously WoltLab Community Framework) - WoltLab/WCF
    github.com

    WoltLab/WCF
    WoltLab Suite Core (previously WoltLab Community Framework) - WoltLab/WCF
    github.com

    WoltLab/WCF
    WoltLab Suite Core (previously WoltLab Community Framework) - WoltLab/WCF
    github.com

    Wieso funktioniert der Code

    Code
    elById('declineLeadHidden').click();

    und der Code

    Code
    Core.triggerEvent(elById('declineLeadHidden'), 'click');

    nicht?


    Wobei .click() ja anscheinend schon ab IE 6 funktionieren soll, dann ists mir letzendlich auch egal ^^


    HTML:

    Code
    <button id="declineLeadHidden" name="declineLead" style="display: none"></button>

    Weiß jmd. wie ich es hinbekomme, dass ein leeres Array per AJAX Request auch bei PHP ankommt?


    software kommt nie in PHP an.


    Edit: Hab es anderweitig gelöst.

    Seit wann entspricht WCF_CLICK_EVENT eigentlich bereits click? Im WSC 3.1 scheint das bereits der Fall zu sein (clickEvent wird nicht genutzt):


    JavaScript
        /* assigns a global constant defining the proper 'click' event depending on the browser,
           enforcing 'touchstart' on mobile devices for a better UX. We're using defineProperty()
           here because at the time of writing Safari does not support 'const'. Thanks Safari.
         */
        var clickEvent = ('touchstart' in document.documentElement || 'ontouchstart' in window || navigator.MaxTouchPoints > 0 || navigator.msMaxTouchPoints > 0) ? 'touchstart' : 'click';
        Object.defineProperty(window, 'WCF_CLICK_EVENT', {
            value: 'click' //clickEvent
        });