Leaderboard

ProcessWire 3.0.167 is the newest version on the dev branch and contains the updates mentioned last week, as well as the following: Improvements and optimizations to several database fulltext index-based text-searching operators (such as *=, ~=, *+=, ~+=) so that they can better match words too short to index, as well as many stopwords. (code changes) New $input->queryStringClean() method is like the existing $input->queryString() method except that it enables you to get a cleaned up version according to rules you specify in an $options argument. I added this method primarily because it’s something I need in the core for some planned updates. But it’s in the public API because I thought it might be useful for some other cases as well. Kind of technical, but some minor improvements to the $sanitizer array methods were made so that they can now support associative arrays with a ‘keySanitizer’ option that lets you specify which sanitizer method to clean up array indexes/keys. The $sanitizer->validateFile() method was rewritten and improved plus new ‘dryrun’ and ‘getArray’ options were added. The core file and image fields have been updated with the ability to require (rather than just utilize) a FileValidatorModule for certain file upload extensions. This was motivated by SVG files being increasingly problematic (or at least my understanding of them) because they can contain the kind of bad stuff that regular markup can (scripts, loading external assets, etc.). But since SVG files are used by many just like the bitmap image formats (JPG, GIF, PNG, etc.) exploits can spread quite easily and unknowingly. I’m not aware of that ever occurring in a ProcessWire site, but it’s one of those things that strikes me as being an inevitable problem for any website (on any software) that has regular SVG uploads. ProcessWire doesn’t allow SVG file uploads by default, but you can manually add “SVG” to your allowed upload extensions for any file/image field… and from what I understand now, a lot of people are doing this—using SVG files not just during development, but as an image format that their clients upload too. The usual protections of having a trusted user admin environment don’t help much here. That’s because what matters is not whether the uploading user is trusted or not, but whether the source of the SVG is trusted. And that’s something we have no control over. It seems apparent the core could provide some extra help and guidance in this area. So ProcessWire now requires you install the FileValidatorSvgSanitizer module if you want to have SVG uploads, OR you can check a box in the file/image field settings to whitelist the extension (acknowledging you understand the risks). Now you could manually add HTML or JS as allowed upload extensions to a files field as well— and if you are rendering the resulting HTML markup or JS directly in the code of your website, then the same risks would be present as with SVG. But the risks seem obvious for doing this with HTML or JS files. Plus, why would someone do that with HTML or JS files unless for some very specific development purpose? I think it’s unlikely any of us are running websites where clients might be downloading HTML or JS files from other sources and uploading them into the website. And even further unlikely that we’d written the site’s code to include the contents of those files among the site's markup. Whereas, this is essentially what happens with SVG files, from what I understand. As I’ve come to learn this week, it’s even quite common to do this (maybe I’m late to the party). Given the above, this week I rebuilt the existing FileValidatorSvgSanitizer module from the ground up, so that it now uses a better/newer SVG sanitization library found by Adrian. I’d suggest installing the module if you are supporting SVG uploads in your site. It seems to do a nice job of cleaning the harmful stuff out of SVG files. I’m not aware of anything it can miss, but I’d still advise some caution with SVG file uploads even if you have the module installed. If you currently allow SVG file uploads but don’t really need them, just remove SVG as an upload option, as that’s still the safest bet. That’s essentially what the current dev branch version does: if you’ve added SVG as an allowed upload extension, it’ll disable it until you decide if you need it; and if you do, then install the sanitizer module or whitelist the extension. I know not everyone is going to like that, but it seems like it’s the right and safe thing to do; as well as a good strategy going forward for any other file formats with similar concerns. When our next master version arrives, it’ll be in the upgrade instructions as well. The core has been updated so that it can support the same means for any other file formats we come across in the future that might be problematic in similar ways. That’s everything I can remember that’s new to 3.0.167. Thanks for reading and have a great weekend!

https://blog.gskinner.com/archives/2020/07/introducing-flokk-a-desktop-app-built-with-flutter.html https://blog.gskinner.com/archives/2020/09/flokk---how-we-built-a-desktop-app-using-flutter.html "Rive takes advantage of cutting-edge technologies such as Flutter and WebAssembly to create native desktop and web apps." https://rive.app "Bring Your Apps and Games to Life with Real-Time Animation" https://blog.rive.app/rives-web-runtime/ "Learn how Rive's web runtime works under the hood and how to embed a Rive animation in a web page."

