PW 3.0.196 – Core updates

[ryan]

ProcessWire 3.0.196 contains 10 minor issue fixes, but the biggest additions this week are 6 pull requests submitted from @bernhard. This most notable PR is an upgrade to AdminThemeUikit that enables greater customization of the theme's markup. 

If you recall, Bernhard also provided a PR last year that enables customization of the admin theme's CSS/LESS, so now he's now completed the circle and provided us with a direction for customizing the markup as well. This newest addition lets you provide your own custom render files for different parts of the admin theme by placing them in /site/templates/AdminThemeUikit/. Third party modules can also define custom render files. Furthermore, this addition adds a new hook that enables you (or your modules) to hook into and modify just about any part of the admin theme rendering. 

Rather than going into all the details and repeating all of the instructions here, see the new AdminThemeUikit README file "Customizing Markup" section which describes all of the different things you can modify and how to do so. You can also find all of the render files in the core AdminThemeUikit directory — any .php files beginning with an underscore are custom render files that can be overridden. 

While not as broad in scope, there were other useful PRs added this week as well, so be sure to see the dev branch commit log if you are interested in seeing what else was added. Thanks for reading and have a great weekend. 

[adrian]

This looks awesome - thanks @bernhard and @ryan

[Ivan Gretsky]

Whoa! That is something I was wishing to have for years! Thank you!

Recently I posted about donations and @bernhard's paypal link was on the list. But to my regret I have not donated to him myself. I wish I could fix my mistake, but things happened since then that do not allow me to pay online abroad anymore ? Please be so kind to help me out here and start donating to Bernhard. I know he will appreciate it. And I will join you as soon as I find a way to.

[bernhard]

Thx Ryan for pulling my changes and improving them ?  I wonder if you have any numbers of how much more efficient it is to use a non-hookable method compared to using a hookable method? I'm usually not thinking too much about this as everything seems to be fast anyhow. But as you have refactored that approach it might be a noticable difference? I'd be very happy about some insights ? 

[cpx3]

After installing the update unfortunately the site does not load anymore. Neither the frontend nor the backend seems to be accessible anymore, everything freezes while loading...

[netcarver]

@cpx3 Were you able to revert to the previous installed version to restore your site's operation?  Also, if you look in site/assets/logs for the latest entries in the error.txt and exceptions.txt files, you may get a better picture of what's going on - and if you are running PHP with error logging turned on you can look in the PHP logs too. The exact location of these files (and if they are even used) will depend on your php.ini file.

[ryan]

Quote

Thx Ryan for pulling my changes and improving them ?  I wonder if you have any numbers of how much more efficient it is to use a non-hookable method compared to using a hookable method? I'm usually not thinking too much about this as everything seems to be fast anyhow. But as you have refactored that approach it might be a noticable difference? I'd be very happy about some insights

@bernhard I don't have numbers, but it would be interesting to benchmark sometime. I do know that I've tried to optimize the hook calls as much as possible, so I expect they should be fast. I would guess that you'd have to get the combined effect of many calls before you start seeing the difference. But it does still take significant code to make hooks happen, as the method call has to pass through a PHP __call() which then checks of there are any hook methods available to call, then it triggers any found before hook methods, calls the the original hooked method, gets the return value, then triggers any found after hooks, gets the return value again, then returns control to the original __call(), which then provides the return value to the caller. It's the minimum needed, but it's still a lot of steps. 

In the case of the admin theme, all the parts of it get added via include() calls to the different layout files, and that's very fast. I wanted to keep that benefit for cases where people didn't need to override anything or, didn't have hooks. That way it's still just a simple fast include(), except when you wanted to hook into it or use customize different files. It may not be something you can feel in any one request, but it would be something you could measure the combined effect of over several requests. I figure it's my responsibility to make sure PW uses as little CPU (translating to as little energy) as possible for anything it does, at least the things where I know how to. Something like the admin theme gets used by everyone that uses PW, and so little things can add up to big things when spread out over the scale of all installations. But how much difference it makes, I don't know for certain. So part if it is also about having fun and trying to be useful. 

