Leaderboard

I just posted version 5 of Hanna Code. The primary additions here are: Predefined (default) attribute values There is a new Attributes field present in the Hanna Code editor. From here you can define what attributes your PHP or Javascript Hanna Code expects. This can also be used to set default values for attributes. Use of this is optional. However, I think it's a good idea to use it as it helps communicate what the options are for a given Hanna Code. It also saves you some code as you can assume your attributes will be defined as variables, ready to access. The main listing page now shows Hanna Codes with their attributes so that they can be copied/pasted into your body text with all attribute options known and ready to fill in. Support for Export and Import of Hanna Codes Now you can export any Hanna code and import it somewhere else using copy/paste. You'll see the Export option when editing a Hanna Code. You'll see the Import option on the main listing page. Below is a predefined Hanna Code you can import if you'd like: Jumplinks Hanna Code (example for import) This Hanna code is meant to be used in your body copy. It collects all the headline tags in the text and turns them into anchor jump links while outputting a linked table of contents. It will put the table of contents wherever you type the Hanna code. See the anchor jump links on this page for an example of what this Hanna Code does. Import Data: !HannaCode:jumplinks:eyJuYW1lIjoianVtcGxpbmtzIiwidHlwZSI6IjIiLCJjb2RlIjoiXC8qaGNfYXR0clxuZm9yPVwiaDIgaDNcIlxuaGNfYXR0cipcL1xuJGZvciA9IHN0cl9yZXBsYWNlKCcsJywgJyAnLCAkZm9yKTtcclxuJGZvciA9IGV4cGxvZGUoJyAnLCAkZm9yKTtcclxuZm9yZWFjaCgkZm9yIGFzICRrID0+ICR2KSAkZm9yWyRrXSA9IHRyaW0oJHYpO1xyXG5cclxuJGZvciA9IGltcGxvZGUoJ3wnLCAkZm9yKTtcclxuJGFuY2hvcnMgPSBhcnJheSgpOyBcclxuJHZhbHVlID0gJGhhbm5hLT52YWx1ZTsgXHJcblxyXG5pZihwcmVnX21hdGNoX2FsbCgnezwoJyAuICRmb3IgLiAnKVtePl0qPiguKz8pPFwvXFwxPn1pJywgJHZhbHVlLCAkbWF0Y2hlcykpIHtcclxuICBmb3JlYWNoKCRtYXRjaGVzWzFdIGFzICRrZXkgPT4gJHRhZykge1xyXG4gICAgJHRleHQgPSAkbWF0Y2hlc1syXVska2V5XTtcclxuICAgICRhbmNob3IgPSAkc2FuaXRpemVyLT5wYWdlTmFtZSgkdGV4dCwgdHJ1ZSk7XHJcbiAgICAkYW5jaG9yc1skYW5jaG9yXSA9ICR0ZXh0OyBcclxuICAgICRmdWxsID0gJG1hdGNoZXNbMF1bJGtleV07IFxyXG4gICAgJHZhbHVlID0gc3RyX3JlcGxhY2UoJGZ1bGwsIFwiPGEgbmFtZT0nJGFuY2hvcicgaHJlZj0nIyc+PFwvYT4kZnVsbFwiLCAkdmFsdWUpOyBcclxuICB9ICBcclxuICAkaGFubmEtPnZhbHVlID0gJHZhbHVlOyBcclxufVxyXG5cclxuaWYoY291bnQoJGFuY2hvcnMpKSB7XHJcbiAgZWNobyBcIjx1bCBjbGFzcz0nanVtcGxpbmtzJz5cIjtcclxuICBmb3JlYWNoKCRhbmNob3JzIGFzICRhbmNob3IgPT4gJHRleHQpIHtcclxuICAgIGVjaG8gXCI8bGk+PGEgaHJlZj0nJHBhZ2UtPnVybCMkYW5jaG9yJz4kdGV4dDxcL2E+PFwvbGk+XCI7XHJcbiAgfVxyXG4gIGVjaG8gXCI8XC91bD5cIjtcclxufSBlbHNlIHtcclxuICBlY2hvICcnO1xyXG59In0=/!HannaCode Usage Examples: [[jumplinks]] Locates all h2 and h3 headlines, turns them into anchors, and generates a table of contents. This is the default behavior with no attributes. [[jumplinks for=h2]] Here we specify a 'for' attribute. It produces the same behavior as above except only anchors h2 headlines. [[jumplinks for=h2 h4]] Same as above except only anchors h2 and h4 headlines.

Hello. Best way i can think of is writing a custom module that actually stores the length of that field in a separate, int field. Try this: <?php class PageIntroLength extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Get Intro Length for filtering', 'version' => 100, 'summary' => 'Stores the intro length into a field', 'singular' => true, 'autoload' => true, ); } public function init() { $this->pages->addHookBefore('save', $this, 'stroreIntroLength'); } public function stroreIntroLength($event) { $page = $event->arguments[0]; // we can specify a certain template that this module should run for. As it is, it will run for all pages. Just uncomment the line blow and replace "template_name_here" with the name of your template //if($page->template->name != 'template_name_here') return; // get the length of the intro and store it in a field named intro_length. YOU WILL HAVE TO CREATE THIS FIELD AND ATTACH IT TO THE TEMPLATE YOURSELF FOR THIS TO WORK. $page->intro_length = strlen($page->intro); } } Save this as PageIntroLength.module and upload it to your modules directory. Install the module (click check for new modules first.) Don't forget to create the field (of type integer) that will store the length. You must name it "intro_length " without the quotes or this won't work. Make the field hidden so the editors don't see it. After you've done all that, each time you save a page, the intro_length field will get populated with an integer that represents the number of characters in the intro field. Then you can filter like this: $pages->find(intro_length < 10); This code is untested, and i am very much a beginner, so if you have any problems just post here. Please let me know how it works!

