Leaderboard

Hello all, I just spent 3 days without internet and I couldn't do much work on my ProcessWire project because I couldn't use the cheatsheet. I realized that there's a need to have PW's documentation in an ebook format including cheatsheet. So I've copy-pasted cheatsheet in a doc file & created a cheatsheet ebook for offline use. I'm posting it here so that others can also use it. Please let me know if doing this is wrong in anyway, I'll delete the files. Also note that there was no intention to make any kind of profit by using cheatsheet to make an ebook out of it. I hope this will help people like me when they're unable to access cheatsheet for any reason. Enjoy. EDIT: Attached file has been updated, as it wasn't readable on Mac and also wasn't very good looking. So I've updated it for better readability but I'm not sure if it still works on Mac, so someone needs to check it for me. Cheatsheet_1.1_v0.2.pdf

Here's a proof of concept PW Admin Theme Switcher (video and write-up). It shows how versatile PW is. Since everything in the PW tree is a page, including Admin this was easy to do. I think on the roadmap PW will eventually allow switching between Admin Themes? Anyway, here's how I did it (verbosity below is intentional ). This is not a module but can easily be converted into one. Currently, I don't plan to do so since I suspect it will be overtaken by events (roadmap). Instead, I used the excellent Admin Custom Pages (ACP) module. On load, PW will first check if there is an admin template at /site/templates-admin. If there is none, it will check in /wire/templates-admin/. The file it looks for first is /site/templates-admin/default.php 1. I copied the contents of /wire/templates-admin/ to /site-templates-admin/ 2. I modified the contents of default.php as shown below in order to use it as a controller file $theme = $pages->get(1424)->theme_selector;//id of admin theme switcher page (the child page) include($config->paths->adminTemplates . "{$theme->name}/default.php"); 3. In order to use ACP in PW 2.3, you have to create a parent and child page. The child page will be rendered in the Admin. 4. I created pages under Admin as follows: Admin Theme Switcher Admin Themes (id#1424) Default Teflon Moderna, etc. 5. Admin Theme Switcher has nothing of interest. It just enables me to render its child page in PW Admin. Admin Themes has a single Page Reference Field from which only its children can be selected. This field is called theme_selector. Its reference value is the ID of whatever child page of Admin Themes is selected. 6. Default, Teflon, etc., have various fields to hold data about the themes - author, version, description, screenshot, etc. I populated these as needed. 7. In the above code (#3), 2nd line, I am telling PW where the default.php is. I am appending the name of the selected child page of Admin Themes. Hence, if the current selected page is Minimalist Blue, its PW name, minimalist-blue is included as part of the path. This means I need to create a corresponding folder at that path. 8. I grabbed all my themes in their respective folders including all their files and copied them to /site/templates-admin/. This ensured that there would be no conflict having multiple themes in /site/templates-admin/ folder. I also copied the default PW theme with all its files into a folder called default. I ended up with a structure like this: /site/templates-admin/default/ /site/templates-admin/teflon/ /site/templates-admin/moderna/ /site/templates-admin/appy/ etc. 9. Of course since the themes were now in sub-folders, paths in their respective default.php would be wrong. I needed to change this, e.g. in /sites/templates-admin/teflon/default.php, I changed the paths as follows: $config->styles->append($config->urls->adminTemplates . "teflon/styles/ui.css?v=2"); $config->scripts->append($config->urls->adminTemplates . "teflon/scripts/inputfields.js"); $config->scripts->append($config->urls->adminTemplates . "teflon/scripts/main.js?v=2"); $config->styles->append($config->urls->adminTemplates . "teflon/styles/droppy.css") <?php include($config->paths->adminTemplates . "teflon/topnav.inc"); ?> 10. Now that all is set up, there's two ways to change the current Admin theme: a. The template file of Admin Themes has a foreach that loops through its child pages (the theme pages) and outputs the meta data in a I column Grid. Each item has a radio input field to select the theme. On save, jQuery Ajax sends the single value (ID of selected theme) to a simple processor file. The processor file updates the value of the single Page Reference Field (theme_selector) using PW API. Via JSON, the processor then tells jQuery if update was successful and page is reloaded. b. Alternatively, the theme can be changed by editing the Admin Themes page, selecting a child page (theme) using the single Page Reference Field (theme_selector) and saving. PW will auto-reload the page, applying the new theme. As you can see, there is no rocket science here.....just an amazing CMS

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.

