Leaderboard

@jtborger, You are not wasting anyone's time. The fact of the matter is that overall, there is still a lot of room to improve ProcessWire's documentation and tutorials across a range of topics spanning both basic and advanced stuff. It is something we are aware of and are keen to improve. Part of the Road Map for 2016 is exactly that...'continued and greater focus on documentation and tutorials'. Of course this does not mean everything will be done and dusted by the end of play 2016 but there should be some positive advances nevertheless. Whilst there are some great examples in the forums regarding various uses of the ProcessWire API, those cannot and should not be considered as a long term solution in lieu of proper documentation. In the meantime though, they are a good place to start if you are searching for particular answers. Welcome back to the forums

Right now we are busy with 2 big data projects and both we do in PW3. It's quite stable, but all software has bugs. For us the reason to choose PW3 is to be ready for the future. ImportPagesCSV for example doesn't work but next to that I do not see many issues. On the other hand, both projects have no front-end, so no testing over there . I think when the time allows potential slowdowns due to bugs, it's good to live cutting edge and support ProcessWire with bug reports.

Hi @holmescreek, Welcome to ProcessWire and the forums. You might want to have a read here first about various approaches to categorising site content. I have only had a quick glance at the PDF. I notice you are creating the ABBA page directly under POP then also having the possibility to select POP (the parent page) within ABBA. That's not the 'usual' way we got about this. What would work best is something like this (page tree): Genres (template genres) Pop (template genre) Foreign Rock Artists (template artists) ABBA (template artist) U2 Rolling Stones Then, in the template artist (for individual artists), add a page field of type multiple, called, for example, genres. In the page field genres, in template of selectable pages, set that to 'genre'. Then, in your artist pages, say when editing ABBA, you can choose all the genres you want for the band, e.g. 'Foreign' and 'Pop'. In the front-end end you can then do something like: // grab all pop bands (if many, you may want to place a limit and use pagination) $pop = $pages->get('/genres/pop/'); $artists = $pages->find("template=artist, genres=$pop"); // or, if users are viewing the POP page $artists = $pages->find("template=artist, genres=$page"); Of course, it is possible to search for multiple genres in a single query. See the selectors' docs here. This type of organisation keeps duplicity to a minimum.

