Leaderboard

Yes, there has been very strong growth recently. Monthly visits in April: 2011: 5 112 2012: 12 448 2013: 48 455 Most popular countries this year: 1. United States 2. Germany 3. United Kingdom 4. Netherlands 5. India 6. Finland 7. Switzerland 8. Canada 9. France 10. Italy

Yes, it looks like PW is rapidly becoming more popular. Ryan posted some stats here some months ago: http://processwire.com/talk/topic/1793-2012-critic’s-choice-cms-awards/?p=20070 Google trends look good too: http://www.google.com/trends/explore#q=processwire

You can add a page field to the user template and a role parent. Then you can give them access to their children pages with (all code written in the browser): if ($user->hasRole("parent") && $user->kids->has($page)) { //show the page } else { // redirect to a general page or show 404 } and to the room page like this: if ( $user->hasRole("parent") && count($user->kids->find("parent=$page")) > 0) { // <- tricky hein? here we had to check if any of the kids of this user has this page as parent //show the room page } else { // redirect to a general page or show 404 } To link to the pages from the entry page you can: // show the kids pages and room foreach($user->kids as $p) { echo "<a href={$p->url}>{$p->title}'s page</a>"; echo " and "; echo "<a href={$p->parent->url}>his room</a>"; } Doesn't help that we are talking about real children and real parents while writing PW code

Today I want to present my personal website with a new design and my tumblr posts (in "Blog" section) directly imported into ProcessWire: Nico.is What do you think?

Hi valan, I've found a solution. The translations of the labels (not default) are stored in the 'data' field in the 'fields' table, as JSON. Example: {"label1012":"Weight"} where 1012 is the ID of the language. You can try this code: $label = 'label'; if ($user->language->name != 'default') { $label = "label{$user->language}"; } // Output label in correct language echo $user->fields->get('field')->$label;

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/

Greetings Everyone, ************************************************* ************************************************* EDIT NOTE: This post started as a work-in-progress discussion as I was working out the elements of a successful form. After contributions from participants in this discussion, the code below has been tested and works well. You can use the code as shown below in your ProcessWire templates! Feel free to follow up with additional quesations/comments! ************************************************* ************************************************* I have successfully built front-end forms with ProcessWire to add pages via the API. It works great -- until I had to include image uploads along with the "regular" form fields. Then it temporarily got a bit complicated. In this discussion, I show how to handle front-end submissions in ProcessWire with the goal of allowing us to create pages from custom forms. I then go a step further and show how to use the same form to upload files (images and other files). I'm hoping this discussion can illustrate the whole process. I know a lot of people are interested in using ProcessWire to do front-end submissions, and my goal for this discussion is to benefit others as well as myself! First, here's my original contact form (no file uploads): <form action="/customer-service/contact/contact-success/" method="post"> <p><label for="contactname">Name:</label></p> <p><input type="text" name="contactname"></p> <p><label for="email">E-Mail:</label></p> <p><input type="email" name="email"></p> <p><label for="comments">Comments:</label></p> <p><textarea name="comments" cols="25" rows="6"></textarea></p> <button type="submit">Submit</button></form> And here's the "contact-success" page that picks up the form entry to create ProcessWire pages: <?php // First, confirm that a submission has been made if ($input->post->contactname) { // Save in the ProcessWire page tree; map submission to the template fields $np = new Page(); // create new page object $np->template = $templates->get("contact_submission"); $np->parent = $pages->get("/customer-service/contact-us/contact-submission-listing/"); // Send all form submissions through ProcessWire sanitization $title = $sanitizer->text($input->post->contactname); $name = $sanitizer->text($input->post->contactname); $contactname = $sanitizer->text($input->post->contactname); $email = $sanitizer->email($input->post->email); $comments = $sanitizer->textarea($input->post->comments); // Match up the sanitized inputs we just got with the template fields $np->of(false); $np->title = $contactname; $np->name = $contactname; $np->contactname = $contactname; $np->email = $email; $np->comments = $comments; // Save/create the page $np->save(); } ?> This works great! After submitting the form, we go to the "Success" page, and new submissions show up in the ProcessWire page tree right away. Excellent! Now I need to add a photo field. I altered the above form so it looks like this: <form action="/customer-service/contact/contact-success/" method="post" enctype="multipart/form-data"> <p><label for="contactname">Name:</label></p> <p><input type="text" name="contactname"></p> <p><label for="email">E-Mail:</label></p> <p><input type="email" name="email"></p> <p><label for="comments">Comments:</label></p> <p><textarea name="comments" cols="25" rows="6"></textarea></p> <p>Click the "Select Files" button below to upload your photo.</p> <input type="file" name="contact_photo" /> <button type="submit">Submit</button> </form> And here's the updated "contact-success" page: <?php // First, confirm that a submission has been made if($input->post->contactname) { // Set a temporary upload location where the submitted files are stored during form processing $upload_path = $config->paths->assets . "files/contact_files/"; // New wire upload $contact_photo = new WireUpload('contact_photo'); // References the name of the field in the HTML form that uploads the photo $contact_photo->setMaxFiles(5); $contact_photo->setOverwrite(false); $contact_photo->setDestinationPath($upload_path); $contact_photo->setValidExtensions(array('jpg', 'jpeg', 'png', 'gif')); // execute upload and check for errors $files = $contact_photo->execute(); // Run a count($files) test to make sure there are actually files; if so, proceed; if not, generate getErrors() if(!count($files)) { $contact_photo->error("Sorry, but you need to add a photo!"); return false; } // Do an initial save in the ProcessWire page tree; set the necessary information (template, parent, title, and name) $np = new Page(); // create new page object $np->template = $templates->get("contact_submission"); // set the template that applies to pages created from form submissions $np->parent = $pages->get("/customer-service/contact-us/contact-submission-listing/"); // set the parent for the page being created here // Send all the form's $_POST submissions through ProcessWire's sanitization and/or map to a variable with the same name as the template fields we'll be populating $np->title = $sanitizer->text($input->post->contactname); $np->name = $np->title; $np->contactname = $sanitizer->text($input->post->contactname); $np->email = $sanitizer->email($input->post->email); $np->comments = $sanitizer->textarea($input->post->comments); $np->save(); // Run photo upload foreach($files as $filename) { $pathname = $upload_path . $filename; $np->contact_photo->add($pathname); $np->message("Added file: $filename"); unlink($pathname); } // Save page again $np->save(); ?> <p>Thank you for your contact information.</p> <?php return true; } else { ?> <p> Sorry, your photo upload was not successful...</P> <?php } ?> Replace the field references with your own field names, make sure to change the various paths to match yours, and change the various messages to be what you need for your project. Read the entire discussion to see how we worked through getting to the solution shown above. Thanks, Matthew

Hi guys, I've been spending the past couple days trying to get myself acquainted with PW... and I find myself swaying between excitement and discouragement. I'm excited because I'm really loving the way PW works but discouraged because I can't help but feel that I'm in way over my head. I'm not sure if this is in part because I still haven't reached the "AHA!" moment, but I'm also just very frustrated with my own lack of PHP knowledge (it's even less than I originally thought - at this moment, I think I'm completely PHP illiterate). Now, I really don't want to give up on PW, so I come here in hopes that someone can help point me towards the best way to approach "learning beyond the basics". I've gone through the various tutorials in the wiki and followed the Basic Website Tutorial as well, felt like I have a decent general grasp of things. Then I decided to upload and take a look at the blog profile. It had a lot of features I'm looking to implement, so I thought it would be good to see how things are done and make changes where necessary... except I think I ended up getting overwhelmed by it. Simply put, I can't make heads or tails out of a lot (most) of the PHP coding I see in the template files - never mind adapt it to the site I want to build! So, I've got a few questions. For someone who isn't a developer, would you say that jumping in and trying to take the Blog Profile apart is a bad idea? Is that considered advanced territory? Should I have just tried to build everything from scratch and add in the extra features step by step? Though, I'm not even sure how I would go about doing that, to be honest. I'm just lost. The basic stuff, I can grasp... like if I were to build a "static" site with various sections and some content, I can do that with PW at this point. The problem is, I think, the more advanced parts - as in, where and how to grow from the basics. I don't know where to even begin to tackle things, especially when it comes to specific customization. For example, I could probably copy and paste code for implementing comments... but then because I can't even understand what I'm copying or how to code PHP, I don't know how to make little changes, like say if I want to make it so that admin comments are styled differently, or if I want to load up Gravatar if one exists and if not then a default avatar, etc. Stuff like that. I'm sorry if this sounds like I'm just rambling randomly... it's just that I think I'm stuck at that point between being able to do the basic stuff but not having a single idea as to how to grow beyond that - short of going off to take some intensive PHP courses or something. So I guess my bottom line question is, how doable is PW for someone who doesn't know any PHP (and isn't just going to build a basic site with some content)? Am I better off not jumping into the deep end without at least knowing some PHP first? I've mostly built sites on ExpressionEngine and a bit of Textpattern in the past, so landing in pages of PHP code makes me feel like a foreigner in a strange country. And while I'm here, may I just quickly ask what the difference between $page and $pages is? The Basic Website Tutorial mentioned it a bit, but I'm not sure I truly understand when to use which... and what it means when pulling content from the page or another page? I sincerely apologize for my newbie whining...