Hey Everyone, I've been building front-end forms with ProcessWire for a while now, and really like it. One area I am constantly looking to improve is file uploads -- making things just a bit smoother and more visual. Recently, I started experimenting with dropzone.js and I think it's pretty neat. Anyone else using this? Any other cool ideas you have used for file uploads with ProcessWire? Here it is -> http://www.dropzonejs.com/ Thanks, Matthew

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

I'm seeing more token replacement modules crop up lately - modules that pick up various tokens (with various syntax) in text/html fields, replacing them with various types of mark-up, snippets, images, etc. Just a point of view: I think parsing and replacing tokens, and (more importantly) introducing augmented syntax, is the wrong solution for all of the problem I have seen people attempting to solve using this approach. Actually that's not specific to PW - a lot of CMS (and contributors) take this route, and it never leads to a very pleasant end-user experience. In my opinion, from the end-user's perspective, it beckons the question: if you're going to make me learn other forms of mark-up, why not just give me a bare plain-text HTML editor and make me learn HTML? At least HTML is one consistent syntax, it's universally useful, and it's not some strange mix of a whole bunch of other HTML-like syntaxes mixed into what is actually HTML. I'm not posting this just to gripe - I've actually worked on (I think) a "better" solution in the past, but unfortunately it was never completed. Rather than making people learn and type actual syntax, I used an approach with simple placeholder tokens, like so: <h1>Welcome!</h1> <p>Pretty picture of my pet fish:</p> {fish} <p>And my pet bird:</p> {bird} The placeholders are not "tags", and they don't have any actual "syntax" - the names are arbitrary and don't mean anything at all, except in terms of semantics used by the author. They don't have attributes, and there is no concept of "blocks" or start/end tags. They are all local to the body/content field you're editing, and have no shared meaning outside of the current context. Instead, the client-side editor recognizes the {fish} and {bird} placeholders, while you're typing, and a graphical user interface appears, presenting you with a list of placeholders you've used in the text or WYSIWYG content-area you're editing. You can then click on the placeholders in the list and decide what type of "macro" you would like to replace them with - then configure the properties of that macro. In the above example, you might select the {fish} or {bird} placeholder from the list, select the "image" macro, and upload or select from a library of images, configure cropping or resizing, perhaps watermarking, etc. In ProcessWire, two very useful macros would be Page and Field - allowing you to expand a placeholder, replacing it with a rendered Page or an individual rendered Field from a specific Page. This very simple solution could enable you to build things like block systems or navigation without any additional programming - just simply define reusable Pages with snippets of content, images, or Page references and so on, in a reserved folder in the root of your site, and then pick from those using macros. Is this comprehensible? (I might be able to dig up the very old prototype and post some screenshots) And what do you think of this idea?

hana.pirana gallery, u type : [[gallery tag=pirana]] ,,gallery,, hana code : $fotos=isset($tag)? $page->images->findTag($tag): $page->images; if(count($fotos)) { foreach($fotos as $foto) print "<img src=$foto->url>"; } else { print "<img src=/buttocks/fotos/bottolusk.jpg>"; } have.this right do i mr.ryan ? [[gallery float="right" summary="Colorful photo gallery of Piranhas in action" width="400"]] [[image id=789 caption="Adorable Piranhas flocking around my legs"]] [[image id=123 caption="Piranhas attacking my legs"]] [[image id=456 caption="What was left of my legs after the attack"]] [[/gallery]] mind.play.dkk u good ​

Just posted version 0.0.2 that addresses the items above. It also adds an option that lets you specify whether the immediate surrounding HTML tag should be replaced with your Hanna Code output or not. For instance, if your [[hello-world]] Hanna Code output is "Hello World" and is applied to the body copy containing "<p>[[hello-world]]</p>" then you probably don't want it to replace the surrounding <p> tags. Whereas if your Hanna Code outputs block level elements like "<ul><li>Hello World</li></ul>" then you probably do want it to replace the surrounding <p> tags, otherwise you'd end up with some invalid markup like: <p><ul><li>Hello World</li></ul></p>.

