adrian

Thanks for figuring that out. At least the logs rabbit hole made me notice an issue with its caching which is great :) Now for the reason for the Info panel - can you please go through Tracy's settings for the panel and figure out which of its sections are causing the slowdown - I can only think it's the Versions List and something on the server taking a long time to return something within that. I can replicate the misalignment issue when the ms is really long like that, so I'll take a look at fixing that.

Thanks for all those details - helps to narrow things down a bit - it's certainly not an issue with the size or number of log files. I still don't know why you're having the slow loading or why the ms/kb is showing when the panel isn't loaded - I'd be curious if there is a difference if the panel is disabled permamently from Tracy's settings. One thing I did just find and fix was the caching - it wasn't actually working as intended. I still don't think it will help with your slow loading, but worth checking to see if it also has any impact on the ms/kb populating when the panel is disabled - it shouldn't but who knows 😖

Hi @iank - that first screenshot is confusing me because if the PW Logs panel is disabled, it shouldn't load at all and you shouldn't see any ms/kb values. I am not really sure what you mean by "only seems to work for a minute or so, and then the long loading time reappears" - if you're using the "sticky" option to disable it, then it should remain disabled until cookies are cleared, but even if that happens, the checkbox next to it would be checked. I can't see a way for the ms/km to be there with the checkbox unchecked (after sticky has been clicked). As for the actual slowdown - you mention that the log files on dev are the same - are they the same size as well? How large are the log files - can you check through and let me know the largest one. Are you loading just the default last 100 lines? It's also worth noting that Tracy caches the lines from the log files so it should only ever read them if their modified timestamp has changed since the last load. Let me know those things and we'll go from there.

Just a note that I set Tracy to 100000 so you'll want to make sure your highest one is still lower than that if you want to be able to use Tracy within other modules.

Having Tracy run on production servers in production mode can be a very useful tool - logging exceptions with Tracy's full stack trace saved and notification of errors via email and slack.

Thanks @Tiberium I can reproduce if I try to load Tracy's settings page when it's not enabled and the logs file doesn't exist, but this is not something that will ever happen with a regular usage which I suppose is why no-one has ever reported it. Anyway, new version should sort things out for you.

Hi @Tiberium - Tracy definitely tries to create the directory: https://github.com/adrianbj/TracyDebugger/blob/98d9d3b8c3eb141f25d75ec1a4ec62d12ad42527/TracyDebugger.module.php#L995 everytime it is loaded, so there must be some permission issue.

Yeah, actually that is a better approach - I was actually just falling asleep and realized that there is the possibility of an RTE with something like empty <p> </p> tags so you definitely want to strip those before checking !$text

Sorry, now I am seeing: Deprecated: strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated I guess it needs to be after: if(!$text) return;

@Robin S - I just did a little bit of testing between various online Flesch Kincaid Reading Ease calculators and the same text resulted in very different "reading ease" scores. Your module - 52.5 https://serpninja.io/tools/flesch-kincaid-calculator/ - 37.85 https://hemingwayapp.com/articles/readability/flesch-kincaid-readability-test - 50 https://goodcalculators.com/flesch-kincaid-calculator/ - 46.8 https://charactercalculator.com/flesch-reading-ease/ - 43.16 https://codebeautify.org/flesch-kincaid-grade-level-calculator - 31.9 https://app.readable.com/text/?demo - 50.4 ChatGTP - 47.2 ChatGPT also tells me that the reason for the differences I am seeing is due to the counting of syllables and sentence boundaries, etc so I guess the key thing is getting used to what your module returns and compare relatively with other field content on the site. One thing I didn't understand though is why the readable.com demo wasn't returning the same score as your module given that https://github.com/DaveChild/Text-Statistics?tab=readme-ov-file#useful-links links directly to it as a demo of it in action. But looking into it, I realized that when I was pasting the text into these calculators, it was just text and not the HTML that is part of RTE field content. So, I added $text = strip_tags($text) and now I get the same 50.4 that the demo on readable.com does. Do you think it makes sense to add that?

Thanks @Robin S - good point on the color coding. Thank you for the formatted content fix and a great implementation of the tooltip info. Much appreciated as always.

