szabesz

Thank you so much! I will not bother with trying to uninstall it as I do not find it particularly problematic, but from now on I switch to using PageEditSoftLock on new installs, hoping that one day Ryan will roll out a solution baked right into the core.

So far I have been relying on Ryan's "System Notifications" module, which is at least notifies users when concurrent editing takes place but that's not too much help, just the basics. Also, the "System Notifications" module can be problematic, see: https://processwire.com/talk/topic/9526-strange-errors-following-upgrade/?do=findComment&comment=95893 and it has not been given any love from Ryan in long years, its short description is still "Adds support for notifications in ProcessWire (currently in development)" for at least 5 years in a row. Me too. It is a very popular request with currently 17 likes : https://github.com/processwire/processwire-requests/issues/23 Maybe it is time to rethink it all: concurrent editing (borrowing ideas and features from Adrian's frok of PageEditSoftLock) page drafts (Ryan hinted that he is going to port the foundation of ProDrafts to the core) "System Notifications" module "finalized", or better yet, reborn with features integrated with the previous to points above Could you please at least share it on GitHub (I would like to move away from "System Notifications" module), and let's see what @ryan thinks about this request?

@adrian Would you please become the maintainer of this module? In this GitHub comment of yours you wrote: "I use a modified version of Soma's module in hard lock mode. The modification I made makes superusers exempt form the hardlock. Obviously I still don't edit when someone else is editing, but at least I can view the page edit screen. I think ideally, the hard lock would let everyone view the edit screen, but they wouldn't be able to save it." I would love to see you take this module a bit further by adding the features you described above. You might want to ask @Soma first of course, but since he is not an active PW dev these days, he will surely agree... After that you can ask Ryan to re-publish it for you, perhaps. Good plan, isn't it ?

cross reference:

cross reference:

Unpoly 2 is promised to be released soon: http://triskweline.de/unpoly2-slides/#1 Powered with Bootstrap 5 it might be a game changer for me. I have never been a fan of Bootstrap but version 5 impressed me so far. With the (optional) integration I can't wait to see what sort of productivity boost is possible for me by building upon both.

@adrian I don't think you should spend more time on this as it is just a minor issue of a minor feature. Thanx anyway!

Perhaps FatFree can be another source of inspiration (or it could even be added to our projects easily? The whole library is 483 KB and 45 files...!) https://fatfreeframework.com/3.7/routing-engine https://www.youtube.com/watch?v=XGldwy1pmU0&feature=youtu.be FatFree has good a history of being maintained: https://github.com/bcosca/fatfree/releases

Since you are using ProFields, have you thought of asking Ryan for help? (Provided you currently have an active license, of course). Anyway, I do not think the number of pages and fields are causing the issue. You should not blame the system for this, as it it highly unlikely that the system itself is the root of the cause.

Hello, Have you tried to bump up the max execution time as a starter? Usually I set it to max_execution_time = 60

I might have figured it out: actually, there is no problem when I can perform a single-click without moving the mouse between mousedown and mouseup. However, even if I happen to move the mouse just by one pixel during the click, then the #tracy-debug-logo div's mouse drag kicks in, and that is the end of the story... It also works the same way in Chrome, so actually there seems to be no difference in the way these two browsers work in this case. When I use the trackpad of my MacBook Pro, then it sometimes happen that I cannot single-click without moving my fingers a bit.

@adrian Thank you very much! Maybe the gray of the gear icons could be lighter because currently there is too much focus on them (if it is possible to recolor those SVG icons in the first palce...) But most importantly, the "go to top" single click works randomly in Firefox (mac). I also tested it in Chrome, where it works all the time but – for some strange reason – not always in Firefox.

I have not yet tested the difference, so it is something I need to look into. To tell the truth, I have just started to use page classes, so I am happy to hear how others make use of it.

If I'm not mistaken, it can be simplified by utilizing the __loaded() method instead. PW will call that method after the page object's data has been populated from the database (so all its field values are accessible), and it can also act like your "manually" called init function. Credits for this "tip" goes to @Robin S: https://processwire.com/talk/topic/25107-custom-page-class-how-to-use-__construct-or-similar/?do=findComment&comment=211144

True but I don't think that matters as the "Main setup" section is at the top, so there's not too much need to use that quick link anyway. It's just there for completeness, I guess ?

