Leaderboard

https://www.maletschek.at It's online now for quite a time and my biggest PW-project so far. It has loads of content (sitemap) and the editors are loving how easy it is to manage - client quote: "it's a quantum leap forward" edit: screencast added here: https://processwire.com/talk/topic/10006-maletschek-nautics-boat-center-at-neusiedlersee-in-austria/?p=95531 Highlights shortcut edit-links almost everywhere on frontend with a single line of code in the template file (planning to release a module for this one day i find the time... or if anyone is interested in doing this i can share the code i have so far) and showing what part of the site is going to be edited on mouse hover point of contact for every section - option to inherit it to the whole sub-branch of the tree for example "jakob" is point of contact for boats and he will by default also be POC for every single boat posted in this section. if there is a different POC for one single page in this branch (eg /boats/small-boats/) that's also possible by checking the checkbox - so all boats on sub-pages (/boats/small-boats/boat1) will again have jakob as POC Caching with custom Cache Reset Module (necessary due to the previous point in the list) at least for me that's a highlight because that was the first time i needed to hook something... https://processwire.com/talk/topic/8997-clear-cache-for-all-children/ widget system with complete control of where to display the widget: in this example the "point of contact" widget is shown an all pages ( site "/" - "show" - "also on subpages" ) except section "blog" ( site "blog" - "dont show" - "also on subpages" ) yumpu online catalog textformatter module like on this page: https://www.maletschek.at/shop/bootszubehor/pfeiffer/ see forum thread here: https://processwire.com/talk/topic/9888-textformatter-yumpu-embed/ i hope you like it and i'm looking forward to hearing your feedback and of course thank you all for your help! ps: sorry, there's only a german version of the website

here you go: it's very simple, yet extremely comfortable for clients. you just need one simple javascript function: function editLink($pageid) { if(wire('pages')->get($pageid)->editable()) { // add page if action == add // check permission first! ob_start(); $editid = "editlink_" . uniqid(); ?> <div style="position: relative;" class="editlink" id="<?= $editid ?>"> <div style="position: absolute; right: 0; top: 0; z-index: 100;" class="uk-text-right"> <a href="/admin/page/edit/?id=<?= $pageid ?>&modal=0" target="_blank" class="uk-button uk-button-primary editmodal" style="color: white;"> <i class="uk-icon-edit"></i> edit </a> <?php // next floating button here ?> </div> </div> <script type="text/javascript"> $(document).ready(function() { $("#<?= $editid ?>").parent().addClass("editlinkparent"); // paddings must be adjusted when window is resized $(window).on("load resize", function () { // remove top and right margin var paddingright = $("#<?= $editid ?>").parent().css("padding-right"); var paddingtop = $("#<?= $editid ?>").parent().css("padding-top"); //$("#<?= $editid ?>:first-child").css("border", "1px solid blue"); $("#<?= $editid ?>:first-child").css("right", "-" + paddingright); $("#<?= $editid ?>:first-child").css("top", "-" + paddingtop); }); // colorbox /*$(".editmodal").colorbox({ iframe:true, width:"90%", height:"90%", onClosed: function() { location.reload(); }, });*/ }); </script> <?php return ob_get_clean(); } else return false; } and little CSS: // edit link .editlink {display: none;} .editlinkparent:hover {outline: 3px solid #ddd;} .editlinkparent:hover > .editlink {display: block;} note that i'm using markup for UIKIT css framework. what it does: let's say you have a blog-template showing all the children as postings. all you need to do when you want them to be editable on mousehover would be this: <?= editlink($page->id); ?> <section class="uk-grid uk-margin-left uk-margin-right uk-margin-large-top"> <div class="uk-width-large-3-4"> [...] <?php foreach($posts as $post): ?> <div class="uk-grid"> [...] <div class="uk-width-medium-3-4"> <?= editlink($post->id); ?> <h4><a href="<?= $post->url ?>"><?= $post->get('headline|title') ?></a></h4> [...] </div> </div> <hr> <?php endforeach; ?> the result is something like that: note that it needs only 2 lines of code! you can easily add this to any existing website in minutes... in FREDI you have to define your editable fields. that can be an advantage, but i prefer to only rely on the ID of the page (or the posting or the widget...) and have the user redirected to the right page in the backend. as you can see in the commented section of the function i also had this working with a colorbox and using modal=1, but it's more foolproof having it open in a new tab. using only the ID has the advantage, that if something changes with my field settings i don't have to change anything on frontend. how does it work? it injects some jquery javascript inline (it's only for logged in users so that won't affect your "public" markup of the page!) add HTML for the edit-button with edit-link add javascriptadd "editlinkparent" to parent DOM element this makes it possible to show the border around the affected content on mouse hover remove spacing so that the edit-button is on the very topright position of the highlighted div that's all again: i would love to pack that into a module so that it gets reuseable across other CSS frameworks with different markup and you don't have to care about adding the function and the css, but i don't know when i can find time for that. if anyone wants to try - all the info is above and i'm always willing to help

