Leaderboard

Yeah, I had my nightmares with this situation too. There are lots of scenarios when ProcessWire could redirect your ajax requests and the graphql will not receive the query. The ones that I had encountered were: If the url ends without slash: ...website.com/graphql ==> ...website.com/graphql/ If there is now www prefix: website.com/graphql/ ==> www.website.com/graphq/ And now I guess when languages are enabled you also gotta make sure ProcessWire is not redirecting you to the respective language url of the graphql api. I haven't tested the module with the languages enabled yet, but I am sure there would be some additional caveats. Yes, that's the expected behavior. Unfortunately to support permission inheritance would be too expensive. Because it means to check template permissions of each ancestor of each returned page. I think the module is already slow and supporting permission inheritance would make it even slower. I guess I have to mention about not supporting permission inheritance somewhere in the documentation of the module. That's right, it turns out there was a bug. I pushed an update regarding the datetime field. Grab the latest version of the module and it should work properly. Yep. That's the way. I know, it's ugly. But I can't think of a less verbose way to return a single page from the api. We could, of course introduce an additional field for each template like basic_page_single or something. But I don't think it's worth it, plus it will make the schema bigger for very little gain. I totally agree. We can't allow everyone to create images. The size field of the image type creates images only if the user has an edit permission on that image field. It is still available to the users who do not have edit permission, but only for getting existing variations, and it should return null if there isn't an image variation with the requested size. Edit: By the way, thanks a lot for the feedback.

Today I have been running in mysql errors using @renobird s Module MarkupActivityLog which still uses mysqli Driver. @all developers Although mysqli is still supported PDO driver is the default database driver in PW since https://processwire.com/about/news/introducing-processwire-2.4/ and its strongly recommend to all module authors to use/change-to PDO driver instead of mysqli. @renobird I have sent a pull request. A list of other affected modules not updated until now. (I try to keep them up to date. Please help) @apeisa ProcessTrashman, ProcessRedirects @netcarver ProcessDiagnostics

While mostly just routine updates, this week we have a new core version on the dev branch with several tweaks and PRs. Work also continues on the Uikit admin theme framework, and more: https://processwire.com/blog/posts/processwire-3.0.58-core-updates/

