Leaderboard

In the spirit of Matthew Following Matthew's example, I'm going to be boring and actually take this serious. Sorry guys, no funny images here. Before: I was basically switching my “go-to CMS” every, phew, 6 months or something like that? I'm not going to list them all since I don't see the point in that, but suffice it to say that I have at least evaluated almost any CMS that regularly shows up in one of those “most popular open-source CMS” lists. And frankly, they basically all suck in one way or another. As Matthew stated, it was basically looking for the lesser evil for any given project. After: I just looked it up – the last time I built a new site with a CMS other than PW was September 2013 (explicit client's request for a specific CMS). I frequently do freelance frontend developement for an agency which uses TYPO3 for almost everything, and I catch myself thinking “Boy, how easy this-and-that would be in ProcessWire …” In fact, I finished a project the other day which was built in static HTML because (project management voice) “… a site like this can't be implemented with a CMS.” It could've been. Easily. Just would have had to use the right CMS. Most important of all, and this is what I always mention when I talk to people about ProcessWire, I'm now actually having fun implementing sites. That used to be very different back in the day.

I camped out all week in front of his store to get Form Builder. Can't wait to use it.

How about this little process module You can choose the templates, access permissions, roles, and whether you want to add or remove these roles from the selected templates/access permissions. Test carefully, but I think it should observe all other permission rules etc. For example, it won't let you add Create if Edit is not checked, or already assigned in the current settings. Also, if you choose to remove Edit, it will automatically remove Create even if you don't select it. These are to adhere to PW's access rules. Not sure if this is worthy of being added to the PW modules directory or not - what do you guys think - would people actually use this?

I use this: $fg = $fieldgroups->get("basic-page"); $fields->saveFieldgroupContext($fg->getFieldContext("sidebar")->set("label", "aside"), $fg);

I think it is a very important topic lisandi brings up. Lack of decent translation for PW (at least for languages other than Deutsch and Finnish) is the thing that could limit its propagation. There is a Russian translation module, but it is quite outdated. I still can't figure out how to easily update it - the translation workflow is complex and not documented in any way. There are probably no translations for any modules in Russian. This topic was brought up several times by many but was never made clear. Managing translations could require some adjustments to the software itself. As our community has a distinguished leader and most architectural decisions are made with some sort of his approval I would ask Ryan to step in. We are eager to solve our problems ourselves, but we want to do it together in a non-contradictory way. Let's decide on something )) Translations are a step to make PW more wide spread and therefore to make its development and support more economically advantageous, as I see it.

New addition to contain: weighten! If you want to put some images of different aspect ratio onto a webpage and you want that they are displayed more equal visual weightened, you can use this method and options now: . * contain with option weighten $image->contain('square=90, weighten=on'); . . There is also the possibility to prioritize portrait or landscape oriented images: . $image->contain('square=90, weighten=x1'); // landscapes are a bit larger than portraits $image->contain('square=90, weighten=x2'); // landscapes are a bit more larger than portraits $image->contain('square=90, weighten=y1'); // portraits are a bit larger than landscapes $image->contain('square=90, weighten=y2'); // portraits are a bit more larger than landscapes . . Have a look to this output here: . . . . . PS: @Martijn: I have taken your code for the calculations and set the percent value hard coded to 38. This way we only need to turn weighten on or off and have not to deal with values here. The only thing I have added to the calculation is an adjustment to fit better with the largest dimension into the initial bounding box dimensions. (Github)

I know that using PW compared to many others can make you FEEL like you have died and gone to heaven, but as far as I am aware, Matthew is still very much with us!