This is great news. Congratulations Ryan on a superb CMS. I personally use PW on most of my projects. The CMSCritic award nominations are now open for 2013. PW will get my vote this year. Last year it won the Critic's Award, let's try and get the People's Choice Award as well this year. Community - please provide your support, Now! P.S. @CMSCRITIC (Mike) Disqus is not loading on the nominations page for some reason? Edit: I thought this would be better placed in the News section, but I cannot start a post there!!

hey Marc! thanks oh, of course, I'm an idiot (no sleep).

I've always happily used VI (VIM) and always will. But I found a way to make the newest PHPStorm look and behave like VIM, so that's what I'm slowly adapting to. So far I like it, it's a fairly impressive piece of software. Lets me still be in VIM (or at least trick me into thinking I am) while giving me all the power of PHPStorm. I was also motivated by their support of open source–they provided the full license for free for ProcessWire development.

Hi everyone! With Batcher you can batch-edit and create Pages in the Pw Admin. If you install this module, you get a new Page "Batcher" under Setup. Modules page: http://modules.processwire.com/modules/process-batcher/ Github: https://github.com/wanze/ProcessBatcher Editing How does it work? Search your pages with a selector. You can check if you want to include also hidden/unpublished pages with the filters. Select the pages you want to execute an action (the action only gets executed on "checked" pages). Select the action and if necessary, additional data like the new parent or the new template. Execute. Supported actions: Publish/Unpublish Pages Hide/Unhide Pages Lock/Unlock Pages Trash Pages Delete Pages Change Parent Change Template Batcher does the following permission checkings for the current user: Don't display pages that are not editable Remove Actions if the user doesn't have the permissions (page-delete, page-move, page-template, page-lock) Important notes: When changing a template, data in fields of the old template which are not assigned to the new template gets deleted. When changing the parent, the template of the new parent must accept the pages template as children. This is a setting in the template under "family". Creating How does it work? Select a parent where your new pages will be added as children Add as many pages as you want by clicking "add Page" Click "Create Pages" You must enter a title and choose a template. The name is optional: If left empty, Pw will generate this for you. Includes permission checking and Family template restrictions. This means in detail: The selected parent must accept children and their template The pages template must accept the parents template User needs the permission to add children to the selected parents template User needs the permission to create Pages for the chosen Template Batch-creating tips The chosen template and the statuses are always cloned from the last row. So if you need to add 30 pages with the same template, define it first and the click "add Page" - it'll make your life easier ;-) You can drag & drop the table rows should you want to change the order. The dragging looks ugly but it works. For the lazy dogs and keybord hackers among us, you can add a new row by pressing "ctrl+n". This works (at least in firefox) only if no input has focus. After adding a new row, the title input gets the focus. By pressing 3 times tab you arrive at the published-checkbox, here the short-cut works. Restrict Batcher for a user to only allow editing or creating Create permissions "batcher-edit" and/or "batcher-add". As soon those exists, the module checks if the current user has the permissions. If you only need batch creating, check out the following module by Soma: http://processwire.com/talk/topic/2138-process-tools-create-pages-wip/ Cheers

ProcessWire Online Installer Since there's now a shortcut to download latest stable PW http://grab.pw , I created a simple helper PHP script you can upload to your server to download and extract a new PW installation. Upload this php file to the server where you want to install latest ProcessWire Go to the browser and call this script. It will download and extract ProcessWire files. Once done successfully it will redirect to the installer. Downloaded zip the grabpw.php will be removed. If anything fails, make sure permission are correct on server and you remove files manually in case. I tested this on my local XAMPP (Mac) install and on some of my account on a ISP. Also I took some methods to download and extract files from my ModulesManager which seems to be "reliable" so far. Download The script can be found on github: https://github.com/somatonic/PWOnlineInstaller Why Just because it's cool. There's many ways to accomplish this task if you have ssh access for example using shell. Just wanted to have this alternative and maybe people find this useful too. @ryan. Do you think you could provide an latest dev shortcut url too?

