Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by adrian

  1. 8 hours ago, Mike Rockett said:

    @adrian – I've released 1.5.64 which adds the safety net around CLI usage (as a general rule) and request_uri. Please let me know if that solves it.

    Thanks - that has taken care of things. I actually think there are lots of modules that get loaded via CLI scripts even though they aren't needed. I kinda think PW should have a module autoload option for this to make it easier / more obvious to the developer to disable via CLI unless needed.

    • Like 2
  2. 40 minutes ago, Mike Rockett said:

    The only thing I can think of is an upgrade to PHP 8.1, as that's the only thing that can cause it.

    That would make sense, except I have been running 8.2 on that server for many months and the error started appearing immediately after updating Jumplinks from 1.5.61 to 1.5.63.

    35 minutes ago, Mike Rockett said:

    Guessing this should do the trick…?

    Yep, that should work just fine.

    Just a little FYI about something I have noticed in the past - sometimes $_SERVER['REQUEST_URI'] returns false rather than the URL or NULL (https://github.com/nette/tracy/issues/351) which means checks need to consider that. Obviously not relevant given your CLI check.

    PS - thanks so much for continuing to support your modules even though you're no longer using PW - very generous indeed.

  3. @Mike Rockett - sorry, I should have come with more details - looks like it's happening from a cron executed PHP script that bootstraps PW. That would explain why it's null.

    I'm not sure why it's a new error though - on a quick scan I can't see anything from your most recent commit that would cause this change.

  4. Hi @Mike Rockett - brand new issue with the latest version: 

    PHP Deprecated: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated in ProcessJumplinks.module.php:206

    EDIT: I see that line hasn't changed recently, but I've never seen the error before on the same server with no recent PHP upgrades. Regardless, it still needs a fix please and thanks.

  5. 14 hours ago, bernhard said:

    PS: Just did an update to the latest version and got this error:

    Error: Undefined constant Tracy\Debugger::Version in /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/bar.phtml:15 Stack trace: #0 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(119): require() #1 /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Helpers.php(364): Tracy\Bar->Tracy\{closure}() #2 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(120): Tracy\Helpers::capture(Object(Closure)) #3 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(89): Tracy\Bar->renderPartial('main') #4 /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Debugger/DevelopmentStrategy.php(123): Tracy\Bar->render(Object(Tracy\DeferredContent)) #5 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Debugger/Debugger.php(309): Tracy\DevelopmentStrategy->renderBar() #6 [internal function]: Tracy\Debugger::shutdownHandler() #7 {main} (stored in /var/www/html/site/assets/logs/tracy/exception--2023-11-05--11-52--6565da4fb6.html)

    Yeah, I know about this and not sure there is an easy way around it, but it fixes itself after a modules refresh.

  6. Thanks @flydev 

    The only issue I noticed is that the supplied mysqldump.unix.sh looks like this:

    # (1) Set up all the mysqldump variables
    # Fix trailing slash in cache path
    # (2) In case you run this more than once a day, remove the previous version of the file
    # unalias rm     2> /dev/null
    # rm ${FILE}     2> /dev/null
    # rm ${FILE}.zip  2> /dev/null
    # (3) Do the mysql database backup (dump)
    #  - to log errors of the dump process to a file, add --log-error=mysqldump_dup_error.log
    # (a) Use this command for a remote database. Add other options if need be.
    # mysqldump --opt --protocol=TCP --user=${USER} --password=${PASS} --host=${DBSERVER} --port=${PORT} ${DATABASE} ${DATABASE} > ${OUTPUT}
    # (b) Use this command for a database server on localhost. Add other options if need be.
    mysqldump --routines --triggers --single-transaction --user=${USER} --password=${PASS} --databases ${DATABASE} > ${OUTPUT}

    Note the missing PORT from the variables in #1 and also the duplication of ${DATABASE} in #3a

    Once I fixed those two things, it work great!

    Thanks again for making this configurable - a really nice improvement!

    • Like 1
  7. Hey @Robin S - good question. I have played around a little without any success. I feel like I am missing something obvious like output buffering getting involved, but perhaps it is just down to the way I instantiate a PW template and render it via AJAX https://github.com/adrianbj/TracyDebugger/blob/ec79b76bf0443118a6c402c9ffe2a9c491a8b5cc/includes/CodeProcessor.php#L197-L203 

    I'll keep mulling it over, but not sure what the solution might be at the moment.


    • Like 1
  8. Thanks - looks like it goes deeper than php-saml to one of it's dependencies (https://github.com/robrichards/xmlseclibs) - https://github.com/SAML-Toolkits/php-saml/issues/79

    php-saml branch without mcrypt: https://github.com/SAML-Toolkits/php-saml/tree/remove_mcrypt but this was created in 2017, so who knows when it will make it into the master branch.

    And it looks like mcrypt has been removed from https://github.com/robrichards/xmlseclibs - https://github.com/robrichards/xmlseclibs/pull/101

    I don't know - looks like some of these relied upon packages aren't really being maintained anymore, so hopefully php-saml will merge those changes to master sometime :)

  9. Yeah, PW page objects are pretty huge. I wonder if you might also benefit from removing the Full Object tab from the dump and just going with the Debug Info tab? Personally I wouldn't because there are times I do want to look through the full object, but perhaps you might find it a better option?

  10. Hi @flydev - for remote DBs, I find I need this for native backups to work.

        $data = '
            # (1) set up all the mysqldump variables
            FILE=' . $this->options['backup']['filename'] . '
            DBSERVER=' . wire('config')->dbHost . '
            DATABASE=' . wire('config')->dbName . '
            USER=' . wire('config')->dbUser . '
            PASS=' . wire('config')->dbPass . '
            PORT=' . wire('config')->dbPort . '
            # (2) in case you run this more than once a day, remove the previous version of the file
            unalias rm     2> /dev/null
            rm ${FILE}     2> /dev/null
            rm ${FILE}.zip  2> /dev/null
            # (3) do the mysql database backup (dump)
            mysqldump --opt --protocol=TCP --user=${USER} --password=${PASS} --host=${DBSERVER} --port=${PORT} ${DATABASE} > ' . $cachePath . '${FILE}

    The key things are setting the DBSERVER to $config->dbHost and adding the PORT

    Also, wondering if you've had any thoughts on making the line in section #3 configurable in the module settings, because currently any module updates break native backups.


    • Like 1
  11. 19 hours ago, Robin S said:

    This didn't work for me. $_SERVER['HTTP_HOST'] and location.hostname just give me "mywebsite.com" and without the "https://" it doesn't form a valid base for the URL.

    That makes total sense, but for some reason it worked fine for me - weird.

    Unfortunately $_SERVER['HTTP_ORIGIN'] doesn't work when the page 404s.

    I did some testing with $_SERVER['PHP_SELF'] and that actually seems to work nicely, including when bootstrapping PW in a directly called .php file in the URL. However, reading back through https://github.com/nette/tracy/issues/407 I see that there is a specific reason for loading from the current URL (the linked to XDebug issue: https://github.com/nette/tracy/issues/216), so I am not sure this is actually a good idea.

    Maybe it does come back to the last point I made in that issue and the loss of the GET params making it through. I am not sure anymore, and am out of steam on this at the moment. Let me know if you have any good ideas :)

    • Like 1
  12. Hey @Robin S - this has bugged me for quite some and I did ask about it some time ago: https://github.com/nette/tracy/issues/407

    It's basically due to htaccess's rules 16 & 17 in combination with the way the Tracy core loads itself at the base url rather than from the root url, eg, it loads:


    rather than:


    I have been playing around with fixing that. It seems like everything is working, but it's not well tested yet, so I am not sure if there will be any side effects. Would you mind also testing?


    //$baseUrl = $_SERVER['REQUEST_URI'] ?? '';
    $baseUrl = $_SERVER['HTTP_HOST'] ?? '';


        //baseUrl = location.href.split('#')[0];
        baseUrl = location.hostname;
    Can you think of any reason why this approach would be problematic? If not, I am tempted to reopen that issue and suggest these changes to @dg 
    • Like 1
  13. Just now, Tyssen said:

    Not necessarily. Page title might be terms and conditions, but you don't really want the page name being /terms-and-conditions/

    Agreed, that is why I said in almost all cases :)

    That is also why the module has lots of options for respecting existing differences and excluding certain pages / templates from its effects etc. It's definitely worth playing with :)

    • Like 1
  • Create New...