Like everything that you share on the web, people will always be able to download it if they really want to. There are for instance sites that download any soundcloud file for you. I think the easiest way is to use the <audio> element, and if you want to make it less easy to download, just remove the element from view and use the API to create custom commands, or use a plugin that will do that for you (ex: http://kolber.github.io/audiojs/). This will at least force them to go to the source code to know where to get the file. It really depends on the people that you will give access to, so make sure you chose them well. You can always degrade the files, either by cropping them or by reducing the sound quality, to make them less valuable and still show the music, but this might annoy the people you are trying to impress. I would tend to just be very picky with whom I would invite to listen, and be very clear about the conditions by writing it on that page. I believe that showing trust will give your client better reviews.

@flydev: many thanks for your contribution, I have added it to the module by following your perfect guidance step by step. Very Nice. So, I have not tested it because I have no server with a Self-Signed Certificate at hand. But I very likely trust someones code who is able to contribute PHP code backwards compatible from PHP 5.6 to PHP 3.0! $version=explode(".",function_exists("phpversion") ? phpversion() : "3.0.7");

I needed a language switcher so i searched the forum and docs, found very useful stuff, but as im new in processwire (came from joomla) all this is still a bit confusing for me, need time to get use to it i guess. There's probably other people like me get confused in all the power of pw, and need language switcher on the site, so i decided to share what i came up with. Actually its very simple, a lot easier then i thought. There is very nice example in docs using select box (there i found out about $languages array, and its clicked), but you need additional script if you wanna style it, so i came up with something simple: TADAAAAA <?php foreach($languages as $language) : ?> <a href="<?=$page->localUrl($language)?>"><?=$language->title?></a> <?php endforeach;?> Here's another example, but now active language is just a span with active class. (Style used on most websites). <?php foreach($languages as $language) : ?> <?php if($user->language->id == $language->id) :?> <span class="active"><?=$language->title?></span> <?php else : ?> <a href="<?=$page->localUrl($language)?>"><?=$language->title?></a> <?php endif;?> <?php endforeach;?> Here is UIkit dropdown example, same can do with bootstrap, just a bit different markup. <div class="uk-button-dropdown" data-uk-dropdown> <button class="uk-button"><?=$user->language->name?></button> <div class="uk-dropdown uk-dropdown-bottom"> <ul class="uk-nav uk-nav-dropdown"> <?php foreach($languages as $language) : ?> <?php if($user->language->id != $language->id) :?> <li><a href="<?=$page->localUrl($language)?>"><?=$language->title?></a></li> <?php endif;?> <?php endforeach;?> </ul> </div> </div>

Hi folks, I quickly tested locally with ProcessWire 3.x and it worked by disabling the file compiler for the external mpdf library. I need to test a bit more, especially the multi language support of the module, before I commit a new version. But if you want to make it work in the meantime, here you go: Add // FileCompiler=0 to the first line after the php opening tag in the file /site/modules/Pages2Pdf/mpdf/mpdf.php Delete the folder /site/assets/cache/FileCompiler/site/modules/Pages2Pdf to make sure the module files are recompiled Now generating and downloading PDFs should work Cheers

On the second question regarding placing artists under various genres and allowing the end user to sort the artists for each unique genre I think I got it. At lunch, I got the bright idea of implementing the above, but, reversing the page field implementation. In other words, instead of going to artists->artist and selecting the genres they belong to I did the opposite. I set up where you could go to genres->rock and select the artists -- using AsmSelect the user can now manually re-arrange the list of artists that is unique to each genre. So now the user can manually sort artists differently under each genre. example: music->ROCK ABBA ZZ-TOP JENNIFER LOPEZ ROLLING STONES JOAN JET BRITTANY SPEARS music->POP JENNIFER LOPEZ BRITTANY SPEARS ABBA Thanks, I thought about the same thing over lunch (above) -- was doing my post about this as you were posting the idea.

If you want to sort the artists differently for each genre, you'll probably have to reverse the logic and add an "artists" page field to the genre template and put the artists there. Each page then keeps its own sort order for its field contents, so your client can sort the artists however he wants. It doesn't scale as well though if you have many artists.

You're mixing two concepts here: First, the native parent-child relationship that PW provides. ABBA is a child of the Pop page (category). This is what the backend shows and every page can only have one parent. Second, you have relationships through page fields. This is completely structure-agnostic. You're actually making things a little complicated by placing the artists underneath a category. Easier would be to have a page "artists" underneath "music" with its own template and under which you have all artists, no matter what category they belong to, and simply set all the categories for the artists like you already do. Presentation of the relationship for the frontend happens in your PHP template file for music-genres, where you get all the artists for the category with a selector like $artists = $pages->get("template=music-artist, music_genre_types={$page->id}"); instead of calling $page->children. You could mix both concepts and merge $page->children with the result of the selector above, then your current approach would still work.

This is just a directive. You can include the code without any issue. [doc]

Cool ! but... I forgot the following line in step 3, class hnsmtp; In the constructor we need to add $this->emailMessage->smtp_certificate = $this->smtp_certificate; I edited my previous post containing the instructions. Nice module and thanks for the update, I tested it right now and it work like a charm!

Hey Horst, Thanks for your post. We figured it out. My assumption that the Inputfield stores the tags wasn't correct. You have to get the field itself and you can access the tags from there. You can find the code that actually works: wire()->addHookBefore('Inputfield::render', function($event) { $inputfield = $event->object; if ($inputfield->hasFieldtype && !empty(wire('fields')->get($inputfield->name)->tags) { $inputfield->set('wrapClass', "tag-" . wire('fields')->get($inputfield->name)->tags); } });

Hello, Here is a small contribution from me for the PW community I converted the Greek characters to ASCII ones so when a user writes a title in Greek language it will be auto validated. To do this you have to copy and paste the below values on Modules > Core > Page Name. α=a ά=a β=v γ=g δ=d ε=e έ=e ζ=z η=h ή=h θ=th ι=i ί=i κ=k λ=l μ=m ν=n ξ=ks ο=o ό=o π=p ρ=r σ=s ς=s τ=t υ=y ύ=y φ=f χ=x ψ=ps ω=w ώ=w It would be great if Ryan include this on the next PW release.

And we are back... I now recall I have seen this error before (when I was playing around with enhancing the Comments Manager). Yeah, the error is not very intuitive. ProcessCommentsManager should at least catch the error and give a more informative message. What is happening is this. In line #92, Comments manager is calling a constant from the Comment Class. The Comment Class is not a module but a .php file. It is loaded/required_once in FieldtypeComments.module line #22. So, unless you at created at least one field of type Comments, you will get that error. That field does not have even have to be added to a template yet for this to work. If such a field is present, it calls FieldtypeComments.module which in turn loads the Comment.php class and everything is fine and dandy. So, long story short, first create a field of type Comments before attempting to load ProcessCommentsManager. I would also file a request on GitHub for @ryan to consider catching the above error and returning a more meaningful error message for supersusers.

A highly configurable and flexible ACE editor input field. This module is sponsored in part by Nibiri, aka forum member Macrura which was a great jump start. So many thanks to him. See this short screencast to get an overview: Get it from Github or the Modules Directory. Roadmap add full screen mode expose a jQuery api for resizing, setting row count etc. add image handling like in Adam Kiss' version

Hi usually I don't create topics until i feel they are necessary but this is really become a chore for me in development phase, The issue is the Developer Documentation; its really hard for me to get the necessary information I need. I have to go through various topics and navigate through conversations just to find what am looking for. Just today I was looking for the API for the PageField to save a page as a value and I have no luck, I feel this can increase development time to those new to Processwire. i found out there's a site called wiki.processwire.com but it's been last updated 2012 and the cheatsheet.processwire.com doesn't go indepth enough for me to understand what's going on. ADVICE: I feel we can have a documentation page where users can edit and contribute text to it gradually, there's recipe.processwire.com but its still not enough, it would cool to have something like this http://framework.zend.com/manual/current/en/index.html Forgive my rant I come from a country where electricity is not guaranteed so its a big deal for me when I have to spend alot of time looking for information. I don't mind contributing examples or if we can find ways to allow community update the wiki.processwire.com. THANKS GUY Still looking for how to use code to save a PageFieldtype with another page

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/

I'm migrating a massive project that consists of about 15 business systems (like Martijn's they have no front-end), but the same install also powers a fairly large University level public site. It's just on a dev server for now, but so far we haven't found anything broken. Nothing. Zero. I still can't believe it, but there's a lot that remains to be tested.

