Leaderboard

Hi all, After seing the website featured in the latest Processwire weekly (thank you @teppo !!), I thought it could be nice to post some details here. I have actually made a few websites using Processwire, but it's the first time I'm posting one in the showcase. Backstory I made a first version of this website in end-2017 when I was starting to use Processwire after a friend recommended it to me. I was in charge of the front/back-end, and helped a bit on the design. At the time there was a slideshow of featured projects as the homepage, the project page was the only template with content blocks, and the information pages (about / contact) were specific templates. About the content blocks, I didn't know about the Repeater Matrix module so I kinda implemented my own, having a simple Repeater with a Select Options field defining which fields to display. All in all the website was pretty nice when it came out and I learned a lot in the process, but this year the agency wanted an update to fit their new narrative, so it was a nice opportunity to make some due changes. Back-end Modules I used : Repeater Matrix ProCache Seo Maestro Email Obfuscation Inputfield Chosen Select Color Minimal Fieldset Page Field Edit Links Runtime Only Tracy Debugger (of course!) This new version is all about content flexibility. The information pages now all share the same template, allowing them to create as many as they want. Each visible templates ("home" / "page" / "project") contains a Repeater Matrix field for content blocks, with 15 different types to choose from and options to add variations in the layout. Front-end To answer to the PW Weekly : it is indeed all custom-made except for three external libraries : plyrjs, flickity and lottiejs. I really like sveltejs but I still have to figure out how I could mix it with PW in my process. The animation in the introduction is described by a .json file and displayed as a SVG using Lottie. The transition colors can be changed. The menu order is defined by the manual sorting in the admin... I don't really know what to say here since it's all hand-made, let me know if you have any question! Screenshots Thanks !

Looks like someone (apparently a single user) has been going around forums and vulnerability databases posting about a ProcessWire "local file inclusion" vulnerability, claiming that in a specific old version of ProcessWire (2.4.0) simply passing "download" GET attribute to index.php is enough to download any local file on the system, including files that may be outside the ProcessWire installation path. This is not a real ProcessWire vulnerability — this kind of argument has never existed in any version of the system. Simply put the report is either fake, mistake, or there could be some custom-built vulnerable piece of code (or other vulnerable software) on the host resulting in this behaviour. We take such claims seriously, however unlikely they may seem, so just to make sure I've just checked parts of the codebase in both 2.4.0 (where this is supposedly occurring) as well as various later versions, and there's zero evidence to back this claim up. I've also manually tested this on various setups, including a brand new 2.4.0 installation, to no avail. (Note: I wouldn't post about this here unless the original claim was relatively widely spread. Just felt it made sense to clear things up.) --- That being said: as one builds sites using ProcessWire (just like with any other system) they need to be careful not to introduce vulnerabilities of their own. ProcessWire is armed with brilliant tools for preventing common vulnerabilities — the selector engine helps avoid various SQL issues, Sanitizer has many tools for cleaning up dirty data, SessionCSRF makes implementing proper CSRF protection downright trivial, etc. — but it can't protect you automatically from every mistake ? More security tips: https://processwire.com/docs/security/.

I've just tried the ForgotPassword module and I wonder why the password reset process can't be smoother for the user. Especially I don't understand why there must be this "verification code" that has to be transfered manually to the password reset form. Why couldn't it be integrated directly into the URL? It shouldn't make any difference as to security since both URL and verification code are transfered through the same channel (e-mail) anyway. I'm planning to migrate my current non-PW site to PW, and since I don't have my user's clear-text passwords, I can't migrate them, too. That means I'll have to force all my users through the password reset procedure, and I really wouldn't like to make this more tedious than necessary. Another feature request: I'd like to confirm the additional field values in the first step (before sending the e-mail) rather than in the last one. I think this would not only improve user experience, but it would also allow to use e-mail rather than user name for identification even if there are duplicate e-mail adresses, since you could use the confirm value field for disambiguation.