Having passed to the specified address the user can replace the email address, in result of that, it can replace the address with the address of the existing user, such in a way having used possibility of change of the password, to change the password and to come on a site under account of other use https://github.com/ryancramerdesign/ProcessWire/pull/192

Processwire is a perfect load balanced template/code system. If that fact is recognized and experienced by more people it can really boom drupal and wordpress away from cms land. But then again, strangly enough, it doesn't work that way. You can be the best and yet other wanna be designs get more credit and more fame. I am in the repair/service field for computers for more than 15 years and I know of tools like deepfreeze and shadow user that can recover a pc fool proof from any software problem/attack/virus/mis-installs/wrong driver installs/dumb users/user mistakes/ etc. etc, simply by rebooting the pc. And yet is everybody knowing about it and buying it ? No ! Why ? Beats me ! Same for tools that can make a pc with 8 Gb of ram or more start to fly and run your programs in high speed mode by using a ramdisk or supercache. Doesn't everybody want his pc to run your programs super fast ? Make IE / FF / Word / Photoshop / etc. etc. run fast ? Yes ! Do people know and use ramdisks and supercache ? No ! Why ? Beats me ! I guess people are sometimes hard to understand.

There aren't any core security issues that I can find here. But Khan is right that the email address really should be unique, just as a general security principle. Not enforcing unique emails does lead to potential security issues, or at least plenty of ambiguity when writing login/password related stuff. We should spare people from having to think about that in their own API code, and think the solution has to be at the database level with a unique key on the email field. That way if you are writing your own front-end login and/or password reset capability, you don't have to consider the implications of email addresses not being unique. If you have the core "forgot password" module installed, then realize that your account is only as safe as your email (which I think is safe to assume for any such function). That means that you should only put in email address you have access to, and if you ever lose that email, then make sure you update your account with your new email address. But of course, that would be a problem whether in ProcessWire or anywhere else. But there is a reason why the "forgot password" capability is not installed by default, and that's because such features always reduce security, even if they are written in a secure manner. So as always, leave the forgot-password capability uninstalled unless you absolutely need it (whether in PW or anywhere else). Yes, you'd basically be giving the other person access to your account. Or at least the ability to reset your password. But it doesn't really matter if that person has an account or not, so long as the email has a recipient. But this is the nature of the beast, whether in ProcessWire or elsewhere. I suppose making email addresses unique doesn't really matter all that much in this case. But I still agree on the value of having emails be unique. It just makes for a more bulletproof/less ambiguous user system.

