Leaderboard

Looking at your fields again, I see you are storing some simple stuff as comment ID in their own field (i.e. db table). I seriously think you should consider creating some custom Fieldtypes to store some data. For instance, the forums views could all be in one Fieldtype and the different view properties would all be stored in it as sub-fields, i.e. the database schema of a FieldtypeForumViews could look something like this: forum_id forum_cat_view forum_desc etc 1 xxx This is a cool forum 2 xxx This is members only forum Sorry if this seems to be taking you back. My thinking is that you'd rather get it right (or better) at the beginning than later. I don't know how comfortable you are with code and if you will be able to develop custom Fieldtypes and Inputfields that will come as part of the forum. However, Fieldtypes are very powerful, modular, will still allow you to use the PW API, are very scalable and will allow storing of lots of stuff that would otherwise probably end up as a page (nothing wrong with pages but sometimes a custom Fieldtype is better than using a field that ships with the core). TBH, if I was to do my Blog module all over again, this is the approach I would most likely follow. I for one would be willing to help you although my time is very limited. Sorry if I am raining on your parade, but thought this was an important matter to consider.

I am not sure this is how I would consider it. Btw, a lot of fields is relative. There's a site here in the forums that had 800+ fields! Whilst I thought (then) that that was a lot of fields, some people looked at me like duh! Since then my perception has changed and is guided differently. So, rather than asking these from a cosmetic point of view (visual bloat?), I think we should be asking the following questions? What are the forums data needs? How best can we store that data to facilitate efficiency? (i.e. easy, fast and optimized queries) What format should we best store a data format in? Varchar, int, etc? If storing strings, are we better of storing some stuff as JSON? Should we store some stuff in one page or as different pages? Should we store some data in its own table or store it as part of a column (sub-field) in a row? How will the forum scale vis-a-vis our data model? EDIT: See next post - Are all/some of our data needs best served by developing custom Fieldtypes and Inputfields? We then base our data model around such questions. If that results in 20, 50 tables, so be it. Give me a scalable data model any time than a short list of fields in the backend, something that I won't be spending my time interacting with often Just my 2p

I actually registered back in January but then proceeded to bounce around CMSs, then went back to wp because it's just so easy to find and activate a plugin. Now I have a multisite with ummm, 40+ plugins and a highly functional theme. I cringe on every update. I even have a couple I can't update because I had to tweak them. Lucky for me, there's a plugin to prevent other plugins from being updated accidently. Time for some sanity and some learning. I know html/css pretty well. Last year's versions at least. php or programming in general? Not so much. Took the UK Kent Univ programming aptitude test and didn't do too bad, considering I've never taken an algebra class. I've been blue collar all my life. Electric sign fabricator for 25+ years. Large projects that took weeks. Did many high profile jobs but towards the end, no matter how fancy it was, it was boring. Time for something new. Getting too old for all the climbing, stooping, lifting and breathing toxic fumes typical of a sign shop. Inks, paint, welding etc. Likewise, getting into another blue collar field is not much of an option at 50 so I've decided web dev as my new career. Jumping into a tech career at 50. Did I say sanity? Nevermind. Winter's coming on here and I've set this winter aside for learning php and a CMS thouroughly. Or as thouroughly as I can in one season. It was going to be wp but I just can't stand the UPGRADE TO PRO atmosphere and worry it might be contagious. (there are exceptions of course as I have come across some stand up guys and gals there) I've got a lead on building a site for a small nearby city and the thought of using wp brought feelings of panic and nausea. Depending on their time frame, I may have to use a responsive html/css/js site and upgrade them to a cms later. I don't have the job yet so I'm not going to stress about it. However, I still want to get into something a little more structured yet flexible and it really comes down to ss or pw. I think they're pretty similar but pw looks to have a less steep learning curve. So here I am. I am the type of person that likes to figure things out or find things on my own but I'm sure I'll have plenty of ignorant questions. Thanks for your patience in advance, John

In the past few days I rewrote FEEL as a module. I can say that it's more usable this way, and will be even more if it gets to the modules directory. Module settings makes it easier to adjust global options. The ability to override options on individual edit link was also kept. There may be some quirks in the module version but it's quite stable as it is. I tested it on 3 sites (single-lang and multilang) and seems to work fine. Notable changes: rewritten as a module, usage mode changed to $page->feel() array format for options (options can be accessed by their names) new option: "Enable module" - toggle module on/off globally new option: confirm iframe close if edit form has changed (only on Pages, uses the built-in admin notification message) fixed: wire("user")->language only available on multi-lang setups JS callback functions (still in WiP status) new: override options on individual edit links The new github repo is here: https://github.com/rolandtoth/FrontEndEditLightbox I'll keep the previous repo for historical reasons, with a big "unmaintaned" warning.

You need to use quotes if you've spaces in the attributes value.

I have to add that documentation at code level was always good, but lately, it's becoming even better.