Table of contents Introducing the App and author Needs First version in PHP/MySQL without any Framework Why Processwire? App Version 1.0 Introducing the App and author Hi, my name is Luis and i´m a German based Web and Frontend Developer. I started 2010 with my own Internetbusiness and noticed at the very beginning of my business that it takes to much time to handle my accounting, invoices and clients. The main problem was that I needed for almost every task his own software solution, so the usual workflow in creating an invoice was something like open the CRM Software because the invoice software was good in creating invoices but bad in managing and searching clients, copy and paste the client into invoicing, create the invoice and handle it over to the accounting software. Not good at all... So I decided to create my own solution to fit my needs in the office management. Needs Invoicemanagement and creation Clientmanagement, very basic CRM Accounting Multi-User Simple financial stats about the Keyfacts of my business possibility to export the data for my tax consultant PHP / MySQL to work with it on intranet After pointing out my personal needs and writing down my usual workflow I started to develop the first version. First version in PHP/MySQL without any Framework In winter 2011/2012 I completed the very first version of my OMS (office management suite). The whole project was written in good old fashioned PHP from scratch. I´ve used this version till November 2012. Why Processwire? In mid 2012 I discovered Processwire and had no idea in how many ways this tool would change my life as webworker. After playing around with PW and developing the first little sites I had a little talk with my tax consultant, she said that my financial reports are pretty good and help to save money. (less time, smaller invoice from her) Why not publish the tool? Well, at this point my app was solely written for my needs, without possibilities for an Multi-User environment or for use in an companies Intranet. I finally decided to port the app to PW because of it´s flexibility, scalability and built-in user-roles. I had to dig deeper into PW at this point to see if I really could. Late 2012 I started porting the app in PW and was surprised how insanely fast developing could be. The whole database structure was ported into PW Pages, no SQL query is done by the app itself. It was possible to recreate the core functionality in about 2 weeks, implementing the Login and Multi-User functionality took another week. WebApp Version 1.0 https://youtu.be/PIgUMLZEcIU The app is now available for purchase @ www.misterui.de * also Processwire with an own eCommerce Script

There's no drag and drop... hmm, this is hard to put in words, I should dig up that prototype and post it somewhere...

Sorry, I think I missed this or ignored it because it's very hard to decifer your code and with very little initiative from you trying to find out. You may already have solved it but after taking a short look at the code I think I found something $field->addOption($d,$d); I think the problem is that the $d is a formated date string? Maybe the value (first argument) should be a timestamp... or at least converted to timestamp before assigning to the $page->time. You know that's lots of beer there?

Other uploaders/topics that may be of interest http://www.plupload.com/ (by TinyMCE guys) - this is a beast! http://www.fyneworks.com/jquery/multiple-file-upload/# http://www.phpletter.com/Demo/AjaxFileUpload-Demo/ http://pixelcone.com/jquery/ajax-file-upload-script/ http://www.jscripts.info/mfupload.php http://www.jquery4u.com/plugins/10-jquery-ajax-file-uploader-plugins/ http://www.9lessons.info/2012/09/multiple-file-drag-and-drop-upload.html http://www.nacodes.com/2013/04/14/DROPAREA-jQuery-Html5-drag-drop-file-uploader-plugin

Sweet success... It loaded up, the install page at the localhost root. Now to try a few sub-folder installs Thanks soma! Quick question are time-outs ever a problem if on a slow connection? Looks like the default time out is maybe only 60 seconds for the download to happen? This could also necessitate changes to one's INI file, or checking with your host if it's a hosted server environment.? Oops looks like timeouts were covered earlier in the thread, and those involve several places that may need timeouts changed. Where Soma mentions the scripts is set to 120 sec. Thanks again.

Wrong link Soma...that links to this thread ...we get your point though . Thanks for the tip!

Goto http://cheatsheet.processwire.com , File -> Save Page as... or context click on page -> Save as... Enjoy.