I am working on 2 Sites going only within the next month. Another big one going online maybe in June. A private site is already online. Until now everything is working quite stable. Look forward, not backwards.

You could perhaps use OR-groups in the selector (untested): $options = array( "level" => true, "max_levels" => 2, "selector_level2" => "(parent!=$lastpageid), (id=$items)" );

Phew, the flexibility is overwhelming. But yeah, that would be checked for.

I think this will work pretty good, Mike. And it will work for pages that are only published in one language as well.

kuba you are linking to documentation for foundation 5. you need to build it like here http://foundation.zurb.com/sites/docs/reveal.html if you have downloaded foundation 6

Perfect, Sergio. I think that I need to spend some time getting to fully understand how multi-lang sites work so I can attempt to incorporate support for them. A quick thought that ran through my mind was this: Source: /{lang}/books/book-details/{id}/? Destination: [[template=book, wpid={id}], {lang}] In the background, this would change the user language if it exists, get the URI, and then quickly change it back. ({lang} would be a specific parameter, which would be allowed to be empty.) That said, the syntax may change for JL 2... Not sure as yet.

Mike, thanks a lot for taking the time to reply. Your solution worked! I thought something similar before posting, but decided to give it a shot. For these book pages, your approach is good indeed, as there are few books. But for my next challenge, mapping hundreds of download items to their new pages, my proposed solution would be handy. But for now I'll just create a script to generate the collection list for me. Cheers!

Hi Sergio, I see your dillema indeed. The problem is that the destination selector is language-agnostic, or, doesn't give specific consideration to the language being requested by the end user. Adding language to the selector doesn't seem to be the way to go - though I haven't tried it at all (not very familiar with multi-lang at this point). The only suggestion I could make is to deviate from using destination selectors (I know they're wicked and what not, but sometimes they're just not the beasts they want to be), and use mapping collections instead. In fact, I think it is more suited to the task. However, it should be noted that I haven't given Jumplinks the ability to have optional params ({segment?}, for example) as yet. So it would be a case of having a jumplink for the URIs without the lang code, and another with the lang code. Source (without lang code): books/book-details/{id}/? Destination: books/{id|wpbooks}/ Source (with lang code): {segment}/books/book-details/{id}/? Destination: {segment}/books/{id|wpbooks}/ Mapping Collection named wpbooks: 1=foo 2=bar n=baz Sure, this is a tad tedious (two jumplinks where there could be one), but I think it's the safest and most reliable bet at this point. I hope this works out for you. Of course, I'll be looking at all of this as I continue with JL 2. Optional parameters is something that has been on my mind once or twice.

