Leaderboard

Repeater Easy Sort Adds a compact "easy-sort" mode to Repeater and Repeater Matrix, making those fields easier to sort when there are a large number of items. The module also enhances Repeater Matrix by allowing a colour to be set for each matrix type. This colour is used in the item headers and in the "add new" links, to help visually distinguish different matrix types in the inputfield. Screencasts A Repeater field A Repeater Matrix field with custom header colours Easy-sort mode There are two ways to enter easy-sort mode. 1. Click the double-arrow in a Repeater item header. This activates easy-sort mode and also highlights the item with a black background so it's easier to find it in easy-sort mode. 2. Click the horizontal ellipsis icon in the Repeater field header to activate easy-sort mode. To return to normal mode click the vertical ellipsis icon. While in easy-sort mode: The items will reduce in width so that more items can be shown on the screen at once. The minimum width is configurable in the field settings. Any items that were in an open state are collapsed, but when you exit easy-sort mode the previously open items will be reopened. You can drag an item left/right/up/down to sort it within the items. You can click an item header to open the item. An "Exit easy-sort mode" button appears at the bottom of the inputfield. Configuration In the field settings for Repeater and Repeater Matrix fields you can define a minimum width in pixels for items in easy-sort mode. While in easy-sort mode the items will be sized to neatly fill the available width on any screen size but will never be narrower than the width you set here. If desired you can enable easy-sort mode for a field by default. Since easy-sort is then the default mode for the field no "Exit easy-sort mode" button is shown. Use the mode buttons in the field header to change between easy-sort and normal mode when needed. In the field settings for Repeater Matrix you can define a custom header colour for each matrix type using an HTML "color" type input. The default colour for this type of input is black, so when black is selected in the input it means that no custom colour will be applied to the header. Exclusions The easy-sort mode is only possible on Repeater/Matrix fields that do not use the "item depth" option. https://github.com/Toutouwai/RepeaterEasySort https://processwire.com/modules/repeater-easy-sort/

ProcessPageAdd.module has this (that is the process module that is executed when adding a page): $form->addClass('InputfieldFormFocusFirst'); And inputfields.js has this note: * - InputfieldFormFocusFirst: Class assigned to form that should focus the first field. ProcessPageEdit does not add this class, so there is no field focus on edit screens. What I'd do is probably this: // in site/ready.php $wire->addHookAfter("Inputfield(name=title)::render", function(HookEvent $event) { // we focus the field only if it is empty if($event->object->value) return; // show a hint and focus the field $event->return .= "<div>Please enter something here</div>" ."<script>$(function() { Inputfields.focus('#Inputfield_title') })</script>"; });

Guys, I found the method that I meant. It is not the field=fieldname URL that Bernhard mentioned. A long time ago I also tried to tackle a similar task, where I wanted to remember and focus the last edited field after you saved a page. I opened a github issue for this and later Ryan added some methods that he mentioned in a reply, that achieve the behaviour I and @Peter Falkenberg Brown want. Just add a #focus-field_name to the URL when the page is saved and the redirect is executed and the field gets focused. An example URL looks like https://domain.com/processwire/page/edit/?id=1056#focus-subheadline and would focus the field named "subheadline". I am a fan of using native methods that ProcessWire offers, over custom ones. But what the others wrote is also viable. I will provide a hook, just have to test it out, but it goes somewhat like this: <?php namespace ProcessWire; $this->addHookBefore('ProcessPageEdit::processSaveRedirect', function (HookEvent $event) { $url = $event->arguments(0); $page = $event->object->getPage(); if ($page->template == "book_sales" && !$page->isTrash()) { if ($url !== "../") { $goto =$page->url . '#focus-list_price"; $event->arguments = array($goto); } }