wireshell 1.0.0 is out See Bea's post -------- Original post ----------- Now this one could be a rather long post about only an experimental niche tool, but maybe a helpful one for some, so stay with me Intention Do you guys know "Artisan" (Laravel) or "Drush" (Drupal)? If not: These are command line companions for said systems, and very useful for running certain (e.g. maintenance, installation) task quickly - without having to use the Admin Interface, first and foremost when dealing with local ProcessWire installations. And since it has a powerful API and an easy way of being bootstrapped into CLIs like this, I think such a tool has a certain potential in the PW universe. It's totally not the first approach of this kind. But: this one should be easily extendable - and is based on PHP (specifically: the Console component of the Symfony Framework). Every command is tidily wrapped in its own class, dependencies are clearly visible, and so on. ( Here was the outdated documentation. Please visit wireshell.pw for the current one )

Hi everyone, Here's a little module that allows you to force users to change their password on their first login, or at any time if you manually force it. http://modules.processwire.com/modules/password-force-change/ https://github.com/adrianbj/PasswordForceChange Key Features During install it creates a new checkbox field in the user template, "force_passwd_change". Automatic checking of this checkbox when creating a new user is determined by the "Automatic Force Change" module config setting. When a user logs in for the first time (or if you have manually checked that field for an existing user), they will be warned that they have to change their password and they'll be automatically redirected to their profile page. They must change their password to something new - they are not allowed to re-enter their existing password. Bulk "Set All Users" option to at any time, force all users (by selected roles) to change their password. Hopefully some of you will find it useful and please let me know if you have any suggested changes/enhancements. PS I used the new info.json way of defining the module details, so it requires PW 2.4.3+

Hi all, I thought I'd take this opportunity to announce a module I've been working on for a private project. Although it's not yet complete, I thought I'd take the time out to see if anyone would be interested in it. I only have the module locally on a test site, so if there is any interest, I can upload it somewhere suitable and maybe others can add to it, provide feedback etc. What is HermodBB? Hermod (messenger of the Norse gods) BB (Bulletin Board) is a module that installs a selection of templates and fields that you'd expect for a frontend forum. It also provides some methods to easily save topics and comments. All topics and comments (replies) are simply pages, and are organised like can be seen in the following image. Each forum has checkbox permissions for viewing, posting, pinning etc (see image below). These permissions can then be verified with some simple code (see below). // Use the helper method to pull a list of forum pages $forums = $hbb->forumsRender(); foreach ($forums as $forum) { // Only show the forums to those that are allowed to view them $rolesForumView = $forum->hbb_forum_view; if ($rolesForumView->has('id=' . $user->roles)) { // User has view access for the forum } } HermodBB also makes it easy to add comments to other pages, i.e articles, blogs etc. Comments are added as sub-pages, just like they are for topics. What HermodBB doesn't do HermodBB does not dictate any markup or sanitization. Any sanitization method can be used, and each topic and comment can easily be rendered as required. I'm currently using UIkit and CKEditor, but this can easily be changed to Bootstrap/Foundation etc. It keeps everything simple so that Processwire can do all the heavy lifting. Note: I am aware that there is the excellent comments module by Ryan, and also the Discussions module by Apeisa, but I needed something a little different for my current project, so I decided to have a bash myself. I am by no means on the same level of coding as the majority of members on here, so please be gentle I'd also like to thank Ryan personally for such an excellent framework. Any questions etc, please feel free to ask.

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 know that trashed pages keep the prev. parent in their name, so it can be restored later, but is there a api way to get that value without restoring the page? E.g. still getting the (parent) event a reservation was part of, even if the reservation time elapsed.

After finding ProcessWire, I knew it was the perfect fit for our corporate site. The power behind PW meant I could do anything I wanted quickly and efficiently. I very quickly moved on from WordPress to PW for our clients and I have never looked back. WordPress has always been frustrating to use however I felt the alternatives I found came with their own faults also. However this is a very different story with ProcessWire, it ticks every box. The API is powerful, versatile and easy to use. The CMS is secure with no known venerability (how great is that!), The templating is very easy and sticks to PHP convention. There is plenty of custom fields in the core, but great module support also. But also it's very easy to use for clients. All these are important and ProcessWire ticks every box (including multi-language). I can't thank you enough Ryan (and others working the project) you have really made an excellent product. http://www.thebrandnewidea.co.uk/ I look forward to hearing your feedback.

Can is mostly right. _x is one of the tags that indicates a translatable string, which you can then translate via PW admin. The _x means that it is a context sensitive string. Read all about it here http://processwire.com/api/multi-language-support/code-i18n/#context It should output the language code for the current user language. If you're doing multilang sites it's wise to study all of the docs linked above.

Kongondo - just wanted to send a big thanks for this - just used it for the first time as a way to provide a preview of content from a hidden page tree and a modal edit link to edit that content - really very handy!