it was, but made some problems and other parts were more important. you are right, i think a search would totally make sense and maybe we will ad it one day. thanks for the input! thank you! i changed it to SVG but it's not better. i think that's the fault of the logo itself because in my editor it also does not look very nice? do you see any difference? thank you i'm using pagetable instead of repeaters now because the UI is much clearer and they do not waste so much space. did a little screencast for some more insights - also on the edit-shortcut-links

Hi guys, Been "kicking the tyres" on some UI tweaks to the PW image fields and modal windows. Many of these are in-progress designs and to be straight, none of the designs are entirely resolved. At this stage, I thought I'd throw them up (poor choice of words!) and maybe someone can take them further or offer some fresh eyes. I'm not a developer so making these a reality is impossible for me. They're flat designs. Why? PW is an amazing experience for editors. It's just so elegant and beautifully realised (especially with Reno Theme) that often, my training sessions with clients are very brief. One area which does cause friction though has always been concerned images, image fields and image modals. Especially with the latest image modules, I think a lot of inconsistency has crept into the UI. Hopefully these designs can help improve things a bit. A tiny part of the design work is influenced by a similar idea I had for MODX but which never progressed. 1A. Current Image Modal Editor has clicked 'Add image' icon in CK editor. Issues: I believe the Upload Image button can be better placed. It's not clear to users that they have a choice of two actions (Select an Image OR Upload one) To help solve this, I thought we could: Place available images under a Choose tab Create another tab titled Upload Rename modal to just Image (from Select Image) tweak slightly the Images on page path to be less prominent The following image illustrates the result. Clicking the Upload tab would result in: In the above image I've created toggle-able accordians for Drag and Drop and Manual upload. This follows closely the UI an editor is presented with when choosing Insert Link within CK Editor. IE Link to URL, Select Page and Select File and the extra Attributes tab. So overall, it's more consistent. 1B. Alternative to above - combined Select and Drag/Drop I thought it might be worth exploring what modal would look like with no tabs and a single UI for both Selecting an image and Drag/Dropping. 1C. The Image field I then moved onto looking at the Image field in PW. So currently it looks like this (below) for a simple image field called Image Gallery. So although the current Image field works great, I wondered if there was a way to simplify it by Making the drag/drop more visual and obvious Moving the Choose Files button and removing the No file chosen text and the file types allowed Here's the result. Admittedly, this treatment adds more height to the overall field. Here's how it looks when images are uploading (slightly smaller plus icon and "drag and drop..." text. To be honest, I can't recall what other changes I made there! And here's a proposed layout for when there are multiple images. This includes image titles grid layout mouse-over for edit and delete options/buttons 2. Cropping Next thing I looked at was cropping. Native cropping introduced recently is one of my clients favourite features and time-savers and I wondered if things could be improved a little. So heres the current layout (this may have changed further recently) And here's my proposal. Changes are: Width, height and X and Y fields are moved below the image Apply and Cancel placed bottom right of the image Save Crop should be titled Apply. I think that's less confusing as in some instances there are so many Save options Save and Replace should be greyed out further In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side). Forgive the croptions label (Crop + Options pun - I was tired!) The benfit of this I think is that Modules such as CoppableImage and native Crop would be unified in a single UI. Presets (on right) could be a few out-of-the-box presets which come natively. Croptions houses any crop ratios defined in image modules. if CopppableImage isn't installed, they just don't display.. That's it. I wish I'd more time to work on this but it's at the stage where it's ready for some initial thoughts. Hope you guys like.