Did you really include all these libraries? http://foundation.zurb.com/sites/docs/reveal.html#js-module

You could write a PW page/template that handles nothing but the selectors and returns results as JSON. (written in PHP, with header("Content-type: application/json"); at the top) On the page where this filter is used, you would include some JS that handles the user-selection and talks to the above-mentioned script via AJAX. json_encode + json_decode are your friend

You may be running into a key length issue if your asymetric key has less bits than the data (plus a small amount of padding that openssl adds to close some attack vectors) you try to encode. In your example you have 172 bytes of data, which is too long for a 1024 bit RSA key. You can explicitly state the desired key length through the private_key_bits configarg when you generate a key pair with openssl_pkey_new.

Hello, you might look at this module for the login thing : https://processwire.com/talk/topic/8387-page-protector and some snippets code there: https://processwire.com/talk/topic/107-custom-login/

Sure, could be. Although the docs are much more extended and more up to date than the earliest forum post I found about it accepting the options. But still could very well be. I dont want to sound like a whining boy who points out what is not right. I know I do but this is not my reason for posting this. Its mainly curiousity and the question if it is missed on purpose, if one is aware of it and is by choice of is just the way things are to be done... Dont wanna waste anyones time here.

It might even be, that parts of the docs are created at a time, where the render() method didn't even have any (useful) options.

Hello, I am reading this forum for quite a while now.. and try to stay and help where I can. But I have to learn it first. I tried your solution and IT WORKS! Many times a solution is much more simply than one is thinking. Normal installation. No custom path involved Thanks again! I tried to dig up a few things and only found out that the "FieldtypeComments"-module is not loaded when looking via debug-tools -> modules. Therefore I assumed there is some error. Should I write this bug report or will you/ryan? Also maybe good to work on: If CommentsManager is installed, it is impossible to uninstall. And it is also impossible to uninstall the CommentsModule as CommentsManager is installed. => You really need a field, to uninstall. I think install/uninstall should work without the needing of a field. Have a nice day!

Hi Arjen, in this case, the InputfieldText extends the Inputfield class and has to provide a class named ___render(). Every class that extends the Inputfield class have to do this, otherwise an error will be thrown by PHP. But the parent class itself has not an executable method. To declare it abstract means, it is declared as mandatory for all (child) classes that extends this (parent) class to have this method.

I'm not sure, but I think it is not possible to hook into an abstract declared method: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Inputfield.php#L577, or is it?

Thanks a lot Matthew!! I have done a few things with D3.js and it's amazing what can be done, just browsing the examples page is really great! For example, I am a BIG fan of this guy and his work, be sure to check it out.

For the input type, you should be able to set it like this: $f->set("inputfieldClass", "InputfieldCKEditor"); The text formatters setting works the same, only it expects an array of values (in order of execution): $f->set("textformatters", array("TextformatterEntities")); There's also documention for inputfield dependencies in the API docs.

Tony, You are looking in the wrong place. renderArchives() is only responsible for all archives (e.g. /blog/archives/) and year archives (e.g. /blog/archives/2015/). For month archives (e.g. /blog/archives/1/) it is all about renderPosts(). Have a look at line # 33 in blog-archives.php. Just before that is where you need to pass your options. I am assuming you are using the blog-archives.php demo template file that ships with Blog. $options = array('post_count' => 0, 'post_comments' => 0, 'post_author' => 0); $content .= $blog->renderPosts($posts, true, $options);

Take a look at this issue at Github: https://github.com/ryancramerdesign/ProcessWire/issues/1580 It's fixed on 3.0 (branch "devns"). Not sure if Ryan backported the fix to PW 2.7.x.

Yes, by adding $config->templateCompile = false; to config.php. https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/

