Leaderboard

To allow Rector to inspect/refactor older modules, you also need to add the following config to your rector.php $rectorConfig->fileExtensions(['php', 'module']);

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.

Thanks! It’s now updated https://processwire.com/modules/tags-to-folders/ ?

@MarkE there’s this module I made some time ago https://processwire.com/modules/tags-to-folders/ with one of the latest updates being having the system fields/templates in their own submenu. I could add an option to hide them so I’m taking your question as a feature request ?

I will wholeheartedly admit that I may be going a little hard on WP. I know there are good devs everywhere who use the platform that works for them and their clients. I could be taking it a little easier on WP and it's plugins. ALRIGHT, THAT HAVING BEEN SAID *takes swig of beer, chucks bottle* Kidding, but I have been posting very punctuated examples of issues, some of which are more widespread than others. I also haven't been posting any real nuance, so I guess that's also not really a fair play either. I'll admit that I haven't been in a situation personally where a media manager came to mind- so I'm not going to make a blanket "never use them" statement. I can definitely see how what you said could grow into an issue, and combined with the "free for all" no size limit image fields, certainly. I like per-page media but a centralized media manager makes sense logically, especially to developers because we reuse code/resources to stay DRY. It's 100% appealing to me in that sense. However the "management" part of a "media manager" takes active effort and I'm inclined to believe that this isn't something clients/users keep in mind. I say that both theoretically and empirically. Media management can be an efficiency construct that exists outside of "keeping my website updated". Contrast to PW's per-page assets that works the way a client would think it does- when a page doesn't exist anymore, none of it exists anymore. The developer gives up what they know would be a better idea technically for asset reuse (central management) for the simplicity in user experience (distributed management). Recently I was forwarded email from a client from their web host stating that they had reached their website backup space and directed them to upgrade their plan. They asked if they should buy the upgraded package, I told them I'll take a look. I logged into one of their WordPress sites and deleted almost 1gb of images that had not been in use for years. Logged into another and deleted even more. I was almost 100% sure I knew what the culprit was just reading the email. This was a layer deeper than their server disk space. A hybrid approach (I'm sure this has been discussed before elsewhere already) in PW would be interesting where asset fields have a "Select From Another Page" option that allows for reuse, but is still tied to pages. Not to get too in-the-weeds, but extend the current assets/{page id} concept where selecting an asset from another page moves that file to assets/{new id}_shared. Now both reference the same file "manager style" on the filesystem. Asset fields could have a way to view a list of pages that also use the asset, with the ability to "Delete From All". If the file is removed from all pages except one, it's moved back to the assets folder of that page and assets/{new_id}_shared is deleted. The back end handles the centralization, the user's workflow remains enhanced but without additional work. One of the things I discuss with clients is "How can we add utility without increasing workload?". It helps us balance what they want with what they can or are willing to do to make it work. I'm inspired by Colin Chapman, founder of the Lotus car company, where his philosophy when building cars was "Subtract weight, add lightness". In day to day use, I think an optimization for the developer should feel like an optimization/feature for the user if they have to interact with it (as much as reasonably possible of course). I will repeat the caveat that I haven't experienced a situation where the solution was centralized media management- or I've been such a devotee to distributed management that I never think to consider it. Either way that's on me ? The only time I've run into this is for truly site-wide content like logos, or certification/awards logos for the footer which is handled easy by a "Site Settings" page in the page tree, it works because there's still some sort of dedicated purpose for those fields that keeps the images contextually organized. That might be another case-in-point about my limited experience in that situation though. I considered this the most on the my last post re: Contact Form 7. It's a plugin and not core, absolutely. So the developer dropped the ball, happens. Unfortunately issues happen all too often, so I mention it in a manner of a cumulative stack amongst many plugins. I will suggest some responsibility by WP though because of it's built-in reliance on plugins- oh, you want custom fields? (you know what comes next) It's arguable that there's an ecosystem problem, one that WP's architecture, theme reliance, messy admin, and plugin implementation has a healthy hand in. Is the complexity or quality of the core a contributor to plugin problems? 5 minutes with the WP Codex is a little convincing IMHO. If I had the time maybe I'd try my hand at Fluency for WP (did I just say that out loud?). Ironically, the list of issues I (and many of us) could come up with exists as an antithesis to the PW methodology- and I guess that's why we're all here in the first place. So I may need to acknowledge that the dead horse is dead and put my beating stick down ?

I wrote this a while back for my company's internal documentation and just realized it might be a benefit to others on the forum, so here it is! Checking whether a field was changed To check whether a specific field was changed you can do $page->isChanged(‘field’). This can only be done before Pages::save, since the save clears change tracking by default. Getting the values of a page before they were changed, from within a hook before Pages::save Method 1: The hacky way $clone = clone($page); $e->wire('pages')->uncache($clone); $oldP = $e->wire('pages')->get($clone->id); $oldP then represents the page and all its values as they were before any changes were made. Again, this will only work for hooks that run prior to Pages::save. Method 2: Using change tracking to get the old values If change tracking is set to track values, then the above is not necessary. In this case, calling $page->getChanges(true) will return an associative array of fields that changed and each field's prior value. Note that the value itself is also an array, since it is designed to be able to track multiple changes over the course of a single request/response cycle. Tracking of values is turned off by default (for efficiency sake), and there is no global switch to turn it on and off. To enable tracking of values, you must call $page->setTrackChanges(Wire::trackChangesOn | Wire::trackChangesValues) before any changes are made to the page that you want to track. Here is an example of how you can enable value tracking in ProcessWire's page editor: $this->addHookBefore("ProcessPageEdit::execute", null, function($e) { $p = $e->pages->get((int)$e->input->get('id')); if($p->template == 'event-registration') { $p->setTrackChanges(Wire::trackChangesOn | Wire::trackChangesValues); } }); Running hooks on both page saves and field saves Please note that using the following hooks is preferable if you want the hook to run both when individual fields are saved as well as the whole page: Pages::savePageOrFieldReady https://processwire.com/api/ref/pages/save-page-or-field-ready/ (for before a save) Pages::savedPageOrField https://processwire.com/api/ref/pages/saved-page-or-field/ (for after a save) Getting changes in a hook after Pages::save Note the $changes parameter passed to Pages::saved and Pages::savedPageOrField allows you to check which fields were changed during the save, even though the save is already completed. Using this is sometimes preferable to using a Pages::saveReady or Pages::savePageOrFieldReady hook since you don’t have to worry about the page cache or something else in your code preventing the original save from completing. A $values array is also provided, which is populated only if change tracking is set to track values (see above) Page cache issues when hooking before Pages::save Page cache issues may occur when you try to save another page inside of a before save hook (Pages::saveReady or Pages::save). A page save normally clears the entire page cache, which means any page fields on the page you were originally trying to save will have their values reset. So if you have to save another page inside of a before save hook, just use $page->save([‘uncacheAll’ => false]) to prevent the cache from being cleared. Preventing hooks from running on a particular save To prevent any hooks from running on a particular page save, you can use $pages->save($page, [‘noHooks’ => true])

If your layout remains like this (3 per row) with maybe one breakpoint for mobile you could do something like this: <div class="team"> <div class="team_member"> <img class="team_image" src="/path/to/image" onclick="this.nextElementSibling.classList.toggle('team_about--opened')" /> <div class="team_about"> <!-- content --> </div> </div> <div class="team_member"> <!-- repeat --> </div> <div class="team_member"> <!-- repeat --> </div> </div> CSS (non-tested, overly simplified and missing things, like accounting for the gap in the grid...): .team { display: grid; grid-template-columns: repeat(3, 1fr); } .team_about { width: 300%; height: 0; position: relative; background-color: blue; } .team_about:nth-child(3n + 2) { /* every 2nd element per row */ left: -33.333%; } .team_about:nth-child(3n + 3) { /* every 3rd element per row */ left: -66.666%; } .team_about--opened { height: auto; } .team_about::before { /* arrow */ content: ""; display: block; margin-left: -10px; position: absolute; bottom: 100%; left: 25%; border: 10px solid transparent; border-bottom-color: blue; } .team_about:nth-child(3n + 2)::before { left: 50%; } .team_about:nth-child(3n + 3)::before { left: 75%; } Basically the idea is to have the dropdown within the team member’s div so that when you open it it adds to the parent’s height (thus pushing the next line) and then you account for the offset by using position: relative. This is ok for such case where the layout is well defined but it doesn’t “scale” well if you decide to have 4/5/... members per row. However this is me not using any preprocessor but since I know you’re using Less (or Sass?) maybe you could easily write a function generating the necessary CSS based on the number per row. (in my example, JS is necessary to add the "team_about--opened" class, but you could do something with pure HTML/CSS using the amazing details tag)

FYI: You can also "follow" a topic on the top right and then choose when to get notifications about new posts, eg asap or once a day. ? You can even subscribe to whole categories.

Really nice module! Just tried it and it works great and really improves the UI/UX. Thx for sharing ?

Oh ok! Just saw your report (https://github.com/processwire/processwire-issues/issues/1866). I guess we just have to wait then...

Looks spot on to me!

Here’s the update @MarkE, let me know if it’s all good (looks fine on my side) and I’ll push the update on github/modules directory TagsToFolders.module.php

This is a known issue. I actually made a big report in the PW issues repository on GitHub.

When moving out / back in the files did you make sure you moved the .htaccess (the one in the PW’s root directory) file as well? You can easily forget about it as it can be hidden by default.

Gosh, that's a good answer and well documented too ? Many thanks Da2, I'll look into that too.

This would also work: <?php if($page->matches("id=1042|1043")) ... ?

I am looking in the forum for a solution but I didn't find it. I redirect people based on their browser language, with I use this code (that I grab somewhere in the forum): foreach($languages as $language) { if(strpos($config->httpHost, "$language->site.it") === 0) { $user->language = $language; break; } } $name = $sanitizer->pageName(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2));; $language = $languages->get($name); if($language->id && $name != $user->language->name) { $url = "https://www.site.it" . $page->localUrl($language); $session->redirect($url); } Now the problem is that: the users can't change the language because they are always redirected to theirs browser language. I would like to let the users change the language. I try to work around Session class, I thought of enabling redirection only on first arrival, but I don't know how to do it. Maybe I have to work with the cookies? I'm not sure about what I can do. I find this post, but I will not use this module but incorporate within my _func.php file, because before to get to the language selection I have other statements. If I have understand well he used this part to make the redirect only in first session, but I'm not sure how can I integrate this // Set some session variables then redirect $this->session->languageAlreadyDetected = true; if (wire('user')->language->name != $matchedLanguage AND !isset(wire('input')->get->{$this->noDetectGetParam})) { $this->session->redirect($page->localUrl($matchedLanguage), false); } MY SOLUTION: probably not the best solution, but it works // set the cookie expire after 5 min, I know is not the best because after 5 min the user not load page is forced to change language, // but the average time of a session is that and in this way I'm sure if the user cameback there isn't this cookie $user_is_first_timer = !isset( $_COOKIE["FirstTimer"] ); setcookie( "FirstTimer", 1, time() + (60 * 5) ); if( $user_is_first_timer ){ foreach($languages as $language) { if(strpos($config->httpHost, "$language->playwood.it") === 0) { $user->language = $language; break; } } $name = $sanitizer->pageName(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2));; $language = $languages->get($name); if($language->id && $name != $user->language->name) { $url = "https://www.site.com" . $page->localUrl($language); $session->redirect($url); }

Raymond Geerts, has pointed me a way to swap templates folder based on the hostname. (His post is somewhere here on the forum.) You need to place this code in /site/config.inc Here's my variation: /** * Switch ProcessWire templates directory on $_SERVER['HTTP_HOST']. Type the * Hostname as key and the name of the new templates folder as value. * */ $config->templates = array( 'sub.domain.dev' => 'templates-dev', // domain => templates folder name ); if (isset($_SERVER['HTTP_HOST']) && isset($config->templates[$_SERVER['HTTP_HOST']], $config->templates)) { foreach ($config->templates as $host => $folder) { if ($_SERVER['HTTP_HOST'] === $host) { $config->urls->templates = "/site/" . $folder . "/"; $config->paths->templates = dirname(__DIR__) . $config->urls->templates; } } } Here is Raymond's post.