The linchpin mentality would be espouse all possible solutions appropriate to the scope of the project, considering all elements including budget, time frame, intended audience type and size, target devices, developer's time resources, with the goal to ship it on time and on budget. Themeforest is a great resource for front end designs, and I use it when appropriate (and also codecanyon). But don't expect to get much in terms of support; also sometimes the technologies used are not quite up to date, and the css can be bloated. We all love bespoke–after all, the engine running the site is already as bespoke as it can get without writing your own CMS. But most clients I work with can't afford bespoke frontend and backend so a choice has to be made. I have a few "go-to" TF authors that are great both in terms of design and code quality. The clients usually pick the template by visiting TF. If this was my full time job, I would probably only do 100% bespoke front end because it would be more fun and engaging. But this is all relative- we're already abstracted a few levels away from the bottom with frameworks, css preprocessors, and CMFs... Nobody Cares How Hard You Worked

Sorry, a birthday bottle of wine got in the way ... I will try in the morning! (One has to get old disgracefully, you know)

Same here

Currently to change the 'summary' description in context of 'basic-page' we would have to do this: // get the template $t = $templates->get('basic-page'); // get the field in context of this template $f = $t->fieldgroup->getField('summary', $useFieldgroupContext = true); // value of the field $f->description = "'basic-page' summary description"; // save new setting in context $fields->saveFieldgroupContext($f, $t->fieldgroup); What I'd like is something like this // get the field $f = $fields->get('summary'); // value of the field $f->set('description', "'basic-page' summary description", $context = 'basic-page'); // save new setting, perhaps optional, because behind // the scenes `saveFieldgroupContext` has been called already? $f->save(); Similar for getting in context: $f->get('description', $context = 'basic-page'); Not only is it more intuitive, but less verbose, in my opinion. What do you think?

before: https://www.youtube.com/watch?v=cubV4nELOyk after:

Sounds like a good idea for a future Inputfield type though.

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/

This is the way I use to integrate both worlds together. 1.- _header.php ( or whatever is called the file that contains your <body> tag ) <head> ... <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.2/angular.min.js"></script> <script>var app = angular.module('myApp', [])</script> </head> <body ng-app="myApp"> ... 2.- yourTemplate.php <script> app.controller('myCtrl', function ($scope) { $scope.myvar = []; $scope.myvar = <?=getChildren("template=yourtemplatename")?>; console.debug("my Object form php",$scope.myvar); }); </script> <!-- now $scope.myvar is accesible --> <div ng-controller="myCtrl"> </div> 3.- getChildren is a function that I include in _func.php function getChildren($pageId) { $pagina = wire('pages')->get($pageId); // fields to be avoided $avoid = array("FieldtypeFieldsetOpen", "FieldtypeFieldsetClose","FieldtypeFieldsetTabOpen","FieldtypeFieldsetTabClose"); // fields that must be returned $wanted = $fields; // selector $paginas = $pagina->find($selector); $arr = array(); foreach ($paginas as $child) { $array = array(); foreach($child->fields as $field) { $array['id'] = $child->id; // if we dont' want all fields back if ( !in_array($field->type, $avoid) && in_array($field->name, $wanted) && (count($wanted)>0) ) { $array[$field->name] = htmlspecialchars($child->get($field->name)); } // we want all fields back if ( !in_array($field->type, $avoid) && (count($wanted)==0) ) { $array[$field->name] = htmlspecialchars($child->get($field->name)); } } array_push($arr, $array); } echo json_encode($arr); }

Happy birthday @Joss (according to LinkedIn). Hope you've got that PostMan Pat tie on and are sipping a nice whiskey