Thanks for taking the time to explore this stuff Peter. I like what you've done, particularly the tabs in the modal, for consistency with the Link dialog. I prefer icon/text of your drop zone to the one we've got now. Though I'd want the drop zone to be consistent whether in the editor or in the modal. There's also the consideration of what image field you'll be uploading to. If you've got multiple image fields on the page, you are going to have multiple fields to which you can upload to, so a single large dedicated drop zone in the modal would not work. However, I think taking your drop zone that appears in the page editor, and using the same exact thing in the modal would do a nice job of having an improved drop zone, while still allowing for the possibility that there may be multiple drop targets. I like what you've got going on the Image Gallery screenshot in grid mode, but it does blur the line between list mode and grid mode. Not saying that's undesirable, but that it's different from what was intended: for grid mode is to be the opposite of list mode, and keep it as minimal as possible with basically nothing but the images themselves. Whereas list mode is meant to spill all the beans. Behind the scenes, these two modes use the same markup as a matter of efficiency, just styled differently. So there are some limitations in that respect (they have to use the same thumbnails and such). When it comes to any image operation in a modal, the buttons are placed at the top because we don't want them to fall into a scrollable area that's hidden. An important function of the image editor is to allow for the option of working with the image at its actual dimension rather than scaled, which in many cases means part of the image may need to be in a scrollable region. After all, we have no way of knowing what the size of the modal will be as it depends on the client side. If we adopt a standard of having any buttons/inputs, etc. below the image, then in many cases they simply won't be visible. That's why the choice was made to keep those buttons/inputs at the top. However the buttons that affect the modal window itself (like closing it) are able to go outside the modal document and into the window footer. I prefer your use of defined labels for "width", "height", etc., rather than the current arrow icons. I was trying to save the translators some work there, but after using it awhile agree that text labels are better. As for cropping presets, I agree about the usefulness. But I also really didn't want to cancel the purpose of Horst & Apeisa's crop modules, which they've put a lot of work into and already do a great job of this, better than I could do. Maybe someday we can get those preset functions integrated into the core image editor with their help. But the current intention with the image editor is leave that need to dedicated modules, while accommodating the more basic general purpose cropping needs, especially for things like RTE inserted images where a preset isn't necessarily what you want. But if there's sufficient demand for "croptions" (love the label), maybe we can talk Horst and Apeisa into helping us get those in a future PW version. I'm conflicted on the Apply vs. Save Crop labeling. My eyes prefer Apply as you've got it, but that button is actually saving a crop rather than applying the crop to an existing image. I like to leave the option of letting the user determine whether the crop should replace the original, or whether it should become a new image. To me, the term Apply implies replacing the original, though maybe since we give them that choice separately, it's okay to use it here. I'll take it for a test drive.

Another way could be to use two image fields, one called imagesbefore and the other imagesafter. Set them up to be displayed side by side each 50% width in the template. You can get them like for ($i=0; $i<count($page->imagesbefore); $i++) { $urlbefore = $page->imagesbefore->eq($i)->url; $urlafter = $page->imagesafter->eq($i)->url; }

This is already available within the RTE, I think the same functionality should be brought through to the Image field (note: I am not asking for a media manager )

At X-com we build and maintain ticketingsoftware, named Itix. About 20 Dutch Theatres run our software and since we've dropped maintentance our own CMS, we're slightly migrating more and more of those theatres towards a ProcessWire powered website. Using various API's and synchronisation tools, all needed information and actions are provided to the ProcessWire frontend, resulting in a cool e-commerce solution which is flexible towards the client and scalable for us. Our latest and greates is Schouwburg Venray. Go check it out at http://www.schouwburgvenray.nl The design was done by http://www.dejongensvanboven.nl The technical implementation by us at http://www.x-com.nl

I like the idea of adding class into parent element and using that to hide/show/style the hover. I think it will work in most designs, but not all. I'll add that as option into Fredi.

Overhead means that repeaters are actually pages, which are stored somewhere in the admin section. But it's not the pages per se, but it should be something about the handling of them as I remember Ryan stating that pagetables are better in that regard. About your repeater problem: foreach($page->before_after as $r){ // This may be easier to set up instead of tagging every image $before = $r->Images->first(); $after = $r->Images->last(); $thumb = $after->size(300, 300); // Markup }

