Leaderboard

RockAwesome ProcessWire Fieldtype to easily choose FontAwesome Icons Usage Install the module. Set paths in the Inputfield's settings page. Add a RockAwesome field to any template (or change an existing TEXT field). Preview https://modules.processwire.com/modules/fieldtype-rock-awesome/ https://github.com/BernhardBaumrock/RockAwesome

This looks like a reasonable approach! There is currently nothing like those tools you mention. What I've seen works for a lot of ProcessWire developers is to use the Repeater Matrix module to create content. Take a look here: https://processwire.com/store/pro-fields/repeater-matrix/

FYI: I've been running two sites with that modification to the database without any errors or issues.

Yeah, well in that case it really seems impossible. Can't you narrow it down with some other condition? has_parent, template, or similar? I know you said you want something future-proof, but certainly you are not adding new templates every day? Field dependencies let you write your own logic in plain PHP (one of many options), I guess Ryan has a reason he didn't allow such freedom when it comes to Lister (Pro or not) - probably security concerns. You might want to take a look at @bernhard's RockGrid module instead. A bit more work initially than just creating a new Lister Pro instance, but you're totally free to list / select / query whatever you like.

The page ID is stored in an unsigned auto-incremented int column (you can find this in ProcessWire's install.sql file) in the pages table in MySQL, so the highest the IDs can go is 4294967295 - that should be plenty ? You can manually reset an auto-increment column in MySQL, but not lower than the highest value that exists in the table. I guess you could also manually change the column to a BIGINT, I haven't checked but I don't think it would break anything in ProcessWire. That said, is it really necessary to trash and rebuild all pages every time? I don't know what job advertisements database you have, but if you can get a unique ID or identifier for every job posting from it, you could store that identifier in a hidden field in the corresponding ProcessWire page and then selectively update the fields that have changed (or at least only rebuild the pages that have been changed). This way you also retain meaningful created/modified timestamps inside ProcessWire, so it seems like a better approach.

Do you mean you place that class in CKEditor? You have to enable inline classes, otherwise the richtext editor strips it away when saving. Admin => Setup => Fields => Your field => Input => Extra allowed content Enter something like a[*]{*}(*) config / syntax examples: https://ckeditor.com/docs/ckeditor4/latest/guide/dev_advanced_content_filter.html#custom-mode

@JeevanisM PW has WireMail base class and this class can use different senders to actualy send emails. There is branch of such modules: https://modules.processwire.com/modules/wire-mail-smtp/ https://modules.processwire.com/modules/wire-mail-gmail/ https://modules.processwire.com/modules/wire-mail-mailgun/ See more here https://modules.processwire.com/categories/email/ So you can try different sender to see which work best for you There is new module that helps to log information about all mails that are sent https://modules.processwire.com/modules/rock-mail-logger/

FieldtypeFontIconPicker Supported Icon Libraries FontAwesome 4.7.0 Uikit 3.0.34 IonicIcons 2.0.1 Cahangelog NOTE: Module store data without prefix, you need to add "prefix" when you want to show your icon on front-end, because some of front-end frameworks using font-awesome with different "prefix". Module will search site/modules/**/configs/IconPicker.*.php and site/templates/IconPicker.*.php paths for FieldtypeFontIconPicker config files. All config files need to return a PHP ARRAY like examples. Example config file : create your own icon set. File location is site/configs/IconPicker.example.php <?php namespace ProcessWire; /** * IconPicker : Custom Icons */ return [ "name" => "my-custom-icons", "title" => "My Custom Icon Set", "version" => "1.0.0", "styles" => array( wire("config")->urls->templates . "dist/css/my-custom-icons.css" ), "scripts" => array( wire("config")->urls->templates . "dist/js/my-custom-icons.js" ), "categorized" => true, "attributes" => array(), "icons" => array( "brand-icons" => array( "title" => "Brand Icons", "icons" => array( "google", "facebook", "twitter", "instagram" ) ), "flag-icons" => array( "title" => "Flag Icons", "icons" => array( "tr", "gb", "us", "it", "de", "nl", "fr" ) ) ) ]; Example config file : use existing and extend it. File location is site/configs/IconPicker.altivebir.php <?php namespace ProcessWire; /** * IconPicker : Existing & Extend */ $resource = include wire("config")->paths->siteModules . "FieldtypeFontIconPicker/configs/IconPicker.uikit.php"; $url = wire("config")->urls->templates . "dist"; $resource["scripts"] = array_merge($resource["scripts"], ["{$url}/js/Altivebir.Icon.min.js"]); $resource["icons"]["flag-icons"] = [ "title" => "Flag Icons", "icons" => array("tr", "en", "fr", "us", "it", "de") ]; $resource["icons"]["brand-icons"]["icons"] = array_merge($resource["icons"]["brand-icons"]["icons"], array( "altivebir" )); return $resource; After you add your custom config file, you will see your config file on library select box. Library Title (Location Folder Name). If your library categorized and if you have categorized icons set like uikit and fontawesome libraries, you will have category limitation options per icon field or leave it empty for allow all categories (default). Example : output if ($icon = $page->get("iconField")) { echo "<i class='prefix-{$icon}' />"; } MarkupFontIconPicker Usage // MarkupFontIconPicker::render(YourIconField=string, Options=array) echo MarkupFontIconPicker::render($page->YourIconField, [ 'prefix' => 'uk-icon-', // Icon class prefix, if you have different prefix, default is : "fa fa-" 'tag' => 'span', // Icon tag default is : "i" 'class' => 'fa-lg', // If you have extra cutom classes, for example : icons sizes, Array or Sting value 'style' => 'your custom styles if you have' // Array or String Value ]); Theme support Search support Category support

Just wanted to thank you @Tom. for that brilliant hint! I'm not that experienced in frontend stuff, so basic tasks like slide-toggling a menu can really be a pain for me ? I've always made it easy for myself and just included jQuery for such things... Today I tried the UIkit JS utils and it's not that hard to do (here I'm using Zepto.js, but that's not a necessity): var util = UIkit.util; $(document).on('click', '.tm-burger', function(e) { e.preventDefault(); var $menu = $('#tm-menu-section'); var element = util.$('#tm-menu-section'); var duration = 700; if($menu.height()) { // hide menu $menu.height(element.scrollHeight); util.Transition.start(element, { 'height': 0, 'overflow': 'hidden', }, duration, 'ease'); } else { // show menu $menu.removeAttr('hidden'); $menu.height(0); $menu.css('overflow', 'hidden'); // trigger window resize to make sure that the menu renders correctly $(window).resize(); util.Transition.start(element, { 'height': element.scrollHeight, 'overflow': 'show', }, duration, 'ease').then(function() { $menu.height('auto'); }); } }); The benefit here is that I don't need any dependencies and I can create any transitions that I need and I'm not limited to jQuery's .slideUp() .slideDown() etc. ?

I absolutely agree. Currently the synchronisation is in development and testing. The database (or better said, the distributors API) only provides a very narrow set of interrogations. And has some strange data field types also (e.g. row modified is delivered, but internaly stored as a string type in a unusal format). So the create/delete of pages every import is just for testing purposes. If all is set and stable (and i can rely on the DB modified field), your approach is definitely the way to go. The questions (page ID limitation? Reset...) came up while testing. And i was curious about it ? Thx for you answer (also to @rick) Olaf

Try it with include=all as another filter.

Well, there's no selector "if template / page has field_x", so a workaround could be two custom selectors: custom (field=value) 1 = meta%= custom (field=value) 2 = meta!= Make sure to check the checkbox on the right (make it OR rather than AND)

New version release! 1.0.2 I am very happy to inform you guys that the new major version of the module is out. ⚠️ WARNING: Breaking Changes! ⚠️ The module was rewritten to use webonyx/graphql-php instead of youshido/graphql. This was a big issue because the latter was not properly maintained anymore and the webonyx/graphql-php gone very further in development and supports more features that we need. There are some more breaking changes that are listed on the latest release page. What's new trash(id: ID!): Page! field allows to move pages to trash via GraphQL api. Solves N+1 problem for FieldtypePage field. Significantly improves response speed! Support for even more ProcessWire permissions. Now the full list is: page-add page-create page-delete page-edit page-move page-view page-edit-created page-edit-trash-created It is already available in ProcessWire's modules directory. So you can install it via class name.

Sorry for the spam on this post, but I just went through the process of figuring out and setting up the above so I thought this might help anyone interested. Lets say you have: - domain1.com in G Suite with user@domain1.com as a user account - domain2.com that you want to relay mail through GSuite SMTP Add domain2.com to the domains of your G Suite without adding all the MX records, just the txt DNS record for confirmation. You can of course add the MX records as well, but if you aren't going to use domain2 for new G Suite users or as an alias for existing users, then no need. In admin.google.com Apps > G Suite > Settings for Gmail > Advanced settings look for "SMTP relay service" under routing and add a setting like screenshot below. This will let you: - authenticate smtp-relay.gmail.com:465 or smtp-relay.gmail.com:587 using user@domain1.com / password - send mail through GSuite relay as anyadress@domain2.com The only things to note are: - both the above need TLS enabled. I believe if you use 25 without SMTP AUTH you can only send to accounts in your G Suite organisations but I might be wrong, the instructions are quite confusing - to save to your sent box in the account you use for auth you need to enable comprehensive mail storage for G Suite Also I haven't tested this with any of the Processwire SMTP modules, I have a working setup using postfix. Will be testing this with PW soon thought so I'll report back here.

@cst989 The issue could be that you incorrectly set ID of a page and then you get redirect to bookmarks page. Redirect is handled here https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L77

Did you adapt the SMTP settings in php.ini? It might be configured to use sendmail by default.

I've been working on this a looks like it WILL require a change, as it now requires you update your payment journey to use PaymentIntentions, e.g. setting a intent to pay at the beginning of any payment checkout before actually requesting card information, address, email etc etc... I'm currently having to do this for my clients and adding support for Stripe Elements. Love this to be robust butI'm simply not a very good backend dev so muddling through it. Will release what I have when it's done hopefully in a week.

FYI, sometimes it is simpler to do an in-memory search of the WireArray. E.g. $oneItem = $myWireArray->get("id=20");// id is a property in the WireArray if($oneItem) echo 'we got the item folks!'; $multipleItems = $myWireArray->find("price>500");// price is a property in the WireArray if($multipleItems->count()) echo 'We got several items';

With a bit of hooking it is possible to both dynamically control the selectable pages for a PageAutocomplete inputfield, and dynamically set the parent/template of new pages created from the inputfield. I have only played around with this and haven't used it in production, so use it at your own risk. Dynamic selectable pages for PageAutocomplete The idea is that in the field settings you define a broad selector that includes all of the pages you might want to select. It could be something really broad such as "has_parent!=2". Then you modify the selector in a hook according to the page being edited. In /site/ready.php... $wire->addHookAfter('Field::getInputfield', function(HookEvent $event) { $field = $event->object; $inputfield = $event->return; // Only for this one Page Reference field if($field->name !== 'test_page_field') return; // Only for ProcessPageEdit if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); // Get findPagesSelector (or findPagesSelect if you used that) $selector = $inputfield->findPagesSelector; /* Now append to or overwrite $selector however you like, depending on $page maybe. You can even define some $allowed PageArray like with the "Custom PHP code" option that is possible with other Page inputfields, and then use it in the selector as "id=$allowed". But note that there is a 500 character limit enforced on selectors. */ // Set the modified selector back to the property you got it from $inputfield->findPagesSelector = $selector; }); Dynamic parent and/or template for pages created from the inputfield The idea is that in the field settings you do not define a parent or template for allowed pages, but then set these properties in a couple of hooks according to the page being edited. In /site/ready.php... $wire->addHookBefore('InputfieldPage::renderAddable', null, 'dynamicParentandTemplate'); $wire->addHookBefore('InputfieldPage::processInputAddPages', null, 'dynamicParentandTemplate'); function dynamicParentandTemplate(HookEvent $event) { $inputfield = $event->object; // Only for this one Page Reference field if($inputfield->hasField->name !== 'test_page_field') return; // Only for ProcessPageEdit if(wire()->process != 'ProcessPageEdit') return; $page = wire()->process->getPage(); // Now set $parent_id and $template_id dynamically depending on $page $parent_id = 1234; // demo value $template_id = 56; // demo value $inputfield->parent_id = $parent_id; $inputfield->template_id = $template_id; } Have fun!

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 this 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 interest 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 are: 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.com/talk/topic/3553-handling-categories-on-a-product-catalogue/ http://processwire.com/videos/create-new-page-references/ http://processwire.com/videos/page-fieldtype/ http://processwire.com/talk/topic/1041-raydale-multimedia-a-case-study/ http://processwire.com/talk/topic/683-page-content-within-another-page/ http://processwire.com/talk/topic/2780-displaying-products-category-wise/ http://processwire.com/talk/topic/1916-another-categories-question/ http://processwire.com/talk/topic/2802-how-would-you-build-a-daily-newspaper/ http://processwire.com/talk/topic/2519-nested-categories/ http://processwire.com/talk/topic/71-categorizingtagging-content/ http://processwire.com/talk/topic/2309-best-way-to-organize-categories-in-this-case/ http://processwire.com/talk/topic/2200-related-pages/ http://processwire.com/talk/topic/64-how-do-you-call-data-from-a-page-or-pages-into-another-page/

What I do is use $config->js to populate the config array that I then output in the head for dynamic variables that want to share in a script. $config->js("myconfig", array("myajaxurl" => $pages->get(1991)->url); You can do this in templates or modules doesn't matter as long as it's before rendering page. Then this little to output as json. This is the same as PW uses in the admin to share config vars with js. <script type="text/javascript"> <?php // output javascript config json string to html // for use in javascripts from this point on $jsConfig = $config->js(); $jsConfig['debug'] = $config->debug; $jsConfig['urls'] = array( 'current_url' => $page->url, 'root' => $config->urls->root, ); ?> var config = <?php echo json_encode($jsConfig); ?>; </script> Then use in your script as var rootUrl = config.urls.root; for example