This week I’ve continued work on the new modules directory and today have launched an updated version of it on the site. This is just an initial version of it, as there’s still plenty to do. But the basics are up and running if you’d like to take a look at https://processwire.com/modules/ The new modules site is using ProcessWire’s multi-instance support to boot a copy of modules.processwire.com and to pull and manipulate data from it. In order to prevent content duplication, I’ve setup most of the pages at modules.processwire.com to redirect to their equivalent versions in processwire.com/modules/. There’s not much new here in terms of data that is being displayed, though it is also different in several ways. For starters, it finally has the look-and-feel of the main site. The modules homepage takes a different approach and lists 3 modules each in these different sections: Recently added modules Recent updated modules Popular modules Modules recently liked by users Modules in the “recently updated modules” section are those that have had recent commits at GitHub. The “popular modules” section randomly selects 3 modules that have a certain threshold of “likes” quantity and date of user activity, combined with being updated within the last 6 months. Or you can view them all (no random selection) at the dedicated popular modules page ... this section will grow as users interact with it. The “modules recently liked by users” section looks for modules that have had the “like” button clicked on recently, and puts them into this bucket. Like the “popular modules” section, this one will grow and increase in relevance once there is more user interaction with the new modules directory. There’s also a new feature on this modules site where you can maintain a “cart” (of sorts) that keeps track of which modules you have liked. In addition, the new modules site estimates how much usage each module has by analyzing request data from the ProcessWire modules web service. This is something the old modules site does not do. It uses this data solely for providing a unique sortable view of modules. Because this data hasn’t been tracked for long, it’ll increase in relevance over time. One area that I want to build out quite a bit more is the module “authors” section. Since the new modules site will be using authenticated login sessions with LoginRegisterPro, we’ll be able to maintain a lot more “profile” info for module authors (full name, bio, photo, website, anything else?) There are a few things still in development, so you won’t see them just yet: Edit module ability (it directs you to the old modules site for that) Add module ability (also directs you to the old modules site) Informational pages (how to install modules, etc.) More to come here, but that’s where it is now. Nothing all that exciting I know, but still an improvement hopefully. If you find anything that isn’t working, or have other feedback or suggestions, please let me know. Thanks for reading and have a great weekend!

New release — 0.18. This version adds Tracy panel for Wireframe: Obviously the panel will only show up if both Wireframe and Tracy are installed. Currently it displays some content I thought could be useful while developing, but I'm open for suggestions. Tracy doesn't really enforce any rules here, so in the future the panel could also provide interactive developer tools or something along those lines... just not sure yet what would be useful ? Thanks to @adrian for adding support for custom panels!

@picarica Could you please use a more civilized language in here? I'm no PW forum admin, but I'm pretty sure the F*** word is not welcome here. If you have a problem with that particular module, you should post your question in the respective support forum instead:

Yes, there is a review process. Normally, module authors would indicate this in their support thread, something along the lines of 'the module has been submitted to the modules directory and is awaiting review. The module is hosted on GitHub....link' ?.

Ok, DOMDocument drives me crazy. It does not properly work without a surrounding container, so I've changed the loadHTML as follows: $dom->loadHTML('<div>'.mb_convert_encoding($str, 'HTML-ENTITIES', 'UTF-8').'</div>', LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD); This, of course, needs to be cleaned up at the end, which I quick&dirty done like this: // strlen('<div>') = 5 $markup = substr(trim($dom->saveHTML($dom)), 5, -6); The trim is required, since the return of saveHTML ends with a newline and I don't want to hard-encode this using -7 for the length parameter of substr, sigh. Edit: changed <dummycontainer> to <div> to make loadHTML happy.

<?php /** * getFieldsetOf * * for ProcessWire * * gets fields inside a fieldset of pages or templates * choose to retrieve values * * @param Template|Page $context the page or template * @param String $fieldsetName name of the fieldset * @param bool|boolean $collectValues want to collect values of the pages fieldset? * @param string $fieldsetCloseIdentifier default: '_END' * @return FieldsArray|WireData returns FieldsArray or if data wanted, WireData */ function getFieldsetOf($context, String $fieldsetName, $collectValues = false, $fieldsetCloseIdentifier = '_END') { if ($collectValues === true && $context instanceof Page) { $collectedItems = new WireData(); } else if($context instanceof Template) { $collectValues = false; $collectedItems = new FieldsArray(); } else { throw new WireException("getPageFieldset: first argument must be of type Page or Template", 1); } if (!$context->fieldgroup->get($fieldsetName . $fieldsetCloseIdentifier)) return NULL; $collecting = false; foreach ($context->fieldgroup as $field) { if ($field->name == $fieldsetName) { $collecting = true; continue; } if ($field->name == $fieldsetName . $fieldsetCloseIdentifier) { break; } if ($collecting) { if ($collectValues) { $collectedItems->set($field->name, $context->get($field->name)); } else { $collectedItems->add($field); } } } return $collectedItems; } Some extension of the above code - works with templates and pages. If thrown at pages you may choose to retrieve the values inside the fieldset as a WireData object. edit: @dragan (below) thanks for the hint! Just removed it.