PW 3.0.143 – Core updates

[ryan]

This version on the dev branch contains 26 commits (relative to 3.0.142) and is focused primarily in resolving reported issues, and we managed to cover 18 of them in this version. Thanks for the reports and help in our GitHub issues repo. This version represents about 2 weeks of work, and ProcessWire Weekly #284 has good coverage of those that occurred last week. More details about this week's updates can be also be found in the dev branch commit log. 

There are also some other minor additions and improvements in 3.0.143 as well. My favorite are the improvements to our logs system. It now collapses identical log entries that occur near each other. That means a single recurring log entry (like an error message) won't repeat indefinitely in the log and take up a lot of space. Now it just adds a counter to one log entry and updates the timestamp, rather than duplicating the entire log entry... Much more efficient. When you view a log in Setup > Logs, it identifies these collapsed log entries for you.

In addition, the output in the "errors" and "exceptions" logs now have improved readability, isolating error messages and filenames from stack traces. Lastly, the ajax navigation in Setup > Logs now shows logs in newest-to-oldest (modification date) rather than alphabetical, which I find a lot more useful. The log at the top of the list is always the one most recently updated. 

For core updates in coming weeks, I'm primarily focused on preparing the current dev branch to merge to the master branch, as it's been awhile since the last merge and the master branch is itching for a new version. Most of you reading this already run on the dev branch, but there are many out there that also stick to the master branch, and with all the new stuff on the dev branch, I'd like to get our master up-to-date with this as well. Thanks for reading, have a great weekend!

[teppo]

17 hours ago, ryan said:

My favorite are the improvements to our logs system. It now collapses identical log entries that occur near each other. That means a single recurring log entry (like an error message) won't repeat indefinitely in the log and take up a lot of space. Now it just adds a counter to one log entry and updates the timestamp, rather than duplicating the entire log entry... Much more efficient.

I haven't had the chance to see this in action yet, but looking at the code I'm wondering about one thing: at least in my case it's often important to know exactly when a particular issue first occurred, so that I can figure out what might've caused it – but if that initial occurrence is now removed, doesn't this make that process difficult, if not impossible?

My initial thinking is that perhaps we should also store the timestamp for the first occurrence along with the counter data. That would, in my opinion, be an improvement over just logging the latest case along with a counter.

While debugging a strange issue it's sometimes also helpful to know about the exact timestamps of all occurrences, but then we're basically back at not having this feature at all ?

Overall I can see value in this, particularly from the UI point of view and for those cases where you're somehow spammed with a truckload of identical log entries, but I'm also a bit concerned that it could make debugging problems harder. As such, it might actually be a good idea to allow disabling this feature altogether; this way users could still opt-in for "full logging" instead if that works better for their workflow.

[markus_blue_tomato]

11 hours ago, teppo said:

I haven't had the chance to see this in action yet, but looking at the code I'm wondering about one thing: at least in my case it's often important to know exactly when a particular issue first occurred, so that I can figure out what might've caused it – but if that initial occurrence is now removed, doesn't this make that process difficult, if not impossible?

My initial thinking is that perhaps we should also store the timestamp for the first occurrence along with the counter data. That would, in my opinion, be an improvement over just logging the latest case along with a counter.

While debugging a strange issue it's sometimes also helpful to know about the exact timestamps of all occurrences, but then we're basically back at not having this feature at all ?

Overall I can see value in this, particularly from the UI point of view and for those cases where you're somehow spammed with a truckload of identical log entries, but I'm also a bit concerned that it could make debugging problems harder. As such, it might actually be a good idea to allow disabling this feature altogether; this way users could still opt-in for "full logging" instead if that works better for their workflow.

Some possebility to fold/expand duplicates in the log view would be great.

[fliwire]

hi ryan,

using MariaDB 10.4.7 

after installation processwire (InnoDB) and delete page cant empty trash.   MyISAM not have this error. Cant test with Mysql InnoDB but just report.

[fliwire]

installed xampp also has mariadb and not have this error.

install mysql 8 to laragon and not have this error.

laragon and maria db cause issue, there is no log in php_errors.log and mysqld.log.