Quote

After installing the update unfortunately the site does not load anymore. Neither the frontend nor the backend seems to be accessible anymore, everything freezes while loading...

@cpx3 What version did you upgrade from? Enable debug mode ($config->debug=true; in /site/config.php) and also check the log files that netcarver mentioned above. That should hopefully point to whatever the issue might be in this case. Please let us know. 

[cpx3]

Thanks for the support! I tried everything, including a complete new installation, but the update seemed to be a coincidence. Actually the error message I found in the logs was the following: "Error: Exception: Unable to obtain lock for session (retry in 30s)"... When not using any sessions it seems to work.

[zoeck]

4 minutes ago, cpx3 said:

Thanks for the support! I tried everything, including a complete new installation, but the update seemed to be a coincidence. Actually the error message I found in the logs was the following: "Error: Exception: Unable to obtain lock for session (retry in 30s)"... When not using any sessions it seems to work.

Do you have an older version of Tracy Debugger installed?
If yes, try to switch off Tracy or update Tracy to the latest version (4.23.25).

[cpx3]

Yes, I did! Thanks for the hint, I will immediately update it!

[cpx3]

I did the update, now I cannot even login to PW anymore as the admin is not loading... (I restarted the whole server but it does not help at all). Any other ideas?

[zoeck]

4 minutes ago, cpx3 said:

I did the update, now I cannot even login to PW anymore as the admin is not loading... (I restarted the whole server but it does not help at all). Any other ideas?

Sounds like something went wrong with the update.

Just Rename the "TracyDebugger" Folder in "\site\modules" to ".TracyDebugger"
After that try again if you get back into the admin panel

[cpx3]

There seems to be a problem with the sessions. I always find the error message: Error: Exception: Unable to obtain lock for session (retry in 30s) in my log and the page seems to be delayed. I commented out all the sessions but it does not become better. Maybe there is no relation between that and the update but the problems occured immediately after updating PW.

[adrian]

Have you looked at: https://processwire.com/talk/topic/26070-error-exception-unable-to-obtain-lock-for-session/ ?

I didn't actually know about this Tracy issue. I think perhaps it's a combo between it and the SessionHandlerDB module. Tracy does now use a different approach to sessions (by default), but I'd still try disabling the SessionHandlerDB module.

[zoeck]

30 minutes ago, adrian said:

Have you looked at: https://processwire.com/talk/topic/26070-error-exception-unable-to-obtain-lock-for-session/ ?

I didn't actually know about this Tracy issue. I think perhaps it's a combo between it and the SessionHandlerDB module. Tracy does now use a different approach to sessions (by default), but I'd still try disabling the SessionHandlerDB module.

That's where I got my info, but I missed that it's related to the SessionHandlerDB module ? 

[ryan]

@cpx3 It sounds like the session is locked in the database. Try again from an incognito window or another browser. Or if you are running localhost like on WAMP/MAMP or something, you might try to reboot the database, which should also clear it. 

[cpx3]

Adrian, thanks for your reply. I actually disabled both of them (by uninstalling the SessionHandlerDB module). It became slightly better but now another problem appeared: The selector "select_regions.name!=schweiz,select_regions.name!=liechtenstein, template=template-news, start=1, limit=1, sort=-id". Any idea what might be wrong?

 

•  

 

[cpx3]

15 minutes ago, ryan said:

@cpx3 It sounds like the session is locked in the database. Try again from an incognito window or another browser. Or if you are running localhost like on WAMP/MAMP or something, you might try to reboot the database, which should also clear it. 

Thanks for the incredible support here!

[gornycreative]

On 3/11/2022 at 1:49 PM, ryan said:

You can also find all of the render files in the core AdminThemeUikit directory — any .php files beginning with an underscore are custom render files that can be overridden. 

How can I turn off these notices? Even when debug mode is disabled, they appear for any custom render files replaced every time the page is loaded.