I need that because my admin action copies content of fields from one language to another, and we should somehow warn user that languages are identical (since I think it doesn't make sense to copy the content to the same field). I've thought that not allowing to pick language in "destination" fields might solve the root problem, but I already solved my problem using PHP. Just added the warning that languages were identical after successful execution of Admin Action.

Yes, I think this is exactly what I will do. Like you say, it's easy to do so might as well. As a simple addition to @FireWires great answer: Don't forget about the relatively new url hooks! https://processwire.com/blog/posts/pw-3.0.173/ You don't need a dedicated page then (which means that you also do not need to hide that page from the tree via hooks)

OK. STEP #1 Create a file, e.g admin.js and save it to your preferred location. In this example, we have saved it at site/templates/scripts/admin/admin.js STEP #2 Add either of the below JS code in admin.js (you don't need both; choose one or the other). jQuery version: $(document).ready(function () { // #wrap_Inputfield_list_price is the ID ProcessWire will assign to your list_price field's wrapper (an li element). // you can confirm this by examining the markup around your 'list_price' input in dev tools. // Inputfields is a utility files that ships with ProcessWire. // more details: inputfields.js - JS specific to behavior of ProcessWire Inputfield forms. Inputfields.focus("#wrap_Inputfield_list_price") }) Plain JavaScript version: const InputfieldAdminScripts = { focusAnInputfield: function (inputfield_id) { const inputfieldToFocus = document.getElementById(inputfield_id) // if we found the element,focus it if (inputfieldToFocus) { inputfieldToFocus.focus() } }, } // DOM ready document.addEventListener("DOMContentLoaded", function () { InputfieldAdminScripts.focusAnInputfield("Inputfield_list_price") // this will also work here. you can use it instead of the above // Inputfields.focus("#wrap_Inputfield_list_price") }) STEP #3 Inside ready.php, add this code to load admin.js. You can modify this to only load under certain conditions if you wish. <?php namespace ProcessWire; $this->addHookBefore('AdminTheme::getExtraMarkup', function (HookEvent $event) { $config = $this->wire->config; $url = $config->urls->templates; $config->scripts->add($url . "scripts/admin/admin.js"); }); Please note that in Chrome (and maybe FF as well), if you have your dev tools opened and the cursor currently focused on it, the inputfield might not seem to be focused, but it actually is. ?

ProcessWire definitely shines in the security department and the login page does have throttling. I don't know what your threat model is but usually sites have to deal more with bots than individual bad actors, but that depends on the purpose/use for your site. I've built many PW sites over the years and not one has ever been compromised. In my opinion, your biggest threat as far as hackers go would be a person that came into possession of one of the users' login credentials or much more common automated attack scripts with other vectors like requests containing data that the code isn't prepared to handle, or MySQL injections in your forms. Here are some additional thoughts on your login URL. If you don't want bad actors to know the login URL then it should be changed it to one that is practically unguessable like /clientname-admin-login or something easy to remember but hard to guess. Consider that your /processwire login URL is not unknowable because it's the default. Someone intent on getting to the login page or knowing what CMS you are using could analyze the markup and see that your images are being served from /site/assets/files/{page id} and any assets like JS may be served from the templates directory like /site/assets/templates/scripts- the file structure consistent across ProcessWire sites. When you load a page on a ProcessWire site, the server returns the request with the header "x-powered-by: ProcessWire CMS" unless you've disabled it and that will let someone look up what the default URL would be. Using /processwire in JS isn't really the issue. All that aside, it's not automatically a disadvantage to have your login URL known. Most of the PW sites that are built probably keep /processwire. My take is that if you have the opportunity to change it and reduce the chance non-authorized people would see the login page to begin with, why not? If this were my project I would change the login URL and create a dedicated /api page in the admin then use a hook to hide it in the page tree on render for non-superusers. It would keep the main site tree tidy as desired, allow for a clean semantic URL to work from, and not hard code in references to a part of the website that isn't content-related. If you want to take security against bots into consideration I would look into adding some bot blocking rules to your .htaccess file, I use 7G Firewall. Bot blocking prevents bot HTTP requests from requiring ProcessWire to boot up, analyze the URL, determine that it doesn't exist, and then serve the 404 page- this improves performance by reducing server load. Blocking bots also takes care of many other automated malicious requests as described above. I kinda blew this open a bit, but I think your question about security being limited to hackers and the login page could benefit from a wider scope.

Hi, I upgraded 100+ sites to the latest master on Friday, and we've gotten the following error email notification from a few of them over the weekend: Umm… Error: Exception: Unable to obtain lock for session (retry in 30s) (in processwire/wire3/modules/Session/SessionHandlerDB/SessionHandlerDB.module line 96) User: ?, Version: 3.0.184 This is a new error, added in the latest master release: https://github.com/processwire/processwire/commit/7a2ff6c15dde8f6768676181bfbeeaefe4761b0b#diff-4c158c18e5f331d4e9ff8b27eff8ae2c4cd34d16f6d0f2b427aa36791637c64f The session lock time is set to 50 seconds, I think this is the default, so I suspect the issue is on our end with our databases/server(s). I'm going to investigate further and try and figure out the issue and will update here if/when I do. If anyone else has come across this or has any more info, please let me know! Cheers, Chris

Good day! I think about moving some development away from localhost to a remote dev machine. It is password protected, so noone will see the Tracy Debugger bar. And I want to show it for guest users too, like I can do on localhost. Is there a way to do it?

Hi @Ivan Gretsky - I've had a couple of other requests for this so it's definitely on my list. I will try to get to it shortly.

I've been using Bootstrap 4 all the time, but I didn't want to take the step to version 5. I'm making my first, successful steps with Tailwind and I'm currently very satisfied. But you have to learn a lot of new things, because it's still a bit more complicated than Bootstrap, but you also have a lot more freedom. I also use Htmx and Alpine.JS with TailwindCSS ? many nice new things ?

just curious, how many of you like/work on https://alpinejs.dev/ ?

Tried this for the About page. The URL echoed is /about-us/ (which is what is set under admin for the about.php page). It takes me to www.mywebsite.com/about-us/ and gives me the URL not found on server error. Also another thing I observed that on the admin panel, when I click on View for the About page, it takes me to www.mywebsite.com/test/about-us and gives the same URL not found error. The 'test' folder is where the site dir, wire dir, .htaccess and index.php files are. Essentially that is the document root where the domain is pointing. However on the admin panel as you can see that folder name is still appearing after the domain address. Could this discrepancy causing all this? Just a guess, not sure. What should the admin URL be after migration? Does that change too? Thanks.

this is surely related to the file/folder permission issue. Please try clearing cache as well. But I would like to suggest another way of moving PW work from dev machine to Production Live. Once you finished the development, you can follow as below steps : install this module Profile Exporter for ProcessWire 2.5+ ( Admin => Module => New , then use the Module Class Name method ) upon successful installation Admin => Export Site Profile This will give you a form to give a name, title and image for the profile and lets you export into zip format Upload this file into Production/Live server root (wherever you like to install PW) Upload the PW Master version and extract it Copy/Move your site profile backup file and extract it Now, you will have site profiles folders like site-classic, site-blank, and site-the-name-you-have-given go to the installation URL and you choose your site-the-name-you-have-given from the menu and install it this will import the database, files, assets and everything. I hope this works for you.

That worked. I cleared the site/assets/cache folder and also the caches table from the db. Thank you all!

Just reset the name + password for the superuser, then you can login as that user and create other users or edit them and their roles.

Below is one way to detect if the page is new, in which case add our script. The disadvantage of this is that the whole file is only included under certain conditions as opposed to a just a function inside the file being called under certain conditions. This means the admin.js file will only be used for focusing the list_price field. There are other ways around this. Hopefully others will chime in with better solutions/ideas. Change the ready.php code I suggested above to this one: <?php namespace ProcessWire; $this->addHookBefore('ProcessPageEdit::buildForm', function (HookEvent $event) { $page = $event->object->getPage(); // new pages GET a 'new' query string/parameter, i.e. &new=1 // we check that $new = (int) $this->wire('input')->get('new'); if ($new && $page->template == 'book_sales') { $config = $this->wire->config; $url = $config->urls->templates; $config->scripts->add($url . "scripts/admin/admin.js"); } }); There's probably other more elegant ways to detect if a page is new but I cannot remember any of the top of my head at the moment.

Hi @kongondo, This is so cool. Thank you VERY much. It works perfectly. I'm wondering what the best way to load it under certain conditions would be. Right now, it places the cursor in the field whenever I go into edit mode, not just on the initial edit that comes right after adding a record. In my ready.php file I have this: $this->addHookBefore('AdminTheme::getExtraMarkup', function (HookEvent $event) { $config = $this->wire->config; $url = $config->urls->templates; $config->scripts->add($url . "scripts/admin.js"); }); $pages->addHook('added', function(HookEvent $event) { $page = $event->arguments(0); if ( $page->template == 'book_sales' ) { .... etc.... So, in the code that comes after the addHook('added') it only operates in the subsequent edit screen, but not when I go back to a record and click on edit. (At least I don't think so.) Is there a way to only initiate the cursor focus during that initial edit? Thank you again! Peter

Hey y'all! It's been a while since I jumped into the forums, so I'm hoping this is in the right place. So — I'm using Pro Cache to deliver cached versions of my site pages. It's the absolute best. But I recently added a dark-mode to my site, which first checks for a cookie to set a global <body> class based on the visitor's established preference, and falls back to the user's system-level color scheme with the media query: @media (prefers-color-scheme: dark) The problem is, cached pages seem to adopt the mode of the user who first visited the page and triggered the cache? I'm still messing around with it, but if anyone has ideas for how to both cache pages, and deliver each user content in the mode they prefer let me know. Thanks so much!

Thanks so much horst! That makes a ton of sense — I'll get into it and post when I've got a solve.

Thank you, @kongondo! It's a field called "list_price." It's a field of type float. It's in a template called "book_sales." See my ready.php code at the beginning of the thread for what I'm doing with adding values to fields, on a new add record routine. Thanks again for your help! Peter

I do such things with a small javascript or AJAX call on doc ready or similar. Or sometimes in the head section of the HTML page, depending what is needed. So you may add a small JS snippet directly after the opening body tag that checks the user preferences and according the result, add or remove a css class from/to body. (?)

@Clarity - I think you'll need to write your own JS for that scenario. That said, I am a bit confused why you need the two separate fields. Any reason the user can't just select one or many languages from the ASM version? I am sure there is a good reason, I just can't see it :)

@pwfans 1) You can parse out what you need like this: 2) Same as above really, although it will be a little less efficient. 3) It returns true / false if a page is prohibited for the current user.