Mindplay, I have read your post 4 times and I still don't see the fundamental differences between what you are suggesting and what the 3 tag parser modules we have (shortcodes, tag parser and hanna) do . A couple of thoughts... I see no difference between your placeholders and the tags/tokens used in the above modules. They are all placeholders in my book . I see no difference between { } and [ ]. The names in the above modules are also arbitrary (at least in the case of shortcodes and hanna). You can even change the "placeholders" you want to use. In the current modules, you make the decision about what type of "macro" you want when creating the "placeholder". The difference between your approach and the current approaches is when the decision is made. In fact, IMHO, if I'd be more confused if sometimes {fish} can mean images and in other cases {birds) and they "don't mean anything at all". I suspect I just don't get what you are suggesting . I agree though, that a GUI would make work easier for some people. I would accept this as a another choice rather than do away with the approach offered by the current modules. One very important difference between the current modules and other CMS is what the modules actually do. I'll give an example from MODX since it is a tag based system I have used before. In MODX, when the system encounters the tag [[*content*]], it replaces that with the "body" content. That is a fundamental difference with above modules. I consider the PW modules nothing more than search and replace tools . Unlike in MODX, where the user doesn't care how MODX works its API juju to replace [[*content*]] with actual text of the "body" content, in the PW modules, the user must still be able to write "PW API" (the PHP the tags will inject). I think this is a good thing and is in line with PW philosophy about the types of users it is targeting. PW is growing and it is attracting many people with different skill sets. Part of this crowd are wanna-be-coders like me . These modules offer choice to people like me. Come to think of it, the modules are also useful to seasoned coders - e.g. ability to inject some code on a page rather than at the template file level. As long as these modules are not part of the core, I am happy. If I want point and click I'll use Joomla. I have to admit initially I was concerned with the different tags used by these modules (including Image Manager). Maybe it is not a big deal? After all, they are not part of the core. Anyway, I probably haven't understood your proposal. However, there is a place (and in the near future, I suspect a very big place) for modules like hanna considering the crowd PW is attracting. My 2 cents Cheers/k

Greetings, In my experience so far, Shopify is great if you want to build the entire system in Shopify -- in other words, use Shopify as your CMS and your full e-commerce actions. If you want to use ProcessWire as your CMS and pull in just the shopping cart/e-commerce elements and credit card transactions as needed, then FoxyCart is better. Both solutions have their benefits. However, ProcessWire excels so wonderfully at being a flexible CMS I want to build all my sites with it. In that case, something like FoxyCart is better, since it just ties into my ProcessWire site. Thanks, Matthew

I've always thought it would best to have the Cheatsheet available as a PAGE or TEMPLATE available to download/import into our own installation. Search would be enabled, a nice jQuery dropmenu would make it easy to find all the information

You have input (backend) and output (front-end) formatting for date fields. I think you miss understood what I was trying to say about output formatting: To get the unformatted timestamp of a datefield you can do $timestamp = $child->getUnformatted("date_start"); instead of $timestamp = strtotime($child->date_start); Which depending on the format the date has, will fail to get the right timestamp. So a more bullet proof way is to do this in your code: strftime("%l:%M %P", $child->getUnformatted("date_start"));

@vineonardo - thanks for making this... it will be good to have this on an ereader and be able to study it sometimes.

Congratulations and thubs up for CMS Critic! Site is amazingly fast. Gotta get pro cache immediately.

Tiny mind blown...

Hey Kunane, nice to see you here ;-) Just define "Maximum files allowed" as 1 in the image field (tab "details") that you use for the repeater item.

Im not sure I can follow, but did you know you can switch themes with ModulesManager?

Awesome thanks for the feedback. I've noticed the pageviews are up 300% from previous.

I have used komodo for long time, but now have converted to sublime. Both are great.

A quick update. Ran a page speed test on pingdom and it came back with a 588ms load time (faster than 95 percent of websites)

The output formatting of date field you can define in the field settings "Details" and "Input" for in and output format. To get the timestamp value you have to get around output formatting: $timestamp = $child->getUnformatted("date_start"); I'm not sure about your problems with strftime. %i for strftime doesn't exist. http://www.php.net/manual/en/function.strftime.php To get pages from today you'd have to get the 00:00 and 23:59:59 from the day and compare it in the selector. Or you can use "today" or any strtotime keyword and PW will take it. $start = strtotime("today"); $end = strtotime("today + 1day"); $pages->get("/events/")->children("date_start>=$start, date_start<$end"); or $pages->get("/events/")->children("date_start>=today, date_start<tomorrow");

