Most Liked Content

I wanted to give you a little preview of a new module I've been working on recently: the Form Builder module. This module lets you create simple-to-complex forms and place them in your site without any need for development.

In this video we show how we can create, publish and test a simple contact form in less than 5 minutes. Then we take a quick look at a more complex form (already produced).

I recommend viewing the full screen + HD 720p version so that you can see it more clearly than in this small forum embed.



(note: there's no sound, so no need to adjust your volume)

More about the Form Builder
The Form Builder has many options for the developer to customize output and create their own themes, markup, etc. But the goal here was to build something that could enable you (or your client) to publish a form in less than 5 minutes, so that's the focus of this video.

This tool is literally easy enough for your clients to create and manage their own forms. Or from a developers perspective, it takes something that used to consume hours and makes it happen in minutes.

Form results save in the database and optionally can be CC'd to you by email. Result entries and be viewed, filtered by date, and even edited in the admin. You can export results to a spreadsheet as well. I'm working on the ability to export to pages, though that isn't quite ready yet.

How the Form Builder will be licensed
This module will be individually licensed on a per-site basis for a small license fee. It will also be available for free personal use to established forum members. Basically, I want to see if I can substitute some of my client work to focus on ProcessWire instead. And in order to do that, I need to have an income (I have a family to support). So I thought that building a special tool like this would be a way to make a go of it.

A lot of you have asked to make donations to the ProcessWire project, and while we still won't be able to take donations, you will be able to support the ProcessWire project by purchasing and using the Form Builder in your own client projects. So a lot of motivation for this module came from wanting to provide something really special for all that had wanted to support ProcessWire.

After a few months of work, I'm pretty happy with how this module has turned out -- it's already saved me tons of time in my client projects. So I'm thinking and hoping you guys will really like it too. I look forward to your feedback.

Sorry I'm a little behind with messages here,  I'll be caught up by mid week. But I've got a good excuse. Yesterday Karena Savannah Cramer was born. She is our 2nd daughter (Hanna Ryan, age 3 is our first). We will all be coming home from the hospital hopefully tomorrow. 

Thanks Steve! That's very kind of you.

What you may not know is that I've been raising my beer glass to all of you this whole time. Here's the rest of my profile photo

ProcessWire now implements ALL of the jQuery traversal functions in the Page API. Existing ProcessWire versions already implemented most of them, but once we started updating parent() and parents() to support selectors, I figured we might as well be fully complete and consistent with the jQuery equivalents. Now we are. The following functions were added or updated:

• $page->parents([$selector]) -- Now you can specify a $selector and it will return parents that match your selector. 
• $page->parent([$selector]) -- Now you can specify a $selector and it will return the closest matching parent. 
• $page->closest($selector) -- Same as parent($selector) except that it considers the current page in addition to the parents.
• $page->parentsUntil($selector, [$filter]) -- Return all parents from current till the one matched by $selector, optionally filtering them afterwards by $filter (a selector string). Note that $selector may be a selector string, a Page, a path, or an ID. 
• $page->next([$selector]) -- Now you can specify a $selector and it will return the closest matching next sibling. 
• $page->nextAll([$selector]) -- Returns all siblings that come after this $page, optionally filtered by a $selector. 
• $page->nextUntil($selector, [$filter]) -- Return all sibling pages after this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID.
• $page->prev([$selector]) -- Now you can specify a $selector and it will return the closest matching previous sibling. 
• $page->prevAll([$selector]) -- Returns all siblings that come before this $page, optionally filtered by a $selector. 
• $page->prevUntil($selector, [$filter]) -- Return all sibling pages before this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID.

Arguments in [brackets] are optional. 

 

These functions duplicate the arguments and behavior of their jQuery counterparts. The exceptions are that parent(), next(), and prev() have a slightly different behavior: they will traverse to find the closest match (which I thought was a lot more useful in our context). In jQuery, they don't traverse beyond the direct parent/next/previous item in the DOM. 

 

As before, all the next and prev functions should be used cautiously when $page has a large amount of siblings. All these functions require loading all the pages they interact with, as comparisons are done in memory and not via SQL queries. All of them accept an optional last $siblings argument, which is a PageArray of siblings you want it to analyze (which is presumably a more limited set), and this is what you'd use if you need to scale to thousands of pages when using these functions. But if you aren't dealing with huge amounts of pages, then you don't need to consider this.  

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.proce...rocess-batcher/

Github: https://github.com/w.../ProcessBatcher

 

 

Editing

 

How does it work?

1. Search your pages with a selector. You can check if you want to include also hidden/unpublished pages with the filters.
2. Select the pages you want to execute an action (the action only gets executed on "checked" pages).
3. Select the action and if necessary, additional data like the new parent or the new template.
4. 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?

1. Select a parent where your new pages will be added as children
2. Add as many pages as you want by clicking "add Page"
3. 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" - i'll make your life easier ;-)

 

You can drag & drop the table rows should you want to change the order. The draging 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.c...eate-pages-wip/

 

Cheers

 

ProcessWire is fast. With ProCache, ProcessWire is insanely fast! ProCache provides the ultimate performance for your website by completely bypassing PHP and MySQL and enabling your web server to deliver pages of your ProcessWire site as if they were static HTML files. 

 

The performance benefits are major and visible. Using ApacheBench with the homepage of the Skyscrapers site profile, we completed 500 requests (10 concurrent) to the homepage. The amount of time occupied to complete each of these was as follows:

• 29 seconds: no cache enabled
• 6 seconds: built-in cache enabled
• 0.017 seconds: ProCache enabled

As you can see, the performance benefits are substantial. ProCache gives you the ability to drastically reduce server resources and exponentially increase the amount of traffic your server can handle. This is especially useful for traffic spikes.

 

Beyond measurements, ProCache makes your website feel faster to users, respond faster to search spiders (which can help with SEO), and helps to conserve server resources for requests that actually need PHP and MySQL. 

 

ProcessWire is already very fast, and not everybody necessarily needs what ProCache delivers. But regardless of whether you need it or not, there is little doubt that you can benefit greatly from ProCache.

 

For an example of ProCache in action, visit processwire.com or the skyscrapers site. Look in the lower right corner of the page (in the footer). If it says "ProCache", it means the page was delivered via ProCache. We did this for demonstration purposes (ProCache does not put anything in your markup unless you tell it to).

 

More information about ProCache can be found on the ProCache documentation page. 

 

Please note

 

There is a known issue when using ProCache with the LanguageLocalizedURL module. I hope to have this figured out soon, but for the moment you should not use ProCache in combination with that module as it doesn't appear to work in full.

 

ProCache does not yet support multi-host capability (i.e. cache and delivery of different content per hostname), but it will very soon. 

 

How to get it

 

Like with Form Builder, ProCache was produced as a commercial module to support development of ProcessWire. It is now available for purchase here. 

 

ProCache is in a beta test period. As a result, it's being offered with introductory pricing that may increase once we're out of that period. During the beta test period, I just ask that you let me know if you run into any bugs or issues during your use of ProCache. I also recommend that you follow the usual best practices with regard to backing up your site and testing everything before assuming it's all working. Beyond the introductory pricing, you may also use coupon code PWPC-BETA for 10% off the listed prices at checkout. This code will expire as soon as we're out of beta. 

 

When you get ProCache, you'll also get 1-year of access to the ProCache-members support and upgrades board, available here in the ProcessWire forums. Upgrades to ProCache will also be posted there for download. 

 

Disclaimer: At the date/time that I'm writing this, I think that I am currently the only one using ProCache in production use. That's why I'm providing it with the lower costs and coupon. If you are running production sites where everything must always work perfectly, you will either want to: 1) wait to install on important sites till it's out of beta; or 2) test thoroughly on a staging server or localhost before taking it to production use. In either case, always make sure you have good backups anywhere you install new modules, and always test to double check everything works how you want it to. 