This is a very simple way to display some instructions to the admin users. Before starting, you need to write some docs; they can be a hidden branch of your page tree, using basic-page, or a different template of your choosing. You should make each subject it's own page under the docs so you can output each one under an accordion trigger. Required Module: Admin Custom Pages 1.) Follow all instructions to install the module; Also add the ACP_scripts_and_styles field to the admin template. 2.) Make a new page under admin, called Docs or whatever; assign the process as described in the module instructions. 3.) Make a template in your themes directory to generate the output of the docs page. 4.) Select that template from the page select in the admin custom page you created. 5.) also make a folder to keep your admin custom pages scripts and styles; 6.) create a css file to use for the display output and some basic styles (like ol, ul li etc..) 7.) Add the custom css file to your ACP_scripts_and_styles field. You can use any output you want, but i'm using a nested accordion, which is provided here: http://tympanus.net/codrops/2013/03/29/nested-accordion/ this is the content of the admin custom page: <?php $docs = $pages->get(4259); ?> <div id="docs"> <ul id="cbp-ntaccordion" class="cbp-ntaccordion"> <?php foreach($docs->children as $doc) { ?> <li> <h3 class="cbp-nttrigger"><?php echo $doc->title ?></h3> <div class="cbp-ntcontent"> <?php echo $doc->body;?> </div> </li> <?php } ?> </ul> </div> <script src="<?php echo $config->urls->templates ?>_admin_custom/js/jquery.cbpNTAccordion.min.js"></script> <script> $( function() { $( '#cbp-ntaccordion' ).cbpNTAccordion(); } ); </script> you'll also want to add the provided css, js and fonts that come with the Nested Accordion; in the css file you'll need to point the fonts to the actual font directory, for example: /site/templates/_admin_custom/fonts/icomoon_arrows/icomoon.eot it should come out looking something like this: *if you are using Reno theme, you can customize the icon, like for example fa-book, which is used in this example: -- Thanks & Credits to Diogo for originally creating the ACP module, and for Nico for getting it to work with the new admin theme system...

Here in Russia the price of Ryan's commercial modules just multiplied x1.5 with the rise of the dollar. And I did not manage to buy Liser Pro as I intended. I know Black Friday - the day of crazy sales - is comming tomorrow. So I just wanted to suggest PW Store to make a marketing action on this if it is possible)))

What! ?

I was in that line too. One of those guys tried to sell me a counterfeit Form Builder though...

It's an issue of the modules directory: https://github.com/ryancramerdesign/ProcessWire/issues/793.

No, your idiomatic use was fine - I am just adept at bending and twisting idiomatic language to breaking point

WTF? I just discovered that you can assign a custom page class to a template in the system tab in ProcessTemplate and via API. Since when is it in there? I gotta play with that ... this opens tons of new possibilities, MAN!

Ever since.

Use count() to check if images present in a multiple images field...http://processwire.com/api/fieldtypes/images/ (it's an array). Otherwise it always returns true.. if(count($page->bfd_people_picture))