FieldtypeMatrix and InputfieldMatrix Modules Directory: http://modules.processwire.com/modules/fieldtype-matrix/ GitHub: https://github.com/kongondo/FieldtypeMatrix The module Matrix enables you to save data from a 2D-Matrix table. The rows and columns of the matrix table are made up of pages retrieved via a ProcessWire selector or via a page field selection of parent pages. The matrix values are made up of the data input in the matrix cells, i.e. the 'intersection of rows and columns'. Example Usage You have Products whose prices vary depending on colour, size, material, etc. Using the Fieldtype, you can create a table with rows made up of colours and columns made up of sizes the combination of each making up their respective values (in this case price). So rather than creating multiple text fields to do the following: Colour Size Price Red Small £10 Red Medium £20 Red Large £30 Red X-large £35 Green Small £9 Green Medium £15 Etc... You can instead have the following in one field: Small Medium Large X-Large Red £10 £20 £30 £35 Green £9 £15 Blue Etc... Yellow Purple If you set a selector in the Field's settings, to retrieve pages to build your matrix's rows and columns, it follows that all pages using the template the Fieldtype is attached to will have identical rows and columns. In some cases, this could be the intention. For instance, you might have 'Car' pages, e.g. Audi, Volvo, Ford, Citroen, Mazda, BWM, etc., each of which uses a 'Cars' template that has a single FiedltypeMatrix called 'car_attributes'. If you set a selector to build the Fieldtype's rows and columns, your users can easily compare the cars based on a combination of different values. The following matrix table best illustrates this: Type Engine Size Fuel Efficiency Carbon Emissions Warranty Road Tax Price 1994 Audi brand 1 values, etc. 2000 Audi brand 2 2006 Audi brand 3 2012 Audi brand 4 Each of your car pages would have similar matrices. This allows you to make easy but powerful queries. Such a setup allows you to compare within and across car brands. Say you wanted to find out which car(s) offered the best value for money given certain parameters such as warranty, emissions etc. You can easily make such comparisons (see code below). You can also compare within one car type, e.g. which brand of BMWs does best in what area...The possibilities are endless. In the database, Rows and column pages data are stored as their respective page->id. Matrix-values store any data (varchar(255)). If instead you wanted a template's pages to each have a matrix built of different rows and columns, you would have to name a Multiple Page Field (attached to the same template as the as your matrix field) in the matrix field's settings. When editing those pages, your matrix table's rows and columns will be built using the published children pages of the 2 pages you select in the Multiple page field.. The module allows the creation of matrix tables of any sizes (rows x columns). The rows and columns dynamically grow/shrink depending on the addition of row/column pages that match what you set in the matrix field's settings (see its 'Details Tab'). Please note that, if such pages are deleted/trashed/hidden/unpublished, their data (and presence) in the matrix are also deleted. Entering values in the matrix You have three choices: Manually entry Uploading a comma delimited (CSV) file. This can be delimited by other characters (tab, pipe, etc); not just commas Copy-pasting CSV values. (Tip: you can copy paste directly from an Excel spreadsheet. Such values will be 'tab-delimited'). In addition, if your server supports it, in the field's settings, you can enable the use of MySQL's fast LOAD DATA INFILE to read and save your submitted CSV values. Note that for large tables, you may have to increase your PHP's max_input_vars from the default 1000 otherwise PHP will timeout/return an error and your values will not be saved. I have successfully tested the module with up to ~3000+ values (10x350 table), the Fieldtype is not really optimised (nor was it intended) to handle mega large matrix tables. For such, you might want to consider other strategies. Install Install as any other module. API + Output A typical output case for this module would work like this: The matrix's rows, columns and values are subfields of your matrix's field. So, if you created a field called 'products' of the type FieldtypeMatrix, you can access as: product.row, product.column and product.value respectively foreach($page->matrix as $m) { echo " <p> Colour: $m->row<br /> Size: $m->column<br /> Price: $m->value </p> "; } Of if you want to output a matrix table in the frontend: //create array to build matrix $products = array(); foreach($page->matrix as $m) $products[$m->row][$m->column] = $m->value; $tbody ='';//matrix rows $thcols = '';//matrix table column headers $i = 0;//set counter not to output extraneous column label headers $c = true;//set odd/even rows class foreach ($products as $row => $cols) { //matrix table row headers (first column) $rowHeader = $pages->get($row)->title; $tbody .= "<tr" . (($c = !$c) ? " class='even' " : '') . "><td class='MatrixRowHeader'>" . $rowHeader . "</td>"; $count = count($cols);//help to stop output of extra/duplicate column headers foreach ($cols as $col => $value) { //matrix table column headers $columnHeader = $pages->get($col)->title; //avoid outputting extra duplicate columns if ($i < $count) $thcols .= "<th class='MatrixColumnHeader'>" . $columnHeader . "</th>"; //output matrix values $currency = $value > 0 ? '£' : ''; $tbody .= "<td>" . $currency . $value . "</td>"; $i++; } $tbody .= "</tr>"; } //final matrix table for output $tableOut = "<table class='Matrix'> <thead> <tr class=''> <th></th> $thcols </tr> </thead> <tbody> $tbody </tbody> </table>"; echo $tableOut; The module provides a default rendering capability as well, so that you can also do this (below) and get a similar result as the first example above (without the captions). echo $page->matrix; Or this foreach($page->matrix as $m) { echo $m; } Finding matrix items The fieldtype includes indexed row, column and value fields. This enables you to find matrix items by either row types (e.g. colours) or columns (e.g. sizes) or their values (e.g. price) or a combination of some/all of these. For instance: //find all pages that have a matrix value of less than 1000 $results = $pages->find("products.value<1000"); //find some results in the matrix (called products) of this page $results = $page->products->find("column=$country, value=Singapore");//or $page->products->find("column=$age, value>=25"); //$country and $age would be IDs of two of your column pages Other more complex queries are possible, e.g. find all products that are either red or purple in colour, come in x-large size and are priced less than $50. Credits @Ryan on whose Fieldtype/InptufieldEvents this is largely based @charger and @sakkoulas for their matrix ideas Screens Field Details Tab Inputfield Larger matrix table Example output