You mean something more elaborate than this (which has always been possible btw)? $p = $pages->get(1091); $p->of(false); $matrix = new Matrix(); $matrix->row = 1060; $matrix->column = 1073; $matrix->value = "This is my value"; $p->results->add($matrix); $p->save('results'); $p->of(true);

TextformatterImageInterceptor ( Textformatter module ) Let editors use WYSIWYG images, but let you control the image size, aspect ratio & behaviour. How to install Copy the TextformatterImageInterceptor.module file to your /site/modules/ directory (or place it in /site/modules/TextformatterImageInterceptor/). Click check for new modules in ProcessWire Admin Modules screen. Click install for the module labeled: "Image Interceptor". Go to the module config screen and set the settings you wish. How to use Edit your body field in Setup > Fields (or whatever field(s) you will be placing controlled images in). On the details tab, find the Text Formatters field and select "Image Interceptor". Save.About the settings Render Inline styles If checked, some inline styles are added to the image.High Density Double the pixel width of an image if the percentage is not set. (fixed image size)Default there are settings for landscape & portrait images. Squared images will inherit all settings belonging to portrait settings and there's a way to escape the default settings. But before we dive deeper in tagged sets I want to spread some light on the landscape/portrait settings. All images portrait/landscape wil get the class name .default. ps, All images including tagged set images get the image orientation as class (.landscape / .portrtait) Percentage The width of the image in percentage. This setting makes the image responsive or if left blank the image wil be fixed size. Images receive a .responsive and a .p-50 class (where 50 is the width in percentage) Width The width of the image in pixels. So the width of the image in percentage and the pixel width combined wil be the key to pixel desity. Alignment There are 5 different ways to align an image. left, center, right, inherit (inherits from the WYSIWYG editor) and not aligned. If render inline styles is checked the aligment wil be set directly in the inline style of the image. Alignment classes wil be added to the image. Aspect Ratio (cropping) if an aspect ratio is given, the image will be cropped to the given ratio. If you type 2:1 in the landscape settings. Images 800 pixels wide, will be croped to a 800x400 image. The image gets the following classes: .cropped and .crop-2x1 Image Captions Type here your class name(s) for the caption. When a class name is provided and an image has a description, the image is wrapped (if not already) and *has-* is set in front of the class name(s). For the caption a div is created with the class name(s) and the image description as text. Next to these settings. You can give custom classes to images. This way you can give it framework specific classes for example. And you're allowed to wrap the images with custom HTML. (Some frameworks needs additional HTML to make images more fancy) Then additional styles could be added to images if render inline styles is checked. Tagged sets Tagged sets are an image tag followed by settings specific for images with that tag. To enable tagged sets, the image field need "Use Tags?" to be checked. Go to setup, then fields go to your image field and under the details tab check "Use Tags?". Taged sets are a good way to escape the default image behaviour. Say you have a bunch of nicely ordered images on the page, but you want to show a company logo on 150px floated left. With tagged sets it's no problem. type: (logo 150px left) on one line and you've created your first tagged set. (don't forget to tag the image to) If you want captions for a tagged set, keep in mind that captions need at least 1 class. The format to enter: caption.class-name. For an image wrapper we use the same rules. The only difference is we start typing wrapper followed by class names starting with a dot. example: wrapper.logo.stand-out. You can have a multitude of sets, every set on it's own line. Every set needs at least a tag-name and a pixel width. Note: If you use a wrapper or captions (wrapper will be created if none is set), the inline styles and specific width & alignment classes will be set to the wrapper and removed from the image. This way no duplication of styles wil take place. github modules directory

Another approach would be to have a duplicate of your template folder where you use diffferent code inside your templates. I use this a lot for development in a live site, but its an easy solution to use it for a mobile website too. When your normal site is finished (or while developing) make a duplicate of the template folder and name it "templates-mobile". The goal here is to have exactly the same template files in both folders. Paste the following code at the bottom of the /site/config.php file and change the m.domain.ext to your needs if($_SERVER['HTTP_HOST'] == 'm.domain.ext') { $config->urls->templates = '/site/templates-mobile/'; $config->paths->templates = $rootPath . $config->urls->templates; } This way when you visit your website on m.domain.ext it will use the templates out of the templates-mobile folder while it still uses the same data from the database, assets folder and the modules.