Okay, that was sneaky! But thanks. Bit early for whiskey (and yes, it will have an "E" in it - all those Rorkes in my family tree, don't you know), and I am wondering where the tie is? Since I moved a few months ago I am still having trouble tracking a few bits down.

It's great but the fact that you have to select one option at a time and then it collapses and you have to reopen it can be a bit time consuming... it's fantastic otherwise Would be great if there was the option to use checkboxes as a workaround to select multiple options at once.

Some enlightenment (damn difficult word) tea from Soma would also help!

I'm not aware of any 100% safe way to break module backwards compatibility without risking some older sites having issues. Tagging and adding a note about it here and at the modules directory is an option, of course, and another option would be creating a new branch for 2.3+ and leaving master as-is. Options, options.. Support for specifying where to find a version of a module suitable to specific ProcessWire version could be nice addition to the modules directory and/or native modules manager, but that won't help us much here. Sounds like a wishlist item to me

Why on earth would average business owner care if the website design is custom made or based on high quality template? I don't think they would like to pay extra for custom made car, much rather buy the Toyota hiace and add some nice looking paintings on it. Many people buy ready designed houses, instead of asking something just for them. Price matters. It's entirely different thing when the business is online or the main marketing channel is websites (and clients can be from all around the world). And of course if client just has money and wants something just for them (emotional buying).

What a wonderful world of advice - this should be archived somewhere! Eventually I will get my personal site back up and then I must reprint some of these threads on there. Eventually......

Greetings, This would be great! Tuts+ gets a lot of positive attention, and they do a great job. It would be a really positive thing to have ProcessWire there. I'm ready to march forward with the uservoice vote! I just added my 3 votes! Thanks, Matthew

I am looking to display Scorecards on a rider_profile.php page. I am using a event_results.php page that has a pagetable field that generated the scorecards. The settings of the pagetable field has the pages being created under a page called scorecards. There are going to be multiple cards throughout the year for each rider depending on how many events they attend. Since there are multiple cards per rider I set the pagetable setting for Automatic Page Name Format to Ymd:His to create different folders for each scorecard. When I did that my code below doesn't work of course. How do I search the children folders? I am using $pages so I don't think I can use children() . $event_hx = $pages->get("/2014-season/scorecards/")->find("template=scorecard, Competitor~=$rider"); foreach($event_hx as $hx) echo "<li><a href='{$hx->url}'>{$hx->Event_Name}</a></li>"; Link to Dr Frankenstein's monster. EDIT: I noticed this thread suggested by the forum as related and changed the code to below and it works. $pages->get("/2014-season/scorecards/, include=all")

I disagree with this. It doesn't even have to be 3rd party, but can be self-hosted like pointed out above. I've used Transifex and Crowdin and they make things smooth. Developers can just pull everything at once whenever they wish. Another self-hosted solution is http://www.mediawiki.org/wiki/Extension:Translate and this for easy deployment http://www.mediawiki.org/wiki/MediaWiki_Language_Extension_Bundle Existing file format support: http://www.mediawiki.org/wiki/Help:Extension:Translate/File_format_support

Oh Lord this is exactly what i was gaming for, and your explanation is correct. I will sit on it tonight and read the codes after work, it seems i have to research heavily on Fields as that's where the main concept lies around.

Sorry for poor communications from my part. New shop module is currently in closed beta testing. I am pretty busy at the moment (both work and personal), so there is not too much focus on this. For the pricing I am thinking something like 50€ - 99€ for single site license. Also currently (slowly) building full featured shop profile, that would be single purchase and free to use parts or fully as many times as wanted (single site license required for all new shops though).

before after

Greetings, This is fun. But it really is a good subject to compare what life is like before and after ProcessWire. I already posted my humorous visual. But now, after using ProcessWire more in recent months, here's another way I see it... Before ProcessWire I spent too much time comparing and experimenting with CMSs and frameworks, chasing after specific capabilities. How well does this system do search? What are the templating or theming requirements? Is there a module for [fill in need]? Does it do tags? Is it easy to integrate scripts? No single system did all of these things well, so I was always trying another one, always having to be satisfied with "good enough," and always working around limitations. New projects always presented another "surprise" coding need I had not considered before, forcing me to search again for a system that can do it. After ProcessWire I can confidently handle all of these capabilities, dong them the way I need them to be done for each project, and I know the system will provide an intuitive way to handle those "surprise" coding needs that inevitably arise. I gain better and better understanding of the underlying coding principles behind these development capabilities. Thanks, Matthew

Tnx WillyC it's commin from here. before: after:

Due to scope, you need to use wire('config') inside a function. Same is true for all the PW variables: http://processwire.com/api/variables/ If you'll be using it a lot in the function, you can do $config = wire('config') and then use $config as normal after that.

The Beach Boys before and after Processwire Before: After: https://www.youtube.com/watch?v=9kg-pYItaj8

Martijn Having spent the first 25 years of my career as a recording engineer working in both advertising and music, I relate to that on so many levels that I just cannot begin to count them Absolutely precious! Joss Edit: Probably should clarify my past a little bit (though terribly incomplete): http://www.imdb.com/name/nm0762708/

b.efor after

Hey Everyone, Having just migrated from another CMS, the "before and after" is fresh on my mind each day I work with ProcessWire. My comparison focuses on the experience of building sites before and after ProcessWire, This requires a couple of videos, as opposed to still shots. Here you go: Before ProcessWire Thanks, Matthew EDIT: Something is wrong with the forum embed function...