Leaderboard

HTML Purifier is an HTML sanitization and validation module for ProcessWire. It serves as a front-end to the HTML Purifier PHP library. From htmlpurifier.org: Usage: This module is something that you would use from a template file or another module. The syntax basically goes like this: $purifier = $modules->get('MarkupHTMLPurifier'); $cleanHTML = $purifier->purify($dirtyHTML); The default settings seem to be about right for most cases. However, you can also specify custom settings to HTML Purifier by performing set() calls before calling purify(). For example, UTF-8 encoding is assumed, so if you wanted ISO-8859-1 instead, you'd do: $purifier->set('Core.Encoding', 'ISO-8859-1'); About this module: The reason I made this module is that I'm currently working on a CKEditor module for ProcessWire. It supports a very nice inline mode that I'd like to use. But the problem with an inline mode is that the text you edit is real rendered HTML (rather than a textarea), so that could be a security problem (i.e. XSS). I researched into into how best to resolve that, and the HTML Purifier library kept coming up. So here this module is. The new CKEditor module will require it if you want to use inline mode. Download: GitHub: https://github.com/ryancramerdesign/MarkupHTMLPurifier Modules Directory: http://modules.processwire.com/modules/markup-htmlpurifier/

I've got a CKEditor 4.1 Inputfield pretty far along. I'm trying to duplicate most or all of the functionality we have in TinyMCE with regards to the link and image plugins. So far I've got the link one fully functional, and hope to have the image one wrapped up soon. The docs are nice to look at for CKEditor, but I haven't found them to be any more useful different than TinyMCE's. I still have to ultimately figure out how to do everything via the Chrome web inspector and "trial and error". Though part of this is because we use our own dialogs rather than the ones supplied with TinyMCE and CKEditor. I'm loving the inline mode (using it in the admin). I've got a couple dozen textarea fields to power on a single page. Using TinyMCE or CKEditor regular editing mode, it took several seconds of loading/initialization. I experimented with Redactor, which was quite bit faster for that, but still not perfect. Then I tried out CKEditor's inline mode and BAM! they all load in an instant. So CKEditor's inline mode seems to have some real benefits in speed… particularly if you need to power lots of rich text fields in 1 editor (like you would in a repeater, for instance). Or in my case, several repeater items, each containing TextareaLanguage fields for 6 languages… meaning, potentially dozens of rich text fields in 1 editor. So finding something that could do rich text editing quickly became a necessity. And it looks like CKEditor nailed it with this.

Here's a link to the CKEditor module work-in-progress if you want to try it out. I'm not yet using it in production, but it seems to work well locally on the sites I'm developing. https://github.com/ryancramerdesign/InputfieldCKEditor

@arjen, @isellsoap: I'm not quite sure if it became what you were thinking of, but this conversation was the inspiration behind this: http://processwire.com/talk/topic/2967-pagereferencestab/ At least it's something you could use as a base for something more if it's only half way there at the moment.

It might be possible, I will look into it. One way you could currently accomplish it is by making a child page of the homepage that serves as the rootParent. Lets say you needed to support 3 languages, with English being the default. You'd give this single page the names "en", "fi", and "de" (to match up with your language names). The template would need no fields, and the template file would contain just this: $homepage = $pages->get('/'); $language = $languages->get(trim($page->path, '/')); if($language->id) $user->language = $language; echo $homepage->render(); In that manner, all of your non-default language homepages could be accessed at /fi/, /de/, etc. And you'd build your structure below that single language gateway page. You'd end up with URLs that are probably exactly what you'd want in a multi-language site, with no need to duplicate any pages. If you guys are interested, the LanguageSupportPageNames module is now committed to the dev branch. It's an early version only suitable for testing, so don't install on any production sites.

https://www.udmedia.de/news/279/fuenf-updates-drei-neuerungen-owncloud-processwire-und-webtrees-im-software-installer

Something I regularly add is this to Additional Settings: paste_text_sticky: true paste_text_sticky_default:true This automatically removes formatting from anything pasted into the editor - this can save a lot of mess! And if you want to turn the context menu on, add contextmenu to the plugins field.