Hello, In the backend, you can go to Modules > Site, there is a "Clear Compiled Files" button at the bottom of the page. Or you could try by directly removing the content inside site/assets/cache/ (or perhaps just inside site/assets/cache/FileCompiler/). Edit: there is also https://processwire.com/modules/process-cache-control/.

@AndZyk, I don't think this is entirely accurate. Maybe things have changed since I last read the thread but below is the quote from @ryan with respect to his thoughts on a layout / page builder: https://processwire.com/talk/topic/25129-weekly-update-–-12-february-2021/ So, it is not a matter of lack of interest but more about 'lack of expertise', albeit with willingness to support it on the PHP (ProcessWire) side ?. By the way, I could have offered to take lead on this but until a certain module is released (getting very close now! ?), I don't have much time for anything else ?.

This week I've been focusing on the dev branch and some low level code optimization, especially as it relates to the PW boot process, translating URLs to pages and identifying the page, language, URL segments, page numbers, etc. from the request URL. I'm breaking down much of the logic (currently in the ProcessPageView module) into more focused parts that can become part of PW's $pages API, increasing reusability of related code. (Don't worry, this won't affect any existing hooks). At the same time, I'm looking for opportunities for optimization and performance improvement, and have already found a few. For instance, the LanguageSupportPageNames module introduces overhead into some page finding operations and there's good improvement potential there, among others. I'm pretty much still in the middle of it all though, so am going to hold off on committing any of this to the dev branch until it's further along. But since we've got a quiet commit log this week, I just wanted to keep you up-to-date. Hopefully some of these fairly significant updates will be stable enough to commit to the dev branch next week. By the way, these updates will also enable the SessionAllow module (from last week) to be configurable by page, as PW will now identify the requested page before starting the session. More soon. Have a great weekend!

