Leaderboard

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.

Hi all This module was sponsored by Jason as per this topic: http://processwire.com/talk/topic/3566-email-image-module-development/ It's quite similar to horst & ryan's EmailImage module, but supports multiple email addresses for sending emails to different parts of your site, also allowing you to select different templates. There is also a delimiter option whereby you can split up the email's content and have text appear in the body or sidebar etc. Here's a video to show you what I mean. The video may well be of interest to other module authors as I used some Ajax to push what can normally be done in the module config - hope you like it There was the temptation to build on the EmailImage module with this one, but I already had code for my Helpdesk module (work in progress) that parsed emails using Flourishlib and wanted to use that code instead for this one. EDIT: Also worth noting is that unlike the EmailImage module, this doesn't come with a pre-built gallery template for the front-end. This is intentional as you could pipe emails into any part of a site you like, so I couldn't make assumptions as to usage of the content. You can download it via the modules directory.

I build this yesterday and Ovi sponsored it for open source. Little tweaks and testing before release.

Another minor addition to happy family of ProcessWire modules: Markup Load Atom. Markup Load Atom was forked from Ryan's Markup Load RSS to provide similar functionality for Atom feeds: given Atom feed URL it loads it and allows you to foreach through it and/or render it with built-in render() method. Get it from GitHub: https://github.com/teppokoivula/MarkupLoadAtom Note: I've been using this on a production site for a while now, but haven't really worked much with Atom feeds specifically. If you're a guru in that matter and feel that something is odd or plain wrong here, please let me know and I'll see what I can do. How to use With your own markup: $atom = $modules->get("MarkupLoadAtom"); $atom->load("https://github.com/ryancramerdesign/ProcessWire/commits/master.atom"); foreach($atom as $item) { echo "<p>"; echo "<a href='{$item->url}'>{$item->title}</a> "; echo $item->date . "<br /> "; echo $item->body; echo "</p>"; } Or with built-in rendering: $atom = $modules->get("MarkupLoadAtom"); echo $atom->render("https://github.com/ryancramerdesign/ProcessWire/commits/master.atom"); Installation Installing is identical to most other modules; just copy MarkupLoadAtom.module or whole MarkupLoadAtom directory to your /site/modules/, hit "Check for new modules" at Admin modules area and install "Markup Load Atom". More examples, detailed instructions etc. can be found from README.

The reason that next (and prev) can't be optimized in that way is that it assumes that the sort field is "sort". Typically when you've got a large quantity of pages, they have some other sort, like date or title or who knows what. So that "sort" field certainly could be directly queried, but it wouldn't mean anything unless the page was set for manually sorted children. Manually sorted children is the only situation under which PW can keep that "sort" field up-to-date. If you've got thousands of children, chances are you aren't manually sorting them. You can get around the scalability consideration just by determining the 'prev' or 'next' using criteria specific to your situation. For instance, lets say your pages were sorted by a field named 'date': $date = $page->getUnformatted('date'); $next = $page->parent->child("date>$date, sort=date"); $prev = $page->parent->child("date<$date, sort=-date");

Hi, today I came across a site with a really good presentation tool in HTML5: pik7. English Livepresentation is here: http://pik.peterkroener.de/ The blogpost and video screencast is in german only, but the tool (code) itself is in english. Its' hosted on Github and is GPLv2.

gfdesign, I spent years working with TXP and still maintain a small handful of TXP sites for existing clients. You really don't need to know very much PHP to build sites with ProcessWire. Sure, if you want to build complex things, then you might need a little deeper understanding, but for most sites you don't need more than the basics. Using the example you posted above, let's compare (as closely as possible), ProcessWire to TXP methods. ProcessWire // get pages with the template "skyscraper" $skyscrapers = $pages->find("template=skyscraper"); // for each "skyscraper" display the following foreach($skyscrapers as $s){ echo "<li><a href='{$s->url}'>{$s->title}</a></li>"; } Texpattern In your page: // Get all articles with the category "skyscraper", use form "list" to display them. <txp:article_custom category="skyscraper" form="list" /> In the form "list": // for each article display the following <li><txp:permlink><txp:title /></txp:permlink></li> If you take the TXP tags out of it, there really isn't much difference. When you call a form in TXP, you are basically creating a foreach(). For creating most sites with PW you really don't need to know all that much PHP. Brush up on the basics and dive in. Ask lots of questions, there are nice folks here who are always willing to help. Oh yeah... Welcome.