• Get ProCache Now
• ProCache Documentation

Below are a few screenshots that show the configuration screens of ProCache. 

 

Have questions about ProCache? Please reply to this topic. Thanks for your interest in ProcessWire ProCache!

Thanks for the likes It means a lot to me you guys seem to really like me.

 

I don't know what this number means but it's a little scary... heh

Just wanted to share what I recently used to create forms in modules and in frontend using the API and Inputfield modules PW provides and uses on its own. I think many newcomers or also advanced user aren't aware what is already possible in templates with some simple and flexible code. Learning this can greatly help in any aspect when you develop with PW. It's not as easy and powerful as FormBuilder but a great example of what can be archieved within PW.

Really? Tell me more

The output markup generated with something like echo $form->render(); will be a like the one you get with formbuilder or admin forms in PW backend because it uses the same approach.

Now since 2.2.5~ somewhere, the "required" option is possible for all fields (previous not) and that makes it easier a lot for validation and also it renders inline errors already nicely (due to Ryan FormBuilder yah!).

For example the Password inputfield already provides two field to confirm the password and will validate it. De- and encryption method also exists. Or you can also use columns width setting for a field, which was added not so long ago.

Some fields like Asm MultiSelect would require to also include their css and js to work but haven't tried. Also file uploads isn't there, but maybe at some point there will be more options. It would be still possible to code your own uploader when the form is submitted.

Validation?

If you understand a little more how PW works with forms and inputfields you can simply add you own validation, do hooks and lots of magic with very easy code to read and maintain.

You can also use the processInput($input->post) method of a form that PW uses itself to validate a form. So getting to see if there was any errors is simply checking for $form->getErrors();.

Also the $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automaticly. It's also worth noting that processInput() will work also with an array (key=>value) of data it doesn't have to be the one from $input->post.

Styling?

It works well if you take your own CSS or just pick the inputfields.css from the templates-admin folder as a start. Also the CSS file from the wire/modules/InputfieldRadios module can be helpful to add. And that's it. It's not very hard to get it display nicely.

Here an code example of an simple form.
 

 

<?php
$out = '';

// create a new form field (also field wrapper)
$form = $modules->get("InputfieldForm");
$form->action = "./";
$form->method = "post";
$form->attr("id+name",'subscribe-form');

// create a text input
$field = $modules->get("InputfieldText");
$field->label = "Name";
$field->attr('id+name','name');
$field->required = 1;
$form->append($field); // append the field to the form

// create email field
$field = $modules->get("InputfieldEmail");
$field->label = "E-Mail";
$field->attr('id+name','email');
$field->required = 1;
$form->append($field); // append the field

// you get the idea
$field = $modules->get("InputfieldPassword");
$field->label = "Passwort";
$field->attr("id+name","pass");
$field->required = 1;
$form->append($field);

// oh a submit button!
$submit = $modules->get("InputfieldSubmit");
$submit->attr("value","Subscribe");
$submit->attr("id+name","submit");
$form->append($submit);