where to start? from out of my head: http://processwire.com/talk/topic/3265-fredi-friendly-frontend-editing/ http://processwire.com/talk/topic/3602-pw-online-installer-download-of-latest-pw-install-to-server/ http://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/ http://processwire.com/talk/topic/3745-hanna-code/ http://processwire.com/talk/topic/3474-admin-custom-pages-module/ and most importantly: http://processwire.com/talk/topic/3498-karena-savannah-cramer/

Sorry chaps - been missing in action. Should be back around now! Joss PS: Did I miss anything?

Hey Everyone, I am working pretty much every day on the book and the site, adding more detail and new chapters all the time. It has been a great experience. I definitely want to get the whole project "out there" as early as possible, so I will try to post a preview (at least the table of contents) soon. On a personal note: Joss and I go way back -- to the old (Joomla) days. For the past three years or so, we have been in pretty much constant touch about a range of CMS concepts and issues, we communicate with each other very nicely, and we are both writers and coders. Pete is an advanced coder (and a terrific guy from everything I can see). I'd be happy to collaborate on this effort! Stay tuned, Matthew

I think urls and admin login would be enough at this point. I am happy to take a look.

Joss and I are a little behind Matthew then on page 1 We do have a rough idea of what will be in it but I think other projects have pulled us both away from PW for a while so I will touch base with Joss soon.

Thx Everyone! @PWIred: You are tempting me to do a demo of how "easy" it is to convert an "Evo-like manager" to PW . I get you point though @Mary: Long time no see! Thx for comment. @Soma: Selector: Corrected selector, thx; Indent code: Will do but the editor is driving me nuts! Keeps messing up code ; Settings: Thx for info; MSN - yeah, with those initials, you probably want a better name! hehe. Probably, it also wrongly conveys the message that it can only do simple navigation... /Cheers

This looks great Kongondo!! Although I don't know anything about MODX, I will read it tomorrow in the morning in my Kobo reader If someone else feels like, here is the ePub file that I created (Apparently I can't upload .epub files to the forum, so I'm sharing in Google Drive) https://docs.google.com/file/d/0B6RyV62pA8iwTm1BTnNOYmRYRDA/edit?usp=sharing

I know nothing about MODX, but I can really appreciate your hard work in putting this post together.

This is only something you have to consider if going from a PHP version 5.3.x or newer, and migrating it to a site running PHP 5.2.x. You wouldn't run into this issue going from say PHP 5.4.x to 5.3.x. Also keep in mind that PHP 5.2.x was EOL'd more than 2 years ago. Any servers running PHP 5.2.x need to be upgraded very soon, just as a matter of security. ProcessWire 2.3 is the last version to support PHP 5.2, as PW 2.4 will require 5.3.8 or newer.

can you post the code you are pasting in the template? if you are getting a 400 bad request, it's probably because you have a trailing slash on the base path, or the path is no good; you can edit the paths within the module; I am using this on a new 2.3 site and i can confirm it works as expected, and i just needed to edit all of the paths in the module itself and the path in the code that you paste into the template, with the actual paths to where my assets are located; @olliemackjames - same thing, you just need to edit the paths.