@kongondo or @adrian Maybe one of you could move this thread under the Tracy section of the forum? Now that I have successfully hijacked it? ?

Hello Adrian, thanks for your kind reply. My clients and me solely use the admin on desktop (I guess we do not like to torture ourselves ...) so I have no experience with narrow viewports. Well, it is similar for sure but not the same. Anyway, this idea is not that important so I am quite happy to forget all about it ? How about adding it to the Tracy logo? Currently, a double click is used for taking us to the settings page but a singe click does nothing. Maybe that event could trigger a "go to top". BTW, Server Indicator Type is in the same league: not really about debugging and such but about aiding the developer with a subtle but useful touch.

Another idea popped up in my mind ? The Panel Selector of the Debug Bar lists the panels in alphabetical order, which is quite OK with me, however, what if there wire direct links to the panels settings? Maybe the far right side of each list item can be a good candidate the location of the links (perhaps links on icons?).

While we are at it, coud you please optimize the following as well please: Request Logger Panel: all its three rows can fit in 1/3% "columns". Request Info Panel: "Panel sections" is very tall compared to "Show image thumbnail..." Maybe "Panel sections" options can be spread out into columns? Perhaps a quick and dirty CSS columns property addition would solve it. Actually, you have solve it for the panel selector options already. Error logging: same as above. Log severity is very tall, maybe a two column layout would help while at the same time the other columns next to it could be narrower. BTW, I like the new Quick links, thanks fort that! My only issue is that it is not in alphabetical order, so it is not that easy to find what I am looking for. I understand that it is in the same order as the sections below, but I do not know the order of them anyway, so the current order is not much of a help. The only order I know by heart is the alphabetical one. Also, it would be nice to have a "go to top" option for the debug bar, so that we can easily jump to the top, and not just on the Tracy settings page. (Yes, I can do it with my keyboard, but I often prefer using the mouse instead.)

@adrian Actually, I would love to have the option to have it for the admin only but disable it for the frontend. Currently it is all or nothing, meaning that we can disable all indicators for the frontend, but I would like to disable/enable them individually, separately for both admin and frontend. Maybe the "Where" option could be merged with the "Indicator type", so that each indicator has its own "Where" option. That would satisfy all needs, I guess. We would also save some screen real estate, as both blocks of these options are rather emptiesh, and the merged UI would fit in the block of "Where" easily. That way, the settings page would be a little shorter than it is currently.

Since PW 3.0.127 there is the option of setting "Unique" status for pages. Maybe you could utilize that? https://processwire.com/blog/posts/pw-3.0.127/ I'm not quite sure what you are referring to by saying "across multiple fields". Do you need the value of one field to be unique on the very same page compared to another field(s) of the same page, perhaps?

The page id is an auto-incrementing number. Can't you just simply rely on that? Am I missing something perhaps? Something like the following?

I have just tried this on ProcessWire 3.0.155-dev and 3.0.169-dev ( I do not have 3.0.152-dev to test it with) but this method does not work. If I add some logging to addSuffix like this: public function addSuffix($suffix, $path) { if(!isset($this->suffixes[$suffix])) $this->suffixes[$suffix] = array(); if(!empty($path) && is_dir($path)) $this->suffixes[$suffix][] = $this->path($path); error_log(print_r($this->suffixes[$suffix],true)); } ...then – for example – I get the following during an admin page request (I get a similar but longer results on loading frontend pages): Looks like there are cases when the array is empty, and there are cases when it contains my custom path. Anyway, in the end, custom Page classes are not loaded (except the ones from the default location). Anyone with deeper understanding of the ProcessWire internals has an idea of what is going on?

+1 – please +1 – This should also be optional.

It would even be easier if the css "framework" was built upon css variables, eg: https://www.gethalfmoon.com ("easy dark mode" is also built in). That's what I call a few lines of code: https://www.gethalfmoon.com/docs/customize/ No setup, no build process, only a few lines of code, and there is no need to talk about color preferences in that case ? It has been an optional setting of the UIkit theme right from the beginning. It is easy "not to use it" ? Anyway, I add the client logo and client colors so that I can tell apart the admins I have to work with... so "branding it" is not just for the client's sake but my own, too.