http://caniuse.com/#feat=css-grid The CSS standard Grid Layout will soon be usable in the stable versions of the leading browsers. It should hit Chrome and Firefox in March. It is in Safari tech preview, but no clear date. MS Edge is working on updating support. I guess support in mobile browsers will follow. 2017 is the year to use it on sites, where it is OK to experiment with bleeding edge stuff. A complete guide to the system on CSS Tricks Learn by examples (includes video tutorials) Rachel Andrews summarizing use cases for Grid, Flexbox and Box Alignment in a single article on Smashing Mag (note: heavy with Codepens) News on all things CSS Layout curated by Rachel Polyfill support is unfortunately dragging behind with no contributors stepping up to help Fremy

Needed to show someone how to quickly setup some settings for various things in a simple text area: could be used for slider settings, site settings, etc; What it does: gives you a matching variable for each key of each line... 1.) setup a textarea field for the settings ; i'm calling it settings_ta 2.) add delimited settings, 1 per line; i use a pipe (|) delimiter; example: address|some info here facebook|https://www.facebook.com twitter|https://twitter.com phone|(999) 999-9999 3.) in your _init.php, get the settings - replace the page number and the name of your settings field: $settings_ta = $pages->get(1644)->settings_ta; $settings_lines = explode(PHP_EOL, $settings_ta); foreach($settings_lines as $settings_row) { $settings_pair = explode('|', $settings_row); ${trim($settings_pair[0])} = trim($settings_pair[1]); } more condensed version, for those of you who like brevity... foreach(explode(PHP_EOL, $pages->get(1644)->settings_ta) as $settings_row) { $settings_pair = explode('|', $settings_row); ${trim($settings_pair[0])} = trim($settings_pair[1]); } now you can do this in your templates: echo $address; echo $facebook; echo $twitter; echo $phone; Edit: made the code simpler....; 2nd edit - added trim to support using ace editor with tabs Addendum: as an added convenience, you could use the Ace text editor module which would give you a monospaced text field and the ability to use tabs for your settings, which could be more readable and easier to edit. The code has been updated to support this by trimming the exploded strings prior to generating the variable/value. address | some info here facebook | http://www.facebook.com twitter | http://twitter.com phone | (999) 999-9999

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/

Try seats.name=5 and year.name=2008 With page reference fields you are supposed to specify the subfield from the page that has been selected. I never actually realized that some work without specifying the subfield, but I just tested an can confirm what you are seeing. Not sure if this is really a bug or not, but I would definitely recommend always specifying the subfield (either name, title, or any other field from the selected page).

Hi, I Installed the "AutoExportTemplatesAndFields" and when creating repeater fields the module was affecting the fields editing. I had two repeater fields: "repeater1" and "repeater2", the "repeater1" should repeat the "images1" field and the "repeater2" should repeat the "images2", the problem was each time I edited one of them and change the repeated field the other assumed that modification. Example: editing the "repeater1" and change the field to "image3" the "repeater2" instead of having the "image2" has the field to be repeated assumed the field "image3". After uninstall the "AutoExportTemplatesAndFields" module I could edit each repeater and assign different fields to them. I hope you can find the issue it is a great module to use. Thank you.