This case study relates to the topic here: http://processwire.c...ndpost__p__8988 about creating an archive of 'stories' about how PW has helped in relevant real life scenarios. Website: http://www.ray-dale.com RayDale Multimedia Ray Dale is a multimedia designer. His portfolio website was 2 years old as of March 2012 and in need of a refresh. He found that the content management for his website was more time consuming than he wanted and the website was generally slow in performance and complex to update. Ray needed: A website that could showcase his latest work with separate portfolio content types The ability to show lots of images and videos in each section Complex interlinking between each portfolio item - where each item would belong to a number of simultaneous categories To be able to publish a number of pages under various sections on the website To have a condensed navigation structure - not over-facing the user with navigation A blogging space that was easy to update To gain complete control over the HTML, CSS & JS markup and therefore the design of the website The ability to take more control over the admin experience - without using a host of plugins - so that the CMS could be used for clients to make their lives easier Speedy performance - even if a shared hosting platform were used Good site security The previous solutions Ray was previously using Drupal as a content management system. Drupal is a great system, it’s incredibly flexible, it can be made faster and using template overrides, almost complete control can be taken of the HTML and CSS output. However, the process to achieve any of this is time consuming and clunky from a web designer / front end developer perspective. Drupal was also going to require a number of plugins to be installed to achieve a lot of the required functionality. Ray tested migrating his website over to WordPress. WordPress is another fantastic blogging system with light CMS functionalities. WordPress is generally easier to use than Drupal and a lot of control over the HTML & CSS markup can be delivered - in a much easier manner than Drupal. However, WordPress is still light on CMS features in the admin system. This means that it is difficult without either using a lot of plugins or custom php development (using the WordPress API) to have custom content types and fields. The decision to use ProcessWire Having searched around for an alternative to Drupal and WordPress - revisiting other CMSs that Ray had also previously used - Ray eventually landed on ProcessWire having read about it on a forum. Right from watching the initial video produced by Ryan Cramer (the creator of ProcessWire) Ray was intrigued by the possibilities that ProcessWire seemed to offer - effectively solving all of the issues currently faced. To summarise ProcessWire offered: Custom content types in the admin Custom field types in the admin Good control over media uploads A simple to use admin system A neat and simple API for custom frontend / backend development A customisable admin experience The ability to have a custom admin url Complete control over HTML markup Good security with flood control A powerful and flexible templating system (that was also simple) Ray was extremely impressed by the features that ProcessWire offered, however, many CMSs look great until you actually start using them - where the unnecessary complexities, weak architecture and terrible, bloated functionality often start to appear. The functionality seemed so promising that a gamble was taken to build the Ray Dale Multimedia website - with very little time now available - to ProcessWire and test how it performed. Building the website Having built the original Ray Dale Multimedia website in Drupal, then converted to WordPress before deciding to gamble on ProcessWire - Ray now had very little time left to build his portfolio website. As a testament to the ease and speed of using ProcessWire - he was able (with a little help from articles in the forum) to rebuild the Ray Dale Multimedia website in two days of effective full time development. This included all of the content creation and learning the new system - with the inevitable (but surprisingly smooth) learning curve. Enabling complete control over output ProcessWire allowed Ray to write HTML and CSS without any of the interference you get from other CMS systems. So, Ray was able to use the following frameworks of his choosing: HTML5 boilerplate jQuery Modernizr Masonry A customised version of the 960 fluid grid system PrettyPhoto for lightbox images Less - to create minified CSS Though it must be said that literally anything can be used as ProcessWire makes no assumptions on the frontend - even on the Javascript framework. Quick and easy API One really pleasant surprise was the jQuery influenced API that ProcessWire offered. For example you can use php queries such as: $pages->find("selector"); $pages->get("selector, path or ID"); to find content in the system - you can even filter your queries by template type, fields attached to that item, etc. You can even use a range of selector operators. The API effectively works as a super powered and infinitely more flexible alternative to the WordPress loop. Cross referencing pages easily Complex cross-linking between portfolio items was needed so that capabilities, technologies and services could be linked to each item. It was easy to create a taxonomy system that worked the exact way required once the fundamental concept of how pages work in ProcessWire was understood. Building navigation that works Unlike a lot of CMSs that work effectively as ‘bucket systems’ - meaning that content is separate from any kind of structure or hierarchy by default in the system - whereas everything in ProcessWire is a page and arranged hierarchically. Whilst this may seem strange and restrictive to some used to the aforementioned ‘bucket systems’ - it works incredibly well and enables you to build navigational structures that are easy to plot a current location in. It is also something easy enough to break away from if you want a more ‘bucket’ type system. For example, in Drupal and WordPress it can be very difficult to highlight the navigation on a website if you are using custom content types. Try using custom post types in WordPress and keeping your navigation tracking which page the user has landed on - it’s extremely difficult without a fair bit of custom development (this is true as of the time of writing - WordPress 3.3.1). Because ProcessWire uses a structure and hierarchy by default - this structure makes building navigation that can track the current page very simple. Easy / flexible admin system The admin system in ProcessWire was easy and fluid to use, logical and stable. The admin system can also be overridden with templates (there are already some great community contributed templates). Modules used Whilst ProcessWire has a number of contributed modules from a thriving and helpful community - absolutely no additional modules were needed. All functionality on the website was achieved from a vanilla version of ProcessWire. Performance Another area of importance was the performance of ProcessWire. Again, Ray found this aspect to be well covered with built in caching capabilities that were thoughtfully included ‘out of the box’. The caching was simple to enable on templates and fields. The memory footprint of the Ray Dale Multimedia website was a third of that of Drupal on the same website without using addon caching plugins. Challenges The only real challenge faced was understanding that ‘pages are everything’ in ProcessWire. You build categories, taxonomy, articles, blog systems with the ‘page’ (and any fields it contains) being the basic building block for all of this. ‘Pages’ in ProcessWire can be attached to templates and injected with fields to enable the creation of literally anything conceivable. However, understanding this concept takes a little work for people used to other CMSs such as Drupal, WordPress and Joomla. However, in context - and compared to other systems - this learning curve is still fairly easy. There are so many other time savers that this learning curve becomes negligible. The other area that Ray had to understand about ProcessWire was that there aren’t any template system paradigms that exist in Drupal and WordPress. Other systems have parent and child templating systems with default parent templates that can be leveraged, however, because ProcessWire makes no assumptions on how you are going to build a project (being a true framework) you currently need to create your own template files. This is made easy by good documentation on the ProcessWire website and a decent set of ‘starter’ template files that come as part of the default install. Conclusion ProcessWire was an absolute dream to work with. Ray found it to be very stable, well thought out and hugely flexible. So much so in fact, that Ray has decided to standardise on using ProcessWire for upcoming web design projects. The flexibility and simplicity of the admin system, combined with power in frontend development that ProcessWire provides is something that Ray found to be liberating and more importantly ‘best in its class’.