There's a couple things that made me think this part of the core could be better (and nothing related to middleware). First is that PW didn't originally support multi-language URLs, and so the LanguageSupportPageNames module was built to hook in and add support for that. There are benefits (performance, simplicity, etc.) to having that logic lower-level in the core and part of the same logic that identifies non-multi-language URLs. So that's something I've been interested in for a long time, but it was always more than I wanted to get into. The other thing is that I was working on that SessionAllow module and found it was a real drawback not to be able to know what Page was requested before deciding on things like whether to allow a session or not. Granted, we can still know the request URL before we know the Page, but it just seemed a lot more flexible for the core to know the requested Page much earlier in the boot process. That way, we can do things like configure whether sessions are allowed on a per-template basis, where such an option seems to make the most sense. Another example is 404 pages—maybe we don't need a session on a 404 page. But without knowing whether the URL will resolve to a Page or not, we didn't have that choice. Following these updates, we will. Lastly, I just like to revisit the core logic for things and improve it when/where possible, which helps to keep it fresh on the mind. But I don't like to get into replacing this kind of major core code when it'll soon be merged to the master, as this is the kind of stuff that needs more testing over a longer period of time. So with a comfortably stable master version available right now, it seemed like a good time to work on this.

Ooh, thank you for this pointer, @wbmnfktr. I’ve done just what you suggested!