hi all, new PW site launch: http://www.ohmspeaker.com/ some of the modules that were helpful or essential for this: cropimage formbuilder fredi importcsv minify piwik analytics procache batcher redirects version control template decorator modules manager page link abstractor sitemap xml admin custom pages markup simple navigation (for the sitemap) forum topics related to this site dev: Legacy Site URL redirects: http://processwire.com/talk/topic/3641-redirect-legacy-url-to-new-pw-page/ Clean up spelling: http://processwire.com/talk/topic/3519-use-api-to-spellcheck-whole-siteclean-up-spacing/ hashes in URLs on change selected product http://processwire.com/talk/topic/3496-help-with-url-param-change/ FormBuilder http://processwire.com/talk/topic/2904-how-to-redirect-by-id/ http://processwire.com/talk/topic/2821-3rd-party-send-conditionally/ http://processwire.com/talk/topic/2820-use-session-to-remember-form-selections/ Custom Menus http://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/ other notes: The skyscraper profile provided the example for how to get started with the advanced product search, a.k.a. the speaker finder. The standard search has been extended to show results in different categories. there is some use of Soma's word limiter for the news teaser text, and for making meta descriptions out of body fields, from this topic: http://processwire.com/talk/topic/3429-how-to-set-text-linecharacter-limits-in-templates/ the design is built on twitter bootstrap framework Fredi proved to be totally essential for the client, in being able to rapidly edit things without having to find things in the admin. This site is going to replace an existing site on a different domain (ohmspeakers.com). At some point we weren't sure if/how we would be able to handle the shopping cart element, and then found foxycart, which proved to be the best choice, very flexible, and easy to implement for this type of site. FC is hands down the simplest and easiest way (imho) we could achieve things like the legacy product pages, where there are various parts and upgrades displayed on 1 page. this version is sort of a "v1", and will be expanded/improved a lot for a v2, which would happen in about 4 months.. BTW - these speakers are really good; i now own 3 pairs ... they look great and do sound totally amazing...! -marc

I found (after 2-3 Projects using PW) that it's a good technique to use templates in a way I think hasn't been thought of yet really by some. (Although the CMS we use at work for year, works this way.) I'm sure I'm maybe wrong and someone else is already doing something similar. But I wanted to share this for everybody, just to show alternative way of using the brillant system that PW is. Delegate Template approach I tend to do a setup like this: - I create a main.php with the main html markup, no includes. So the whole html structure is there. - I then create page templates in PW without a file associated. I just name them let's say: basic-page, blog-entry, news-entry... but there's no basic-page.php actually. - Then after creating the template I make it use the "main" as alternative under "Advanced" settings tab. So it's using the main.php as the template file. - This allows to use all templates having the same php master template "main.php" - Then I create a folder and call it something like "/site/templates/view/", in which I create the inc files for the different template types. So there would be a basic-page.inc, blog-entry.inc ... - Then in the main.php template file I use following code to delegate what .inc should be included depending on the name of the template the page requested has. Using the TemplateFile functions you can use the render method, and assign variables to give to the inc explicitly, or you could also use just regular php include() technic. <?php /* * template views depending on template name * using TemplateFile method of PW */ // delegate render view template file // all page templates use "main.php" as alternative template file if( $page->template ) { $t = new TemplateFile($config->paths->templates . "view/{$page->template}.inc"); //$t->set("arr1", $somevar); echo $t->render(); } <?php /* * template views depending on template name * using regular php include */ if( $page->template ) { include($config->paths->templates . "view/{$page->template}.inc"); } I chosen this approach mainly because I hate splitting up the "main" template with head.inc and foot.inc etc. although I was also using this quite a lot, I like the delegate approach better. Having only one main.php which contains the complete html structure makes it easier for me to see/control whats going on. Hope this will be useful to someone. Cheers

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

