Leaderboard

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/

The scope of the project you mention sounds pretty broad and will be a big investment on your part regardless of what system you build it in. I think part of your decision has to come from budget. If you are testing the waters rather than dedicating your full time to this project, then I would pursue whatever path has the most components already built, even if the result is not 100% what you want. I think that means looking into what's available and built through WordPress and IPS. I especially like the IPS option in your case. Maybe it's not perfect, but it does at least get you more than half way there and has the level of integration between components that you are looking for (including ecommerce). There's no doubt that you could build this all beautifully in ProcessWire, but I wouldn't recommend such a big project being your first in any CMS or framework. Whether ProcessWire or another platform, you'd want to have some significant experience developing apps/sites before pursuing such a big project in [x] platform. Unless you've set aside a large budget or don't have a full-time job already, find the tool that gets you closest to your needs before having to get into code. Then, once you've proven the concept or made it a success, develop it exactly the way you want it in ProcessWire or a full-blown framework. But stay with us here and start learning ProcessWire in smaller chunks and on smaller projects, and before long you'll be ready to build anything you can imagine.

In future versions of ProcessWire, including the current PW 2.3 dev branch, you can also do this: if(count($options['pageStack'])) { // don't include header/footer, etc. } $options['pageStack'] is an array of pages that called render(); before the current one. It basically gives a way for a page to discover the context it is being rendered in.

I think this method will work even if you expand it out. I changed a few things up, but hopefully it makes sense. Product pages use "template product", all other catalog pages use "template catalog". Catalogue -- Men ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 -- Women ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 Categories (these pages only a template with a title field) -- Brands ---- Brand 1 (title only template) ---- Brand 2 (title only template) -- Type ---- Type A (title only template) ---- Type B (title only template) -- Collections ---- Collection A (title only template) ---- Collection B (title only template) catalogue.php template & product.php template (same contents) <?php /* There might be a better way to accomplish this. The only reason to have 2 templates is to give find() a way * to only return the actual product pages, and not all the parent pages as well. * * update: You may want to look into using the alternative template method: * * * With this approach you would create a real file (product.php) for the product template, * catalogue template would have no file associated, but point to product.php under the advanced settings tab. */ include("./site/templates/head.inc"); include("./site/templates/product-view.inc"); include("./site/templates/foot.inc"); product-view.inc <?php $brand = ""; $type = ""; $collection = ""; if ($input->urlSegment1) $brand = ",brand.name=".$input->urlSegment1; if ($input->urlSegment2) $type = ",type.name=".$input->urlSegment2; if ($input->urlSegment3) $collection = ",collection.name=".$input->urlSegment3; if ($input->urlSegment4) { // if Segment 4, then we know what page to get $product = $pages->get("name=$input->urlSegment4"); echo $product->title; } else if ($input->urlSegment1){ // check if we are using URL segments if ($input->urlSegment1 == "all"){ $products = $pages->find("has_parent=$input->urlSegment2, template=product"); } else { $products = $pages->find("has_parent=$page->path, template=product, . $brand . $type . $collection"); } foreach ($products as $p){ echo $p->title; } } else { $products = $pages->find("has_parent=$page->path, template=product"); foreach ($products as $p){ echo $p->title; } } Looking at example URLS to see how the selector would get populated: /catalogue/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1"); /catalogue/brand1/casual/ elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual"); /catalogue/brand1/casual/trendy/ $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual, collection.name=trendy"); /catalogue/men/ $products = $pages->find("has_parent=men, template=product"); /catalogue/all/shoes/ $products = $pages->find("has_parent=shoes, template=product"); /catalogue/all/hats/ $products = $pages->find("has_parent=hats, template=product"); /catalogue/men/shoes/ no URL segment here, so the if/elseif are false, so we get: $products = $pages->find("has_parent=/catalogue/men/shoes/, template=product"); /catalogue/men/shoes/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/men/shoes/, template=product, brand.name=brand1"); you get the idea. Again, untested and coded in the browser — but hopefully thought out enough to get you started.

This is a really excellent example of a job posting, thanks Jason! You included all the info that I think people would be looking for. I also think it's very good that you included a timeframe, budget info, and screenshot/mockup. I'm going to point people to this the next time someone asks how they should post a job.

It's not necessary, as anytime you create something new the output formatting state is off. Of course, there's no harm in a $user->of(false); call either, but it's not technically necessary. Another way you can create a new user: $u = $users->add('ryan'); The password is actually one thing (and probably the only thing) that you really shouldn't sanitize, because you don't want to change the password they entered. What you should do instead is validate it, making sure that it's a string with some length and at least [n] characters (whatever your requirements are). By validate vs. sanitize, I mean don't sanitize (clean) what they entered, but give them an error and make them enter something new if it doesn't validate.

Thank you. This was very helpful in building a user messaging feature! Loving ProcessWire.

I'd be interested in taking this one on. Timeframe is more than enough, changes required to the module aren't that tricky either. I don't think you're wanting to do this, but you could assign a different email address to a different section of the site or something if you wanted to handle different blog categories, or else something could be done with category title as part of the email title like "Post title||categoryname" and split on the || Lots and lots of possibilities.

Good day all! I'm looking to hire a programmer to further build out the Email Image module (http://modules.processwire.com/modules/email-image/). I'd like to build upon or modify this plugin to meet my needs. That being said, I am very open to sponsoring this and releasing it to the public as a free module (add-on to the current module or a new one), however it makes the most sense. What I'm looking to accomplish: 1. The text of the email creates a new blog/page entry in a specific category/section. 2. Images (email attachments) upload to the new blog/page entry and inserts into the page below text in grid layout. Images would enlarge with light box treatment or something similar. Descriptions for each individual picture could be edited in PW at a later time. 3. Needs further investigation - option to convert attachments to slider gallery. Basically, this would be a field report that someone would email to create a new entry with pictures underneath. Timeframe: 30 days Budget: Approximately $500USD (please let me know if this is way off base) Payment Method: Paypal, Credit Card, Bank Transfer (international bank transfer possible but I have not done this before with my current bank, so would have to investigate further) Thanks, Jason

In our case just explaining it once usually does the trick -- haven't really had the need to add anything about this to descriptions or stuff like that. It's a simple concept really and our clients have so far seemed to appreciate it, at least once they've been explained why this works this way. Personally I prefer to think of image (and usually file) fields as "storage spaces." If content in those fields should be visible on the page (note: this isn't automatically the case!) it should be added to one of that pages visible fields (in our case most commonly named after columns -- left, main, right etc.) Of course there are special cases where you could automatically show images or files on page.. or you could use repeaters to create fixed blocks with couple of options regarding text and image positioning or something like that. Depends a lot on the use case really. Anyway, my point is that current approach is very good for many situations and can be easily customized for various needs, image manager being just one example of this. Give it a good try, see how it works for you in some real life cases and if it still feels wrong, you can always implement something else for your needs. Regardless of that, one important thing to keep in mind when working with PW is that "page" is so much more than a "page" in some of the other CMS' out there and thus comparing some features between PW and it's competition doesn't necessarily make much sense. In our case a page is an object that can serve multiple purposes and hold all kinds of data for many different purposes.. you really shouldn't expect all of them to be public or even viewable

I agree and don't agree with this. Concerning the images location, Ryan explained already why the choice of keeping the images in each page, and he made some very valid points. And if you don't think of the wysiwyg fields, this implementation is very practical. On the other side, the implementation in the wysiwyg fields is too minimalistic and could be improved in some ways. I will go a bit off topic to illustrate this last point, hope you don't mind: The PW images process eliminates the possibility of using an external image by URL, I think it shouldn't. Images should appear smaller by default in the insert image view (as discussed here: http://processwire.com/talk/topic/635-thumbnails-of-images-in-tinymce/) Would be great to have the possibility of inserting multiple images at once Would be nice if we could drag the images from the image field to the text field in TinyMce (in CKEditor we can, and it's great ) There are two descriptions, one on the image field and one when inserting the image in the wysiwyg field. This can be very confusing.

That's great about the ProcessWire presentation. I really enjoyed the slides. I can't get the video to play more than one frame at a time, and I don't know what's being said either (I don't have multi-language support installed). But it looks like it went on for a good long time. Anyone that speaks German have a summary of what was said / how it went? Also, who did it? Big thanks to the presenter for taking the time to do this.

Are you gone crazy? And even with colors!

Nicely said Ryan! I wonder why always people with "I only know basic HTML and CSS" come with the biggest and most complex coding PHP projects that even an experienced developer would have its adventure.

I think I have leant not to say anything is impossible until Soma has said so! . Where would we be without him!

A german presentation about ProcessWire: Video: (second half is PW) https://bambuser.com/v/3588985 Slides: http://wdcmdresden.github.io/treffen/24-knockout-und-processwire/processwire/#/

All you can do in the site/config.php is something like you can get from PHP: $config->debug = false; if(isset($_GET['debug'])) $config->debug = true; So you could add /?debug to a url and have debug mode on. Or you could add this to the top in admin.php template in site/templates/ folder if($user->name == 'admin') $config->debug = true; And have debug mode only for admin only in admin.

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 backend. It's what PW is made of. 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 a 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>Thanks! Your submission was successful."; } } 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 Edit March 2017: This code still works in PW2.8 and PW3.

Hi all! I want to create the Italian version of processwire site... Who want to join this project ? Every feedback is appreciated !

I'm new here so have been reading a lot of forum posts and doing small experiments. This is about figuring out flexible ways of working with the PW's ways of delivering content. Sometimes having the PW template file echo out stuff from $page is just right but I wanted to figure out an approach that starts with that and adds complexity as needed. So, here I'll show you the parts of my first working test with MVC, recursive rendering of child pages and a template engine. The PW template file is used as a simple controller to delegate rendering to a view. //By default we'll use PW's template as the view name. $name = $page->template->name; //Load the view file require_once '../iop/views/'.$name.'.php'; //Create the view object $view = new $name($options); //<-- options passed to template are passed to view //Hook it into the PW template object $this->addHook('Page::renderView', $view, 'renderView'); //After page does "renderView" output will be in $view->output $page->renderView(); //spew it out echo $view->output; Learned the hook from http://processwire.com/talk/topic/1510-templatedisplay-mode/ The view file: /* this is a view file: $options passed to template are passed to view $options['params'] would be parameters to use in rendering, such as a different template for rendering as child to another page */ require_once $config->paths->root.'/supp/StampTE.php'; class sb3d_mvc_test { var $templateName = null; var $output = null; var $kidOutput = null; var $options = null; var $depth = null; public function __construct($options = null){ $this->options = $options; $this->templateName = get_class($this); //default is to use same name for all the major parts. No extension. $this->depth = count($this->options['pageStack']); } //Prepares data for the template public function prepare($page){ $msg = 'The '.$page->name.' page.'; if(!empty($this->depth)) $msg .= ' The pageStack count = '.$this->depth; return array('msg'=>$msg); } //Renders child pages public function renderKids($page, $params){ $kids = $page->children; if(!empty($kids)){ $this->kidOutput = array(); foreach($kids as $kid){ $this->kidOutput[] = $kid->render(array('params' => $params)); } } } //This view makes use of the StampTE template engine and makes some content from child pages public function renderView(HookEvent $event) { $page = $event->object; $data = $this->prepare($page); //Limit how far down rendering goes and set parameters for child page. Maybe use callbacks? if($this->depth==0){ //not rendering as a child page $raw = file_get_contents('../iop/templates/'.$this->templateName.'.html'); $params = array('renderMode'=>'Sub'); //child pages use this as template name suffix $this->renderKids($page, $params); } else{ //rendering as a child page $raw = file_get_contents('../iop/templates/'.$this->templateName.$this->options['params']['renderMode'].'.html'); } //Now we play with the template engine. This one's interesting in the way it does cut and paste within a template // We could instead leave stuff in $this->output and let the PW template (our controller) build output with PHP/HTML $t = new StampTE($raw); $t->inject('title', $page->title); $t->inject('msg', $data['msg']); if(!empty($this->kidOutput)){ $kidLayout = $t->get('kid'); //extract little subtemplate ('cut') to use for each message foreach($this->kidOutput as $stuff){ $b = $kidLayout->copy(); //each message is put in a copy of subtemplate $b->injectRaw('kidstuff',$stuff); $t->selfkid->add($b); //completed subtemplate is pasted into master template } } $this->output = $t->getString(); } }//class In this case we use StampTE to render the page with the sb3d_mvc_test.html and render the child pages with sb3d_mvc_testSub.html. It's setup to only render child pages from the top level but we could recurse more deeply (not tested) if there was a need to. More could be done. So far so good. The render hook and the $options used by $page->render are key parts. Lot's more to say/ask about PW but I'll dribble it out in future posts. Thanks.

Codemagic is even in the core tinymce plugins in PW. Just have to add it in the field configuration. It even has hightlighting and search replace and autocomplete.

If you do want to stay with TinyMCE there is a plugin to take care of formatting code in the editor: https://github.com/tinymce-plugins/codemagic

NOTE: Here is an updated/more advanced version of the script I posted below. And here's one for updating the CKEditor, if you're using that instead of tinyMCE: <?php include('./index.php'); $fields = wire("fields")->find("name=body|intro|sidebar"); foreach($fields as $field) { $field->toolbar = " Format, Bold, Italic, -, RemoveFormat NumberedList, BulletedList, -, Blockquote PWLink, Unlink PWImage, Table, HorizontalRule, SpecialChar PasteText, PasteFromWord Scayt, -, Sourcedialog "; $field->inlineMode = "0"; $field->contentsCss = "/site/templates/styles/contents.css"; $field->stylesSet = ""; $field->extraPlugins = "pwimage,pwlink,sourcedialog"; $field->removePlugins = "image,link"; $field->save(); } ?> CKEditor is now updated.

Hmmm. The video is working just fine here...of course I don't understand anything they are saying though!

Thanks for the positive response! I'm quite excited about this module and think it will be quite useful to both my projects and the community. Have a great weekend! Jason

This is some code I have been using to generate filter options based on the page fields in a template. I cleaned it up a little, but there is still some stuff in there that is specific to me regarding formatting/output, but might be a useful start for someone. Basically it gets all the fields in the template for the current page (except those you choose to exclude) and builds a filtering form with all of them. You will likely want to ditch the text search field. The reason I excluded body and then added it back in like this was for labeling and ordering changes, but this could be done other, less lazy, ways. This is a POST, rather than GET form. It could be adapted, but the GET that is returned by InputfieldForm is not clean. One thing you'll obviously need to change is where I have the format_results function. I am also using HTMLKickstart, so the output of the filter side div and the no results message won't look great without it. <?php $filter_formcode = ''; if($input->post->filter_save) { // Search selector builder $search_string = ''; $current_field = ''; foreach($input->post as $field_name => $field_result){ if (is_array($field_result)){ foreach($field_result as $f_value){ if($current_field == $pages->get($f_value)->template){ $search_string .= '|' . (int)$f_value; } else{ $search_string .= ',' . $pages->get($f_value)->template . '=' . (int)$f_value; } $current_field = $pages->get($f_value)->template; } } else{ //This is only needed if you want the text search field which is an optional add on below if($field_name == 'body' && $field_result != ''){ $search_string .= $field_name . '%=' . $field_result; } } } $search_string = trim($search_string,','); } else{ $search_string = ''; } $filter_form_page = new Page(); $filter_form_page->template = $page->child()->template; // Populate with the names of the fields you want to exclude OR include (see instructions below) // Leave empty to output all the fields $myfields = array('id','title','body'); $form = $modules->get('InputfieldForm'); $fields = $filter_form_page->getInputfields(); //This adds a text search field if you want it $field = $this->modules->get('InputfieldText'); $field->attr('id', 'Inputfield_body'); $field->attr('name', 'body'); $field->label = "Search term"; $form->append($field); // If array is not empty use it to filter the fields if ($myfields){ foreach($fields as $f){ // Output all the fields minus the ones listed in the $myfields array // Instead, to output only the fields that are in the array, remove the (!) from the condition if (!in_array($f->name, $myfields)){ $f->value = ''; $form->append($f); } } } else{ // Else, include all the fields $form->append($fields); } // Add find button $field = $this->modules->get('InputfieldSubmit'); $field->attr('id+name', 'filter_save'); $field->attr('value', 'Find'); $field->label = "find"; $form->append($field); // Process the form if($input->post->filter_save) { $form->processInput($input->post); } // render out form $filter_formcode .= $form->render(); $filter_formcode = strip_selected_tags_by_id_or_class('InputfieldPageAdd', $filter_formcode); //Strip out the option to add new item to page field (if this has been allowed through admin) even though it only appears to certain admin users $filter_formcode .= '<script> $(document).ready(function() { $(\'select\').css({"max-width":"270px"}); $(\'li\').removeClass("InputfieldColumnWidth"); $(\'li\').removeClass("InputfieldColumnWidthFirst"); $(\'li\').attr("style", ""); }); </script>'; //set select to max width and remove floating selects so each one on own line $out = ''; $out .= '<div class="col_8">'; $filter_results = $page->children($search_string); if(count($filter_results)==0){ $out .= '<div class="notice error"><i class="icon-remove-sign icon-large"></i> Sorry, there are no results, please change your search parameters.<a href="#close" class="icon-remove"></a></div>'; } else{ foreach($filter_results as $result){ $out .= format_results($result); } } $out .= '</div> <div class="col_4"> <h6>Find a Book</h6> <p>Leave filter options blank for all</p> ' . $filter_formcode . '</div>'; echo $out; EDIT: See this post for a cleaner version: http://processwire.com/talk/topic/3583-filter-results-of-selector-using-selectcheckbox/?p=36182

Field dependencies are coming to ProcessWire and FormBuilder later this year, though won't be ajax driven. This probably would not be a good use case for FormBuilder. You can create your own themes with FormBuilder. They are based upon jQuery UI's theme framework. What you are talking about sounds pretty custom, and seems to me more like something one would build from markup rather than with a form building tool.

First of all I apoligise for writing such a long post… was not intended. I'm happy to have found this CMS. I guess like most of us, I came here because somewhere somehow we found a reference to somewhere which leaded us somewhere else and then somehow we landed here In my case I landed here from the CMS Symphony forum, as someone there mentioned Processwire is something to watch out as it looks really cool. Anyhow I don't know if I'm an average Processwire user, and most probably no the right user to create something using Processwire. Why, well, I'm not a programmer, I really have no idea, I could not build the most simple script, I know the most basic HTML and most simple CSS and even though I was able to build simple Expression Engine websites, I'm one of those that knows somehow how to make changes in a template using Firefox firebug or build websites using Wordpress and plugins, so I'm able to build anything as far as I don't have to create much code. I don't know if there are more users as me here, anyway, I wanted to make clear which are my current knowledge limitations but I like learning. So, why am I here? because I have a personal project, I want to do it myself and although I could do it entirely in Wordpress using a bunch of plugins, I'm not sure if that would be the right choice. I have tried to make it entirely using Invisionpower Suite, and although it works in some way, it is not what I really want. So what I want to build is this: A website where users and organizers are able to enter, publish or list events or activities and those users who want to assist to those activities should be able to share their car or accommodation or meet o get know each other even before going to that activity. People who have participated in those events or activities should be able to rate or leave comments about how was that event so that next assistants know if its worth or not to go and organizers can get the benefit of feedback. Kind of an Activities and Events Community with Trip, Accommodation and Informations sharing between assistants. So that is what I'd like to offer: - The activities could be free or pay activities. - Event Organizers should be able to decide to sell pay events on this website using their own paypal or the gateway should be able to calculate a commission in case website's own paypal must be used (small commission for me, the rest for them). - Organizers and users should be able to see how much and how many events tickets are being sold and who is assisting. - People that want to assist to an event should be able to announce that they will assist and if they want, share their car or travel ways with other users going to that event. Ideally when an event is published, you could see e.g: If the event is Barcelona someone from Madrid is going to that event as well by car, so you could just contact that person from Madrid and book a seat in his car. That person from Madrid should be able to list his trip, car model, free seats, seat price, and so on, and when someone else book that seat, then it should show that already one person is driving there in that car with him so that there is still let's say two seats left… same thing for shared accommodation... so you get the idea. - Assistants should be able to share accommodation in case they live near where the event is taking place or maybe anything else… not sure what this project will lead up to, maybe users want to share anything else, or have other demands. - I'd like also to be able to show those activities in a calendar, but an Agenda view would be enough, as there is not such a thing anywhere. - Users should be able to sort and filter those activities (as I see in Processwire that is not a problem) - I was also thinking on integrating a forum but the thing is that without a proper bridge or integration, users end up having two profiles. Having a kind of SSO would be nice. So I think of several ways to do this: 1.- The Wordpress Way integrating following components: - Wordpress - wp-types.com plugins (Forms, Custom Types, Woocommerce plugin, Views) or the ACF (Advance Custom Fields) from http://www.advancedcustomfields.com/ - Woocommerce e-commerce plugin - Woocommerce extensions - Wordpress Affiliates Woocommerce Plugin - Invisionpower IP.Board - Wordpress IP.Board Bridge. - Or integrate it with the new moot comments | forum platform from moot.it, although I must say I like IP.Board. 2.- Expression Engine and the necessary modules (which I have to figure out yet), their forum module is terrible to put it kindly. And after reading their last moves about how are they dealing their Customer Support to small customers, I don't know what to think. I also don't like that in Expression Engine you are not able to add a user to more than one group and that could be a limitation when you build a community oriented website. On the other side there are tons of modules for it. 3.- InvisionPower IPS: I have be able to do most of this customizing the IP.Downloads App module but the end result has lot to be desired. And Invisionpower Suite although it is a really good product, their documentation and Customer Service is not really oriented to help users to build this kind of projects using their platform. 4.- Craft CMS which is still in development, looks really good but lacks an e-commerce module 5.- Processwire which looks amazing. I saw there is an ecommerce module but not sure if I had the necessary skills to adapt it to my needs. And on the other side I guess I'll find myself asking silly questions (for advanced users here) all the time. What do I prefer?… of course the very best thing would be to be able to make it using one single flexible platform and use as little 3rd party modules as possible. Wordpress is not a fast and secure platform and the more plugins you combine within well the slower it can get. What do I like from Processwire? - Simple - Fast - The Form Module looks amazing - The Pro Cache module looks impressive - Updating looks very easy (as I understand just overwrite the Processwire folder with the new version, change index.php and httaccess file) - Documentation (Although I'd have to read it 100 times) looks promising - Great Community, not big right now, but looks very dedicated and friendly. - I like that it works with anything on it (similar to EE) - I have seen that some built sites do similar things as what I want to build. - Built already for Multi-language in mind - It amazes me that there are so much done in such a young system. - It looks as Ryan is a kind of Genius So do you think honestly that someone with my limited skills could build a project like this using Processwire? I think I need so skills I have not right now and I'm specially worried with the commerce aspect of my project… but I'd like to know your opinions about this. Thanks Mario

Hey Everyone, That is an ambitious project! I agree with all that Ryan said. I want to highlight one statement in Ryan's post that I think is most apt here: "But stay with us here and start learning ProcessWire in smaller chunks and on smaller projects, and before long you'll be ready to build anything you can imagine." That makes a lot of sense. I would also add this: instead of looking at the whole project all at once, make a list of each individual challenge in your project, then look for the ProcessWire solution for each one. This is what I did when first using ProcessWire, and I keep using this now for each new project. It is not only a way to learn ProcessWire, but it also becomes a great way to organize your project planning. You will be amazed how even rather complex needs have very elegant solutions in ProcessWire. Thanks, Matthew

IIS isn't technically supported by ProcessWire. Though I understand that several people are successfully using PW in IIS. But just want to point out that this is not the recommended environment for PW, and it would not surprise me if some things don't work. Actually, I'm impressed that it apparently works for the most part–maybe someday we can officially support IIS. This is one component that is LAMP-specific at present. You will have to unzip the language pack locally and upload the JSON files individually. I'm hoping to convert the unzip process to one that is cross-platform before long.

You don't really need any kind of multi-site support if you are just talking about subdirectories. If you want them to use the same database, then just make them all run from the same PW install. If you want them to run from separate databases, then just install PW in the root and the subdirectory… should you want to share the same core, then make /subdir/wire/ a symlink to /wire/. Though when I'm running more than one PW install on the same account, I usually just keep their cores separate so that I can upgrade and test them separately. But it's perfectly fine to run multiple PW installs on the same domain.

Here's another idea to have a flag on the authors page you would keep track if there's any books of the author. So a simple module that does the following on book page save $authors = $pages->find("template=author"); foreach($authors as $author){ $found = $pages->count("template=book, authors=$author"); $author->of(false); if($found && $author->has_books == 0) { $author->has_books = 1; $author->save('has_books'); } else if($author->has_books == 1){ $author->has_books = 0; $author->save('has_books'); } } After that you can simply use: $authors_with_books = $pages->find("template=author, has_books=1); Of course if you have a lot of authors it may not as efficient. But it could be more optimized using a direct SQL then.

Yes, it was more of a proof of concept, but it's working fine. You just have to enter the template and fields of both ends in the module and it will take care when page is saved and map both ends.

If you are planning to build a template for pages that will be viewed on is own, as well as rendered from other templates try this: if ($page->url == $_SERVER["REQUEST_URI"]) include("./head.inc"); // template code if ($page->url == $_SERVER["REQUEST_URI"]) include("./foot.inc"); The head and the foot will be included only if the page is on it's own url.

Ok since you hook Page::viewable every page in PW will be somehow affected, even admin pages as they are also just pages. So the message with $event->object->name is the admin pages rendered in the admin template. I'd guess it's the navigation. But since the ProcessPageList module is ajax driven you won't see any messages from there. $event->arguments is nothing there I think, as the important with these page access hooks is the $event->return value. So you would do set it to false or true $event->return = false; // page won't be viewable All the viewable hook does is define if a page is viewable or throw an 404. In case of the admin page tree the page will still be visible and only have no -view- action button. That's all. If you really want to hide pages in the admin I'm with Ryan, but see that there's cases where it would be nice to hide pages from users and keep a branch hidden from them. I already stumbled and tried very hard 1-2 years ago, but realized it's not easy as there's no obvious hooks available where needed and it's done with ajax and there's some things to consider, didn't really bother. Now after thinking for some time and try error I found an easy way to just remove pages from the page list tree. The trick is to modify the JSON output that goes with the ajax response, convert it to an array and Long story short here's an example module for those interested. I used a pagelist_hidden page field added to the user template to define pages that are hidden for a user. Of course there could be endless configuration possibilities, with roles and what not, but don't want to go any further and maybe someone else finds this useful or as a start for a new module. If Ryan reads this and is still with me. Would you consider adding some hooks to ProcessPageList.module? Or do you think the JSON manipulation is a good way? Most likely there would have to be some additional take care to make those pages also not editable. Those page will still be accessible manually through admin url. Such a module shouldn't be used to hide pages for access restriction, and it's only and best suited for hiding "private" branches in the admin, or functional pages that can't be in the /Admin/ branch for some reasons.

Wel Welcome sosoba! This would be possible by making a hook to any of the the form building methods in ProcessPageEdit.module. All methods with three underscores are hookable. All about hooks. Take the HelloWorld.module and add this hook to the init() $this->addHookAfter('ProcessPageEdit::buildFormSettings', $this, 'buildFormSettings'); And then add this function to the class. public function buildFormSettings(HookEvent $event){ $fieldset = $event->return; // get the fieldwrapper returned $field = $fieldset->get("_pw_page_name"); // get the name field $field->collapsed = Inputfield::collapsedYes; }

I'm not sure what's up but it looks like the caching from GitHub was failing, as I tried to reload it several times but no luck. That issue has turned up in the past too. I went ahead and made /api/cheatsheet/ a redirect to http://cheatsheet.processwire.com - major thanks to Soma for developing the Cheatsheet into a ProcessWire site. It's quite impressive the way he's got it setup with Fredi too. I'm going to start adding more new PW 2.3 functions to it today.

Maybe I am late to the party but I've just discovered this little gem called SearchMark (github link). It's an open source chrome extension that does what historious does. It searches not only you bookmark titles and urls but their contents! I decided to Google for something like this since I have bookmarked lots of PW forum threads! There are times I know I have read something and I have it bookmarked but I just can't find it. I usually resort to Google to search for it again, which isn't the best use of my time . When I was on FF I used scrapbook for similar tasks but that would mean downloading a part of (or a whole) site then searching through the contents. It wasn't dynamic either - I would be searching through old content. But now, with SearchMark, I can "Google" the contents of my bookmarks. It works just like a Google search with wild cards and all! Results are returned with your search terms highlighted I tested SearchMark using this forum thread and was very pleased by its speed and accuracy: I searched the following (on the first post on that thread) // $field->children() - returns that thread + other threads with those search terms "// $field->children()" - returns only that thread // $field->children() -ideas - returns other threads except the above since it contains the word ideas // $field->children() +ideas - returns the above thread plus others with the search terms plus word ideas Now if I could limit it to only search my PW bookmark folder....//Edit: Of course I can add this +processwire.com to my search terms, duh! Hopefully someone finds this useful.

Hats off RayDale - very impressive. No one has ever before written about the guts of processwire so sharp and so clear. On top of that you have put it in context with 2 main cms players drupal and wordpress and that increases the contrast of the whole picture even more !! This post should be put somewhere in the forum fixed and locked (Ryan) Let's not forget about newbies entering this forum repeating the same questions over and over. For them this post is an absolute must read and a real question and time saver.

Kept editing my post so there might be more there than when you last read it

Well, the error clearly states that you don't have an image in one of your pages. The additional if will fix the error. I don't think this has something to do with your harddisk, but maybe an image was not copied over or got corrupt? You could check the pages and make sure all the images are still ok.

I have installed "Elegance" Admin theme on the Windows Hosting and its working fine. Make sure to installed inside /site/templates-admin/ directory.

Thanks Ryan for that beautifully succinct summary of what I was struggling to work out(!). I have almost bitten the bullet that is upgrading my hosting (by migrating to an uprated product that has PHP 5.4.x) and until I do I will just continue to use that simple work-around. Thanks for the clarification Ryan

To avoid any duplication kongondo is talking: In latest versions (not sure if in stable yet), you can do this: $allArticles = $pages->find("template=article|image|video|audio|quote, sort-=created, limit=20"); foreach($allArticles as $article) { $templateFile = $article->template . "-teaser.php"; echo $article->render($templateFile); // It renders the content with article-teaser.php, image-teaser.php etc... } There is of course multiple ways of doing that (I rarely output any markup in templates directly), but I think that would be nice way of doing simple tubmlr-style blog.

For crying out loud! How easy is this system! Only 3 lines of code. PW has spoiled us all! In other words, render outputs those pages including their templates files markup (i.e. not just their field values). The one thing you need to be mindful of (if I remember correctly) is to construct the HTML in those template files (assuming they have HTML) properly so that your rendered pages do not end up with duplicate HTML elements where you should only have one-pair tags, e.g. <body></body><body></body>, head, etc..Only include the markup you need...

This is as simple as: $field = $modules->get("InputfieldSelect"); $field->attr("name", "myselect"); $field->addOption("myoption1", "My Option 1"); $field->addOption("myoption2", "My Option 2");

Ok, changing the code to this makes it work in 5.3 also: $this->addHookBefore('InputfieldPage::findPagesCode', function($event) { $page = wire('pages')->get(wire('input')->get("id")); $event->arguments(0, $page); }); It seems $this was removed from closures at some point (https://wiki.php.net/rfc/closures/removal-of-this) but introduced again (since it works in 5.4).

Looks like a good creative use of tags there. I hadn't planned on them being used that way, but it seems like a good use case. It makes me think I should add a hasTag() function or something, so you wouldn't have to do something like a strstr() and would instead have reliable word boundaries between tags.

Great tutorials and examples Joss! This would probably be a good addition to the Wiki tutorials too?

Translation for core admin, we already have repos. To pack all 3rd party module translation into them too I think is not a good idea at all. Better keep them with the module they belong to.