// form was submitted so we process the form
if($input->post->submit) {

    // user submitted the form, process it and check for errors
    $form->processInput($input->post);

    // here is a good point for extra/custom validation and manipulate fields
    $email = $form->get("email");

    if($email && (strpos($email->value,'@hotmail') !== FALSE)){        // attach an error to the field
        // and it will get displayed along the field
        $email->error("Sorry we don't accept hotmail addresses for now.");

    }

    if($form->getErrors()) {
        // the form is processed and populated
        // but contains errors
        $out .= $form->render();
    } else {

        // do with the form what you like, create and save it as page
        // or send emails. to get the values you can use
        // $email = $form->get("email")->value;
        // $name = $form->get("name")->value;
        // $pass = $form->get("pass")->value;
        //
        // to sanitize input
        // $name = $sanitizer->text($input->post->name);
        // $email = $sanitizer->email($form->get("email")->value);

        $out .= "<p>You submission was completed! Thanks for your time.";

    }
} else {
    // render out form without processing
    $out .= $form->render();
}


include("./head.inc");
echo $out;
include("./foot.inc");

 

Here the code snippet as gist github: https://gist.github.com/4027908

Maybe there's something I'm not aware of yet, so if there something to still care about just let me know. Maybe some example of hooks could be appended here too.

Thanks

Okay this was very short notice so it is incredibly rough!
 

But this is for Diogo and all those others wedded to PW

 

 

(Organized, try listening at less than 120db!)

Fredi is friendly frontend editor for ProcessWire.

 

Code and documentation:

https://github.com/apeisa/Fredi

 

Module page:

http://modules.proce.../modules/fredi/

 

 

Hi

After reading this thread, I decided to make a module that helps generating PDF files of ProcessWire pages.

 

GitHub: https://github.com/wanze/Pages2Pdf

Modules Directory: http://modules.proce...les/pages2-pdf/

 

(I will add some docs and examples on GitHub later...)

 

This module uses the TCPDF library to generate the pdfs. It has fully UTF-8 and basic HTML support for rendering the pdfs.

The output of the pdfs is customizable with ProcessWire templates. These are stored in /site/templates/pages2pdf/.

After installing the module, you'll find some default templates in this folder:

• _header.php - Markup for the header of your pdfs
• _footer.php - Markup for the footer of your pdfs
• default.php - Default markup (more on this later)

You can now create your own templates inside this folder - just use the same name as your site-templates.

 

Example

I've enabled generating pdfs for the skyscraper template of ryans Skyscrapers-profile

with a template that outputs the data in a table along with the body text and the images:

 

 one-atlantic-center-pdf-4177.pdf   27.09K   144 downloads

 

How does it work?

 

1) Install the module

2) Go to the configuration and choose the template(s) that are allowed to create pdfs

3) In your template, add the following code where you want to appear the link to your pdf:

echo $modules->get('Pages2Pdf')->render();

The render method takes also an array of options - you can change the title and markup.

The default options are:

'title' => 'Print PDF',
'markup' => '<a href="{url}" target="_blank">{title}</a>',

4) Click on the link and test the output in your pdf.

5) Create your own template in /site/templates/pages2pdf/ and customize the _header.php and _footer.php

 

For example: If you have enabled the skyscraper template in the module-config, create a skyscraper.php file in /site/templates/pages2pdf/

If you create pdfs from a template that doesn't have a file in /site/templates/pages2pdf/, then the default.php template is used for

the markup.

 

Module options

