adrian

Actually, the only other suggestion is to make it a real initial value for the textarea rather than a placeholder, because I actually had to go and open mysqldump.unix.sh to get a starting script I could then edit.

Thanks @flydev The only issue I noticed is that the supplied mysqldump.unix.sh looks like this: #!/bin/sh # (1) Set up all the mysqldump variables FILE=%%FILE%% DBSERVER=%%SERVER%% DATABASE=%%DATABASE%% USER=%%USER%% PASS=%%PASS%% CACHEPATH=%%CACHEPATH%% # Fix trailing slash in cache path CACHEPATH="${CACHEPATH%/}/" OUTPUT="${CACHEPATH}${FILE}" # (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!

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.

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 :)

@BitPoet - thanks so much for your hard work on this and sharing it with everyone. Just curious though about the need for the PHP-mcrypt library. I thought it was considered important to instead use sodium these days. I'd love your thoughts on this because it seems like you are pretty in-tune with these types of things.

Thanks @ryan - this is fantastic update. My initial testing shows that OR selectors are now working for the WireCache $expire selector (https://github.com/processwire/processwire-issues/issues/1828) which really opens up the ability for some huge performance benefits. Thanks again!

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?

That is the reason that d() is the standard method for dumping rather than db (dumpBig). d() uses those defaults, but db() overrides them.

Tracy module settings > Code Editor Settings:

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. Thanks!

@da² - unless I am misunderstanding you, the PW Upgrades module doesn't do anything to upgrade the DB. There are almost never changes to the PW DB schema, but if they are required, then it is handled automatically the first time PW loads after the contents of the wire folder are updated with the new version.

Hi @Paul Greinke - as @teppo said, it still works as intended on the most recent PW versions and I use it in production so I should be aware of any issues that might arise in the future.

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 :)

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: http://mywebsite.com/doesn't-exist/?_tracy_bar=js&v=2.10.3&XDEBUG_SESSION_STOP=1 rather than: http://mywebsite.com/?_tracy_bar=js&v=2.10.3&XDEBUG_SESSION_STOP=1 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? /site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/loader.phtml //$baseUrl = $_SERVER['REQUEST_URI'] ?? ''; $baseUrl = $_SERVER['HTTP_HOST'] ?? ''; /site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/bar.js //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

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 :)

So long as PagePathHistory is enabled, this shouldn't matter, but probably better to change those to get the pages by ID rather than name / url anyway. I don't think I am alone in my belief that page titles should match page names in almost all cases and it's too hard to expect site editors to remember to change the name when they update the title, hence my module.

Maybe my PageRenameOptions module? Please keep in mind that PW's PagePathHistory takes care of redirects if the page name changes so you don't have to worry about breaking links.

I just tested on the latest version of Chrome and no problem here. Not dismissing this as an issue - just trying to help rule things out.

No issues here on M1 Macbook Pro. I don't really know how to suggest debugging, but is it all sites or just local dev ones? Stupid suggestion probably, but does a machine reboot help? Is this a new issue, or has it always happened on this machine?

Thanks @gornycreative - I never use that Iterator tab on the dumps panel, but error should be fixed in the latest version.

It looks like an issue with your monaco loader script. If you remove that from profileeditor.php then the error goes away and Tinycon is loaded and works as expected.

Sure - compromise - it's still below the Page Info, but it's right below it and open by default.

Thanks for the idea @bernhard - I've added it in the latest version - you'll find a new "Redirect Info" section in the Request Info panel. It is enabled by default on new installs, but will need to be manually enabled on existing ones.

The End Session button should still be a thing. Basically it will kill the user switcher session and leave you logged in as the currently selected user with no option to change. As for a back to xxxx user, I am with Robin - there should really be no need for that, especially if you limit the available users via one of these settings. This lets you remove frontend only users etc from the list making it much more manageable to find your own superuser account to switch back to.

Just added a couple of key fixes to the Exceptions panel - please update your copies and do a hard reload. Also, please note that this panel is now loaded by default (frontend and backend) on new Tracy installs and I would recommend making this change on all existing installs as well.