You can customise TinyMCE exactly the way you would normally, just using the field configuration. Go to the field (body, for instance) go to the Input tab and click on TinyMCE advanced configuration In the valid elements add -sub,-sup, to the end of the list (probably after pre so it ends code,pre,-sub,-sup,) In the theme_advanced_buttons_1 field, add ,sub,sup somewhere. And that should do it. Check on the TinyMCE wiki for other stuff you can add.

Can anyone like a post of mine? 666 is evil edit: thanks Wanze

A short tutorial/help package aimed at new users (Note, a more step by step version of this tutorial is now available on the Wiki as a follow on to the Basic Website Tutorial - http://wiki.processwire.com/index.php/Simple_News_System ) - BE CAREFUL - don't mix the two. Either use the wiki or my files, not both at the same time. To be honest, you will learn more using the wiki version. This is an example script showing how to create a very basic news system with categories in PW. It includes templates and functions and full instructions of how to use it, which fields to create and so on. This is NOT a module or an instant solution, but it will help get you going faster if you have not done this sort of thing before. This example is for when you have a site carefully constructed round the page hierarchy, but want to add a basic news or blog that sits at least partly outside that tree. The system helps you to create a single news page that lists articles that are stored under a hidden parent. The articles are sorted by category - categories are created under another hidden parent and are selected with a page field. Full instructions are in the main newsfunctions.inc script and everything is commented. You can find it all here: https://github.com/jsanglier/Pw-News Joss PS: This is just one way to do a news system and should be taken as an example, not as the best way.

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

Page Link Abstractor module for ProcessWire 2 Plugin module that lets you move pages in your site without worry of ever breaking static links on other pages. Download at: https://github.com/ryancramerdesign/PW2-PageLinkAbstractor What it does Converts links in textarea/rich-text fields to an abstract format for storage, and converts them back at runtime. This means that if you move a page and another page is linking to it, the link won't be broken. It also means you can move your site from subdirectory to root (or the opposite) and not break links you may have created in your textarea fields. This applies to any kind of links: pages, files, images, etc. This module will also notify you when you edit a page that has a link to a page that doesn't exist or is in the trash. This module has been tested with ProcessWire 2.1 but should also work with 2.0. Since this module has not yet had a lot of testing, it should be considered "beta" and use is at your own risk. Please let me know of any issues or bugs you run into. How to install 1. Download the PageLinkAbstractor.module file from https://github.com/ryancramerdesign/PW2-PageLinkAbstractor and place it in: /site/modules/ 2. In the admin control panel, go to Modules. At the bottom of the screen, click the "Check for New Modules" button. 3. Now scroll to the PageLinkAbstractor module and click "Install". 4. Edit any of your textarea fields in Setup > Fields. You'll see a new configuration option to enable this module for that field. How it works This is a technical explanation for how this module works for those that are interested. Reading this is not required in order to use this module, but it may help you to use it more effectively. When you save a page that has a textarea field with this module enabled, it will look for URLs in HTML attributes by looking for an equals sign followed by a URL. It replaces instances of your site's root URL with a special tag: {~root_url} Next it checks to see if any of the URLs it found can be loaded as pages in your site. If so, it replaces those URLs with this special tag: {~page_123_url} where "123" is the Page's ID. When the page is loaded, ProcessWire does the opposite and converts those special tags back to their URLs. Because the URLs were abstracted to tags that are generated at runtime, when a page (or a site) is moved, no links are broken. Note that this module only converts URLs to tags when you save a page, so it only affects pages saved after the module is installed. Where to use it This would be most useful on your main 'body' field that uses a rich text editor (like TinyMCE). Where not to use it There is some overhead in using this module that will be insignificant if you use it carefully. Here are a few instances to avoid using it: Avoid use on fields that have the 'autojoin' option on, unless your site doesn't load lots of pages in a given request. Don't use on textarea fields that can contain anonymous (guest) user input. Avoid use on fields that aren't likely to contain links to local site pages in HTML markup. No need to have this module parsing things unnecessarily. Avoid use on fields where you think you might disable it later. Once disabled, the abstract tags representing the URLs will still be in place. If the module is disabled, those tags will no longer be converted to URLs are runtime. You would have to correct them manually by editing the page. Side benefit The tags that this module abstracts to are intentionally fulltext indexable, so you can perform searches for these tags. This means that you can find all pages linking to another by searching for it (minus the brackets and "~"). For example: $links = $pages->find("body~=page_123_url"); That would return all [viewable and visible] pages linking to page ID 123. Please note In order to convert URLs for pages, this module needs to load those pages in order to obtain their URL. If you are linking to a hundred pages in your 'body' field, you should expect that it may slow down the page 'load' and page 'save' time for pages containing lots of links. This module doesn't yet abstract local URLs that have a schema/protocol and domain in it. It just works with path-type links like /path/to/page/ and not http://domain.com/path/to/page/. This module hasn't yet been tested with migrating a site from subdirectory to root, but I will be testing this soon.

Page References Tab This little module adds a new tab, References, to the page editor. There it lists pages referencing the page that is being edited (title, path, field). There are also links to view or edit the listed pages (if they're viewable/editable). Only fields of type FieldtypePage are considered to be references and system fields are not listed at all (roles, permissions). It's nothing much, but as the subject has turned up a couple of times in the forums, I decided to give it a try. So watch out what you're asking! Screenshot Links Modules directory: http://modules.processwire.com/modules/page-references-tab/ GitHub: https://github.com/niklaka/PageReferencesTab

Not sure if this has already been suggested, but for the less php literate among us it would be great to have some sort of repository of php scripts on the PW website for formatting template data, i.e. the php snippets for outputting different kinds of menus, breadcrumbs, bloglists, etc. Similar to a database or list of modules, but specifically for the templating side of things, where you don't require a full-on module. Right now you have to scour the forums (or write your own code) if you're looking to do something beyond the basics that are included in the default templates.

If I am writing a journal entry I may want to write a paragraph, insert an image inline with the text, write another paragraph and embed a Youtube video. I don't want to create a new page type with a text field or two, an images field, a movie field and a template to put them all together. I just want to sandwich some html markup with a header and a footer and move on. There would be nothing stopping you from doing so with any text area field with tinymce turned on. Images added to the page become available in tinymce/rich text via the 'Select Image' button. You can also choose from different pages. By default the tinymce configuration is fairly bare-bones but you can change this to the point where it is a ms word clone. Not 100% sure about youtube stuff but you can prolly just insert the embed code where you want. Ryan is also working on a CKEditor implementation which may be of interest to you. Even if you load the images in a journal entry into the images field of a typical page template, how are you supposed to access them from within your rich text or markup?... see the above One of my competitors is Salesforce's Desk.com, and they have an outrageously good sales website. A site like this would be really tough to develop in ProcessWire since almost everything on the site is handcrafted, single-use content. Not much of their site is well-suited for templates, but the whole thing is pixel perfect. There's a place in the world for content that isn't generated by invoking a template on a set of page data. I don't see anything on that site (which is indeed nice) that would be particularly tough to do in PW. In fact, it would suit PW well i think. When you say "Not much of their site is well-suited for templates, but the whole thing is pixel perfect." i don't understand. How do templates and fields relate to a design and layout being pixel perfect? In essence the desk.com site is a well executed Twitter Bootstrap site and i'm guessing that they have structured their content well in the backend. Or maybe it's just handwritten html, who knows. ProcessWire is an awesome tool, but not all content is so rigidly aimed at separation into data and templates. Some content is just content, use it once and keep moving. Lots of other CMS's make that easy, but they don't excel at the structured repetitive stuff like ProcessWire does. It would be great if ProcessWire also made it easier to produce those conventional throwaway pages, too. I'm not saying that PW is perfect. Some things take getting used to, others could be improved upon and surely there are other systems out there that do a better job at a certain content management aspect. What i don't see is that PW makes it particularly hard to create content, throwaway pages, or otherwise.

Please send a cold keg of Unibroue La Fin Du Monde, and I'll have my tap ready. Just kidding, but that's one of my top 3 beers and has been for a long time. Canadians know how to make some damn fine beer, that's for sure. Luckily it's easy to get around here. A good thing, because Georgia has some kind of laws about shipping beer (to protect the poor beer/wine distributors).

Antti, I think you should be able to just set that email field before you output your comments. I don't think you'd need any modules or hooks or anything like that. So lets say you had a field on your page called comments_email. You may be able to do something like this: if($page->comments_email) { $commentsField = $fields->get('comments'); $commentsField->notificationEmail = $page->comments_email; } echo $page->comments->render(); echo $page->comments->renderForm();

Arjen, you don't necessarily even have to create a module for this. You could just add a template, then create a page with it in the admin, like you would on the front-end of your site. This is something I often do just because it's sometimes quicker than creating a dedicated module. Adding a page in the admin can be technically no different than adding one on the front-end of your site. So listing all users could just be a matter of creating a template like below, and then creating a page in your admin: include("./head.inc"); foreach($pages->find("template=user, include=all") as $user) { echo "<p>$user->name</p>"; } include("./foot.inc");

Oh, I thought I did that already... Here it is finally: http://modules.processwire.com/modules/process-preview/

Just did a little test round. So far it's working great. Just noticed a problem when logged in and having checked another language than default for my user (in profile). When calling the url for default it stays on the user language and doesn't switch language at all. When I make my user have defualt language checked it works like a charm. I'm using latest PW. Edit: Forgot about the homepage issue. This is indeed something we would need to handle. It would be great to have support for language segment in url like /de/ueber-uns/ and /en/about-us/. Yes this is how we build most sites. Do you mean to have a root page that has the site inside? And have that gateway page names like "en" and "de" ? How would then rootParent() behave. Sure there's the workaround with parents but you get it. Now also having maybe, if possible, some possibility to publish languages individually. How would you go for it if you need it with this support? However I think if there's an easy way to do it, then-or anyway the LanguageLocalizedURL becomes obsolete, because this module solves the main issues with LLU, which I'm not unhappy about. Remember it was created because there were no support in core yet.

Nico: I'm a bit late to join this party, but.. thanks for making this module! Was looking for exactly something like this from modules directory just last week -- how 'bout adding this there too?

Yes, you are right about that. It´s just that I´m porting 2 of my websites to PW, seeing how it was done with template variables in modx evo, that´s why I came up with it. Actually, I appreciate your reply because I didn´t see it, in that so obvious comparison. I guess I still have to get used on switching to my new work in PW. Yup, but not everybody is a high skilled coder like you are Soma. For the time being I have to do it that way

But that's another error now Are you on Pw 2.2.9? Grab the latest dev version or just the Upload.php class from there, I think the "setMaxFileSize" method was added later.

You can enter any php code in text and use eval like modx, but that's horrible practice not shining.

The possibilities are endless in Pw to achieve what you want. Some Possibilities: Don't use $page->title but $page->id instead - this id is unique even if you change the title Better: Give the pages you need the additional js the same template => this way you only have to check for the template Add a checkbox field to the template(s) of pages that need the additional stuff and check if this is set If you really, really need to access the templates url from inside a textarea, you could do something like this: //in Textarea blu blu blu {{templates}} blub blub blub //In template $blub = str_replace('{{templates}}', $config->urls->templates, $page->blub); @pwired What? In Pw your fields ARE the template variables, just more flexible. Who stops you from adding html/css/js into a textarea field in ProcessWire?

Digitex I am with you there. However, as soon as I find a really good solution, I am trying to store it as a reusable something, even if it only a reference. If I am feeling sensible, I even remember to comment it so I know what it is. I do this with music too. I am a professional composer, but if I come up with a really nice brass arrangement, I often store it separately - I wont use it again exactly as it is, but it is really helpful if I am looking for a particular sound.

Hi LeiHa, As far as I know, it's currently not possible to have Asian letters in the url. ProcessWire accepts only the characters mentioned in the description. This restriction is already fix in the .htaccess. Any url that doesn't match the criteria isn't routed through Pw: # ----------------------------------------------------------------------------------------------- # Ensure that the URL follows the name-format specification required by ProcessWire # ----------------------------------------------------------------------------------------------- RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$"

You can't use setTargetFilename on multiple. You should be able to just rename them after uploading: foreach($u->execute() as $key => $filename) { $file = pathinfo($filename); $newfile = md5($file['filename']) . "." .$file['extension']; @rename($entry->images->path . $filename, $entry->images->path . $newfile); $entry->images->add($newfile); } However this works, you create a new page everytime which stays there if there's an error. Best practice would be to first upload to a protected temp folder and create page and add files if everything went well... See also my script example here: https://gist.github.com/somatonic/4150974

Ryan, you are animal. Others talk, but you do. I definitely agree with ckeditor and it's inline speed. And about the docs: yep, I had the same experience recently when I had to dig little deeper. My first experience with the docs was very positive though

Marty, I think you could set the outer tpl to an empty string and add the ul-tags and your page manually: <?php $customPage = $pages->get('/.../'); echo "<ul>"; echo "<li><a href='{$customPage->url}'>{$customPage->title}</a></li>"; //Add your entry above all others echo $modules->get('MarkupSimpleNavigation')->render(array('outer_tpl' => '')); echo "</ul>"; Not tested and just an idea, maybe Soma has a better solution Cheers Edit: Damn I need to get some sleep NOW

Hi, when you are on your own local machine and want to 'upload' a file and wants to get it unzipped, you should provide the path to an unzip-app and all needed params / flags for it. (A commandline app!) If you don't have one, you may go and fetch 7z. It comes with an additional commandline prog called '7za.exe' Put it somewhere into your systempath, open a shell command (cmd.exe) and type in 7za -h or 7za --help to get a list of available commands and switches. If you have figured out the needed command and switch/es, write this into your PW-site config.php, instead of the unix there. I use 7za.exe sometimes with PHP-CLI on my local machine, - but only to zip archives. I never have used it to unzip via cli.

Thanks, really appreciate your feedback I know exactly what you're talking about, it's a bit frustrating.. especially since a lot of things I've worked on lately have been a combination of two or even three modules. Anyway, for now adding a notice to ProcessRevisionHistoryForTextFields.module about some settings being in VersionControlForTextFields.module (and vice versa) should help others avoid this problem. I haven't been keeping my modules 100% up to date in the modules directory, should probably start doing that right now. Thanks for pointing this out!

You are so much better at this than I am. Oddly, I understand what you've done. 6 months ago i wouldn't have been able to say that. You're schoolin' me. Even so, I would never have thought of doing that on my own. It's a great solution as long as I make sure they understand the importance of maintaining the format price=label. They're pretty savvy so that shouldn't be a problem. Thanks Ryan. I owe you again. Tell me where to send it and I'll ship you some Canadian beer.

http://www.bbc.co.uk/news/technology-21697704 Looks like you are much safer sticking to using a nice little Cray then.

I look at it like a line of obedient hounds following a trail of tasty morsels. When they get to where you are currently standing, they all sit there looking at you with big, expectant, eyes, waiting for you to drop something.

Morjensta Apeisa! Do you have any plans to upload the package to Github? Since it's not 100% done it would be easier to contribute.

pw will never compete with out-of-the-box-blog-engines like wp when it comes to setting up a blog rapidly. from my point of view this is a major advantage of pw.

I think that a config option in the core module might make sense here, and I don't usually suggest that but in this case I see it just being a checkbox labelled "email post author when new comments are made" which seems a but much having a whole module for it. In this case it would work for one blog with multiple authors or multiple blogs as well. To be honest, you'd then want another one to toggle whether the admin email address gets an email with every comment as well as this might then be unnecessary on some sites. The more I think about it the more options I want to add to the config but then we're getting away from a simple config option

Think Fieldtype Concat will help you out. Only fieldtypes stores data in DB, not their fields. So I think when you look at The above Fieldtype lots of questions will be solved.

There's no built-in feature for this as far as I know, but something like this could be turned into a module with relative ease. Since users are essentially pages, your module could hook into saveReady() method of pages and do it's magic (such as sending an email using user credentials, essentially info taken from that page) to this user. Password field is one I'm not very familiar with and thus I can't really say for sure if you'd be able to use it's actual value in this way. You may have to add another hook just to get that. Another option would be to avoid sending passwords and just instruct user to get a new password with "forgot your password" feature -- this is what many sites already do. Anyway, in init() of your new module you'd add a hook: $this->pages->addHook('saveReady', $this, 'sendEmail'); .. and that sendEmail method could look something like this, though probably you'd want to add some checks etc. (does email exists and so on): public function sendEmail(HookEvent $event) { $page = $event->arguments[0]; if ($page->template != "user") return; // stop here if this isn't a new user $message = "your message goes here.. or you could specify it in module settings. Hello {$page->name}!"; mail($page->email, "welcome, {$page->name}!", $body); } You'll find plenty of examples on creating modules around the forum. I hope this helps you get started! Edit: moved hook to "saveReady" instead of "saved."

Adapting sites to a responsive design can be difficult depending on the layout. There's a heap of responsive frameworks you conceivably wrap your site with. Here's a reasonable roundup of frameworks that might interest you. With my own site I recently used Toast to make it responsive. I previously used categorizr to detect which templates to serve mobile and desktop - which has its benefits in situations where you don't want/need to serve javascript to mobile devices. The other great thing about categorizr is you could have a link to enable mobile users to switch to the desktop version - and back again if they wished.

+1 for books

I honestly don't understand the confusion with pages. When everything are pages, that's really all you have to know. Couldn't be any simpler...

I actually wouldnt take the route to give editor admin rights just for this. It relatively simple to create a dediacted admin page that lists unpublishes users. It much more confident to do this. Let us know if you need example.

Hey, UD-Media is a german hoster. And they offer a feature-request system. So some weeks ago I posted there if they could add PW to the "1-Click-Install" stuff and today I got a mail that it will be available with the next software update they are doing. Much love to them: Go and register yourself there: udmedia.de (and support me by clicking this link before this ) They are really great and a lot cheaper then my old hoster I left two years ago. Greets, Nico

Another option that would bypass Pw caching, even ProCache is to send an ajax request to handle the counter. If you use jQuery, this would be something like this: //Javascript <script> $(document).ready(function() { var data = {'action' : 'handleCounter'}; var url = '<?= $page->url?>'; $.post(url, data); }); </script> //PHP if ($config->ajax && $input->post->action == 'handleCounter') { //... //put your php code in here //... exit(); //Quit since this was only a request to update the counter } To make this work you would need to disable caching for the POST "action" variable. This is done in the template settings under Cache > Cache disabling POST variables

I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>

Good news for my little learning curve; thanks to the help I've received from this thread I hit another problem and solved it myself \o/ I realized I've been committing the cardinal sin of trying to solve a problem that was not fully fully defined. @Pete's last code taught me some stuff so I then went on and produced this code: $tags = $pages->get("/tags/")->children->find("sort=title"); $tagged_pages = $pages->find("tags.count>0, sort=title"); echo "<dl>"; foreach ($tags as $tag) { echo "<dt>{$tag->title}</dt>"; foreach ($tagged_pages as $tagged_page) { foreach ($tagged_page->tags as $tag_to_test) { if($tag_to_test->title == $tag->title) echo "<dd><a href='{$tagged_page->url}'>{$tagged_page->title}</a></dd>"; } } } echo "</dl>"; which now produces this output; which was really what I needed. One improvement I am going to add is to check the URL to see if we're on /tags/ in which case the above will be used or /tags/a-tag in which case I will only show the pages related to a-tag. So — thanks everyone who has helped me, when this is fully finished I'll write it up for any poor souls who are are PHP-weak as I am Cheers!

I think it would be great and make sense to have repositories of scripts and modules that are approved by the PW members to ensure they're quality modules. With launching the new PW website we're working on it will come.