I believe this thread is the documentation

Please search google for this: processwire Error: Maximum function nesting level

How is the data stored on the cheatsheet? Would it be possible to host the project on GitHub? I've wanted to add stuff many times, but it's not really obvious how to contribute.

Update: I think I found solution. In InputFieldFile.js replaced xhr.setRequestHeader("X-FILENAME", unescape(encodeURIComponent(file.name))); to xhr.setRequestHeader("X-FILENAME", encodeURIComponent(file.name)); and then in WireUpload.php (line 134) replaced if(!$filename = $_SERVER['HTTP_X_FILENAME']) return false; with if(!$filename = rawurldecode($_SERVER['HTTP_X_FILENAME'])) return false;

That's a lot of fields. How about an option to bundle groups of them into Textareas fields, or maybe put some in an external table. Just thinking out loud here, haven't thought any of this through.

Andrey, With adapted code stolen from Soma here: https://processwire.com/talk/topic/4476-validating-field-before-page-save/ (post #2), you can do something like below in an autoload module. Be sure to read Soma's explanations as well in that post/thread. <?php class ValidateEmail extends WireData implements Module { /** * Return information about this module (required). * * @access public * @return array module info * */ public static function getModuleInfo() { return array( 'title' => 'Validate Unique Email', 'summary' => 'Ensure Uniqueness of Emails across site', 'author' => 'Kongondo, Soma', 'version' => 001, 'singular' => true, 'autoload' => true, ); } public function init(){ $this->addHookAfter("InputfieldEmail::processInput", $this, "validEmail"); } public function validEmail($event){ $field = $event->object; if($field->name == 'mail'){ $page = $this->modules->ProcessPageEdit->getPage(); $oldEmail = $page->get($field->name); $newEmail = $field->value; #$this->message("old value: $oldEmail"); #$this->message("new value: $newEmail"); $existEmail = $this->wire('pages')->get("id!=$page->id, template=basic-page, mail=$newEmail, mail!=''"); if($existEmail && $existEmail->id > 0) { $field->value = $oldEmail; $field->error($this->_("That email $newEmail is already taken mate; go fishing! :-)")); } } } } This will save if unique, keep old value if not unique and show error. I am not sure what you mean by admin gets error notification; you mean send them an email or log the error? I'll let you Google that

Thanks for the feedback. It's always appreciated. My plan is to create a module with minimal code at first, and hopefully others can add to it so that together we can make this something stable and easy to use, with all the features we'd expect. One thing I don't want is a bloated mess. I'm curious to find out what you all think about fields. A forum module obviously has the potential to install a lot of fields. Personally I don't mind if those features are useful, but I'm interested hearing what you think. HermodBB currently installs 21 fields, and these range from storing the IP address, to storing who has viewed the topic, and to storing the permissions for a per-forum based permission system. Some people will consider 21 fields to be bloat, but a forum obviously needs to store a lot of data. So what are your views? I have made sure that fields are grouped in a logical manner so that they're not all over the place. *field names are still likely to change, but you get the idea

All is in the cheatsheet and website docu is years old but still actual and valid (we are working on it continually). (I can update a 2.3 install to latest and it still works).The API doesn't change and there's a version number on each entry and if it's deprecated it will show as such. It's only that some of newer API (only few) are not yet in the cheatsheet, like many other hidden API that's not meant for the cheatsheet officially.

I've created the cheatsheet and there's a extended view of it. The idea is, that there would be more extended description and examples along with deprecated, introduced version etc. It's a work in progress and it's slowly going forward. This was built already 2 years ago. I just fixed a bug that wouldn't show it to the public and many API entries are not yet worked on. Cheatsheet and Extended docu is built on PW! We are a small team that has access to the cheatsheet PW backend. But practically anything would be possible to make this even more a place where dedicated people would be able to contribute. We're just not yet sure how. A good example would be http://cheatsheet.processwire.com/files/image-properties-in-addition-to-those-in-file/image-width/

There's even the maintenance module by pete, where you can setup a raw html page to be shown for guest users.

I cannot insist on how much this comment is true, I was a total PHP noob, never really understanding what I was doing with other CM's. Its like, before I was just scripting my way through life, with Processwire it feels a lot more like I'm actually programming. Now I'm just a noob actually learning programming along with Processwire.

Thanks! The idea behind backup:db is that backup is the entity/namespace, and you can specify: :db for database :files for /site/assets/files :scripts for all scripts (/site + /wire + root files) :all for :scripts + :db

I do the exact same as this quite a lot - obviously if you're tweaking things on a live site a lot and there are lots of visitors it's not ideal as if someone loads the page when you're just uploading a template change and you're doing this quite a lot they'll possibly get an error. I'm doing it all the time on a site at the mo though as it's not open yet - it's in maintenance mode anyway using my module (cheap plug ).