didn't know about renderAll() from fredi, thank you! would be nice to have this on the documentation page i thought that you always have to setup all the fields that you want to have edit-access for and i wanted to avoid this work ^^ there's also one major difference: fredi inserts a plain edit link and screws up your design! take this example from the basic profile: <!-- main content --> <div id='content'> <?= $fredi->renderAll($page); ?> <h1><?php echo $title; ?></h1> <?php echo $content; ?> </div> all the content moves down i'll bring apeisa in - maybe he can bring best of both together

You could use $fredi->renderAll($your-page-id); I think in Fredi to achieve similar? Either way, I am loving front-end editing whatever the method. Not sure why I'd not looked into it sooner myself.

Guys - I feel the same. PW has largely such a consistently brilliant interface that anything even slightly off is amplified. At the same time, the image crop modules are essential. If any core-contributors or module-makers want to team up and move this along, please shout.

I would love to see this As much I like the existing crop modules, I honestly don't like the inconsistencies in the UI/UX between the new core cropping and the 3rd party ones, but I really want predefined cropping.

Thanks for the feedback Ryan. Lots of stuff raised that I hadn't thought of. I was thinking that there was some kind of integration actually. IE If CroppableImage was installed and you had certain Crop-tions set, the Croptions part of the UI would display. If you don't have CroppableImage installed then you don't see 'em. That way I also imagined that future image Modules could selectively plug in to the modal. Then, the more basic 1:1 3:2 and 4:3 were just pre-defined, standard and non CroppableImage out-of-the-box ratios. Anyway, really good to hear from you as I realise there's a ton of complexity and considerations underlying some simple mockups.

Cheers Nico. Just graphics at the moment. I've some refinements on the way.

hi pete, it's not fredi - it's a quite different approach and i love it i'll go more in detail on this asap

1. https://processwire.com/talk/topic/8635-simple-example-for-widget-management/ 2. https://processwire.com/talk/topic/8635-simple-example-for-widget-management/#entry83444 regards mr-fan

Simple Repeater with an Image field in it, setting "maximum files allowed" to 2? Plus add an explanatory note/Description to the field.

I've been working on a module to make it really simple to upgrade ProcessWire from one version to another. Especially as a way to make it easy to upgrade from PW 2.4 to 2.5, or to upgrade from one dev version to another. This tool supports upgrading between any branches of ProcessWire (currently we only have master and dev on GitHub). It will also let you downgrade your ProcessWire version, though no reason to do that. The module keeps up-to-date directly with GitHub, so it works as a long-term tool for every upgrade if you want it to. It works best if your file system is writable. However, if it isn't, the tool can still be used. It will still download the upgrade files to the server and then tell you where to move them. I should also mention that this module is somewhat inspired by a similar module Nico built awhile back called AutoUpgrade. So far I've used this tool to upgrade this site (processwire.com), the skyscrapers site, and the modules site (modules.processwire.com). Before releasing this officially in the modules directory, or suggesting it for production use, I'd like to get some help testing. If anyone has availability to help test this on non-production sites, your help is appreciated. It can be downloaded from GitHub here. As a bonus, it will also be a good opportunity to help test PW 2.5! Thanks in advance. What I'd really like to do as the next step with this is make it support upgrade by FTP. That would provide a nicer and safer solution for those that don't have writable file systems on their servers. This tool should be compatible with ProcessWire versions as far back as 2.3.4. I will also update it to support older versions than that if there's demand for it.

Hi there, I'm building a website for a small firm, which plans lighting and builds a specialized led-lamp system. They wanted their visitors so not have anonymous access to all their downloadable files, so I integrated a simplified memberaccess. The visitors need so fill a small form, if they're interested in one of the restricted-access files, which asks for some general information about the person. If they do so they get a password and the download link via email. So at least the email has to be right, to get to the download. With the password they can now download other files, without filling the form again. But the downloadlinks are always send via email. Now my question is, if I should implement a mailservice like e.g. sendgrid or mailchimp to send those emails. I've never really used more then simple php mail(), as I never needed something other, but now it will be more critical, that it just works for their clients. Greetings, Benjamin

Nice solution LostKobrakai, and thanks for the info on repeaters. I would certainly add some checks to ensure images are available, better now than after going live <?php // check if there is any "before_after" repeater on the page if($page->before_after->count()) { foreach($page->before_after as $r) { // ensure there are exactly 2 images in the repeater if($r->count() == 2) { $before = $r->Images->first(); $after = $r->Images->last(); $thumb = $after->size(300, 300); // Markup } } }

