adrian

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.

Let me know if you need those changed. https://github.com/search?q=repo%3Aadrianbj%2FTracyDebugger expireNever&type=code

Thanks for chiming in @Robin S - I was out when I replied above. Good point about reporting vs causing. Also, in case it helps, I do on rare occasions see lock errors in PW even without SessionHandlerDB. PS - That issue you pointed to is unfortunately not fully solved - I am still hoping Ryan might provide a better solution for that string issue.

Interesting - I wonder if you have the file compiler turned off in your config file - perhaps the "moduleCompile" setting?

@Roych - are you using the original (https://github.com/marcostoll/processwire-fieldtype-assisted-url), or my fork: https://github.com/adrianbj/processwire-fieldtype-assisted-url ?

@gebeer - are you running PHP8? If so, it might make a difference if you update to the latest Tracy - back in March there was an update to the Tracy core (which is PHP 8 only, although I maintain older versions within the package for those on older PHP versions so upgrading won't hurt). The other thing to make sure is that the "Use Native PHP Session" setting is unchecked. If those don't help, I am not sure what to do at this point - I can't count the amount of time I have spent workaround issues with SessionHandlerDB and Tracy.

Ah, thank you - I did a quick scan for function_exists checks around all occurrences of posix_getpwuid but missed that one because of the check for posix_geteuid - my eyes didn't see the difference. Fixed in the latest version. PS - yes, feel free to add new threads for bug reports - would definitely be preferable.

Hey @bernhard - the calls to that are already wrapped in a function_exists() so I am surprised that isn't enough - this is the first report I've had of an undefined function error. https://github.com/adrianbj/TracyDebugger/blob/0d88866516be43156c945b45c6cd77c664d79204/panels/DiagnosticsPanel.php#L1201 Can you figure out why that check is failing for you?

Thanks @bernhard - fixed in the latest version.

Hi @Jonathan Lahijani - thanks for the write-up. You mention "myself only", so perhaps that's the reason for your approach - so other superusers don't have Tracy running in DEV mode? Is that the key functionality of this approach that you needed? Otherwise, I think you might be confused about Tracy's DEVELOPMENT vs PRODUCTION modes. DEV mode is what enables the debug bar, while production mode runs Tracy in the background, logging and notifying errors (via email and / or Slack). It's not about whether your install is DEV or PROD. I just set to PROD mode and use the "Force superusers into DEVELOPMENT mode" option so that DEV mode is enabled for me (and other superusers) regardless of whether we are on the dev or prod servers.

Looks like we've been down this path before:

Hi @olafgleba - are you happy enough with that solution for now? Can you see a way to edit the module so it's not needed?

Hi @jploch - sorry for the late response - I was on vacation. Can you please point me to the line on the Github repo. I feel like it might actually be: https://github.com/adrianbj/TracyDebugger/blob/6f62b8e2c03e1520615ea654e79f4e44b61f9f20/TracyDebugger.module.php#L2847 but that isn't the line number from your error. Also can you please do a dump of parse_url($_SERVER['REQUEST_URI']); so I can see what is returned?

Thanks @bernhard - should be fixed in the latest version.

I think you likely upgraded from a very old version of Tracy at the same time you upgraded to PHP 8. When you saved Tracy's config settings, that adjusted the value of $this->data['styleAdminType'] thereby fixing the error.

@gornycreative - I haven't used it in quite some time, but I think it should still work.

@MarkE - I really do think migration to use imap_open as per my above post would be a better option given the status of the flourish library.

@matjazp - I am getting a little off-topic here, but I found some weird issues with UIKIT 3.16 - I should probably report them, but I was getting several FOUCs on the frontend of my site when I upgraded to it - things like menu dropdowns and modal popup that was meant to be initially hidden, so I stuck with 3.15. Did you experience any issues?

@ryan - another issue which looks like it's just core related - I can no longer view field settings (eg Setup > Fields > body) because of this error: inputfields.js?v=33g:1049 Uncaught TypeError: Cannot read properties of undefined (reading 'toString') at parseValue (inputfields.js?v=33g:1049:13) at inputfieldChange (inputfields.js?v=33g:1370:15) at setupDependencyField (inputfields.js?v=33g:1606:3) at HTMLLIElement.<anonymous> (inputfields.js?v=33g:1614:4) at Function.each (JqueryCore.js?v=1.12.4:1:4048) at a.fn.init.each (JqueryCore.js?v=1.12.4:1:1235) at HTMLFormElement.<anonymous> (inputfields.js?v=33g:1613:70) at Function.each (JqueryCore.js?v=1.12.4:1:4048) at a.fn.init.each (JqueryCore.js?v=1.12.4:1:1235) at InputfieldDependencies (inputfields.js?v=33g:1612:10) Please let me know if you can't reproduce and I'll try to provide more info, but so far it's happening on all sites I've upgraded.

Thanks for the hard work on this @ryan I mentioned this in the AoS support thread as well, but I figure it's worth a mention here too in case folks can't initially figure out why their admin menu dropdowns are broken after upgrade. If you make use of AOS's excellent "Add button to check/uncheck all checkboxes" feature, it will break the top level menu dropdowns in the PW admin (and maybe other JS). The fix is to replace: ("[data-no-checkall-checkboxes="1"]") with: ([data-no-checkall-checkboxes="1"]) in: /site/modules/AdminOnSteroids/scripts/aos.min.js

Just an FYI for everyone who may upgrade to the latest PW dev version today. If you make use of AOS's excellent "Add button to check/uncheck all checkboxes" feature, it will break the top level menu dropdowns in the PW admin (and maybe other JS). The fix is to replace: ("[data-no-checkall-checkboxes="1"]") with: ([data-no-checkall-checkboxes="1"]) in: /site/modules/AdminOnSteroids/scripts/aos.min.js

@Ivan Gretsky - if you can reproduce this reliably, I wonder if you could determine if $locked is 0 vs null: https://github.com/processwire/processwire/blob/6ff498f503db118d5b6c190b35bd937b38b80a77/wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module#L90-L91 If it's null and it's a memory issue, then perhaps increasing your PHP memory limit might fix it?