I think I have found a possible solution for @bernhard and @LostKobrakai concerns about the ability to perform queries in the frontend. You could use the persisted queries technique, basically you can install this npm package (there's also this webpack plugin) that will scan your code and remove the graphQL client side queries and save them to an external JSON file. Then in the PHP side you could load this JSON file and give GraphQL the right query based on the query id sent from the client side (I think you can also send variables along the query id, so the query is not "static"). I guess that if a malicious user sends a standard graphQL query you could just intercept that, so if it is not a valid id from the generated JSON file you won't execute graphQL.

Had a couple of older PW 2.7 sites slow to the point of failure this week. A bit of digging revealed that the external image compression service used by ProcessImageMinimize is no longer available. Development on the module ceased some time ago. Quick fix was to uninstall the module and edit the output code to use native PW image options. All affected sites operational again. Next step is to update them to PW3.0+ ...

Definitely a good point. Just for the record, I'm moving this topic to the Module/Plugins Development subsection of the forum

Hi all and thanks again for a perfect product! I'm glad to see Processwire growing and becoming a strong, popular product. The new look of admin interface (uikit-based) is nice and minimalistic. Maybe it's the starting point to think about the consistent identity for the whole Processwire project. The only thing which is more or less consistent now is the main Processwire color. Somewhate between red and maroon, I call it "Thai color" because it's very popular in Thailand. You meet this color at almost any page related to Processwire, and it's good because this color is very distinctive. But what's about PW logo? There's no consistency. And, i'm unhappy to reveal it, the PW logo (at least the sign, not the text part) is not absolutely original. There are at least three different Processwire logos: The text part of logo at PW homepage (and pure-textual logo in most admin themes, e.g. Reno). The sign part of logo present at PW homepage. The new logo (only sign, textless) present in the new Uikit admin theme. For sure it's too much. A single, unique, consistent logo could be better. As to the sign -- small b in circle -- just look at Beats Audio logo which is very similar. And even worse: there's a CMS which is very popular in Russia and called Bitrix, and it has a very similar logo. So i would like to propose another vision of PW logo. Unique, original, but being inherited from current PW logos. It's only a first approach, will be glad to polish it in case of positive feedback. And thanks again for a great product!

Yeah, I Know.. but with PW you can do whatever you want!! lol

hehe, like this

How does the date field work? I get "Not valid resolved type for field \"datetime\"" datetime being the name of the field in my case. Edit: Forget it I'm dumb, forgot to allow the field. It's unusual to not have access as superuser. But the error message is a little missleading Edit: Lol hmm I added it to allowed fields and still same error. System fields "created", "modified" work fine. Also if you only want to get one specific page is it correct to do for example a { basic_page(s: "id=1001"){ list{ title } } } or are there any other methods? Edit: Something else would be image Pageimage is there any support for creating sizes? I see there's something but I don't understand it yet. Edit: Ok I got it. I have to enable "size" for image first images the it work nicely: ... images{ size(width: 150, height: 0) { url } } ... So we can request a size that doesn't exist and it will create it if we have rights to do so. Thats would be pretty cool. Would be crazy to allow some stranger creating 1million sizes through public API . But still if one has write access it is possible, but maybe thats no real issue. I'm still trying to grasp the concept of graphQL and your implementation in PW. So every new Fieldtype and InputfieldType would have to be implemented to work with graphQL?

Just playing around a little with it and it's amazing having a blast. Just wanted to mention I got caught by a redirect scenario and language stuff. If you have multilange installed and configured to have language segments "/en/", "/de/" ... so trying out ajax requests to "/graphql/" would redirect to "/en/graphql/ " but you get a response: {"errors":[{"message":"Must provide an operation."}]} So it took me a while to figure out and was looking at the query instead. Doing the request to "/en/graphql/" works flawless. I was testing the languages and the graphql pages you create don't have alternative languages active. This also might get you caught, when graphql is installed when there is more than 1 language set up. Permission so far seem to work. The template access setting seem no to be inherited, I guess that is intentional? I may have missed it and it was mentioned. Then I'm sorry. – Like in a default install "home" has guest view access enabled, so all pages inherit that (unless you set it no to). But I had to give basic-page explicit guest view access to get querying. I think it's ok to not have all templates inherit access for graphQL. Thanks and keep up the good work!

This post seems to suggest that Google is looking to offer search results based on its perception of the capabilities of the website's underlying database. That is one of PW's great strengths. An opportunity?

So I figured it out and here is my complete code if it would help anyone else. //get the pages you want $items = $pages->findMany("template=item"); wire()->addHookAfter('Pages2JSON::getValue', function($event) { //get the host $host = wire('config')->httpHost; $value = $event->arguments(0); if(!is_object($value)) return; //check if field is an image, images or file type if($value->className == 'Pageimage' || $value->className == 'Pagefile') { //append the host to those values $urls = array("url" => $host . $value->url, "description" => $value->description); $event->return = $urls; } }); header('Access-Control-Allow-Origin: *'); header('Content-Type: application/json'); echo $items->toJSON(); exit(); Thanks again for the great plugin.

<img src='{$story->imagefieldname->url}' alt='{$story->imagefieldname->description}' /> // single image field <img src='{$story->imagefieldname->first()->url}' alt='{$story->imagefieldname->first()->description}' /> // multiple images selecting the first https://processwire.com/api/ref/pageimages/ https://processwire.com/api/ref/pageimage/

Now all major browsers except Edge ship with Grid Layout support. You can let Microsoft know you want it by voting in Uservoice. The votes do matter:

Default session lifetime is 86400 seconds. You can change this to any value you want. // config.php $config->sessionExpireSeconds = 86400; Allow/ disallow sessions (and the wire cookie) under conditions. Remind that you need this to have access to the backend admin. // config.php $config->sessionAllow = true; If you want to disable cookies only for the frontend /** * config.php * if we would use cookies only for the admin area * */ $config->sessionAllow = function($session) { // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // otherwise disallow session return false; }; If you want to use cookies respecting EU Cookie law I recommend Cans Module MarkupCookieConsent in combination with this settings. /** * config.php * if we would use cookies only for the admin area * */ $config->sessionAllow = function($session) { // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // user accepted cookies due to EU law (Module MarkupCookieConsent) if(!empty($_COOKIE['eu-cookie'])) return true; // otherwise disallow session return false; }; Use the core module SessionHandlerDB to store session vars in the database. Learn more about session setting options and sessions by reading the comments in the files /wire/config.php or /wire/core/Session.php of your processwire installation.

Happy New Year to everyone! For a project that I'm working on, I needed to have dependent checkboxes on page edit forms in the admin. Just like dependent selects but for checkboxes. I couln't find anything and decided to write my first Inputfield module. I have only tried it on PW > 3.0. But it should also work on the 2.x branch. Would be great if some of you could try it out and give some feedback. You can find the module InputfieldDependentCheckboxes at github Here's some screenshots of the module in action and instructions on how to use it. ##An Inputfield for ProcessWire admin interface that handles the display of dependent checkboxes in page fields Sometimes we need checkboxes to depend on other checkboxes in our page edit forms. This module adds this functionality to standard page field checkboxes for 2 or more checkbox fields. ## Installation 1. Copy all of the files for this module into /site/modules/InputfieldDependentCheckboxes/ 2. In your admin, go to the Modules screen and click "Refresh". Under the 'Inputfield' section, install the 'InputfieldDependentCheckboxes' module. 3. Open Modules->Configure->InputfieldPage. Under 'Inputfield modules available for page selection' add 'DependentCheckboxes' from the select dropdown and submit ##Field Setup This inputfield extends the standard checkboxes for page fields. Therefore you need to have page fields configured already that you can extend with this Inputfield type. ###Prerequisites You need to have at least 2 fields of type page that have 'Checkboxes' defined as Input field type and live on the same template. A real world example: There are different types of instructors. Each instructor type can have multiple different certifications. For this to happen, we need 2 page fields (multiple): A) instructor_types: lists pages with template 'instructor_type' B) certifications: lists pages with template 'certification' The certification template needs to have the instructor_types page field to assign one or more instructor_types to a certification. ###Setup (link checkbox fields) 1. Edit your page field A and go to the 'Input' Tab. Under 'Input field type' choose 'DependentCheckboxes'. Hit save. Now under 'Choose the target checkboxes field' choose the name of your field B. Hit save again. 2. In your page field b make sure to choose a template under 'Input' Tab under 'Selectable Pages'->'Template of selectable page(s)'. Your fields should be setup. If you now edit a page that contains the 2 fields, the dependent checkboxes should be working. EDIT: And yes, this is working for multiple dependent checkboxes, too. (I have tried it with 3 so far) Some notes on how the module works behind the scenes: - parent checkboxes (actors) that have dependent checkboxes (targets) get custom data attributes applied which contain arrays of the targets' IDs - some Javascript is initiated on acxtors and targets to handle the display based on the id arrays in the data attributes. EDIT: since this module's mention in ProcessWire Weekly it might get some more attention. I just wanted to point out that it is still in alpha state. I will continue development and more thorough testing while implementing it in an ongoing project within the next 3-5 months or so. I will eventually release a stable version then. If you use the module with only 2 dependent checkbox fields, it should work smoothly. There are still some quirks when using 3 or more and I need to figure out how to best resolve them. So please be patient (or jump in with ideas ).

What $page->get returns depends on the field type, but you'll hardly ever get back a plain array. Btw., $page->get("planos") is the same as $page->planos. For image and file fields, the return value (unless null/empty or set to "Single item") is a PageImages object, which, while it inherits from WireArray and thus implements an iterator so you can run a foreach loop over it, isn't the same as a plain array. If you do need a plain array for some reason (in most cases you won't), you can call getArray() or getValues() on classes inheriting from WireArray.

Almost crying right now. Or having multiple orgasms. Or both. So awesome.