Just a little follow-up to this topic, my new ProcessWire tutorial site processwire.dev (see the discussion thread) is built as a static site, using 11ty. It was super fun to build, and easy to get that coveted 100/100 lighthouse score with ? I see the following advantages of using a static site generator for this project: The big one (at least for me): All the content is under version control! (see the source code here). Having the content stored as markdown files also means I could use my regular code editor (VS Code) to seamlessly switch between templating / developent and writing (though of course that only applies to developers). Being able to search all files (i.e. the entire site) was also super useful for correcting common typos and stuff like that. The site fits comfortably in the free tier on Netlify, so hosting is completely free for me (except the .dev domain, of course). But since it's a static site there's zero vender lock-in, I could switch to Vercel or any regular webhosting package in a few minutes. Having a build step on a linux environment with NodeJS enables all sorts of fun stuff that wouldn't be feasible to do on the fly, especially on shared webhosting packages with a limited environment. For instance, I wrote a fun little script that generates preview images using a special template and a headless browser that takes screenshots programmatically using Puppeteer. See the generated example image below. Not super necessary, but fun ? I published the script on NPM (generate-preview-images) if you want to give it a try, though it's a super alpha version and not really documented yet. So yeah, I think static site generators are going places. 11ty in particular is pretty cool, though it's kind of barebones at the moment and still missing some features that you already have in ProcessWire.

Sorry for the delay all - I'm up to date now and will look at seeing if someone can give me a hand on the approval side so the next batch that come in don't take so long.

https://www.php.net/manual/en/info.configuration.php#ini.max-input-vars As you may already know, it can be changed in your hosting provider account. Possible solution: https://modules.processwire.com/modules/process-admin-actions/ FTP Files to Page Add files/images from a folder to a selected page. Something that could be useful - to put in the admin.php file (source: Adrian): $this->addHookBefore('InputfieldFile::render', function($event) { $inputfield = $event->object; if($field = $inputfield->hasField) { if(!is_object($field)) return; $p = $event->object->hasPage; $inputfield->label .= ' (' . $p->{$field->name}->count() . ')'; } });

Hey again, following @bernhard's suggestion of making stuff a little more readable, and after some refactoring, here's the result: In templates/admin.php // user custom theme warning in backend $this->addHookAfter('Process::execute', function($event) { // make stuff more readable $user = $this->wire('user'); // early exit if user is not logged in if(!$user->isLoggedin()) return; // array of themes that will be excluded $x = array('', 'default'); // early exit if current user theme is in excluded array if(in_array($user->custom_theme->value, $x)) return; // set up message $u = $user->name; $t = $user->custom_theme->title; // set up path for profile link $p = $this->wire('config')->urls->admin . "profile"; // send message $this->wire->warning("Frontend wird für Benutzer \"$u\" aktuell mit dem Theme \"$t\" ausgegeben. <small>Einstellung \"Frontend Theme\"im <a href=\"$p\">Benutzer-Profil</a></small>", Notice::allowMarkup); }); Also added an array of values to be excluded to make this more reusable in the future. Looking neat, working as expected. Thanks again and servus from Bavaria!