Hello, I need something that is probably quite simple for anyone that is familiar with developing modules in PW. I need to augment the FieldtypeComments module with a 5-star rating field. That's all. The user would see an additional drop-down field when they post the comment that allows them to select a value from 1 to 5 stars. I intend to make the resulting module available publicly for the community after it is developed, as i think it is an essential part of the module collection that is sorely missing at the moment. Please contact me on Skype ( my ID is ovidiu.savescu ) with offers on how much this would cost. Thanks!

I am looking for a developer with experience using both Shopify & ProcessWire. US-based developers only for this project, please. Please contact me at: marc at marccarson.com; feel free to mention any experience you have with Shopify, PW, & e-commerce. Budget for this developer's work on the project would probably be north of $5K but could change as we discuss the client's needs prior to submitting a proposal. Thanks.

Thanks Guys, for so many examples using TXP as reference. All of you have been a great help so I'll put on practice your advices. Surely, I'll go back for more questions about lists of pages or other things. I hope to be helpful to you as well. Best regards

Why not use on every overview-page: $session->set('lastOverviewPage', $page->url); and on every gallery page: echo '<a href="' . $session->get('lastOverviewPage') . '">go back to overview</a>'; ?

Check it out this page with useful jquery plugins. Might help you!

Wow! Nice one; you've been busy! Yes, there have been two or three questions from MODx'ers in the forums about something like this - the ability to randomly, directly call snippets, chunks and TVs within the body field/area in TinyMCE. Previously they've been pointed to shortcodes and tag parser. Hanna is certainly more powerful and would solve this issue easily. I can't wait to see the creative ways people use this . Thx for the module!

Must see video - f*ck you pay me http://vimeo.com/22053820

@doolak You may try this. I took my code and modified it a little so it may not work out of the box. //parent of your galaries $galleryHome = $page->parent; //all your published gallery pages (make sure you use the same sort option as in your template when output) $galleries = $galleryHome->children; //page being viewed $currentPage = $page; //number of galleries per page $galleriesPerPage = 5; //index of the page in array $PageIdInArray=NULL; //the number of the page your current gallery belongs $pageNum=0; foreach($galleries as $i => $p) { //iterate every galleriesPerPage time if (($i%$galleriesPerPage)==0) { $pageNum++; } // if ($currentPage->id == $p->id) { $PageIdInArray = $i; break; } } //if we found our page in array and $pageNum<>0 if ($PageIdInArray && $pageNum) { //construct url to the galleris landing page $url = $galleryHome->url . "page" . $pageNum; echo "<a url='$url'>Back to galleries</a>"; }

This is the module Antti refers to - very good work https://github.com/apeisa/ProcessUserExtended

Finally merged some updated from Teppo - thanks! Now includes multisite support: http://modules.processwire.com/modules/markup-sitemap-xml/

A newly released CSS library from the folks at Yahoo!: http://purecss.io/ There already are a gazillion out there but this does seem like a pretty neat CSS baseline for some projects.

Thanks for the link. I've been looking for free mind mapping software for a while now. Nearly purchased a mind map Chrome/Googledrive extension but Freemind looks the ticket! Cheers.

Is made with FreeMind!

Wow, thanks horst, that's amazing. I love your graphical overview and video too. I will try it out next week.

And it's already got me wondering how easy it might be to build the presentations in ProcessWire and use this system... Hmmm....

In this case it makes sense to show an alternative way of doing what Reno showed. Just to make it a bit closer to the TXP example: <ul> <?php foreach ($pages->find("template=skyscraper") as $s): ?> <li><a href='<?=$s->url?>'><?=$s->title?></a></li> <?php endforeach; ?> </ul>

my MP3-SiteProfile: http://processwire.com/talk/topic/3604-release-localaudiofiles-mp3-db/

Sounds like your site_header_banner field allows more than one image. That's probably why it's returning directory path instead of image URL -- it doesn't know which image you want to output. Try altering that field to only allow one image (via field settings) or try doing this instead to get URL for first image in that field: <img src="<?php echo $pages->get("/site-settings/")->site_header_banner->eq(0)->url ?>">