Hang on. I think I understand now. I was going about that wrong.

I got it working, but it is very hackish and definately should be looked after. I will fork apeisa's code tomorrow and try to figure out why my current version does work and the latest on github won't. For now you can check if this gist works for you. It does for me. It's an old version of the module I installed on my local machine at home. Then I changed some code with the new version. I didn't fix one warning, just placed an @ before it to stop the warning.

USA, USA, USA! Oh wait, this isn't a futbol.

Just use isset($input->post->list)

Looks very interesting - http://alphapixels.com/prepros/ (Windows only)

With url segments (http://processwire.com/api/variables/input/ scroll to the middle of the page). Allow them on the authors page template, and on this template's file put something like this: if ($input->urlSegment1) { ​$username = sanitizer->name($input->urlSegment1); $userpage = $pages->get(name=​$username, template=user, include=all); if ($userpage->id) { // echo the user info. these would be custom fields added to the "user" template echo "<h2>{$userpage->first_name} {$userpage->last_name}</h2>"; echo "<p>{$userpage->bio}</p>"; } } You can add any info you want to the users pages by adding fields to the "user" template (on the templates page, under "filters", enable "show system templates?") Edit: Wanze beat me again. He beats everyone lately Edit2: corrected my code to make the check for guest visitors that Wanze refered, except that I'm using $pages instead of $users to get the user page

Hi patrik, You can use urlSegments for this case. In your template used by the /author/ page, enable urlSegments in the Template config. Then in the template file (example code): if ($input->urlSegment1) { $username = $sanitizer->selectorValue($input->urlSegment1); // Maybe you need to add 'check_access=0' to your selector if also guest users can see this page... $u = $users->get($username); if ($u->id) { // Display the information about user } else { throw new Wire404Exception(); } } // No urlSegment passed - throw a 404 or output some message

Hi sakkoulas, That's because the standard font set by the module does not have those characters included. I removed all fonts but the standard ones from the tcpdf folder so the module doesn't get too heavy. You can do those steps: Download TCPDF Copy all files starting with freesans* or freeserif* to /site/modules/Pages2Pdf/tcpdf/fonts In your module configs, set freesans/freeserif under Default font Then the greek characters work (make sure you enable debug mode or save the page to delete any cached pdfs). I think this is the easiest solution. Disadvantage is that the pdf is a bit heavier due to this font which includes all unicode characters. Another possibility is to convert a greek font to TCPDF according to the docs: http://www.tcpdf.org/fonts.php Does this work for you?

Hi, I have a series of sites I'm building which are, for the most part, reasonably straight-forward. But there's an element to each one that I'd rather give to someone else to work out for me. The site is for a day care centre (part of this service) which has 3 'rooms' - one room for each age group (o-2, 2-3 & 3-5 years). In each room there are approximately 30-35 children. The task I've been set is to give the parent of each child a unique login with which to view their child's portfolio at the end of the year (it might be a PDF or a gallery of jpegs, I'm not sure yet). Additionally each room has a daily 'diary' and if you're the parent of a child in that room you can also see a gallery of images for that day. Home - Rooms - 2013 -- Room A --- John Johnson --- Frank Smith --- Bertie Jones --- etc -- Room B --- Mark Smith --- Ted Nelson --- etc - Daily Diary -- 2013 --- Room A ---- 29 March ---- 30 March ---- etc --- Room B ---- 29 March ---- 30 March --- Room C ---- 29 March ---- 30 March In the PW admin I need a straight-forward admin page that the administrator of each section can: a. Create a username & password - and be able email it when necessary to that parent. b. Assign selected pages (most likely just the diary page and their child's page - they may have more than one child at the centre) to that user so that only they can see it c. Help with template code and code for login forms & password reminders At this stage I'm happy to be guided by the bigger PW-brained people as to how best to achieve this - and how much it'll cost of course. The crucial thing is having the user admin be easy to use as the folk using it haven't used ProcessWire before. Regards Marty

