adrian

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more. I love css vars (I never jumped on the less/sass bandwagon), but they only work if they are distinct enough to modify everything as needed because if we need to mix and match between css vars and class/id targeted overrides it becomes an awful mess very quickly and things will surely get broken with future PW changes. I really am trying to figure out a way I can turn on the new theme for users because I know that it's only a matter of time before the old one is no longer supported (that's not a slight, it's just reality when there is limited time and resources to maintain things). I really wanted the background of the main nav to be darker color with white text, so went with: :root { --main-background: #FFF; --text-color: light-dark(#444, #efefef); --muted-color: light-dark(#999, #efefef); --masthead-text-color: #FFF; } #pw-masthead { background-color: #c3d152; } but you end up with the placeholder for the search box white as well. I am sure I can override that as well but my point is that it gets messy fast without more specific vars to work with.

Also, as I mentioned in the other thread, along with changing the text color away from pure black, I still think another very important tweak is the color of the dropdown menu items - I still think they need to be the same color as the top level menu items when not selected. At the moment it looks like all submenu items are selected because they are the same color as the selected top level item. All items (top or dropdown) should be the lighter color unless it's the current page.

@ryan - thanks for the option to disable toggles, but would you consider reversing it because as @bernhard and I pointed out, there are too many situations in 3rd party modules where toggles are just broken so I think the default should be checkboxes still. Also, keep in mind that the inputfield type is called "checkbox(es)", not "toggles".

Hi everyone, Tracy is now using the brand new AdminNeo project. It's been quite a rollercoaster in the Adminer world with the apparent death of Adminer, to AdminerEvo, and then AdminerNeo, then the revival of Adminer, and now AdminNeo. I have been following both Adminer and AdminNeo and deciding which one to use and while I do worry that AdminNeo might not survive given the long history of the original Adminer (now it's alive again), the theme we were using was written by the AdminNeo developer and I just can't live with any of the Adminer themes by comparison. AdminNeo also introduces a robust external login system (instead of the hack needed by Adminer), so that's where we are now. Along the way I also added styling to page IDs so you can now tell if a page is hidden, unpublished, both, or trashed: I have also added a modal viewer for images, audio, and video, along with download functionality, along with thumbnails for images. And we also finally have a nice interface for the full Adminer Process module (Setup > Adminer) when not in Standalone mode - @Robin S - I think you might actually want to use this now 😜 Please let me know if you notice any issues or have any suggestions.

Just another note on toggles - this impacts even checkboxes that are added to process modules, but in some cases the css for it is broken so it's unusable. Also, in this case the checkbox is in a table and it takes up much more space. On another topic, I find it weird that the font color for the main menu is so black (mentioned above by someone), but also that for the dropdown items, the unselected items are black whereas for the top level items, the unselected are grey and the selected is black. I also think that dropdown menus should reflect the current page by being in the darker color, but again, definitely not #000

As noted above regarding z-indexes, they also seem weird for top nav menu dropdowns. It looks like they are set to 200, but they still appear behind Tracy panels when they are set to 100. I haven't narrowed down the exact required index, but setting Tracy to 50 lets the menus dropdown over Tracy panels. In the original theme, the menus are also set to 200, so it must have something to do with the new fixed header nav messing with things.

Sorry, one more thing (for now). I think there should be separate CSS vars for the dropdown menus (vs the --masthead-background). And to re-iterate my point above about --blocks-background and --button-color. Having any css var assigned to another css var seems like a real limitation and there are many other cases where this happens.

Any chance we could have css variables for page list action buttons for color, background, border-radius and padding? I really want to go back to the look of them being buttons. Or, we need to separate the usage of --blocks-background, because at the moment it is also used for the hover color when the page list actions are displayed. I don't like the grey page background so I have changed --main-background to white, so I need to change the color of the page list actions hover but if I change that to something useful it makes all fieldsets look awful because --blocks-background is also used for those. Actually, it seems that --blocks-background is also used for some button text colors --button-color: light-dark(var(--blocks-background), var(--text-color)); - this is problematic because you can't override --blocks-background without overriding --button-color I honestly think there needs to be quite a bit of tweaking of the css variables to make things usable.

Thanks everyone for the work on this! A couple of issues I noticed right away: Tab indicator not positioned correctly. Add new button padding (Repeater Matrix) I also really need checkboxes back - toggles don't work en masse and I also heavily rely on https://github.com/baumrock/RockAdminTweaks/tree/main/tweaks/Inputfields/CheckAllCheckboxes for being able to quickly check all checkboxes. This came from AOS originally, but I ported over to RockAdminTweaks.