A very interesting discussion posted by Soma here: "A different way of using templates / delegate approach" http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/

I have no idea why $_GET['q'] would be missing from the request when you specified it, but the only thing I can think of is if your request possibly resulted in a 301 first that went by unnoticed? This could happen if you specified the URL without a trailing slash in your <form action> attribute. In modern versions of MySQL it seems there isn't much difference even when you get into thousands of records. I suspect the real difference starts showing up in the hundreds of thousands to millions of DB records to search.

Works perfect. Little addition to avoid that the index.php gets into the google index. # Redirect index.php to root RewriteCond %{THE_REQUEST} ^.*/index.php RewriteRule ^(.*)index.php$ http://%{HTTP_HOST}/$1 [L,R=301]

Follow up: A few URLs are hard-coded to /, and that ends up a 404 if you have PW installed under a sub-context (ie, localhost/pwire/....)

Khan: Great module! I see someone has already reported the problem with the avatar attribute already existing on a profile, but has no value (line 449) I encountered the problem on a new install, with no users but what comes by default. I'm currently logged in as the admin on the admin pages, and went to the main site and used the "profile" link that was added to the top menu. Someone above tried a solution, but I haven't yet -- perhaps checking for the length of the url > 0? Also, on the checkinstall, it is checking twice for the birthdate field, and skipped checking for the gender (lines 685 and 688). I hope that helps you and others! Thanks again!

No problem, I just confused by terminology I guess. This should get you there: $language->getUnformatted('title')->getLanguagevalue($language->id)

How do I get access the FormBuilder forum? I purchased a license, but didn't see anything about how to access it. Maybe because I used a different email address than on this forum? Anyway, I have a question about how I might be able to integrate the form with a payment processor (probably just PayPal). Basically, all I need is a way to gather all of the value attributes from all of the selected radio buttons in the form and add them up into a single input element (total price) that can then be posted to an outside URL (set in the formbuilder settings). I've been trying to do this using jQuery, but I think that the fact that the form is in an iframe may pose an issue. I haven't worked a lot with iframes, but my guess is that the form submission isn't going to post any values from outside of the iframe... Am I right? Edit: Oops, especially since the form tag is inside the iframe... Yeah, that definitely won't work, at least not using the embed method. Not sure if this topic has come up already. Maybe someone has developed a better solution for it. Edit: Oops again... I'll PM Ryan about the support form.

Hey, no worries on this one, I figured it out. It was a namespace issue that was causing the confusion. Cheers ...

Ryan, only getting around to working with it, all seems to work great and very fast! Thanks

yeah thumbs down for Drupal & Joomla 6 (2013) Movie saw it last week, in this 5th sequel, Drupal meets Joomla, Drupal loses Joomla, Drupal finds Joomla again, marries Joomla... Drupal & Joomla VII (2014) (sci-fi) Drupal meets Joomla. Drupal loses Joomla. Drupal builds Joomla. Drupal, Wordpress & Joomla (2015) Drupal meets Wordpress. Drupal loses Wordpress. Drupal finds Joomla. Chase takes forty minutes, dialogue six, and gun shots fill in void. Drupal & Processwire (2016) Drupal meets Processwire, they belong to different gangs, war breaks out.

You're welcome. Here's a good overview how Hook works: http://processwire.com/api/hooks/ Also checkout the captain which shows you all the hooks available: http://somatonic.github.io/Captain-Hook/ And here an example, written in the browser and not tested: // Inside your autoload module you have installed... public function init() { $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'hideFields'); } public function hideFields(HookEvent $event) { // Do nothing if we don't edit a user if ($this->page->template != 'user') return; // Get the form instance returned from the hooked method $form = $event->return; // Define fields to hide per role $hideFields = array( 'role1' => array('field1', 'field40'), 'role2' => array('field5', 'field2'), ); // Hide the fields foreach ($hideFields as $role => $fields) { if ($this->user->hasRole($role)) { foreach ($fields as $field) { $f = $form->get($field); $f->collapsed = Inputfield::collapsedHidden; } } } $event->return = $form; }

