adrian

Apex looks nice - thanks! As for C3js - I knew there was a time when development was slow, but it looks like it's ramped up again (https://github.com/c3js/c3/commits/master). Do you know something else we should be aware of?

Note that end of life for ubuntu 14.04 is either passed, or in next month, depending on the variant you have. If you're installing a custom version of PHP, at least go for 7.1+ - I don't see any reason for not going with 7.3. So you know, 7.0 has already reached end of life: http://php.net/supported-versions.php If you decide to stay with Ubuntu 14.04, check out this guide for installing PHP 7.3: https://www.rosehosting.com/blog/how-to-install-php-7-3-on-ubuntu-16-04/ - it refers to ubuntu 16.04 but it should be the same. Also, check your phpinfo (via Tracy is easy) to make sure apache is using the new version, because sometimes the CLI can be using a different version.

Here's some code that automatically adds new pages to the page table field: The key part for your needs (I think) is: $pp->{$ptf->name}->add($child);

I haven't looked recently for new options, but last time I researched, this is what I ended up using: https://c3js.org/ It might not look sexy by default, but, it is built on D3js and outputs SVG and it's super simple to tweak to your needs with D3 and CSS.

Thanks to ideas and feedback from @tpr, the File Editor panel now has a recently opened files selector which shows the last 10 files you opened - much quicker if you need to navigate back and forwards between several different files. There is also a new config setting which lets you exclude folders. Previously for performance it was best to limit the Base Directory setting to "Templates", rather than "Site" or "Root", but now you can select an higher level and exclude what you don't need. Most users will probably want to select "Site" and exclude "site/assets" and "site/modules" - this lets you access site/templates, as well as config.php, init.php. ready.php, & finished.php - you get the idea. I also made some other speed improvements by excluding completely any directories with files that are not editable, so the payload for this panel is now much smaller. Hope this helps you out when an online editor is the only option you have. Don't forget the fullscreen toggle at the top left of the editor, or the normal "Maximize" toggle at the top right of the panel - makes life much nicer!

Yeah, that'll do it ? I am curious though - with the caching now in effect, doesn't it load quickly now? If not, then I expect there is an error that is being logged on every page load (meaning that the cache needs to be updated on each page load). What errors are being logged?

Sorry, updated the github issue link. The PW core fix that is needed is to remove that trycatch if Tracy is installed.

Hi everyone, I'd really appreciate some comments of support on this Github issue: https://github.com/processwire/processwire-issues/issues/829 It really messes with Tracy's bluescreen stack trace. Thanks! PS - Thanks to @bernhard and David Grudl over at Nette for figuring out what was going on.

Sorry, I didn't notice that it was mostly uppercase variants that were new - I just saw a lot more options ?

Just committed some improvements to the log panel caching and also added caching for the ToDo panel which is a HUGE improvement - this has gone from 1.5 seconds to 60ms in my tests.

@kongondo and everyone else ? I have just added caching for both the Tracy and PW logs panels so now they only read a log file if it has changed since it was last cached. This should make a dramatic difference to most page loads. Do note that if you have a large log file and a new entry is added, then the load time will still be slow for that first page load when the entry is logged, so you still may want to delete log files (or use the PW log prune function) if you notice a slow load. Hope that helps everyone.

Hey @Robin S - this looks great! I just noticed that the contents of your $default_replacements array is much more comprehensive than the list of character replacements in the InputfieldPageName settings in the core. Not sure whether Ryan would be willing to change those, but it seems to me that your list should be used there. Then perhaps you could pull that list in for your module and users of your module would benefit from any manual additions they have made to those settings, rather than using the character_replacements_str config setting in this module - it seems to me that users may need to add their custom replacements to both places at the moment.

Hey @bernhard - just an FYI regarding your PR which I think it a great idea by the way, but I don't think Ryan wants "all" to actually be all sanitizers: https://github.com/processwire/processwire-issues/issues/85

Hey @bernhard - glad you figured it out. The one thing I would like to know more about is that errant padding at the bottom of the tab labels/links. Could you please figure out what css rule on your site is adding that padding so I can adjust Tracy's CSS so there is no conflict? Thanks.

Just did some debugging and figured out it's a bug in VSCode in a recent update. Stay on v1.31.1 and you'll be fine. Github Issue: https://github.com/Microsoft/vscode/issues/70177 And if you've already updated and things are broken, you can get 1.31 here: https://code.visualstudio.com/updates/v1_31

Can you please clarify that it was deleting all Tracy logs, and not just disabling the Tracy logs panel that fixed the loading speed? In other words, is the loading speed ok with the Tracy logs panel open now that the logs have been deleted?

They are also useful if you are debugging the PW core and bd() calls won't work. This way you can make a $log->save() call and it will appear in the PW logs panel in the Tracy bar - easier than hunting it down in the PW admin.

Thanks for narrowing it down. I can't understand why the Tracy logs would be so slow, but I'll take a look and see if I can figure something out. As for "not needing" them - I would suggest reconsidering - sometimes they will capture errors that Tracy will miss for reasons related to the timing of when Tracy is loaded (I think), so seeing a red icon for one/both of these can highlight the reason for an error you might otherwise be confused about.

But which one is the culprit? I'd really like to figure out which one is causing the problem in case I can fix it ?

Hey @kongondo - I would start by disabling all custom panels via the panel selector. Typically it's the RequestInfo panel that can be the slowdown, so if you identify it as such, then check out its individual section settings and disable everything and re-enable to see which one is the problem. If it's the log panels, then I would suggest clicking "Delete All Logs" for both the Tracy and PW logs. I have seen these slowdown things before when there are lots of large log files. Let us know what you find. BTW, are you using PHP 7.1+ , or older?

Hey @tpr - let me think about this and I'll follow up on your PM with your other idea. @bernhard - probably best to request that as a core feature. On the issue of linking to your code editor, I've just noticed that VSCode links are no longer working for me - not sure if it's a VSCode update that broke something or what. Are they still working for you?

Actually, looking at this, it works as expected for me:

Yep!

The issue is that hooking the path affects the relative url, not the full http url. You can do a redirect to that $page->products_categories_external rather than an $event->return. You could do this from your path hook or maybe it might even be better to do it from Page::render

Changing the path will result in a changed url so I guess I am missing the point somehow. Here is the classic thread on this topic: https://processwire.com/talk/topic/1799-routes-and-rewriting-urls/