Leaderboard

TagsToFolders Github: https://github.com/eprcstudio/TagsToFolders Modules directory: https://processwire.com/modules/tags-to-folders/ This is a small helper tool to visually organise fields/templates into folders in the menu when they are tagged. This is a simple module that can help you declutter your templates/fields menu by organising them in folders using tags. I initially envisionned this module to be used for cases where fields and/or templates were created by modules and thus not polute the ones created by the user.

I am thinking that this might actually be an easy fix in the PW core. I just did a quick edit, replacing this line: https://github.com/processwire/processwire/blob/cc43f8e67600fc3ad73ea3ac095d67f166c5ca96/wire/templates-admin/scripts/inputfields.js#L1483 with: var field = match[1]; if(field.indexOf('forpage.') == 0) { field = field.replace('forpage.', '').replace(/\_repeater\d+/g, ''); } This lets me use: forpage.fieldname=value as described by @999design in the OP. @ryan - can you see any problems with this approach? Maybe I've overlooked something? Note that this approach currently won't work with AJAX loaded repeater items.

Last week we released ProcessWire 3.0.210 main/master and it's been a very smooth launch. No new issues have appeared and all upgrade reports have been good so far. If you haven't yet upgraded I'd encourage you to. Last week's post covered a lot of what's new, in case you haven't seen it yet. Also be sure to check out the ProcessWire Weekly coverage of this new version. This week I've been focused on getting caught up with some client work but there have also been a few minor commits on the dev branch, with more on the way. I hope that you have a great weekend!

PR for the above change submitted: https://github.com/processwire/processwire/pull/255 although I expect Ryan might have a more complete solution, but at least that will hopefully get this issue on his radar.

Yep of course - sorry about that. Done now.

@adrian, I've got one more request (kind of). Earlier you added composer.json, but didn't yet push the project to packagist.org. Would be nice if you could add the module there as well, otherwise it can only be installed by adding the GitHub repository directly. Thanks in advance! ?

@adrian, you are rigth. My Hanna PHP code was wrong (I was using $sanitizer->selectorValue() instead of $sanitizer->pagePathName()). Sorry for my mistake, and thanks again for the module. ?

Hi guys, stumbled over this tool to see your breakpoints in a much more neat way (compared to the default browser development tools) It is opensource and can find it here: (i am in no way affiliated) just want to share it. https://github.com/julienagullo/rwdKit Four ways to see it in action, goto this url: https://open-source.jagullo.fr/rwdkit/ 1) resize your browser window 2) click on the devices icon on the bottom right 3) drag the blue bar on the right side 4) use the arrow buttons on the bottom How to use it: Import library plugin: (remove the scripts on production server) <script src="jquery.js"></script> <script src="jquery.rwdkit.js"></script> Initialize the plugin to generate the breakpoint detector in a specific container or the whole document. $(function(){ $(document).rwdKit(); }); $(function(){ $('body').rwdKit(); }); $(function(){ $('.container').rwdKit(); }); Happy developing

Yes, please! That's what I've been saying for a long time... Yes, please! That's the part that made me move away from AOS. I'm very happy without it btw - it hurt a little in the beginning but I'm not missing anything any more. For field/template edit links we have the great https://processwire.com/talk/topic/26537-adminhelperlinks-shortcut-links-to-edit-fields-and-template-directly-from-page-edit/ that has not caused a single issue in all of my pw instances. AOS on the other hand has cost me hours in finding bugs in my modules that turned out to be bugs in AOS. RockMigrations has the concept of "tweaks" where we can add micro-modules via single php files (https://github.com/baumrock/RockMigrations/tree/main/tweaks) and enable/disable them via GUI in the module's settings: Agreed, but don't forget that some features also need several hooks in place, so we need a combination of PHP/CSS/JS. I've also built https://github.com/baumrock/RockAdminTweaks some time ago which had the idea of making it possible to have all those little tweaks organised in a modular and manageable way. I don't see any reason why we would need support for 3 admin themes that all do the same and just look a little different. We have now the possibility to create custom styles of the backend without the need of creating a new theme (see https://github.com/baumrock/AdminStyleRock#wording-theme-vs-style ) I disagree ? Why do you think that or what exactly do you mean? But it's a little offtopic so if it's not easy to answer just ignore it. I agree ? Thx for making the list @dotnetic and pushing that topic forward!