Or you could use SQL directly like so: $pageIDs = array(); $result = $db->query("SELECT id FROM pages INNER JOIN field_intro ON field_intro.pages_id = pages.id WHERE LENGTH(data)<10"); while($row = $result->fetch_row()) $pageIDs[] = $row[0]; $pageArray = $pages->getById($pageIDs); // $pageArray contains what you want EDIT: If kongondo's assumption is correct that you are just looking for an empty intro field, then his approach is the way to go for sure!

It's good to realize that not every available function is on the cheatsheet. In this particular example i think i read it in the commit message. You can see that it was added 20 November 2012. I follow Processwire's github repository and every once in a while i pull in the changes and scan through the commit messages. A great way to keep up to date on the latest and greatest. Apart from that you can also just look through the PW source. Ryan has commented everything nicely and it's not that hard to understand what most things do. And of course always read carefully through the official release notes, which are very detailed. You could have read about wireRelativeTimeStr in there as well http://processwire.com/about/news/introducing-processwire-2.3/#newfunctions

Easily insert any complex HTML, Javascript or PHP output in your ProcessWire content by creating your own Hanna code tags. This module is based loosely on the WordPress Hana Code Insert plugin. A Hanna code tag looks like [[hello_world]]. A Hanna code tag with attributes looks like [[hello_world foo=bar" bar="foo]] using HTML style attributes or [[hello_world foo=bar, bar=foo]] using ProcessWire selector style attributes. After installing the module, you define your Hanna codes in Setup > Hanna Code. These Hanna codes that you define can then be entered within your body copy (or other text where you allow) and they will be replaced with the values defined or generated by your Hanna code. A common use case is to embed scripts or other bits of HTML or codes that would usually be stripped out by an editor like TinyMCE. However, Hanna codes can be more than just static snippets--they can be dynamic PHP or Javascript that outputs different things according to the request. PHP-based Hanna codes have access to the entire ProcessWire API. Hanna code accepts named attributes in the tag that can be passed as variables to PHP and Javascript Hanna codes. These attributes can be specified either in HTML attribute format or ProcessWire selector format. In either case, quotes should be used around the attribute value when the value contains whitespace or a comma. How to install Place the module files in /site/modules/TextformatterHannaCode/ In your admin, click Modules > Check for new modules Click install for TextformatterHannaCode Now to go Setup > Fields and locate the Textarea field(s) that you want to use Hanna codes with ("body" for instance). When editing the field, click the details tab, and select "Hanna Code" as the Textformatter. Save. Now go to Setup > Hanna Code and start defining your Hanna Codes! You may want to use one of the examples from this document to get started. Tag format Below is a Hanna code tag named hello_world with no attributes. If you pasted this into your body copy, you would get whatever the replacement value is that you defined. [[hello_world]] Below is a Hanna code tag named hello_world being passed attributes of foo, bar and foobar. If this were a PHP-based Hanna code, it would receive the variables $foo, $bar and $foobar: [[hello_world foo="bar" bar="foo" foobar="foo bar"]] Below is the same Hanna code tag as above, but with attributes more like ProcessWire selectors. You can use whatever format you prefer. Just note that unlike regular ProcessWire selectors, quotes (single or double) are required around any value that has whitespace. [[hello_world, foo=bar, bar=foo, foobar="foo bar"]] How to use Please make sure that you have completed the How to install section first. Then in your admin, go to Setup > Hanna Codes. Each Hanna code that you add has a type of either: Text/HTML, Javascript or PHP. The Text/HTML type is literally self explanatory in that your [[custom-tag]] is replaced with exactly the text you paste in. Anywhere that you type your [[custom-tag]] in your body copy will be replaced with exactly the static text you defined. More power opens up with the Javascript and/or PHP types of codes. These codes execute at runtime and thus can contain specific logic to produce different results. In fact, PHP Hanna codes have access to the entire ProcessWire API and are executed in the same manner as template files. Your PHP-based Hanna code should simply "echo" or "print" the replacement value. PHP example Create a new Hanna code with the name "children". Select "PHP" as the type. Paste in the following for the code: foreach($page->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Now go and edit a page that has children. In the body copy, enter [[children]] in the place where you want the output to appear. View the page, and you should see the rendered list of links to children. PHP example, part 2 Now lets take the above example further... Go back and edit your "children" Hanna code, as we are going to modify it to respond to a "parent" attribute. Change the code to this: if(isset($parent)) { // If $parent is an ID or path, lets convert it to a Page $parent = $pages->get($parent); } else { // otherwise lets assume the current page is the parent $parent = $page; } foreach($parent->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Go back and edit the page where you previously inserted the [[children]] tag, and change it to: [[children, parent=1]] (specifying the homepage) or [[children, parent=/path/to/some/parent/]] if you want to try something else. View the page and you should now see it showing the children of the homepage (or of another parent you specified). Please see the Javascript and PHP usage notes on the Hanna code entry screen. Security There are major security implications with a tool that will let you enter unfiltered text and code from your web browser. As a result, Hanna codes are meant for definition only by superusers and we recommend keeping it that way. Download Download the Hanna Code module from the ProcessWire modules page or from GitHub.

You've been using MODX but now you've found ProcessWire. It’s totally amazed you and you can’t wait to get started. But…you are wondering where everything is. If this is you, read on… This guide is primarily aimed at those who are coming in from MODX and wish to know how to accomplish “MODX things” the “ProcessWire (PW) way”. This is not meant to be a full blown PW tutorial. It will focus on some key MODX concepts/tasks and how to accomplish those in PW. It will cover, whenever possible, both versions of MODX - Evolution and Revolution. The guide assumes that you’ve at least logged into a PW site and/or viewed a demo. The Table of Contents mostly reflects MODX terminology. Table of Contents 1. Manager 2. File System 3. Resources 4. Templates 5. Template Variables (TVs) 6. Template Files 7. Snippets 8. Modules 9. Plugins 10. Chunks 11. Miscellaneous 12. Examples - the PW way… a. Template Variables b. Snippets c. Modules d. Plugins e. Chunks 1. Manager In PW, the “manager” is referred to as the “Admin”. The default location of the Admin is www.yoursite.com/processwire. As of PW 2.3, you can rename the Admin to anything you wish during install. Just be careful to remember the name you use or you will be locked out! (If that happens, there are ways to get around it though). Logging into Admin, you will notice a tree just like in MODX. The Admin runs on jQuery UI and as you’ve seen, it is insanely fast! Don’t be fooled by its simple facade. PW is a really powerful CMS, highly extensible and very easy to use. Customising the PW admin is very easy. There are a number of custom themes available. It is also trivial to make yours. Custom Admin themes go into the folder site/templates-admin/. You can have only one theme at a time. On a related matter, if you wish to create a custom Admin page, it is easy to do so. See this thread for more info. 2. File System After installing PW, you will see two main folders; “site” and “wire” in your file system. Site is where all things related to your site reside. This is your playground and will survive an upgrade. Wire houses the Core. You will never have to go into that folder. 3. Resources In MODX, Resources can be many things (documents, etc.). There is no such term in PW. However, the most important “resources” you need to know about in PW are page and pages. Pages are a very powerful concept in PW. Page can refer to your website’s frontend pages, i.e. what can be viewable by your website users. I say can be for a reason. There are many uses for Pages in PW. This can be confusing to newbies but once you get the concept, you will appreciate the power of the system. Just because something is a Page does not mean it has to be viewable. It can have other uses such as a container that holds data for use by other Pages - in this case the Pages do not have to be displayed on the frontend. In fact, everything you see on the PW tree is a Page. That’s right; even the Admin and its components (Users, Roles, etc.) are all Pages! Still confused by Pages? Have a read here. Pages reside in the PW tree - you may have noticed . You can drag and drop pages to move them around. If drag and drop doesn’t work you probably have MySQL 5.0.5.1 installed. Upgrade your MySQL and you are sorted. The root of your site is the uppermost Page in the tree. In the default PW install this is called Home. You can change the name to something else. The default PW install comes with a number of Pages pre-installed. Try editing a Page. All those Fields you see on that Page when under the “CONTENT” tab? They are not default Fields. They are all Custom Fields! Yes, not even the Title! The only required Field for a Page is “name”. You find this under the “SETTINGS” tab on the page edit screen. More about Fields below… Other related stuff: Menuindex: As an aside, if outputting something like a menu, unless you state otherwise, it will reflect the tree hierarchy. Show in Menu: This functionality is covered by the Page status, whether hidden or not. Hidden pages do not get output on menus (more about menus later) unless explicitly stated so using PW API selectors (see below). Menu Title: No such term in PW. You can name your menu items what you wish to name them. Very important: All Pages must be assigned a Template. 4. Templates In PW, Templates mean something slightly different compared to MODX and many other CMS. MODX describes templates as: That is not entirely true of PW Templates. In PW, the term Template is used in the sense of the English definition of the term: PW Templates serve as a pattern for the foundation of your Pages. By foundation, I do not mean the HTML or CSS. Rather, the Template servers as blueprint for your Pages. What is available to the Template is available to the Page that uses it. Templates establish a pattern for the Pages by the inclusion of Fields to the Template. A Template can have as many or as few Fields as you wish. You can create as many or as few Templates as you wish. You can easily change the Template a Page uses when editing the Page. See under SETTINGS. Note that if you have Fields on that Page that are not in the Template you are switching to, those Page Fields will be lost! PW will warn you about this when switching Templates though. OK, so how do you show “Resources to the world”? That will be the work of Template Files which we’ll look at in section 6. 5. Template Variables A powerful feature of MODX is Template Variables (TVs). If you loved MODX TVs you will absolutely adore the PW equivalent. In PW, TVs are known as Fields. You can define your own Custom Fields. In fact, you will need to create your own in most cases. This is because PW does not have any required Field except for “name”. It is perfectly reasonable to have a Page with only the name Field! Many people do add at least a Title Field for such Pages. In the default PW install, the reason you see the Title Field in all Templates is because it has been set as a “Global” Field under the ADVANCED settings of the Field (edit the Field to see this setting). There are many types of Fields to hold all sorts of data - images, texts, urls, passwords, reference to Pages, etc. You can call your Fields anything you wish. You can call the Field for your main content “body”, or “stuff”, or “content” or whatever you wish as long as you follow the naming convention, i.e. “[a-z], numbers [0-9], or underscores (no dashes or spaces)”. Fields are reusable across different Templates. The order in which they appear on your Page follows the order in which they are arranged on your Template. However, it is important to note that: The order in which Fields appear on your page and/or the inclusion of a Field on your Page does not mean that: The Field will be output on the Frontend. The inclusion of a Field on a Page does not automatically mean it will be output; PW does not make that decision for you. It only makes the Field available to you to use as you require. You can output all or none or few of the Fields on your Page. The order in which Fields appear on a Page does not mean the same order will be reflected when you output the Page. You make that decision. Also note that you are able to arrange Fields side-by-side on your Page (via settings on the Page’s Template) to mimic your site’s layout or for other visual/ease-of-use purposes as you edit the Page in the Admin. You can also give each Field a label and a description. These will appear above each Field when editing a Page. In most cases, the content of Fields will be saved directly to the database. In the case of file related Fields, the path to the file will be stored in the database. There are no direct equivalents of MODX TVs “@Bindings” (data sources). These are inherently built into the different types of Fields. Note that you cannot run PHP code within Fields (so no @Eval). This is by design. Fields are a very powerful and much loved concept in PW. Just Google "custom fields cms" and you’ll see what comes up tops. 6. Template Files So far, we've seen that you create Fields, add them to a Template you've created and edit a Page using that Template to input your content into that Page’s Fields. So far so good but how do you output the content to the world? You do this via Template Files. Template Files live in /site/templates/. You have to create your own Template Files. In MODX, a Template will have both system fields, e.g. body, title, etc. and custom fields (TVs). Rendering a Template is achieved by adding MODX tags to your Template. In PW, in order for the content of your Page to be seen by the world, its Template must have a Template File (or there must be some other Template File associated with a different Template that is dynamically pulling and outputting elsewhere the content of a Page whose Template does not have a Template File). This does not mean that all content within a Page will be automatically output by the Template File. No; in the Template File you can choose to render all or some Fields present in the Pages using that Template or none at all! You tell the Template about the associated Template File when you create/edit the Template. PW assumes that there is a Template File with the same name as the Template in /site/templates/ and will tell you if it does not find one. However, you have two other choices. You can either enter an alternative name for your Template File or tell PW you do not wish to have a Template File for that Template. This means that a Template does not require a Template File. Obviously, in such a case, you will not be able to directly output the content of the Pages using that Template. In some cases, that is exactly what you want . As you get to know more about the system, you will find out how powerful and flexible the PW Template system can be. For instance, you can use your Template as a controller. That’s beyond this guide but feel free to search the forums for more info. Template Files are typically PHP files with logic to dynamically output your content. In most cases, Template Files are HTML with PHP tags inserted to output your content. The PHP in the Template File will in most cases be PW API. Hence, you will see things like $page and $pages in Template Files. The former always refers to the current Page and the latter to any other Pages in the system. These are very powerful variables in PW and give you access to ALL information about ALL pages including their Fields and whether those are empty or not, etc. See below for more info about these variables and have a look the docs too. Note that Templates do not care about what’s in your Template Files. In fact, they won’t even check. All they want is for you to tell them if and how you wish your Pages' contents to be rendered. Your Template Files can even contain pure HTML (although that won’t be dynamic!)! Your Template Files can have references to other things related (or not related!) to the Page using that Template File. For instance, within your Template File, you can pull in the 10 latest “posts” from your Blog or the Children Pages of that Page. There are just too many possibilities to list them all here. Don’t let the PHP in Template Files scare you if you are no coder. I am no coder but I am able to use PW. You will only need to know at least some very basic PHP to use PW. The most important are: echo; foreach; and if… Anything else is a bonus in most cases. In addition, you will need to know how to use the two most important PW variables - $page and $pages. With these two, most of what you would have done in vanilla PHP is covered. They are easy to use and to understand and very much follow the jQuery concept. Check out the docs to learn more. 7. Snippets In MODX, Snippets are the method by which MODX allows you to run dynamic PHP code in any of your pages. In PW, the term Snippets does not exist. What!?! Not to worry; in PW MODX-like Snippet functionality can be achieved in two ways: Template Files: Most PW Template Files are essentially dynamic PHP code. That’s Snippets for you right there. PW Modules: PW Modules do what MODX Snippets do and more (see below). It’s just an issue of terminology. For instance, the popular MODX Snippet WayFinder has a Module counterpart in PW. This is the Module Markup Simple Navigation. However, you do not need to use the Module to create a menu in PW. You can do the same thing using PHP in your Template File. See the default PW install for a simple example. Check out section 12 of this guide for example “popular-MODX-Snippets-to-PW-how-tos”. 8. Modules MODX Evolution defines Modules as “a program that can only be executed from within the manager.” There are PW Modules that fit this definition, for instance, the Module Batcher which is equivalent to the MODX Revolution add-on Batcher. However, there are other PW Modules that are executed in the frontend, e.g. Markup Simple Navigation previously mentioned. In fact, in PW, a Module is PHP that extends the functionality of PW. Modules contain PHP classes that adhere to PW’s Module interface. 9. Plugins In MODX Plugins are PHP code that are set to execute during certain system events. In PW, although the term Plugin does not exist (except maybe in reference to Modules), MODX Plugin functionality is easily doable in PW. This is achieved via Hooks. There is one difference though. In MODX, Plugins are standalone code you can download and install. You cannot download and install PW Hooks. Instead, PW contains many methods that you may hook into in order to modify the behaviour of the method. In other words, PW offers the ability to hook into its processes/events and manipulate them before or after the event or even replace them, etc. Hooks are usually invoked inside Modules. However, Hooks may be attached from anywhere that you use PW's API, for instance in Template Files. The average PW user will not need to use Hooks. For more info about Hooks check the documentation. 10. Chunks MODX defines Chunks as “bits of static text which you can reuse across your site”. There is no equivalent term in PW. You can, however, easily create Chunks in PW. You can create Chunks as a Page that contains various Fields each of which can act as a Chunk. This means you can have Chunks of all sorts of data. You can then set the Page you create to hold your Chunks as hidden (not available to searches). The Page can also be assigned a Template without a Template File to further limit frontend access. It can also be created as a child/grandchild of the page Admin. That will limit access by User (e.g. login required to view it in Admin). Accessing the Fields of that Page as your Chunks using PW API is quite trivial really. Since you can use labels and descriptions to further define each of your Pages’ Fields, this makes it quite easy to describe what each Chunk is for and/or give instructions on how to use the Chunks. See this example for more info. You can also simply use text files to pull into your content as Chunks. Personally I prefer using Pages as Chunks when I need to. In MODX, it is usual for many Snippets to use Chunks (HTML + placeholders) to structure their output (i.e. tpl Chunks). You do not need to do this in PW. Code output can be wrapped in HTML right within the Template File. The important thing to remember is that any Field in any PW Page is available to any other Page and any Template File. Cross-referencing Fields and Pages is child’s play. Seriously; it is that easy. 11. Miscellaneous Tag Syntax: PW does not use a templating language (tagging syntax) like MODX does. See this article why this decision was taken. I agree 100% with the approach and have come to realise its many benefits over using a templating language. However, there are two Modules that allow you to use template language tags in PW. I have never used them so cannot comment further. They are here and here. Settings Page: PW has no settings page like MODX. Many settings are set in the /site/config.php. Other MODX settings equivalents are interspersed in various places including caching content on a Template by Template basis and in Modules. You can also store custom settings needed for your site in the /site/config.php. You can even use Pages to store your settings as mentioned in section 10 (Chunks). Modularity: PW is a very modular system. The whole of PW is made up of Modules (Core Modules) that accomplish different tasks. 12. Examples - the PW way… In this section I will show you equivalent MODX versus PW add-ons as well as how to accomplish various task using PW “Snippets” equivalent. a. Template Variables As previously mentioned, MODX TVs are PW Fields (although PW Fields are more versatile). Outputting the contents of your Fields is very simple. echo $page->name_of_your_field; This gives you the contents of the Field in the current page. Works slightly different for image fields though. For other pages echo: One page $pages->get(ID or PATH or NAME, etc.)->name_of_your_field; //note replace ID with ID of the Page you want, etc. Many pages $pages->find("selectors"); //this will return an array. You can then go through the array using foreach as shown in the examples below to output the field(s) contents MODX - output main content of Page //MODX Evolution[*content*] //MODX Revolution[[*content]] ProcessWire - output main content of Page //ProcessWire echo $page->content;//note; this assumes you have a Field called content in the Template of the current page. In ProcessWire you can find Fields of other pages like so $fruits = $pages->find("template=yumyum, limit=10"); foreach($fruits as $fruit) { echo "<li><a href='{$fruit->url}'>{$fruit->title}</a></li>"; } //find 10 Pages that use the Template yumyum and echo their url and titles in a list. From these examples, you can see the elegance and flexibility of TVs done the PW way. Since there is separation between a Template and a Template File, you can conditionally echo out the contents of Fields found in Pages. b. Snippets Common MODX Snippets and PW equivalent Modules 1. WayFinder: Markup Simple Navigation or code in Template File (see head.inc in default PW installation for a simple menu). 2. Ditto (Evolution) and getResources (Revolution): Functionality inbuilt in PW. Use $page and $pages variables + selectors to find anything, anywhere. 3. Jot (Evolution) and Quip (Revolution): Comments Module is part of the PW Core. It is not enabled by default. You will have to enable it in the Admin. See also the related Comments Manager Module. 4. eForm (Evolution) and FormIt and FormItBuilder (Revolution): There are various Form parser codes in the Forums. There is also a commercial Form Builder Module. It’s not expensive, is developed by PW’s lead developer and proceeds support the PW project. 5. MaxiGallery (Evolution) and Gallery (Revolution): Presently, there is no equivalent. However, it is quite easy to build a photo album. See this tutorial in the wiki. There is also an Images Manager Module (still in alpha though). 6. AjaxSearch: Ajax Page Search Module. 7. Breadcrumbs: Quite easy to accomplish using PW API. See default PW install for an example. 8. FirstChildRedirect: Very easy to do using PW API like this: $session->redirect($page->children->first()->url); in a Template File. 9. getField (Evolution) and getResourceField (Revolution): Inbuilt in PW $page and $pages variables as shown above. 10. GetParent: Inbuilt in PW $page and $pages variables. E.g. $page->parent. 11. getPage: PW has inbuilt pagination as part of the Core (Pagination Markup Module). See this article for a quick tutorial. 12. UltimateParent: Inbuilt in PW API as rootParent. 13. if (Revolution): Use vanilla PHP with PW variable and selectors in Template Files. 14. VersionX (Revolution): Versioning for text-based fields is coming in PW 2.4 (release date summer 2013). Support for maintaining separate draft and live versions coming in PW 2.5 (Winter 2013/2014). Currently, there is also the Module Version Control for Text Fields. 15. getRelated (Revolution): No out-of-the-box Module for this. Has been previously accomplished using PW API in various ways. Have a look in the forums. 16. importX (Revolution): Import Pages CSV Module. 17. phpThumbOf: Thumbnail functionality is inbuilt in PW. There is also the Module Thumbnails that further extends this functionality. 18. getValue and getValues (Revolution): Inbuilt in PW. You can get the value of any Page using PW API - $page and $pages. 19. getFeed (Revolution): RSS Feed Loader Module. 20. MIGX (Revolution): Repeater Module which is part of the PW Core. It is not installed by default. You will need to do that yourself. For more info see this tutorial. 21. Articles (Revolution): See the Blog Profile Module. 22. NewsPublisher (Revolution): See below under Plugins. Examples MODX Ditto [!Ditto? &parents=`5`&extenders=`summary` &tpl=`tplBlog` &orderBy=`createdon ASC`&display=`6` &truncText=`Continue Reading This Article` !] PW equivalent $items = $pages->get(5)->children("sort=date,limit=6"); foreach ($items as $item) { echo $item->title; echo $item->summary;//etc. } //this assumes you have a Field called summary on that Page The first line in the above gives you all information about the 6 child Pages of the Page with ID #5. It returns an array. In other words, a basket of various documents containing all the info about those documents. Next, you traverse the array using foreach. In layman terms, you rummage through the basket picking goodies! In order to wrap HTML around the code output, we do it like this instead (there’s other ways to do it as well!) echo "<ul class='articles'>"; foreach($pages->get(5)->children("sort=date,limit=6") as $item) { echo "<li><p><a href='{$item->url}'>{$item->title}</a><br /> <span class='summary'>{$item->summary}</span></p></li>"; } echo "</ul>"; In this example, we have asked PW to grab the child Pages directly within the foreach rather than creating a variable $items first. MODX getResources // Output a list of child Resources of the current Resource, using the 'myRowTpl' chunk: [[!getResources? &parents=`[[*id]]` &tpl=`myRowTpl`]] PW equivalent echo "<ul>"; foreach ($page->children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } echo "</ul>"; //You might want to limit the number of child Pages you are getting if they are many! MODX getResources // Output the top 5 latest published Resources beneath the Resource with ID '5', with tpl 'blogPost': [[!getResources? &parents=`5` &limit=`5` &tpl=`blogPost` &includeContent=`1`]] PW equivalent echo "<h3>Latest Posts</h3>"; $posts = $pages->get(5)->children("limit=5"); foreach ($posts as $post) { echo $post->body; } c. Modules 1. Batcher and Docmanager (Revolution): Batcher Module (covers most equivalent functions). 2. DocFinder (Evolution): Inbuilt in PW default install. d. Plugins 1. QuickManager (Evolution): Several Modules can do this, i.e., Fredi, Page Frontend Edit and Inline Editor Modules. 2. ManagerManager (Evolution): Same functionality can be achieved using Templates, Access Control and the Modules Page Edit Field Permission, Page Edit Per User and Page Edit Per Role. e. Chunks See this example. Btw, the PW Cheat Sheet is you best friend... Hope this has been helpful! /kongondo

Greetings Everyone, I just completed building a site which serves as a companion to a book published by Rutgers University Press. The book is about Holocaust films. The author uncovered these films during extensive research in Russia, Israel, and elsewhere. This site is designed to be used as a college classroom resource. Teachers will go to the site, play movie clips for their class, then use the chapter summaries and discussion questions as further materials. For the video pages, I used the video.js player. Every movie page includes an .mp4 and a .webm file, in order to cover as many browsers (and tablets) as possible. The movies play in regular and full screen. Although the site is launched, I am still planning to build additional sections for "educator resources." I may also make some style changes in the coming weeks. Using ProcessWire made the building of this site very smooth! The author can easily log into the site, add or edit chapter text and discussion questions, and upload video files. She can also easily edit any of the static pages. This is a relatively simple site that will get a lot of practical use in college classrooms. Here it is: www.phantomholocaust.org Thank you, Matthew

Hey, I made a new website for a berlin-based "balkan electro dj". Check it out: http://balkantronika.de/ (and listen to the songs at the bottom )

Hi, First, some introduction... I'm new on PW, just started yesterday evening and I'm very enthousiastic! I have 10 years+ enterprise experience in PHP (owning my own software company for 8 years). I have developed an enterprise CMS myself for lawyers, accountants and all sort of enterprise users which focusses towards handbooks (ISO and the likes) which is used by 2000+ companies (incl. government) in The Netherlands. Besides this, I just do some websites for friends and family in my spare time (which I do not have because I'm a dad of 3 too). I stumbled upon PW yesterday after I (again) completely freaked out at Joomla. I know this software when it was called Mambo 4.5.2 and I have created many componenents for it, knowing it from the inside. I always (after the first 3 months) hated it, but you know, when developing a small website it was the tool at hand for me because I knew it so well. And just every time I created a website I got frustrated, but well I got there and "OK, next". But this week, after 4 days of trying and reading and CCK extensions modules overrides custom layouts and all this stuff which makes me sick because its inconsistent as hell, I decided to just QUIT on joomla. It makes me cry. No joy in developing a small website. It's always about fitting in their model instead of the other way around. (And somehow, WP (which I don't know) feels the same way but different) Having said all this, did I mention I am very enthousiastic about PW? Well, I am. I have created in just one day (or half a day) what I wanted to do with Joomla and couldn't do it in four days. Even while I didn't got any sleep last night due to 5 weeks old baby etcetera. So, I'm happy with PW. Very happy. It just delivers. And I'm not familiar with the jQuery syntax (mostly used Mootools in my own software). It is just intuitive. I hope I stay this enthousiastic. But I'll gain some trust every step I make with it. Of course, there are a few things which I don't get directly, but I can search and read. But I wanted to just introduce myself and say a big THANKS for PW to Ryan and all the others. There is something I don't really grasp yet. Like this: I have several news items. These items are linked to from products. This works very nice But of course I want to have an index of all the news items. I can make a news-index template, and just make one. No problem. And then, I have a several review items, and several quotes. And I want them linked to products, no problem. But have an index too. Now, I can make 3 index pages. But somehow, they are similar to each other. Thus, Why don't create a 'polymorph' 'index' template. Which refers to a certain template (like, news, reviews, quotes) and loades all the items. Somehow, I just didn't came across this idea in the docs, wiki or forum. Perhaps I didn't read good enough, and I'm the first to admit I did not spent too much time with PW, but I'm curious if these kinds of concepts are 'the PW way to do things'. Another question/thought I have is about the data model. But thats maybe not the right place to ask right now....Is there something I can read about the thoughts and concept of the datamodel? Thanks in advance, I hope to use PW for my upcoming website projects and just want to finish my first stuff in the following weeks.. So you'll possibly see me some more on this forum. Ow by the way just one point of feedback: when doing my research yesterday, I thought that there were only video's available to get to know PW. After a while I stumbled upon the wiki and getting started links ! Wow. That saved time. But I wonder: why isn't that on the homepage? Every developer just wants to know about this I guess... After all the horrible forums with joomla 'experts' a forum isn't the first place I go look for documentation and help, you see..

I would recommend defining a new role called "deletor" with permissions to view, edit. and delete. Then for the appropriate template you simply give the deletor role the ability to edit the page. Should work as you need. For those templates that should be edit only, only check edit for the editor role, not the deletor role as well. Does that make sense?

I've just discovered this app that should import web pages straight to photoshop files, and divide them by layers (following the DOM structure previously applied). I don't own a Mac (poor me..) but I think this is a great little tool to have, could be useful.

Threw me off as well. You could still be right; OP will let us know

I think the key thing is to use the API to recreate templates, fields and pages. Direct data transfer is okay for a whole site but will break things if done piecemeal (clashes of ids etc). One could come up with tool and for a semi automated process like... Start at the top of a tree of pages Run through it looking for templates Run through those looking for Fields Check that the necessary fields and templates can be made on the destination system or are there and seem identical. - manual intervention - Setup Fields Setup Templates Run through the pages - some intervention and cleanup may be needed - PW maintains a unique index between the page name and the parent_id and adds a number to the end to (smith, smith1, smith2...). Page ids and possibly names may end up different than they were on the source system. This might require attention depending on the situation but seems unlikely to be a big problem. For my current situation it makes sense to setup the templates and fields by hand. The pages are under a couple of root parent pages so they are not going to clash with anything. Still this seems like the kind of thing where having a strategy in place for "partial migration" could payoff later.

Hi Luis, weird thing! I have tested a bit with PW Version 2.3 stable, and it seems that PW and PHP also does a right job. But MySQL could be wrong. I have created a float field and it works as you have described, but also when trying to save 10000.11 it store and retrieve 10000.1 !! But to be short, I have tracked the action until to PW saves the value: "INSERT INTO `field_test_float` (pages_id, data) VALUES('1109', '10000.11') ON DUPLICATE KEY UPDATE data=VALUES(data)" After that, I have looked into that field with a MySQL-Editor and it stores 10000,1 and not 10000,11 (When you use 10000,16, it will result into 10000,2) So, after that I have manually edited the field in the MySQL-Editor, typed 10000,11, save, refresh, and voila there are only 10000,1 in it ! It's definitely a MySQL-thing. But I haven't found a solution, only some posts on stackoverflow and mysql datasheets that I do not understand http://stackoverflow.com/questions/4520620/float-precision-problem-in-mysql http://stackoverflow.com/questions/2160810/mysql-whats-the-difference-between-float-and-double http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

I'm not clear about this. Is your ultimate aim to check whether "introtext" is empty? Is "introtext" a field? If so, all you need is something like this for the current page...from that you get the idea of checking many pages... if ($page->introtext) {// this checks if introtext is empty // stuff } else { echo "move along! no intro to read here"; }

No offense roelof, but I think it would be wise to take a step back and do some php tutorials. You can drop the last ?>. You can't use php in php. See this example below how to fix it. Notice the {} around the variables and the single quotes in the double quotes. For an editor I'm using Sublime Text 2. Don't edit php files in a textarea please <?php if ($page->id == 1) { echo "<link type='text/css' href='{$config->urls->templates}styles/twentythings.css' rel='stylesheet' media='screen' />"; }

@SiNNuT Wow! Thanks I'll check that out as it looks like it does do what I had achieved with Flourish. One question; how did you know this? Is there a feature set for PW that I am somehow not following maybe? I am ashamed to admit that perhaps due to my weak PHPness in the past I have found the brevity of the PW cheatsheet usually left me unable to understand what I was reading or how to apply it (in case your answer is that you saw this on there). If you did see this on the cheatsheet then all the more reason for me to go back and try harder at 'getting' how to use it. Thanks again for pointing this out to me and thanks in advance if you're able to recall how you knew of this (and other) cool functions in PW I may not be aware of. Cheers, -Alan

@alanfluff Maybe you already know but for at least a couple of months (half a year?) now there is the function wireRelativeTimeStr in PW itself which allows for stuff like that. Haven't used it myself and maybe that Flourish function is somehow better or a different beast altogether but it is easy to overlook this kind of thing in PW. For reference: http://processwire.com/talk/topic/3597-how-to-display-relative-dates-in-pw/?hl=relative https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/Functions.php#L292

sweet! unfortunately they perform when people of my age are in bed sleeping ... did you also create the logo? some remarks anyway: the sentence on the front page isn't complete: "Balkantronika ist Balkan-Elektro-Produzenten und DJ-Team aus Berlin." - "ein" is missing and a hyphen after Produzenten- the music stops and has to be restarted from the beginning when you change to another page. i find source sans pro a bit to "brav" for the site - and the cool guys best, christoph

In a rare display of personal work I’ve made a photographic site to show some of my pics. I hope you like it. http://stlmv.in/mw

Dear Matthew, I'm using Ryan's code on this page: http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form as a reference for my system. (Still designing it.) I'm going to keep the normal admin login for admins and editors, with the blocks that Soma mentioned, for other users. For the members, I'm going to make a new login page that will use the regular API functions to look them up in the user field set, and then, based on their user id, look them up in the /member/ account data set, to grab their membership url, and then redirect them to that page, e.g. /members/1097-8247913542/ I was thinking about putting the membership url in the user template/field set, but I'm also using the member urls as a tree in the back end, for admins to view and manage. I don't have the code yet, but I think the concepts outlined here, combined with Ryan's code, should work well. I hope. But one point is that my membership system is entirely locked down, not viewable by the public, and not even viewable by other members. Peter

I eat them.

I have built pretty complex sites with PW and I remember feeling ankward of having similar template file per listing page. I thought that I would use alt-template filename all the time, but haven't actually used that much. And I don't see myself using it much in future neither... After revisiting sites after year or so, I love the fact that when I want to extend something, I always know the "starting point" (consistently named template file). And important to notice: having separate template file for each of your "index templates" doesn't mean you have to do any code duplication. Includes, modules, functions... what ever suits your workflow best Oh and welcome! You will definitely enjoy PW!

pwired: if docs would have all those examples, one by one - it would be just the same that you bought a box of legos and got 3 000 000 pages long manual that would show all the possible combinations that could be done. When you learn the basics: $page, $pages, Page/Wire Arrays, selectors etc and learn how to use cheatsheet (and soon source code), you really can find combinations like that. But, to answer your question: DIOGO: $pages is explained here: http://processwire.com/api/variables/pages/ ->find() (and selectors in more common, ie. what to put inside find) is explained here: http://processwire.com/api/selectors/ (also first item here: http://processwire.com/api/variables/pages/) ->has() is explained here: http://processwire.com/api/arrays/page/ TEPPO: $page is explained here: http://processwire.com/api/variables/page/ ->is() is explained here: http://processwire.com/api/variables/page/ (and again, concept of selectors) SOMA: Operator (^=) that Soma uses in his selector is explained here http://processwire.com/api/selectors/

If you allow multiple images with your 'logo' field, then the code must work - assuming you have at least one image uploaded on the page viewing. I'd try again If it does not work: Enable debug mode in /site/config.php ($config->debug = true) and check for any errors. Btw when you allow multiple images, why not calling your field 'logos' - would be more logical

Yeah. We can start by raiding Soma's Gist

What kills me about this module is that Ryan literally decided to make it because I had something similar in WordPress and needed a substitute solution in ProcessWire (as part of the move of CMS Critic to PW) otherwise I'd have a ton of weird shortcodes in my posts for no reason. He made this module, imported my code from the other module (called Hana Code in WP) and named his Hanna Code (after his daughter) and Poof! a module is born. I am insanely jealous of his mad php skills (but glad they can be bought!)

@Kongondo: Brilliant review! You've covered pretty much all key points here. I remember reading your Wayfinder book, which was one of the first things I had read when I started with Evo in 2009. It was a good read, thank you for that! @Jeroen: Soon after Revo came out I moved from MODx so don't know much about contexts. These topics may be relevant for you: http://processwire.com/api/modules/multi-site-support/ - two ways of setting up multiple sites http://processwire.com/talk/topic/1025-multisite/ - Apeisa's multisite module mentioned in above article http://processwire.com/talk/topic/2979-multi-language-page-names-urls/ - new multi-languge names feature. Currently it's available only in dev branch and is not recommended for production yet. This new functionality makes possible to have unique URLs for each language used by your site with no need of making separate tree for each language. All your multilingual content resides within one page using multi-linguage fields. When the page is viewed in the front-end the content is shown depending on the current language (which is detected by a languale-specific URL). Really excited about it! I think it's very close by its sense to "language contexts" in MODx you mentioned. API respects the context of the current language so it takes away the burden of taking care of language-related logic in your templates.

@mindplay.dk Could you please share what type/amount of work you've put into the effort to namespace Processwire's source? (Maybe this belongs in another topic all together?)

Once the multi-language page names module is stable and in production use. So will probably start developing the namespaces stuff in May. Namespaces are the primary aim, with PSR-0 being a natural extension of that. I plan to shoot for PSR-1 too if it looks like it'll benefit our audience. Also as a natural extension to these updates, I am interested in supporting Composer, and will do so if possible. I agree it's a great asset for PHP, though am less certain if it's as much of a draw for ProcessWire's primary audience. Throughout all of these 2.4 updates, I feel a lot of care will have to be taken to balance these updates with other improvements to the system. After all, our audience is primarily web designers and developers, and less purely PHP coders. I think a majority of our users doesn't actually care about namespaces, PSR standards and Composer, so I don't want to get too far off track, even if I personally have a strong desire for these things. But the driving aim of 2.4 is to help ProcessWire benefit from PHP 5.3+ as much as possible. This likely includes all of the things outlined. I've always been interested in this. PW started as just the content framework, and underneath it still is. I'd like to retain and reinforce those roots. But don't think I want to actively maintain PW as two projects until there is real need for it (just as a matter of resources). I'd like to make it easy for people to integrate components if they want to, and I think Composer is probably the way to do that. But don't currently see a need for any of our core components to come from another framework. Though I'm always open to the idea if there is a real benefit to our users. IoC is not a new concept. ProcessWire was written with an emphasis on best practices, patterns and concepts like this, everywhere beneficial to the project goals. The primary need for unit tests in PW has been with the selector engine, both DB and in-memory, and the consistency of the two. Luckily this is an active project, and it has already been hugely helpful and influential in ProcessWire 2.3 (thanks to Nik). In fact, I would probably consider the issues discovered and resulting solutions the most important upgrade to come with ProcessWire 2.3.

Nate, thanks for the good and honest post. You mention few great points that I do agree. I wasn't too keen on the general tone of this topic and it is great to hear your thoughts. But there are few things I would like to mention: I disagree. For most of us there is a lot more and on higher level than EE or any other CMS out there - that is the reason why we use PW. I had the freedom to choose the next CMS platform for our company. I did evaluate most of the products out there (open source or not, in our projects EE license fees are next to nothing) and PW came out as clear winner (there were 0 third party modules / themes then by the way, January 2011 - PW 2.0 was just released). Now two years later I couldn't be happier - PW has been great for us. Well... I think it is natural that people want to share the good stuff they know. I think for all the people here in this topic the basic intention has been purely honest and nice: "hey, there might be EE users that aren't happy - I hope they find PW since that might solve their problem". But that kind of discussion easily goes to little attacking tone that can annoy people. About to step up our game: I think if Ryan can keep even 25% of the phase that he is developing the core and the growing flow with 3rd party developers and designers keeps up, we are doing just fine No need to try actively catch people from other products - but no need to be shy or shamed about using this great product. EDIT: Pete, alert alert - IP.board is messing my quotes!

Btw, I'm not suggesting this is the style everyone should use in their 3rd party modules unless they want to. I understand that there are different preferences in this area. Of course I'm not going to shoot down anyones preferences. So this standard is just for PW core stuff. I do see us pursuing the PSR-0 standard with the way we use namespaces in the near future, and we already have a lot in common with much of PSR-1 and PSR-2. But I don't fully agree with all the standards recommended in PSR-1 & 2. I think PSR-1 & 2 would mainly be worthwhile as a compromise for a leaderless project or a compromise for a project with a lot of leaders that don't agree.

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>

One other thing about this module that's maybe interesting from a module development standpoint: It installs a page (/service-pages/), and the template for that page loads and runs the ServicePages module when it is viewed. So it installs the means to run itself, and it's not autoload. I might be wrong, but can't think of another module that does this, and maybe it's a good pattern. At least, I thought it was fun when building it. I've been thinking about building a module starter kit that includes skeletons for various types of modules and install/uninstall patterns (ready to build from), and this type of pattern would be one among a few others.

This goes little off topic: IMO good way to learn is to be brave and publish stuff that you have done for feedback. This forum is one fine place to do it (and I remember you have done also) - it's great to get feedback and is many times beneficial for others too! I don't know how to thank Ryan and others enough for all the learning I have got from here. I have also found that there are some concepts that are very common in web development (php & js for me) and understanding those will speed up your learning (not saying that I have grasped these all, still learning basic stuff also..): arrays, multidimensional looping those arrays functions (especially those that return something) classes and objects Web dev basics: server side vs. client side? sessions, cookies, databases. http-basics: post, get, headers... Also there are super simple things that we waste a lot of time. Things like string manipulation or simple maths. If you have problems like that and google doesn't help you right away, then just ask for help - it will help you learn faster. Also - learn to love php.net - ugly but working docs there! There will be boring and depressing phases when you learn slower and even feel going backwards (you realize how much you don't know and it feels bad ). And then there are those awesome moments when you feel like everything is possible and you just want to build and learn more. Most important thing is to keep building stuff. There are those wizard brain lies that keep telling people that they don't know and they will never know something - that they are just incompetent for doing stuff like coding/painting/music etc. "You are just a designer, don't bother trying to code something yourself, it will never work" or just the opposite: "You are just a developer, don't even try to build something beautiful or even usable"... how much better software we would have without lies like that?