I think a good word for this site is "engaging" and I think that's a very important part of any website.

WOW!!! It works! Wanze, thank you for help! - I've started to think that problem doesn't have elegant solutions in PW. But you proved that PW has such solution! P.S. hope to see this kind of hints documented sometime by core PW team!

Anyone using sshfs to edit files in the server? I'm using to edit files in my server, and it's extremely practical. Is there any inconvenient? ps: the equivalent for mac would be osxfuse and for windows win-sshfs

@adrian - No worries buddy @apeisa - Yup, going to later this evening.

No, I liked the footer in the last version of my site so it was allowed to stay

Hello Roelof. You can do that for a right arrow: <img id="arrowright" src="/yourfolder/arrowright.png" width="64" height="64" /> and than, $("#arrowright").click(function() { $('#magazine').turn('next'); }); same process for left arrow $("#arrowleft").click(function() { $('#magazine').turn('previous'); }); If you want to use left and right keyboard arrows: $(window).bind('keydown', function(e){ if (e.keyCode==37) $('#magazine').turn('previous'); else if (e.keyCode==39) $('#magazine').turn('next'); }); Hope it helps.

Sorry, I was wrong. type exists on the field object. So this should also work: if ($fields->get('yourImageFieldName')->type == 'FieldtypeCropImage') { // Thumbnail FieldtypeCropImage is the Fieldtype used by a thumbnails image field.

Well, managed VPS is one option. There you can ask hosting company to configure the server for you. Servint (their vps: http://www.servint.net/vps.php) seems to be great choice and also what Ryan & ProcessWire recommends: http://processwire.com/servint/.

I think that you could do this: if(count($image->getHooks('getThumb'))) { $url = $image->getThumb('thumbnail'); } else { $url = $image->url(); } another way: try { $url = $image->getThumb('thumbnail'); } catch(Exception $e) { $url = $image->url(); }

I think that purely because it varies so wildly from individuals up to agencies, plus how complex the job is (a forum setup in one software is easier than another, similar with styling) you might have a hard time getting responses to this manviny. In my experience, no two jobs are ever the same, even if someone wants the same as a previous client

Great Ryan, I have my own server with IP : 205.186.157.177 You can setup the DNS with this IP. It will be visualized an ugly "Forbidden" but i think is not a problem now Thank you!

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

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

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

Hi antknight That wouldn't work - like I wrote that would produce an error 500. However, I found the cause of the problem in the .htaccess file: #Options +FollowSymLinks Once I commented out this directive, the problem disappeared. I found the solution here: http://www.wallpaper...pache-t718.html And a general explanation of the directive here: http://www.webmaster...orum11/1962.htm I hope this helps others with the same problem. /Allan