adrian

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.

Hi everyone, Got a new feature for you today (at the request of @eydun). First some background - some of you might not even be aware that Tracy saves .html files of it's bluescreen stacktrace when an exception is thrown. The cool part about this is that these happen when Tracy is in production mode on a live site, so if you get a notification (via email or slack) that an exception was thrown, you can navigate to /site/assets/logs/tracy and load these html files in your browser and inspect the code (including values passed to functions etc). This can make debugging much easier because you don't need to try to replicate the error again. The new feature today makes viewing these much easier with a dedicated panel listing all available exception files. Simply click on one to have it display as it would if the exception was thrown while you were interacting with the site. The icon turns red when there are new exception files since your last visit and it shows which ones are new. The clear button will remove the bluescreen so you can return to your site without needing to reload the page. The Validator panel also had a revamp. It now uses https://validator.w3.org/nu/ because https://html5.validator.nu/ was no longer working and I have updated the CSS to support their new output DOM. For those of you who don't know, the key value to the Validator panel is for local dev sites where you don't have a publicly accessible URL to use - this sends the HTML of the page directly. Also included are some PHP 8.2 deprecation fixes.

Hi @teppo - sorry for the delayed response. #1 - from what I can tell, the instances of "There is no difference between these revisions." are only an issue when saving via the API (in this case a frontend form). Not sure if it matters (seems unlikely), but it is an AJAX saved form and fields are saved with "setAndSave()" - maybe that is a factor? #2 - is this case, it's an admin save.

Hi @teppo - firstly, just another mention of how important this module is to me - it's always one of the very first installed on every site, so thank you :) Now to some issues / suggestions if I may. 1) We often find lots of revisions listed for a field that simply return "There is no difference between these revisions". I don't really understand why a revision is stored if there were no changes made. It seems like unnecessary DB bloat, but more importantly, it makes it very hard to find the revisions where changes actually are made. Do you think this behaviour could be changed so that no revision is stored? 2) We often see changes to page reference fields (checkboxes in this case, but I expect it probably doesn't matter the inputfield type) where changes are recorded, but in reality, they weren't actually changed - why would they be recorded as being removed and then added again? 3) When you have a page template where the width of fields is a small percentage (25%, 33%, etc), the interface for viewing the revision history is quite awkward, with lots of horizontal and vertical scrolling required. I was wondering whether you think it might be a better experience to load the revisions in a PW panel (pw-panel - https://processwire.com/blog/posts/pw-3.0.15/) Thanks so much for considering and let me know if there is any way I can help with any aspect of this.

@sodesign - thanks for posting about this. Just to let everyone else know, there is another thread about the same issue affecting the Profields VerifiedURL field and Ryan is engaged, so hopefully this will be sorted sooner than later. I have a workaround for now if anyone needs it urgently.

Thanks @MarkE - that's basically what I had to do. The difference however is that when hooking on saveReady for a just cloned page, the id is 0 even though it is a valid page and not a null page.

Just a follow up to note that my issue with that "WireDataDB sourceID must be greater than 0" error was due to a hook on Pages::saveReady that was setting $page->meta even when the ID of a recently cloned page was still 0. Not something anyone else is likely to come across, but just in case, now you know to be aware of it :)

Hi @bernhard - not really (and I am not sure it's actually related to page classes). I just came across that error for the first time and found Mark's comment about it here and thought I'd see if there was an already determined cause / solution.

@MarkE - did you ever solve the "WireDataDB sourceID must be greater than 0" error? I have been getting it on one install when cloning a page.