• Page orientation (Portrait, Landscape)
• Page format (A4, A5...)
• Document margins
• Header and Footer margins
• Default font (Pages2Pdf includes three fonts: helvetica, times, courier. You can add more fonts by downloading tcpdf and copy the fonts to /site/modules/Pages2Pdf/tcpdf/fonts
• Default font size
• Print Header and/or Footer?
• Cache time

Technical Details

 

Module

• The pdfs are created on "first click" and stored in /site/assets/files/{page-id}/{page-name}-pdf-{page-id}.pdf for caching. The next clicks load the cached pdf.
• The pdfs are recreated after cache time is up or if you save a page in the admin.
• pdfs are always created dynamic when debug mode is on - bypassing the cache for development.

 

TCPDF

You can use very basic html for the markup. For example floats, margins and paddings don't work (yet).

See which tags are supported here: http://www.tcpdf.org...04f92187c621407

Instead of floats, use tables (yeah like in 1990 ). Actually the table tag does support padding for it's cells

You can also use inline css styles for most of the tags.

 

Check out the examples section of TCPDF to see what's possible with HTML:

http://www.tcpdf.org/examples.php

 

Important:

Make sure the html markup is valid. If you don't see any output in the pdf at all, this might be the problem.

Also you have to use double-quotes for the html attributes, single quotes don't work:

//Works
echo "<img src=\"{$image}\" alt="">";
echo '<img src="'.$image.'" alt="">';
//Doesn't work
echo "<img src='{$image}' alt=''>";

 

Advanced usage

TCPDF can do more than render basic html. You can build complex structures and fine-tune positions with Cells and MultiCells.

If you need access to the tcpdf object to set different options or generate your output in a different way than with Pw-Templates,

you can do this:

$pages2pdf = $modules->get('Pages2Pdf');
$tcpdf = $pages2pdf->tcpdf; //Or $pages2pdf->get('tcpdf');

//Some examples how to modify the tcpdf object

// set cell padding
$tcpdf->setCellPaddings(1, 1, 1, 1);

// set cell margins
$tcpdf->setCellMargins(1, 1, 1, 1);

// set color for background
$tcpdf->SetFillColor(255, 255, 127);

// Multicell test
$tcpdf->MultiCell(55, 5, '[LEFT]', 1, 'L', 1, 0, '', '', true);
$tcpdf->MultiCell(55, 5, '[RIGHT]', 1, 'R', 0, 1, '', '', true);
$tcpdf->Ln(4);

//Set the tcpdf object back before calling the ->render() method!
$pages2pdf->tcpdf = $tcpdf;
$pages2pdf->render();

 

Puh, it's lot of stuff to explain.

Hoping this module is useful for anyone having the need to create basic pdf files from Pw-pages.

 

Any feedback and testing is appreciated!

 

Cheers

ProcessWire Skyscrapers Site Profile

This is the profile for the skyscrapers demo site as seen at: http://processwire.com/skyscrapers/.

This site profile release also coincides with some upgrades to the Skyscrapers site. The updates were to re-do many of the template files to make them easier to read, convert some classes to functions (easier for folks to understand), and convert the maps to use the FieldtypeMapMarker module.

The main differences from the live site are that this profile excludes most of the photos and skyscraper text. Only the photos taken by me are included. This is to ensure we aren’t distributing any text or photos in case the license ever changes to something other than Wikimedia Commons. I can change the text/photos on my skyscrapers site, but can’t on any sites someone else sets up with this profile, so figure it’s better to play it safe.

Requirements

• ProcessWire 2.3
• OR ProcessWire 2.2 dev branch (2.2.12 or newer) ZIP

How to install

• Get the latest version of ProcessWire 2.3. At the time this text was written, ProcessWire 2.3 wasn’t yet released, so if that is still the case you’ll want to get version 2.2.12 or newer from the dev branch.
  
• Before running the installer, replace all the files/directories in the /site-default/ directory of ProcessWire with those from this site profile. This includes the following:
  
  • /site-default/config.php
  • /site-default/install/
  • /site-default/modules/
  • /site-default/templates/
• Now run the installer to complete the installation.

Template details

The template files in the profile take the approach of populating variables that are output within a main/shared markup file. This is different from the basic profile that ProcessWire comes with. Specifically, make note of the following files:

• /site/templates/_init.php – This file is automatically included before any template file is executed. We use it to initialize the variables we populate and include a shared library of functions.
• /site/templates/_out.php – This file is automatically included after any template file is executed. In our case, we use it to contain our main markup that also outputs the variables we populated.
• /site/templates/includes/functions.php – This is where we are keeping a shared library of functions, most for generating skyscraper list markup.
• /site/templates/*.php – These are the site’s template files, each named consistently with the page(s) they represent. The primary focus of these files is to populate the $content variable that is output by _out.php.

The use of _init.php and _out.php are something new to ProcessWire 2.3. These are specified in the /site/config.php:

$config->prependTemplateFile = '_init.php';
$config->appendTemplateFile = '_out.php';

Use of this new feature is optional. We’ve used it in this profile because it reduces the amount of redundant include() code necessary in each of our template files.

Download

• Skyscrapers Profile at GitHub or download ZIP file
• Skyscrapers Profile at modules.processwire.com
• Remember that you must have ProcessWire 2.3 (or 2.2.12 dev branch) or newer to install this profile.

I want to say thanks to all people in the forums for being here and make this place so special and a great place to be. There's some spirit and drive going, I think many other CMS forums can only dream of. It's still small and the quality of people and their support to help in the forums always amazes me. Even newcomers help other newcomers in a manner it's quite unique I think. Not saying there's might other places that are the same, but I don't know of any. Thanks for the nice experience to all of you!

Then the biggest thanks would go to Ryan our "Man on the Wire", always sharp and considered helpful, with brilliant ideas and execution. You build something very special here and while maybe some think it's not "sexy" enough, they don't know what's under the hood.  I think people are really excited to get direct responses from you and this is what makes them feel at home, which ignited some friendly fire and spread all over the place.


Quo vadis?

This is for now and I really wonder how it will be when the forums grows to a place, where I hardly will be able to catch up with new posts. Every other day I wonder how long Ryan will still be able to do so for every question in the forum. Don't know how you do it but you do.

So then where will ProcessWire be in a couple years from now? How far will this forum grow? Will there be lot's of PW sites spreading across the web and sharing places as with other big CMS'? Hardly think about it but I think it could very well happen. What could the PW web be? How many modules will there be and quantity > quality...

While at it, Clouds! I can't hear stand it anymore, STILL we have moving clouds in the new ProcessWire website!!! Hope people don't think we go PW Cloud?

Also I would love a horde of crazy new core php developers that help making crazy new stuff with this CMS/CMF.

No I'm not drunk but after that post I'm wired. Keep it up, stay healthy and spread the word "ProcessWire". Peace.

( Ahhh, I reached 2000 posts and I didn't even notice yet! Well never used to post that much in a forum ever. Well mostly just BS nobody wants to hear heh )

I see that Ryan is about to become the first forum member to pass the "one thousand and one" thank-you's (likes) so I'd just like to take the opportunity (seeing as we are in the Pub) to raise my glass and say a big "Thank You" for the effort he keeps putting into PW, the site and the forum.

Whilst I'm at it, I'll raise my glass to the others who contribute regularly too.

One of my clients specializes in putting on conferences/summits around the world, primarily focused on architecture and sustainable design. I mentioned to them how some users here (starting with Netcarver) had expressed interest in a ProcessWire meetup or conference in the UK. This client does conferences in the UK every year and they are extremely enthusiastic about ProcessWire and interested in helping us to put on a conference by letting us collaborate with their conference and share the same venues and accommodations. This would help us benefit from their expertise in putting on conferences (which they've done for more than a decade), as well as help [significantly] on costs in reserving the venues, food, hotels. I have worked with this client since 1994 (18 years), so have a very high level of trust with them.

The conference would be in August 2013 and be 1.5 days in London at a major ad agency, then we'd step on a train for an hour or so and do the rest of the conference in Cambridge at Kings College for another 1.5 days (total 3 days). This would be a small but relatively formal conference with presentations and workshops covering everything ProcessWire, design and web development. We'd cover topics at a higher level than you'd find anywhere else in the world. I don't yet have an idea on costs except to say that we'd find a way to make it accessible to as large of an audience as possible, and it would be completely non profit, food and accommodations (for those that wanted it) included. Yet, it'd still be higher class and more personal than any other webdev conference.

This is about a year out, so I'm interested in finding out who'd be interested in this. Please 'like' or reply to this post if you would be interested in attending (or presenting) at this conference.

This basic tutorial is primarily aimed at those new to PW. It could also serve as a reference to others more seasoned PW users. The question about how to categorise content comes up in the forums now and again. Hopefully with this post we’ll have a reference to guide us right here in the tutorials board.

Many times we need to organise our site content into various categories in order to make better sense of the data or to logically and easily access it. So, how do you organise your data when you need to use categories? Here are a few tips gathered from the PW forums on how to go about this. Using these tips will, hopefully, help you avoid repeating yourself in your code and site content and keep things simple. See the links at the end of this post to some useful discussion around the topic of categorisation.

Before making decisions about how to organise your site, you need to consider at least three questions:

• What items on my site are the main items of interest? These could be people or things (cars, plants, etc.). In most cases, these are the most important content on which all the other stuff point to.
• Where do items need to be grouped into categories? This is about where items need to “live”. It is about the attributes of the items of interest (e.g. responsibilities, job types, colour, etc.). Attributes can have sub-attributes (e.g. a category job type = driver could be further sub-classified as job type role = train driver).
• Can they live in more than one place? - This is about having multiple attributes.

There could be other issues such as the type of content your main items of interest are but that’s for another post. We’ll keep these examples simple. The main principles explained below still apply.

There are at least three possible ways in which you can organise your content depending on your answers to the above three questions. These are:

• Single category
• Simple multiple categories
• Complex multiple categories

These are illustrated below. Note that this is what I call them; these are not PW terms.

1. Single Category

Suppose you need to do a site for a company that’s made up of several Departments each with employees performing unique functions. These could include “Finance”; “Media Communications”; “Administration”; “Technicians”; “Human Resources”; “Logistics”.

We ask ourselves the following questions based on our 3 questions above:
 

1. Q: What items on my site are the main items of interest?

A: Employees.

2. Q: What attributes of our items of interests are we interested in?

A: Departments. (Single main category)

3. Do the Departments have sub-categories?

A: Yes. (Multiple sub-categories)

4.Can Employees belong to multiple sub-categories?

A: No. (Single sub-category)

We conclude that what we need is a Single Category model. Why? This is because, in Single Categories model, items of interest can only belong to 1 and only 1 main/parent category and within that only 1 sub-category

Employees in this company can only belong to one and only one department. Finance guys do their finance and Logistics guys do their stuff. Letting Techies do press conferences is probably not going to work; that we leave to the Media guys . Assuming the company has the following employees - James, John, Mary, Ahmed, Peter, Jason, Barbara etc., arranging our site content to fit this model could look like the following:

Items of interest = Employees
Categories = Departments

Adopting out strategy to keep it simple and logical, let us write down, hierarchically, our employee names against their departments to mimic the PW tree like this:
 

James

Finance

John

Finance

Mary

Technician

Ahmed

Logistics

Barbara

Media

Etc.

We notice, of course, that departments start repeating. It doesn’t look like we are doing this very logically. If we think about this carefully, we will conclude that, naturally, the thing (attribute in this case) that keeps repeating should be the main criteria for our categorisation. This may seem obvious, but it is worth pointing out. Also, remember, that as per the responses to our questions, the categories (Finance, Logistics, etc.) do not have sub-categories. In aspect, we are OK. Using this principle about repeating attributes, we find that Departments, rather than Employees, need to be the main categories. Hence, we categorise our PW site content by doing the following.

• Create a template for each Department. Hence, we have a template called Finance, Logistics, etc.
• Add the fields needed to those templates. This could be a text field for holding Employee phone numbers, email field for email, title field for their names, etc.
• Create top level pages for each Department and assign to them their respective templates. Give them appropriate titles, e.g., Finance, Media, etc.
• Create a page for each employee as a child page of the Department which they belong to. Give them appropriate titles, e.g. James, John, etc.

We end up with a tree that looks like this:
 

1. Finance (ex. main category)

a. James (ex. item of interest)

b. John

c. Shah

d. Anne

2. Logistics (ex. main category)

a. Ahmed

b. Matthew

c. Robert

d. Cynthia

3. Media

a. Barbara

b. Jason

c. Danita

4. Human Resources

a. Michael

b. Pedro

c. Sally

5. Technician

a. Mary

b. Oswald

c. Dmitri

d. Osiris

Since an employee can only belong to one Department, our work here is done. We can then use PW variables, e.g. $page->find, $pages->find with the appropriate selectors to find employees within a Department. This is a very basic example, of course, but you get the idea.

You have the choice of creating one template file for each category template as well. I prefer the method of using one main template file (see this thread). You could do that and have all Departments use different templates but a single template file. In the template file you can include code to pull in, for example, the file “technician.inc” to display the relevant content when pages using the template “Technician” are viewed.

Example code to access and show content in Single Categories model

$hr = $pages->find("template=human-resources, limit 50");
foreach ($hr as $h) {
echo "{$h->title}";
}

But sites do not always lend themselves to this model. Many times, items of interest will need to belong to multiple categories.

2. Simple Multiple Categories

Let’s say you were building a site for cars - red cars, blue cars, 2-seaters, 5-seaters, etc. Again, we ask ourselves our questions based on our initial three questions:
 

1. Q: What items on my site are the main items of interest?

A: Cars.

2. Q: What attributes of our items of interests are we interested in?

A: Colour, Number of seats, Models, Year of manufacture, Types. (Multiple categories)

3. Do these multiple attributes have sub-attributes?

A: Yes. e.g., the attribute Colour has several sub-categories - red, white, green, etc. (Multiple sub-categories)

4. Can Cars have multiple sub-attributes?

A: No. e.g., a yellow car cannot be a green car. (Single sub-categories)

We therefore conclude that what we need is a Simple Multiple Category model. Why? This is because, in Simple Multiple Categories, items of interest can belong to multiple parent categories. However, within those parent categories, they can only belong to one sub-category.

Assuming we have the following cars, manufactured between 2005 and 2008, as items of interest: Mercedes, Volvo, Ford, Subaru, Toyota, Nissan, Peugeot, Renault, Mazda, arranging our site content to fit this model could look like the following:

Items of interest = Cars
Categories = Model, Year, Colour, Number of seats, Type
Sub Categories = Model [Prius, etc.]; Year [2005, 2006, 2007, 2008]; Colour [Red, Silver, Black, White, Green]; Number of seats [2, 5, 7]; Types [Sports, SUV, MPV].

Adopting out strategy to keep it simple and logical, if we wrote down our cars names against their attributes like this:
 

Mercedes

Model-Name:

Year: 2005

Colour: Silver

Seats: 2-seater

Type: Sports

Volvo

Model-Name:

Year: 2007

Colour: Green

Seats: 5-seater

Type: SUV

Ford

Model-Name:

Year: 2007

Colour: Red

Seats: 7-seater

Type: MPV

Etc

We notice, again, that car attributes start repeating. In order not to repeat ourselves, we want to avoid the situation where our child pages “names” keep repeating. For instance, in the above example tree, we want to avoid repeating year, colour, etc. within the tree. Of course in the frontend our output needs to look like the above where we can list our cars and their respective attributes. We just don’t need a tree that looks like this in the backend. Since we have multiple categories and sub-categories, we need to rethink our strategy for categorising our content as illustrated below. The strategy we used in the first category model will not work well here. Hence, these repeating attributes (year, colour, etc.) need to be the main criteria for our categorisation. We need to end up with a tree that looks like this:
 

1. Cars

a. Mercedes (ex. item of interest)

b. Volvo

c. Ford

d. Subaru

e. Toyota

f. Range Rover

g. Peugeot

h. Renault

i. Mazda

2. Model (ex. main category)

a. Fiesta (ex. sub-category)

b. Miata

c. Impreza

d. Matrix

e. Prius

f. E-Class

g. XC-90

h. Scenic

i. L322

j. 505

 

3. Year

a. 2005

b. 2006

c. 2007 (ex. sub-category)

d. 2008

4. Colour

a. Red

b. Silver

c. Black

d. White

e. Green

5. Number of Seats

a. 2

b. 5

c. 7

6. Type

a. MPV

b. Sports

c. SUV

d. Other

At the top of the tree, we have our main items of interest, Cars. They do not have to come first on top of the tree like that but it just makes sense to have them like this. Next, we have the Cars’ categories (attributes). The main categories are parent pages. Each main category has children which act as its sub-categories (cars’ sub-attributes). For instance, the main category colour has sub-categories “red”, “green”, etc. Grouping them under their main category like this makes better sense than having them dangling all over the tree as parent pages themselves.

Now that we know what we want to achieve, the next question is how do we go about relating our categories and sub-categories to our main items of interest, i.e., cars? Fields come to mind. OK, yes, but what about the sub-categories (2006, red, 5-seater, etc.)? Surely, we can’t keep typing those in text fields! Of course not; this is PW. We like to simplify tasks as much as we can.

What we need is a special type of field. Page Reference Fields or Page Fieldtypes add the ability to reference other pages, either single or multiple pages, within a page. For instance, we could have a Page Reference Field in the template that our Car pages use. Let’s call this “car-template”. When viewing Car pages, we would have the ability to select other pages on our site that we wish to reference, for instance, because they are related to the page we are viewing. In other cases, we could also wish to reference other pages that contain attributes/values of the page we are viewing. This is the situation with our Cars example above. Hence, the sub-categories/sub-attributes for our Cars will be pulled into our car pages using Page Reference Fields.

There are two types of Page Reference Fields; single page and multiple pages. What each do is obvious from their names. Single Page Reference Fields will only reference one page at a time. Multiple Page Reference Fields will reference multiple pages.

OK, let’s go back to the issue at hand. We need to categorise Cars by various attributes. Do we need to reference the main categories (Year, Type, etc.) in our Car pages? In fact, we don’t. What we need to reference are the sub-categories, i.e. 2005, red, SUV, etc. These will provide the actual attributes regarding the parent attribute of the Cars. We have said we do not wish to type these sub-categories/attributes all the time hence we use Page Reference Fields. Which type of Page Reference Field should we use? Remember that our Cars can have only one sub-category/sub-attribute. That’s our cue right there. In order to select one and only one sub-attribute per Car, we need to use the single Page Reference Field.

Hence, we categorise our Cars PW site by doing the following (you may follow a different order of tasks if you wish).

• Create a template to be used by the Car pages. Give it a name such as car-template
• Create a page for each of your cars and make them use the car-template
• Create one template to be used by all the main attribute/categories and their children (the sub-categories). We do not need a template for each of the categories/sub-categories. I name my template “car-attributes” Of course you can name yours differently if you wish.
• Add the fields needed to this template. You don’t need anything other than a title field for each actually.
• Create top level pages for each main category and assign to them the template car-attributes. As before, give your pages meaningful titles.
• Do the same respectively for their child pages. E.g., you should have the following child pages under the parent “Year” - 2005, 2006, 2007 and 2008.
• Create the Page Reference Fields for each of your main categories/parent attributes. Using our example, you should end up with 5 Page Reference Fields (model, year, colour, seats and type). Each of these should be single Page Reference Fields. It’s a good idea, under the BASICS settings while editing the fields, to include some Description text to, include additional info about the field, e.g. instructions. In addition, you don’t want any page that doesn't belong to a particular attribute to be selectable using any of the Page Reference Fields. For instance, when referencing the year a car was manufactured, we want to be able to only select children of the page Year since that is where the year sub-categories are. We do not want to be able to select children of Colour (red, green, etc.) as the year a car was manufactured! How do we go about this? PW makes this very easy. Once you have created your Page Reference Fields, while still in the editing field mode, look under the settings INPUT. The fourth option down that page is “Selectable Pages”. Its first child option is “Parent of selectable page(s)”. Where it says “Select the parent of the pages that are selectable” click on change to change the parent. By now you know where I am going with this. For the Page Reference Field named Year, choose the page “Year” as the parent whose children will be selectable when using that Page Reference Field to select pages. Similarly, do this for the remaining 4 Page Reference Fields. Note that under this field settings INPUT you can change how you want your pages to be selectable. Be careful that you only select the types that match single Page Reference Fields, i.e. the ones WITHOUT *. For single Page Reference Fields, you have the choices:
  • Select - a drop down select
  • Radio buttons
  • PageListSelect
• Now edit the car-template to add all 5 of your Car Page Reference Fields.

We are now ready to roll. Go ahead and edit your Car pages. In each of them you will see your 5 Page Reference Fields. If you followed the instructions correctly, each of them should only have the relevant child pages/sub-attributes as selectable. Do your edits - select year when car was manufactured, its colour, type, number of seats, etc. and hit Save.

By the way, note that Page Reference Fields give you access to all the fields and properties of the page being referenced! You have access to the referenced page’s title, name, path, children, template name, page reference fields, etc. This is really useful when creating complex sites. I call it going down the rabbit hole! These properties of the referenced page are available to you on request. It does mean that you will have to specifically echo out the property you want from that page. Page Reference Fields are echoed out like any other field.

Example code to access and show content in Simple Multiple Categories model

$cars = $pages->find("template=car-template, limit=10, colour=red, year=2006, seats=5");
foreach ($cars as $car) {
 echo $car->title;
 echo $car->year;
 echo $car->colour;
}

I have made the above verbose so you can easily follow what I'm trying to achieve. The above code will find 10 red 5-seater cars manufactured in 2006. Remember, colour, year and seats are the names of your custom Page Reference Fields that you created earlier.

Some sites will have content that belong to multiple categories and multiple sub-categories. We address this below.

3. Complex Multiple Categories

Suppose you are developing a site for a school. The school has teachers (duh!) some of whom teach more than one subject. Besides their classroom duties, some teachers are active in various clubs. On the administration side, some teachers are involved in various committees. You know the drill by now. Let’s deal with our basic questions.
 

1. Q: What items on my site are the main items of interest?

A: Teachers.

2. Q: What attributes of our items of interests are we interested in?

A: Subjects, Administration, Clubs (Multiple categories)

3. Do these multiple attributes have sub-attributes?

A: Yes. e.g., the attribute Subjects has several sub-categories - History, Maths, Chemistry, Physics, Geography, English, etc. (Multiple sub-categories)

4. Can Teachers have multiple sub-attributes?

A: Yes. e.g., a Teacher who teaches both maths and chemistry (Multiple sub-categories)

Apart from the response to the final question, the other responses are identical to our previous model, i.e. the Simple Multiple Categories. We already know how to deal with multiple categories so we’ll skip some of the steps we followed in the previous example. Since our items of interest (Teachers) can belong to more than one sub-category, we conclude that what we need is a Complex Multiple Category model. In Complex Multiple Categories, items of interest can belong to multiple parent categories and multiple sub-categories both within and without main/parent categories.

By now we should know what will be the main criteria for our categorisation. We need to end up with a tree that looks like this:
 

1. Teachers

a. Mr Smith (ex. item of interest)

b. Mrs Wesley

c. Ms Rodriguez

d. Mr Peres

e. Mr Jane

f. Mrs Potter

g. Ms Graham

h. Mrs Basket

i. Dr Cooper

2. Subjects (ex. main category)

a. History (ex. sub-category)

b. Maths

c. English

d. Physics

e. Chemistry

f. Geography

g. Religion

h. Biology

i. French

j. Music

3. Clubs

a. Basketball

b. Debate

c. Football

d. Scouts

e. Sailing

f. Writing

4. Administration

a. Discipline

b. Counselling

c. Exams board

d. Public relations

e. Education

We are ready to build our site. Which type of Page Reference Field should we use? Remember that our Teachers can teach more than one subject and can be involved in various sub-category activities. That’s our cue right there. In order to select multiple attributes/categories, we of course go for the multiple Page Reference Field.

• Similar to the previous example, create necessary templates and fields for the site. For our multiple Page Reference Fields, remember to select the correct input field types. These should match multiple Page Reference Fields and are marked with *. For multiple Page Reference Fields, the available choices:
• Select Multiple*
• AsmSelect*
• Checkboxes*
• PageListSelectMultiple*
• PageAutoComplete*

Remember to add the multiple Page Reference Fields to the Teachers template. Go ahead and test different selectors, e.g. find Teachers that teach Maths and Chemistry and are involved in the Writing club. Whether you get results or not depends on whether there is actually that combination. An important point to remember is that your multiple Page Reference Fields will return an array of pages. You will need to traverse them using foreach (or similar).

Example code Complex Multiple Categories model

Find the subjects taught by the Teacher whose page we are currently viewing. You can use if statements to only show results if a result is found. In this case, of course we expect a result to be found; if a Teacher doesn't teach any subject, he/she has no business teaching! subjects is the name of one of your custom Multiple Page Reference Fields.

 

echo "<ul>";
foreach ($page->subjects as $x) {
echo "<li>{$x->title}</li>";
}
echo "</ul>";

There will be situations where you will need to use both Single and Multiple Page Reference Fields (independently, of course). For instance, in our Teachers example, we might be interested in the Gender of the Teacher. That would require a Single Page Reference Field.

Summary
What we have learnt:

• Categorising our site content need not be a nightmare if we carefully think it through. Of course not all sites will fit neatly into the 3 models discussed.
• By providing answers to a few simple key questions, we will be able to quickly arrive at a decision on how to categorise our content.
• There are at least 3 models we can adopt to categorise our content - single category; simple multiple category; and complex multiple category.
• In the latter two models, we make full use of PW’s powerful Page Reference Fields to mimic a relational database enabling us to roll out complex sites fast and easy.

Useful links:
http://processwire.c...duct-catalogue/
http://processwire.c...age-references/
http://processwire.c...page-fieldtype/
http://processwire.c...a-a-case-study/
http://processwire.c...n-another-page/
http://processwire.c...-category-wise/
http://processwire.c...ories-question/
http://processwire.c...aily-newspaper/
http://processwire.c...ted-categories/
http://processwire.c...agging-content/
http://processwire.c...s-in-this-case/
http://processwire.c...-related-pages/
http://processwire.c...o-another-page/

Imagine a hotel website. Done? Yeah, most of them look the same ;-)

 

In this project I took another approach. The client is - thank PW - able to (re)create the whole look of his website by changing tiles (images, sizes, texts). The size adapts to the screen size, so on nearly every device the look is different. But not the user experience. After one week online I can say: It works. Thanks to a lot(!) of image material and an engaged client it is one of the biggest sites I've ever made. There is a lot to discover (only german yet, english is due in May). So click around...

 

Der Blaue Reiter - Design Hotel Karlsruhe

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. 

 

It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice.

 

Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. 

 

You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. 

 

Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4. 

 

I launched it today:

 

http://fyp.washington.edu/

 

I can't even begin to explain how excited I am by this software. It feels like I accomplished more in a month than in the last ten years of professional web dev work. Finally, a CMS geared to the needs of content publishing and information modeling (i.e. taxonomy and ontology) -- not news, widgets, or journaling.

 

Like so many others I had been struggling with the Drupal/Wordpress dichotomy. Drupal feels like hitting myself in the head with a hammer and Wordpress is insecure and inflexible. And both their inner workings seem completely opaque, no matter how often I build with them.

 

Enter PW, CMS of my dreams.

 

The FYP site is combined with Zurb's Foundation Framework, which I am similarly enthusiastic about. Also above all jQuery + CSS3, which seem like a never-ending treasure chest of wonders.

 

I did the interface design and development as well as the information architecture and all of the programming. My favorite thing about the site is the way I was able to give it gears that turn with the seasons -- for each season of the year I added tag "pages" and then tailored parts of the interface to match. The homepage image, the default header, and the selection of front page slides are all determined by what time of year it is.

 

I was able to expose almost EVERYTHING to the content stakeholders through the flexible field system. I could totally get run over by a truck tomorrow and all would be well. I LIKE THIS. Maybe some don't. But I've always been in this field in the hopes of empowering people and making room for creativity. ProcessWire works with these goals, not against them.

 

Cheers,

Jenn

 

p.s. the slider is RoyalSlider. I dig it too.