And/or maybe a hover tooltip that shows some more info about each particular score, eg if the Automated Readability Score is 5, then the tooltip would display: Age: 1-18 Grade Level: 5th If you want some help setting this up, I'd be happy to create some JSON that contained all this info for all the scores that your module could parse. Actually, ChatPT to the rescue. This prompt "Automated Readability Index JSON of scores to ages and grades" returns: { "0": { "grade": "Kindergarten", "ages": "5-6" }, "1": { "grade": "1st Grade", "ages": "6-7" }, "2": { "grade": "2nd Grade", "ages": "7-8" }, "3": { "grade": "3rd Grade", "ages": "8-9" }, "4": { "grade": "4th Grade", "ages": "9-10" }, "5": { "grade": "5th Grade", "ages": "10-11" }, "6": { "grade": "6th Grade", "ages": "11-12" }, "7": { "grade": "7th Grade", "ages": "12-13" }, "8": { "grade": "8th Grade", "ages": "13-14" }, "9": { "grade": "9th Grade (Freshman)", "ages": "14-15" }, "10": { "grade": "10th Grade (Sophomore)", "ages": "15-16" }, "11": { "grade": "11th Grade (Junior)", "ages": "16-17" }, "12": { "grade": "12th Grade (Senior)", "ages": "17-18" }, "13": { "grade": "College Freshman", "ages": "18-19" }, "14": { "grade": "College Sophomore", "ages": "19-20" }, "15": { "grade": "College Junior", "ages": "20-21" }, "16": { "grade": "College Senior", "ages": "21-22" }, "17": { "grade": "Graduate Level", "ages": "22+" }, "18": { "grade": "Graduate Level", "ages": "22+" }, "19": { "grade": "Professional Level", "ages": "22+" }, "20": { "grade": "Professional Level", "ages": "22+" } } So it should be easy to do the same for all the other indices.

Hey @Robin S - this is really useful, thank you as always. A couple of thoughts. Would you mind passing the text through Hanna first. I have a lot of tags in some content and readability is very poor unless I add this to your module. $hanna = $this->wire('modules')->get('TextFormatterHannaCode'); $text = $hanna->render($text); What do you think about adding some easy way to identify if each of the scores is good or not - at the moment you have to look up the docs, but perhaps color coding the values (red, orange, green) or some other way would help to alert us to issues. Thanks again!

Actually, on this note, why do RM fields use buttons, but repeater fields don't?

I've honestly never looked at that option - it seems like a lot of work though on a site with a lot of fields. As I mentioned in my post about this, I thought the "Input types that should be offset with additional top/bottom margin." via Modules > Core > AdminThemeUikit would be the place to set this, but it doesn't seem to do anything. Even if it did, it's still a decent amount of work to set all types. Can you confirm if that setting is also supposed to do the same thing and if so, can we have an option for all? Or maybe I should just use some CSS for this.

@ryan - did you see my comments about top and bottom margins between fields when on PageEdit? Is that setting supposed to make it look like the ProcessModule interface?

@ryan - what do you think about adding the scrollbar (like the menu dropdowns now have) to the Page List > Add New button - I have enough of these that they extend well beyond the viewport.

It's dropdowns on submit buttons, the Add New button (page tree) and the top menu. What actually happens here (and maybe it is expected, but seems weird to me) is that if I want to override: --main-background for the page background at the root level, this automatically sets the --menu-item-backgroud-hover to the same color because of the reference to it. This means I need to re-set --menu-item-backgroud-hover again which works, but I think these references might might be part of the confusion we'll all be having and it's not initially obvious that changing one will impact the other so you might break things without realizing it. So maybe all that is needed is not referencing one var with the value of another? Sometimes it works, but often it doesn't. If I do that though, I can avoid that lower level override of --main-background and just go with the following - in this case I am playing with the menu hovers matching the main color, but you can also easily just reset it to the: #eee which I still might go back to. :root { --text-color: #444; --muted-color: #999; --button-radius: 10px; --main-background: #FFF; --menu-item-backgroud-hover: var(--main-color); } .PageList .PageListActions a, .PageList .PageListActions a:hover, .PageList .PageListerActions a, .PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { color: #fff; border-radius: 3px; background: var(--text-color); padding: 2px 6px; font-size: 12px; font-weight: bold; line-height: 1.4; text-transform: none; display: inline-block; } .PageList .PageListActions a:hover { background: var(--main-color); } h1, .uk-h1 { font-size: 1.6rem; } Sorry, it's only impact repeater matrix fields from what I can see.

PS - please don't forget about repeater buttons:

Thanks @ryan One thing I have been playing around with is setting the background to white everywhere (not just the page tree) - not sure if I want it or not yet, but tried: .ProcessPageList, .ProcessPageEdit, .ProcessModule, .ProcessUser, .ProcessPageLister, .ProcessPageListerPro { --main-background: #FFF; } but the problem does come back to process modules - you would need to specify each process module separately. So I tried: .AdminThemeUikit { --main-background: #FFF; } which does work, but maybe there are unintended side-effects I haven't noticed yet. I guess my point is that because --main-background is used for the body background as well as menu and dropdown button item hover background, we have to do this weird hack. I really do feel that these need separating.

Actually, in case anyone is interested, this is my current complete setup. I've given up on the colored top nav because it really doesn't add anything and in reality does look kinda ugly :) :root { --text-color: #444; --muted-color: #999; --button-radius: 10px; } .ProcessPageList { --main-background: #FFF; } .PageList .PageListActions a, .PageList .PageListActions a:hover, .PageList .PageListerActions a, .PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { color: #fff; border-radius: 3px; background: var(--text-color); padding: 2px 6px; font-size: 12px; font-weight: bold; line-height: 1.4; text-transform: none; display: inline-block; } .PageList .PageListActions a:hover { background: var(--main-color); } h1, .uk-h1 { font-size: 1.6rem; } This results in: @ryan - this still needs fixing though: But, otherwise pretty happy. Toggles and dark mode are disabled in config.php and we still have branding accents, no horrid grey background for the page tree (sorry KONKAT) and my eyes aren't bleeding from the #000 text 😁 Not sure if everything is perfect yet, and I'd rather not have to override CSS vars at non-root level, but it's time to move on and enjoy the fixed nav, scrolling fields and templates dropdowns although we still do need the dropdowns to have a higher z-index than the top-level menu so that Tracy panels can slot into place like they used to. @ryan - is that something you could look into please?

Thanks for all your thoughts there @ryan - really appreciate your input. The one thing I would say about the new grey background is that I think it looks OK when editing a page - I think the contrast between the background and the input fields is quite nice. What I really struggle with is the page tree and the action buttons white background on hover - that is probably my biggest issue with the new theme. Everything else works (except for some bugs that need ironing out), but that page tree view is just really ugly IMO and I know I am not the only one with concerns about it. One solution to this is: .ProcessPageList { --main-background: #FFF; } and of course to need to deal with the action hover, but in this case I like the buttons back so I have also added: .PageList .PageListActions a, .PageList .PageListActions a:hover, .PageList .PageListerActions a, .PageList .PageListerActions a:hover, .PageList .PageListMoveNote a { color: #fff; border-radius: 3px; background: var(--text-color); padding: 2px 6px; font-size: 12px; font-weight: bold; line-height: 1.4; text-transform: none; display: inline-block; } .PageList .PageListActions a:hover { background: var(--main-color); } One other thought for now - I really like the margins between fields when editing module settings, eg: but when editing a page, there are no margins: I thought the setting below would change that, but it doesn't seem to have any impact that I can easily see - it least it certainly doesn't match the module editing layout: Is it another option somewhere else?

Really appreciate your input and problem solving here @ryan. I feel like there has been lots of discussion about whether we should need to override CSS at non-root levels and I tend to agree that we shouldn't have to, hence my suggestion for --submenu-xxx vars. Regarding the choice of green - it's the color of a company brand and it works fine for the menu background, but not great for links when there is a background behind (like that blue). I think perhaps the core issue here is how --main-color is used. It seems weird to me where it is and isn't used. Do you think it would make sense to have a separate css var for link color and link hover color? I think "main" is too generic and will always come down t personal preferences regarding where it should be used. And regarding --main-background I do feel pretty strongly about this being white, so that --menu-item-backgroud-hover is always going to be problematic for non-menu dropdowns (like from Add New and Save buttons) unless I go and do more overrides at non root levels. The problem with non-root level overrides is that it takes a lot more fiddling to get things right and they are subject to future changes to the PW admin classes, but if we had more variables for more things at the root level, we know they will always work - this is their beauty. The network response is: {"status":"ok","adminDarkMode":0} so it appears to be ok and no JS errors.

Another issue with --main-color looking weird because of those blue backgrounds that I think bernhard noted:

It also impacts save buttons - no hover color (because it's white). And, also note the weirdness with the main color on the button dropdown arrow only.