Your list is exactly what I wish for as well, I have nothing to add. I gave it a thumbs-up. Ryan's time to work on ProcessWire is limited and being the only one to stear the boat, naturally, he needs to prioritize. I think the most important issue with implementing and maintaining migrations is that it is a HUGE effort, and Ryan would need to add support for his Pro modules as well. Again, he only has 24 hours a day. I cannot even imagine who would have the time to rewrite the admin theme from scratch. However, if Ryan ever wants to move it forward to the next level, he needs to move his mindset to the reactive era, probably HTMX + Alpine.js. If we drop support for the others, people would surely use AdminThemeUikit :P

I also brought this up before as a wishlist request UX improvements · Issue #392 · processwire/processwire-requests (github.com), because I use these features of AoS in EVERY PW instance. But there are also always voices against integrating useful things into the core, to keep it "lean". For example integrating migrations into the core, which I see as crucial, but others say that migrations are not needed for everyone, and so they should stay out of the core. One feature might be useful for one person, but not for the others, so I am always in favor of "providing options" (turning features on or off). I'm also at a point where I find the admin or UIkit theme stale and not really functional. There are a lot of things missing for me. Reactivity like vue.js or alpinejs or react offer. Better usability of dropdowns in the main menu and other things, but I digress. Several times I started to develop a new admin theme based on vuejs, but also noticed how complicated for example the pagetree is built and moreover I lacked the time. Furthermore, with such a big undertaking, it's also always a question of how many people would really use it, or if I (or WE) are just developing it for fun. Because I don't want to develop anything for &>/dev/null. Back to AdminOnSteroids: Right now it's not modular and uses jQuery under the hood. It's not a bad thing because the PW core also relies on jQuery, but would rather suggest a rewrite here where every feature is a javascript module. These modules could be loaded on demand (conditionally based if a specific DOM element exists or not) at runtime. This keeps the core lean, and also the javascript load and execution time and memory consumption low. Maybe such an update (or the integration into the core) could be developed by crowdfunding. I am also in favor of ditching support for Default or Reno theme, because I think that most people would use AdminThemeUikit, but I might be wrong? Upgrading the PHP part, would not be that difficult, if we drop support for PHP versions < 8.

I'm in! Maintaining AOS would be just too much work for even the most experienced, I think, so no wonder @tpr is no longer interested in it, especially that he no longer uses ProcessWire. Also, AOS mostly supports the Default or Reno admin themes which we should deprecate, IMHO.

It's essential to my PW work as well so would definitely love to see it maintained, or at least some of its key features incorporated into the PW core which is probably the better approach. Maybe we should start a list of the features we all need and put together PRs for Ryan to get them into the core?

Welcome to the PW forums ? PW doesn't currently provide a way to find pages by the length of a field value. Although I think it would be a nice feature so I took the liberty of opening a request: https://github.com/processwire/processwire-requests/issues/424 Technically you could achieve it with a custom SQL query: $sql = 'SELECT pages.id FROM pages LEFT JOIN field_title ON field_title.pages_id = pages.id WHERE CHAR_LENGTH(field_title.data) > 10 AND pages.templates_id != 2 AND pages.parent_id != 2 AND pages.parent_id NOT IN (SELECT pages_id FROM pages_parents WHERE parents_id = 2 OR pages_id = 2)'; $ids = $database->query($sql)->fetchAll(\PDO::FETCH_COLUMN); $results = $pages->getByIDs($ids); But you might find it simpler to stick with what you're already doing.

If I understand correctly, this should do it: https://github.com/adrianbj/TracyDebugger/blob/481a548a4d9f09784ccb1c7f598212e2923b2191/TracyDebugger.module.php#L774-L784

A sanitizer is a good idea, but not $sanitizer->selectorValue() because as you say you are not supplying a selector to the method but are supplying a path (you can also supply an ID which is different again). So you'd want $sanitizer->pagePathName(). Yes, in fact you can see in the error message that PW builds a selector using "path=" when you supply a path to $pages->get(). See here: https://github.com/processwire/processwire/blob/88e04129c72c1702926543c8bef555a9f0d1043f/wire/core/PagesLoader.php#L131-L133 else if($selector[0] === '/') { // if selector begins with a slash, it is referring to a path $selector = "path=$selector";