I haven't comprehended this is detail but in case it has any impact on the issue or @ryan's recent fix, please note this code in Tracy: https://github.com/adrianbj/TracyDebugger/blob/ae38175fe29fc7076dfa269145de98667cce76c7/TracyDebugger.module.php#L963-L966

The error message in the session cookie will be displayed in the console results pane on page reload - it's not logged because it will only ever be populated from code that is run in the console panel.

Hi All, If there are any Canadians out there looking for full time work please DM me with some details of your PW experience. Experience with systems engineering and security implementation a big advantage. Cheers, Adrian

@BrendonKoz - the tracyCodeError cookie is only ever set by the Console Panel so I think that might not be related at all to the download issue. In fact I am not Tracy will be able to help you with that because the html download attribute isn't PHP. Or am I missing something? As for the tracy-2.x folders - each is a different version depending on the version of the PHP you are running: https://github.com/adrianbj/TracyDebugger/blob/d48ebdc0d962c34042651f82b388df93e872ab81/TracyDebugger.module.php#L355-L366 You can delete the unused ones if you want, but they'll just come back next time you update Tracy. May I ask why you want to delete them?

I am running it on 3.0.247 without issues but let me know if you notice anything.

Honestly probably not that obvious so no worries at all.

Hi @psy - maybe I am not understanding exactly the issue. I have Tracy enabled on the frontend for superusers in development mode (with debug bar etc) and in production mode (allowing logging and reporting of errors via email/slack) for guest users. I don't think there should be any Tracy JS on the FE for guest users in production mode. Are you trying enable development mode for guest users? If so, then what you probably want it to just enable "Guest Dumps" - the button on the Selector panel. The other tool that might come in handy is the RequestLogger, but then again, I am not certain what you're actually doing - can you provide some code and context?

Really weird for sure but maybe the answer can be found in that function that is calling token_get_all() still - I think it should be pretty easy for you to figure out whether there is an issue reading the Functions.php file or getting the tokens from it by putting some bd() calls in the appropriate places to see where it's getting to.

@rick - please read this: https://processwire.com/talk/topic/29920-strange-console-panel-error/ and make sure your PHP install has token_get_all available.

I feel like I must be missing something very obvious, but I don't understand how you can get an undefined array key when doing an isset() on it. This is essentially what we are doing: Can you please take a look into those functions I mentioned above and figure out where they are failing to populate the ['pwFunctions'] key. I just have no idea how to reproduce and haven't had any other reports related to the API data functions in years. One final idea - I see that the line number of the error did change, so the files in /assets/cache/FileCompiler seem to be being updated, but I would maybe try deleting them all, just in case.

I am really baffled at the moment, but let's try to at least deal with fixing the error even if I can't figure out the actual cause. Can you please make this change in PwApiData.php and let me know if it helps. elseif($type == 'proceduralFunctions') { $proceduralFunctionsFunctions = $this->getProceduralFunctions('Functions'); $apiData = array('Functions' => isset($proceduralFunctionsFunctions['pwFunctions']) ? $proceduralFunctionsFunctions['pwFunctions'] : array()); if(file_exists($this->wire('config')->paths->core . 'FunctionsAPI.php')) $apiData += array('FunctionsAPI' => $this->getProceduralFunctions('FunctionsAPI')['pwFunctions']); } It should prevent the error, although we might end up with another one for $this->getProceduralFunctions('FunctionsAPI')['pwFunctions']) but that can be fixed the same way. I'd rather know why these aren't being populated though so if you feel like looking into the getProceduralFunctions() and getFunctionsInFile() to see where/why it's failing, that would be helpful. I can't figure out why this isn't being reported by anyone else. I thought perhaps it might be a file permission issue with reading the core Functions.php and FunctionsAPI.php files but when I made these unreadable, I got a very different error.

Can you please post the entire contents of what you see when you open those broken panels

I am sorry, I really have no idea at the moment. Could you try enabling the API Explorer panel for at least one load and see if that fixes things?

PW and PHP versions?

This is where you would tell me if deleting those got rid of that Undefined array key "pwFunctions" error 😁

Hi @rick - what version did you upgrade from? I am just wondering if perhaps it's a really old version and there is some cache from the PwApiData process that needs to be cleared. Could you do this search and delete all entries