After having had such fun creating a first theme for Textadept (see here http://processwire.com/talk/topic/3518-what-ide-do-you-utilize/?p=34637), I now created another theme, this time inspired by the colors of PW You can download Textadept here http://foicica.com/textadept/ And the ProcessWire theme here https://github.com/ocorreiododiogo/processwire-theme

Thanks, fixed I've finally managed to get images updateable. Currently only works for single Image fields but I believe I'll be able to adapt it for the multiple images field. I'll push the update onto Github tomorrow morning after I've fleshed things out.

You beauty diogo! Everything has gone as planned. As I said, Processwire so intuative and easy to use... I have new insight into the repeater field now too. Will use those in a different light. Thanks for your help Wanze and diogo - both invaluable... Regards

I also feel that repeaters are not the best way to go for you. Reapeaters are for information that will be needed more than once, In your case would be more than one per company. I'm guessing that you used the repeater fields to organize the information in blocks. If this is right, that would be better done with with fieldset or fieldsetTab. The first one groups visually the fields in the template, and the second, separates them in tabs (in the backend, this is not the answer to your question about tabs in the frontend). To use them, create a new fieldsetOpen field for each of the groups you have there (Applicant Details, Primary Contact, etc...), and it will automatically create also a "fieldName_END" field for each. In your template organize the fields between the opening and closing field of each group, and you will have a nicely organized edit page. Same applied for fieldsetTab, except that it creates a tab for each group instead of only grouping them visually under a name. To create the tabs --this will depend a lot on what js plugin you will use, if you will use one. I will take the jQueryUi tabs as an example--, you will need to organize the content inside the tabs divs: <div id="tabs"> <ul> <li><a href="#tabs-1">Applicant Details</a></li> <li><a href="#tabs-2">Primary Contact</a></li> <li><a href="#tabs-3">Secondary Contact</a></li> </ul> <div id="tabs-1"> --here goes content-- </div> <div id="tabs-2"> --here goes content-- </div> <div id="tabs-3"> --here goes content-- </div> </div> The frontend will ignore the groups that you created in the backend, so you will have to organize everything manually: <div id="tabs"> <ul> <li><a href="#tabs-1">tab name</a></li> <li><a href="#tabs-2">tab name</a></li> <li><a href="#tabs-3">tab name</a></li> </ul> <div id="tabs-1"> <p><?=$page->organisation_name?></p> <p><?=$page->sector?></p> </div> <div id="tabs-2"> <p><?=$page->primary_first_name?></p> <p><?=$page->primary_last_name?></p> <p><?=$page->primary_email?></p> <p><?=$page->primary_phone?></p> </div> <div id="tabs-3"> <p><?=$page->secondary_first_name?></p> <p><?=$page->secondary_last_name?></p> <p><?=$page->secondary_email?></p> <p><?=$page->secondary_phone?></p> </div> </div> edit: I changed the field names of the contact to primary_something, and secondary_something, because they are different info, and they need different names on the same page.

You could also do this: if ($page->is("name=slideshow18|slideshow28|slideshow38") { I prefer this method, since it's slightly shorter, bit more readable and doesn't need to fetch any additional pages just for comparison.

PWired, I think what is being said here is that there is more to site rankings, SEO than writing lots and lots of articles. Of course, you can write lots of articles if you want...but it doesn't mean your site rankings will go up. There are a number of issues you raise here so maybe not good to get mixed up. Here's my take. Blog: You can easily create a blog in PW. This will come with all the ease of templating and powerful API that PW offers. Of course you can create one in WP too and none of us will be offended . Personally, I wouldn't create anything with WP..I've tried it before and don't want to go there again SEO/Site rankings: Whether a blog or some other sort of site, there are tips on how to improve your search rankings. Google these. Templating: There are a number of approaches. Key questions are these: Do I need lots of templates or few? How do I justify whether few or lots? The fewer the templates you can get away with the better for you, I think. By using PHP conditional statements (if's) with PW you can be as versatile as possible and use a few templates. How to organise your pages: Here I refer to the images questions. I'm sure you know that there are various approaches to this in PW. You can use Soma's image manager (in Alpha currently!); You can create one page to hold all your images. You can upload multiple images for each page. You can include inline images in the rich text editor (not all like this ). Which one you choose depends on your needs. Read more, etc...that's ridiculously easy in PW. Have you looked at the default PW installation? There are a number of ideas there. E.g. , the text before the read more can come from a description or summary text field. You click more it shows you the whole article. E.g. echo "<p>{$myarticle->summary}<a href='{$myarticle->url}'>Read more...</a></p>"; That will give you something like: I gotta run. I'll probably write more later. This reminds me, I really need to write that tutorial about how to approach templating... Hope this helps...

I've run into a similar issue on one of my sites that has a lot of accounts to manage. I'm hoping to improve the core modules (ProcessPageType and/or ProcessUser) in this regard whenever there is bandwidth to pursue it.

Just found another really interesting lightbox. Magnific Popup is a free responsive jQuery lightbox plugin that is focused on performance and providing best experience for user with any device. It's build for speed and seems highly customizable through css (and not javascript like most).

The notices system actually doesn't have anything to do with jQuery UI other than that the default admin theme makes use of jQuery UI class names when generating the markup for notices. But for your own front-end, you can make use of the $notices API variable to output them however you want. It can be as simple as this: echo "<ul>"; foreach($notices as $notice) { $class = $notice->className(); $text = $sanitizer->entities($notice->text); echo "<li class='$class'>$text</li>"; } echo "</ul>"; Then you would want to style the two type of notices in your CSS: .NoticeMessage { color: green; } .NoticeError { color: red; }

Yes helper functions like this can be included using a separate php like in the head.inc and used throughout your templates. I extracted this function from a module I have for a project. This module has various helper function and then I load it in the templates. It's much the same as if I would include a php with functions and just personal preference. For example: $helpers = $modules->get("TemplateHelpers"); then use it like this where I need it. echo $helpers->wordLimiter($page->body); I'm not sure what you mean by applying the function to the body. I use this function to create teaser texts that are limited, and show the complete body only on the detail page. Of course you could modify the body output, that every time you do an echo $page->body, it will run it through a function, but I'm not sure this is a good practice. This using a hook on the formatValue of textfields would do it: (directly in template like a include, or by making it a module) function wordLimiter(HookEvent $event){ $field = $event->argumentsByName('field'); if($field->name != 'body') return; $str = $event->return; $limit = 150; $endstr = ' …'; $str = strip_tags($str); if(strlen($str) <= $limit) return; $out = substr($str, 0, $limit); $pos = strrpos($out, " "); if ($pos>0) { $out = substr($out, 0, $pos); } return $event->return = $out .= $endstr; } wire()->addHookAfter("FieldtypeTextarea::formatValue", null, "wordLimiter"); // now this will trigger the above hook echo $page->body; But it's a little cumbersome, as you can't set the limit. Also this strips tags and on HTML text you'll lose formatting. But just to show adn example what is possible. From your post I guess you like to do something like: echo $page->body->limit(150); // not possible It's not possible to do this, because the $page->body, body is just a string and not an object you could add methods to it. But something like the following would be possible using hooks. echo $page->wordLimiter("body", 120); You can use addHook to add a method wordLimiter to page: function wordLimiter(HookEvent $event){ $field = $event->arguments[0]; // first argument $limit = $event->arguments[1]; $endstr = isset($event->arguments[2]) ? $event->arguments[2] : ' …'; $page = $event->object; // the page $str = $page->get($field); $str = strip_tags($str); if(strlen($str) <= $limit) return; $out = substr($str, 0, $limit); $pos = strrpos($out, " "); if ($pos>0) { $out = substr($out, 0, $pos); } return $event->return = $out .= $endstr; } // this will add a custom method to Page object wire()->addHook("Page::wordLimiter", null, "wordLimiter"); // now you can do this echo $page->wordLimiter("body", 100); // or this echo $page->wordLimiter("summary", 100);

I regularely express myself.