Greetings, Doing a Google search on this topic, Sublime Text seems to be getting all the attention lately! I am planning to try it. For the moment, I use Espresso. On this topic, what do people think about adding ProcessWire snippets to Sublime? Thanks, Matthew

I use Sublime Text.

Maybe simpler to do this: if($page->is("name=slideshow18|slideshow28|slideshow38|slideshow88")){ // page has one if the names } Or if it doesn't matter what number if($page->is("name^=slideshow")){ // page name starts with slideshow }

CONGRATULATIONS!!! From one father to another... You have some important matters to attend to right now, so don't worry too much about the forum! Let us know how we can help. Again, congratulations! Matthew

Thanks Soma, this is a great module and a recurring need--I think it will be helpful to a lot of people, including myself. Nice work with the good documentation too.

Sounds great, I look forward to seeing it. As promised, here's a full example of a simple contact form. This is bare bones, but safe. I've left out spam prevention measures, which I'll be happy to follow-up with if you'd like. Below is an entire template file. I figured it was simpler to show this way rather than splitting into multiple files. Though when forms get really large, I tend to split them in multiple files (and include them). But for smaller forms, I do it like the example below. /site/templates/contact.php <?php $sent = false; $error = ''; $emailTo = 'nikola@company.com'; // or pull from PW page field // sanitize form values or create empty $form = array( 'fullname' => $sanitizer->text($input->post->fullname), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), ); // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate foreach($form as $key => $value) { if(empty($value)) $error = "<p class='error'>Please check that you have completed all fields.</p>"; } // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Contact Form", $message, "From: $form[email]"); // populate body with success message, or pull it from another PW field $page->body = "<h2>Thank you, your message has been sent.</h2>"; $sent = true; } } if(!$sent) { // sanitize values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } // append form to body copy $page->body .= <<< _OUT $error <form action="./" method="post"> <p> <label for="fullname">Your Name</label><br /> <input type="text" id="fullname" name="fullname" value="$form[fullname]" /> </p> <p> <label for="email">Your Email</label><br /> <input type="email" name="email" id="email" value="$form[email]" /> </p> <p> <label for="comments">Comments</label><br /> <textarea id="comments" name="comments">$form[comments]</textarea> </p> <p><input type="submit" name="submit" value="Submit" /></p> </form> _OUT; } // include site's main template which outputs everything include("./main.php");