Hi and welcome! I actually just posted about this: https://processwire.com/talk/topic/10010-users-with-specific-role-as-checkboxes/?p=95546 You'll see a screenshot there showing how to configure a page field to grab all the users from your PW site. You can choose whether you want ASMSelect, checkboxes etc as the inputfield type. Let us know if you have any other questions.

Awesooommeee! Thanks man! That was precicely what I was looking for, never thought to look for that under a page field I created this like shown above with an extra selector to get users with a specific role. Now on the frond end, how do I go about checking these values? something like this? [ sketch programming -> not actual language ] foreach ($page->tags as $tag) { if ($user->name == $tag->name) { if ($tag->value == 1 ) { Show news item } } { something like this? thanx! Gr, Bram

Sounds like you just need a page field that is linked to the users template. Let us know if you need any help setting it up. These settings for the page field should do the trick - in particular note the Label Field set to "name". Of course if you want checkboxes change ASM Select to checkboxes. It really depends on how many users there are and how many will likely be selected as to which will be better.

Really love this! I hope ryan and tom can make that happen (Or maybe you can just send a pull request )

A very nice website. Your "shortcut edit-links" really caught my eye in the screencast. Any additional information regarding those "shortcut edit-links" would be greatly appreciated.

Looks really great. One really minor thing: Maybe the logo could be using svg if supported. For me the oblique lines look a little bit frayed, especially as all the other UI elements look clean and sharp.

The widget system sounds interesting. Any more details there. How is it built, displayed in the Admin and how does it work?

Quality work! Just out of curiosity, a search feature was not planned?

Just noticed you're sanitizing the password, too. When I remember right Ryan mentioned that it's better not to do so because you want to make sure the correct password gets saved, otherwise there is a little chance that somecharacters get sanitized so the user won't be able to login. As far as I understand, because the password will be hashed you don't have to worry about what the users inputs. Please correct me if I'm wrong! @Onjegolders thanks for sharing your code, could grab some parts to improve my registration process. For example I forgot to implement password control like if(!preg_match("/[0-9]/", $input->post->pass) || strlen($input->post->pass) < 6) Saludos, Can

Maybe not the most suggesting thing UI wise, but what about something like this: for($i = 0; $i < count($page->Images) / 2; $i++) { echo "<div id='container1' class='twentytwenty-container'>"; echo "<img src='$page->Images->eq($i*2)->url'> "; echo "<img src='$page->Images->eq($i*2+1)->url'>"; echo "</div>"; } Just use the order to get images together.

Last update should be php 5.3 compatible. I just removed empty() calls like that. //if (empty(wire('session')->get('registerStep'))) { if (!wire('session')->get('registerStep')) { //if (!empty(wire('session')->get('registerStep')) && wire('session')->get('registerEmail') !== $form->fhValue('email')) { if (wire('session')->get('registerStep') && wire('session')->get('registerEmail') !== $form->fhValue('email')) { No warnings or errors with php 5.5. Would be great if somebody could test the new version 0.8.6 with php 5.3. @naldrocks98 Thank You for your feedback! Could you explain which errors you mean? Error mesage?

Checked on smartphone and ipad and everything is looking great. I really like the design and the way the information is presented.

The tutorials for getting started were excellent resources. Awesome starter to go with a solid core. loving PW.

Thanks LostKobraKai, I look forward to learning and sharing as well. So glad my old CMS forced me to move on. So far it is fast, user friendly and the Forums are a HUGE wealth of great information.

aaah, thank you - i was mixing up the wordings "inputfield" and "fieldtype"

For those who want to upgrade to the latest core version like me, I added the following command: Common Upgrade Checks and optionally installs core upgrades. $ wireshell upgrade Available options: $ wireshell upgrade --dev --just-check --just-download Output Example ❯ wireshell upgrade A ProcessWire core upgrade is available master 2.6.0 Downloading ProcessWire Version 2.6.0... 9.35 MB/9.35 MB ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100% Preparing new core version... Upgrade files copied. Installing new core files. Your index.php file is confirmed identical to the one included with ProcessWire version 2.6.0 so it should be safe to replace without further analysis. We have detected that your .htaccess file may contain site-specific customizations. Please double check before replacing it. Upgrade completed. Now double check that everything works. You have to replace htaccess.txt manually. A lot of the code is taken from Ryan's ProcessWireUpgrade Module.

Version 0.8.5 Add some more comments to FrontendUserRegisterEmailValidation module FrontendUser::auth() is now hookable (to build a auto login after sucessful user registration) Add usage shorthand to call login / register with one method call by set a second param ($redirect) // load module $fu = $modules->get('FrontendUser'); // login echo $fu->login(null, $redirectDestination); // with default fields //echo $fu->login(array('username', 'password', 'persist', 'forgot'), $redirectDestination); // load module $fu = $modules->get('FrontendUser'); // registration echo $fu->register(null, $redirectDestination); // with default fields //echo $fu->register(array('username', 'email', 'emailValidation', 'password'), $redirectDestination); The compatibility to PHP 5.3 seems to work fine, but isn't fully tested. Because Processwire 2.5 / 2.6 requires PHP 5.3+ I would't increase the requirements to PHP 5.4

Processbombing, surely!

I guess photobombing for a good cause is acceptable

I made this into a blank site profile. Download and instructions here. Tested on a new PW install and it is working fine. Maybe some of you want to test it in other environments and let me know if I need to amend the README. Thank you.

Greetings, You will have to force a template to set a temporary password for you. 1. Add this code to any template file in your site: $temp = $users->get('admin'); $temp->of(false); $temp->pass = 'rememberme'; $temp->save(); Replace "rememberme" with your own temporary password. 2. Browse to the page where you placed this code. 3. Remove the code from the template (so it does not reset the password again). 4. Log into your site and change your password from the admin control panel. Thanks, Matthew

Thanks for posing this Kyle! A few things to mention: For even more security with the activation code, you might want to use something completely random that isn't influenced by the username. We have something built-in that will do the trick: $p = new Password(); $hash = $p->randomBase64String(100); // 100=length of string See here how it works: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Password.php#L154 (code is originally from Anthony Finta's password_compat library). Make sure that you are using $sanitizer->pageName("username"); for your username sanitization. Using $sanitizer->text(); is not adequate for sanitizing usernames or any selector values. In your function that checks for duplicate usernames, check for duplicate emails as well. When you check for users or emails do $users->get("name=$username") rather than $users->get($username); as this will ensure it's checking for only the username, and not potentially confusing a numeric username with a user ID. I recommend using $input->get->var rather than $_GET['var'] because the $input->get version makes it so that you never have to worry about PHP's magic_quotes setting. Last thing to mention is that it might be good to include what type of fields the user_real_name and user_activation are. I believe these are supposed to be text fields, but wasn't sure (especially for user_activation) until later.

The germans are taking over over!

Just wanted to reiterate what Wanze said about this: <input type='text' name='first_name' value='{$input->post->first_name}'> This is a major security hole. For example, try submitting this in the first_name field: '><script>alert('Gotcha!');</script> ...and if you can do that, you can do some pretty bad stuff. Definitely entity encode user submitted input that gets output again. Wanze's example: $v = $sanitizer->entities($input->post->first_name); echo "<input type='text' name='first_name' value='$v'>"; If you are running an older version of PW that doesn't have the $sanitizer->entities() method (a fairly recent addition) then do this: $v = htmlentities($input->post->first_name, ENT_QUOTES, 'UTF-8');

ProcessWire core is a framework. And on top of that built a CMS I think it goes this far /wire/core - is the framework /wire/modules /wire/admin-templates - is the admin/cms built on top of the core /site/ - your site with possibilities to extend admin and cms functionality You could start now and build your own CMS basing on core.

Users don't represent viewable pages on the front-end so you may want to connect them with some other template by way of URL segments. i.e. $username = $sanitizer->pageName($input->urlSegment1); if(empty($username)) throw new Wire404Exception(); $page = $users->get($username); if(!$page->id) throw new Wire404Exception(); // prevent superuser or users that don't have a specific role from being viewed if($page->isSuperuser() || !$page->hasRole('some-role-you-want')) throw new Wire404Exception(); $page->of(true); // now you can continue just as if this were the user template // as $page now represents a user As for finding users by role, try adding "check_access=0" or "include=all" to the selector. Those user pages are going to be protected from normal access, so adding one of those to the selector makes them accessible to the find().

You can always reset your password just by pasting this temporarily into any one of your templates, and then viewing a page that uses the template: $u = $users->get('admin'); // or whatever your username is $u->of(false); $u->pass = 'your-new-password'; $u->save();