Just a searchable note here in case s.o. else runs into the same problem ? You suddenly cannot log in any more with TFA/2FA (Two Factor Authentification)? After the step two (inserting the 2FA code) the server responds with an ERROR 500? There is no corresponding entry in the server logs? Check this: Open your site files with FTP, go to /site/assets/logs/ and look into the file exceptions.txt If you find an entry there, like so: ... Invalid base32 string (in /site/modules/TfaTotp/TwoFactorAuth/lib/TwoFactorAuth.php line 190) This indicates that the 2FA code got messed up. Two ways to fix this: Via FTP, move TfaTotp out of /modules/ Login and go to User/Profile While the login session is active, via FTP, move TfaTotp back to /modules/ Disable TfaTotp - and then save your profile page Re-enable TfaTotp - and then save your profile page again. …or (tip from @adrianj): Create a new superuser via the API and login via that and then disable and re-enable 2FA for the affected user via Access > Users. --- More in depth info from @ryan at Github: 2FA login error 500.

@picarica - you can also simply place the hook code in your sites ready.php file (https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#new-core-files-for-site-hooks). There is no need to a create a dedicated module for this, although also no problem if you prefer this approach.

Glad you got it sorted! ProcessWire modules are written in PHP, and PHP code always requires the "<?php" start tag -- otherwise it's interpreted as plain text. In case you're embedding PHP within HTML you'll also need the closing tag "?>" (<h1><?php echo $page->title ?></h1>), but if the entire file is in PHP (as module files usually are) it's best to leave that one out.

Just checking, but you didn't forget to add <?php at the top of your module file, did you? ? Note: I've moved this topic to the "Module/Plugin Development" forum area. The "Modules/Plugins" area is only intended for support threads of finished modules.

First of all, what you're saying here seems a bit off: you mentioned using selector field, but judging from the value it looks like you might actually be using a Page reference field — is that correct, or is the field type really Selector? Anyway, if it is a Page reference field, then $pages->get() is obsolete here: the stored value is already a Page. What you're doing here is taking that selected page, reading the value of the "title" field from it, and then asking ProcessWire to give you that same page again with $pages->get(), even though $sp->parent = $sp->some_field is all you really need to do. And even if you do have to get the parent with $pages-get(), you shouldn't match "title" to "name"; either match "name" to "name", or better yet use "id" (which is always unique across the system) ? Also note that whenever you use $pages->get(), it will return any matching Page, including those that have been unpublished or trashed. In most cases you should use $pages->findOne() instead, or alternatively add some checks to confirm that this is indeed a valid (and non-trashed) page. -- As for the error you're seeing, I think the biggest issue is that you're not sanitizing the selector value. Whenever you use a "dirty" value (including values stored in ProcessWire fields) in selectors, you should make sure it's valid. $sanitizer->selectorValue($new_parent) is the "generic" way to do this, but in this case you're using the value as a page name, so you should rather use $sanitizer->pageName($new_parent). Note that if at this point $new_parent contains encoded entities, this could mean that you're using this code snippet in a context where output formatting is enabled. You can always get the "raw", unformatted value from a field with $page->getUnformatted(): $new_parent = $sp->some_field->getUnformatted('title'). -- Finally, depending on the use case you should know that this script could result in some errors or notices since you're not checking if $sp->some_field contains a value before you try to use it as an object. It's possible that you intentionally omitted some parts when posting the code snippet here, but if not, then you might want to add something like "if (!$sp->some_field) continue;" to the beginning of your foreach loop to skip empty values. -- So, long story short: it's possible that the whole $pages->get() operation is unnecessary — but if that's not the case, then the issue is likely related to missing sanitization (and possibly output formatting) ?

Mobile first is a front-end concept. It really doesn't matter which back-end CMS you use to serve data. Obviously ProcessWire is the best solution. ? Personally, I prefer the blank profile to start most projects. The responsive approach is in the name, mobile first. Start with whichever CSS you prefer (Bootstrap, etc.) and design from mobile upward. I find it easier to sketch the mobile interface on a whiteboard, then sketch at the additional breakpoints, noting the changes for each. A clear map up front will save you many headaches later. It's all personal preference as to which CSS framework , profile, javascript library, etc. that you want to use.

Version Update 2.0.0 The current version has got some improvements, bug fixes and new features. Many thanks to @Autofahrn, who created the idea and code base for copying multiple items at once! Amazing feature! Also, there is now the option to disable the copy and paste dialogs. Last but not least, thanks to @joshua, for suggesting a bug-fix in context with normal repeater fields. All information and downloads are updated in the first post.

It's possible to hide the page tree, and redirect users on login to some other page. Lister Pro allows you to create your own pages that show data in custom table layout that are editable, and it's not too hard to create your own admin dashboard module with links to several listers. Here's a thread with some discussion of both:

Not sure about a table layout (of course, you could build it yourself!). But you can change the default process you see after logging in easily. In the page tree, find the Admin page and go to edit. There you'll find a Process option. Switch this from the default (ProcessPageList) to ProcessPageLister to show the page lister by default. If you're using ProLister, the Process might have a different name, not sure right now. After saving, logging in or clicking on the logo in the admin bar should take you straight to the page lister.

I always use the Markup Regions, until now I haven't needed more complicated system in my projects. Roughly this is my standard configuration: _main.php <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Title</title> <link rel="stylesheet" href="..3rd_party_styles_1.css"> <link rel="stylesheet" href="..3rd_party_styles_2.css"> <pw-region id="styles_area"></pw-region><!--#styles_area--> <link rel="stylesheet" href="..my_main_style.css"> <pw-region id="head_area"></pw-region><!--#head_area--> </head> <body> <header> Header Content Here (regularly a file included) </header> <div class="container"> <pw-region id="content_area"></pw-region><!--#content_area--> </div> <footer> Footer Content Here (regularly a file included) </footer> <pw-region id="append_area"></pw-region><!--#append_area--> <script src="..3rd_party_scripts_1.js"></script> <script src="..3rd_party_scripts_2.js"></script> <pw-region id="scripts_area"></pw-region><!--#scripts_area--> <script src="..my_main_scripts.js"></script> </body> </html> template_file.php <?php namespace ProcessWire; $vars_or_arrays = "fill_some_vars_or_arrays_here"; ?> <pw-region id="styles_area"> <link rel="stylesheet" href="..3rd_party_styles_3.css"> <style> body { background: #F2F2F2 !important; } h2 { text-transform: uppercase !important; } .classA { background: red; } .classB { font-size: 2rem; } </style> </pw-region> <pw-region id="head_area"> <link rel="dns-prefetch" href="//example.com"> <link rel="preconnect" href="//example.com"> <link rel="prefetch" href="image.png"> </pw-region> <pw-region id="content_area"> Here render your page content from $page or using $pages, $vars_or_arrays, etc. </pw-region> <pw-region id="append_area"> <div class="modal"> <a href="#">close</a> <div class="modal_body"> Content of modal window </div> </div> </pw-region> <pw-region id="scripts_area"> <script src="..3rd_party_scripts_3.js"></script> <script> window.onload = function(event) { alert('Hello World!'); }; </script> </pw-region> Use the regions from the main layout as needed on each page, to add a modal window, run a javascript, add styles, etc. I always use <pw-region> because this element is removed from the final markup if it's not used in the template file.

UPDATE 2020-02-01 SnipWire is now available via ProcessWire's module directory! https://modules.processwire.com/modules/snip-wire/

If you want pages where a field is not empty you don't need to deal with the fieldsets/templates at all. Just: $count = $pages->count("title!='', has_parent!=2");

Hi @vwatson - I have coded up a new action for the AdminActions module called: Ftp Files To Page If gives you a nice and easy GUI for choosing: the folder where you have FTP'd the files to (you can choose from any folder under /site/assets/cache/AdminActions/ the field you want the files added to the page you want the files added to whether you want the action to automatically delete the FTP folder and all files once the action is complete Hopefully once you have the AdminActions module installed, you'll find this action very easy to use. Let me know if you have any problems or any thoughts for how it might be improved.

This is a great module, appears to work great and is exactly what I needed. I just tripped over something, not necessarily an issue with this specific module, but I'm getting this Notice: Undefined index: HTTP_USER_AGENT in <CUT>/modules/LoginPersist/LoginPersist.module on line 508 When I bootstrap Processwire for use in a backend cron job. It seems like in init() there should be some check to see if Processwire is running in the context of a web site. Not sure the best way to fix it, and I admit most users probably don't bootstrap PW for use in a cron. It's an edge case for sure. Here's what I did: public function init() { if (php_sapi_name() != 'cli') { $this->set('doLoginHook', true); $this->session->addHookAfter('login', $this, 'loggedIn'); $this->session->addHookAfter('logout', $this, 'loggedOut'); $this->_pruneLogins(); $this->attemptLogin(); } } Detecting if PHP is being used via CLI with php_sapi_name() is based off an answer on stackoverflow at http://stackoverflow.com/questions/343557/how-to-distinguish-command-line-and-web-server-invocation Great work on this module!