Leaderboard

Update. Font size is now 14px for all base fonts, heading/nav are mostly 16px. Sidebar action shrink down. I think we now have enough space for most page trees. Removed the boxes around the fields as suggested by apeisa. Thin lines to seperate them, especially the multi-column fields. Not sure about this one, because it' really defines the "look" of the PW admin. Updated setup view added. Now looking forward to do more on those fields. Repeaters and image uploads, fieldset. Note: You can use this design under a Creative Commons BY-SA 3.0 licence. Of course, the ProcessWire logo is owned by Ryan Cramer and the Icons are taken from Entypo. Contact me, if you want the layered files or sliced graphics.

Hey all, Here's a demo of what I've built. It's become my primary bookmarking system: I didn't demonstrate it in the video, but this system works amazingly on a mobile device too. It's so easy and quick to pull up stuff I want to read when at a coffee shop or have a few minutes to kill when on the go. I found Diigo's Android App very limiting in comparison, especially since it doesn't allow you to view all of your bookmarks on the mobile app (last time I checked). I have no plans as of yet to release this, but I may in the near future if you are all really interested. There are features I still want to build out as well as a lot of code cleanup and security measures that need to be implemented. Enjoy! Jonathan

Maybe we can make the base color adjustable. A single line of CSS or a line in $config. Here are the only PW blue, green or black versions: I wouldn't make the topic more complicated than it is. We can right now customize the admin theme and write modules. This discussion is good, because we ould create some interessting ideas for future modules - build for the backend of PW. The idea of a blank admin theme is great. This could be layed out as a kit to develop your own admin theme. (In addition, PW could ship with a theme created on top of this blank master).

I think it doesn't matter. The question is wether the page get's deleted or trashed (in backend?). In general, I can't stress enough on you guys here that coding is knowing how to debug and try out thing, print out vars, exit or die. I think you would easily find the problem. The more infos you have to more likely and easily you'll find the problem. No fear! Often with hooks it's good to exit("your var $page->name"); or use $this->message("your var $page->name"); so you can see the message and if the hook get's called and output some infos. Most often a NullPage means a get() or find() doesn't find a page and returns a NullPage, so further operations don't work.

<quote style='diogo'>I dislike looking for a piece of garlic in my fridge</quote>

pwired, you posted now half a dozen links to that webuilder. It's cool you found it and seem to like it but little annoying to have 3 continuous posts of you with the same links to their features list. Apart from that it's not an IDE but a code editor. I almost closed window after reading: "WeBuilder is a faster, smarter and more powerful all-in-one code editor for web developers. Clean interface, ..." I never got why these editors have so many buttons and interfaces (ugly)... then they even write something like: "No clutter WeBuilder is quick, clean and lightweight. It very powerful, yet not stuffed with useless buttons or panels." lol? Looking at their websites code, I think doesn't speak well for them and their editor. I'm so happy I don't have to use such editors and there's these wonderful new editors that focus on what's important. // personal rant over

GitHub: https://github.com/adrianbj/ProcessMigrator This module has gone through lots of iterations with lots of new functionality each time. It is now a fully fledged content migration tool. *** Please be sure to read the GitHub ReadMe to find out what it can do now as most of the posts in this thread are no longer correct regarding its functionality Once it is release worthy, I'll create a fresh thread with all the details. This modules allows export, sharing, and import of page lists via JSON files. It takes care of replicating all the pages, as well as creating any templates and fields that are needed. I have defined "Page Lists" as page trees (parent and children) that store selector values for a Page fieldtype. An example would be a list of countries that would be used to populate a countries drop-down select field. The fields might include: Country Name, 2-digit code, 3-digit code, number code. I would like to suggest a place where we can post json files to be shared and updated - maybe a dedicated github repository? Start of a repo of lists ready to import is now available: https://github.com/adrianbj/ProcessWirePageLists It might handle migrating other simple pages trees as well, but it should not be considered a tool for migrating general pages as it does not handle associated files, nor does it handle fields which store arrays. Probably lots of other things it doesn't handle either It now handles migrating all (I think) field types, including repeater fields, page fields, all Profields fields, multi-language versions of fields etc. The only omission is the actual uploaded files and images in file/image fields. WARNING: This should be considered an Alpha module - please don't use this on a live site at the moment and be sure to back everything up before testing. Would appreciate any feedback on the concept, the code, and the idea of a shared and community edited resource of these files. Also, would love to hear what page lists would be good to share. Here are a few quick ideas: States (separate files for each country) Measurement units Languages Religions Race Academic subjects (chemistry, biology etc) Publication types (book, journal article, newspaper article, newsletter, thesis etc) Car makes and models Anyone have a better idea for a name, or how to better describe "Page Lists"?

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

Sorry to digress, but I just want to thank and agree with Soma here. He mentioned this on some post I read and it has really helped me with my coding. foreach used to be my best friend but now, exit; is my best friend closely followed by var_dump and it's cousin print_r. Add these to the knowledge that PHP and PW provide very useful messages when an error occurs, so far, these are all the debugging tools I need . So, thank you Soma!

So going further good coding is not just assuming it will work, often it begins with always checking if you get what you need. if($p->id) { // do soemthing with $p } else { $this->error("Page not found"); } Will always make a huge difference in finding errors or prevent them.

It's easy to make a module just for the purpose of holding settings and that way you get a nice user interface for them in the admin area. Good clues in the wiki: http://wiki.processwire.com/index.php/Module_Creation#Example_of_a_configurable_module $settings = $modules->get("MySettings"); echo $settings->greeting;

Yes, that's what most of us do . Reading your post I just assumed you knew and that this was for a different use case (good catch Adrian). Helpful resources about Page Fieldtypes are here: http://processwire.com/videos/page-fieldtype/ http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ I still like your method for some stuff I'm working on

I'm with soma here. If I wouldn't mind lots of buttons in a code editor I would be using a full featured IDE like netbeans for a long time already. Speaking of that, I really like the semantic commands in light table. You press ctrl+space, write "op"... oh "open file" is already there. You press ctrl+space, write (set)... oh "user settings" are already there.

WeBuilder's functionality does look mighty impressive. It's just. It's just. It looks kinda ugly.

Good point. You'll find this stressed by many lead developers here including Ryan. Never shy away from using what you believe is the right tool for you and/or for a particular project . Looking forward to reading about your experience with PW once you've put it through its paces

Greetings, To pcreact: Remember, I believe that ProcessWire is a framework with CMS components built into it. I operate day-to-day with that as my working vision of ProcessWire. My comment about "no back-end" is a way of saying that the other frameworks mentioned have just that one bit more of openness and "no assumptions" attitude we all prize. But for me it just means I use a few more lines in my code to tie into the ProcessWire page/field system. Then I am home free to develop exactly like those other frameworks -- but with one very powerful advantage: the querying ease and depth of ProcessWire. Once you are working entirely in the ProcessWire API, I don't currently know of any applications that could not be built with ProcessWire. Thanks, Matthew

Hi Vallery, Did you think about using a Page fieldtype for this? That seems to be the PW way of assigning categories to a page. Set up a parent page, with child pages for each category. Then create a field with the "Page" fieldtype and in the input tab have it point to the parent of the category pages. Choose Asm select (or other) from the Input field type and you should be good to go. I get the feeling you are populating this from the front end? These fields can also be populated via the API, so no problem there. I am not completely sure of your goal, so maybe I am off base here, but I think this approach will give you more flexibility. A bit of a read on the pros/cons of serializing: http://www.mysqlperformanceblog.com/2010/01/21/when-should-you-store-serialized-objects-in-the-database/

(Added by Soma) Note that this module is deprecated. The newer and more maintained version is found here: https://github.com/somatonic/Multisite/ You can get the current dev version here https://github.com/somatonic/Multisite/tree/dev (Original Post) Just pushed simple multisite module to github: https://github.com/a...ultisite.module What this module does? It allows you to run multiple sites with different domains run from single install, using same database. While you can easily do "subsites" like www.domain.com/campaign/, this allows you to turn that into www.campaign.com. This is nice stuff, when you have multiple simple sites, that all belong to same organisation and same people maintain. How to use it? Just create page with name like www.campaigndomain.com under your homepage, then edit this module through modules menu and add same domain there. If your domain resolves to same place where your main domain, it should just work. Please notice that if you have editing rights, it allows you to browse the site from www.olddomain.com/www.campaigndomain.com/, but users with no editing rights are redirected to www.campaigndomain.com (this is because session cookie is otherwise lost). Any problems? Not any real problems, at least yet known. Of course think twice when deciding should the site have own install instead of this. There are few benefits, like getting data from other sites, one admin view for all sites etc... but it can easily get out of the hands: number of templates, fields etc.. It is harder to maintain for sure. Isn't there multisite support in core? Yes, kind of. It is very different from this. It allows you to run multiple pw-installations with shared core files (/wire/ folder). This is totally different: this is single pw-installation which has multiple sites running from different domains. This is basically just a wrapper with one config field for this little snippet Ryan posted here: http://processwire.c...ndpost__p__5578 (so most of the credit goes to Mr. Cramer here). What it also does is that it manipulates $page->path / url properties to have right subdomain value.

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/

hi all, new PW site launch: http://www.ohmspeaker.com/ some of the modules that were helpful or essential for this: cropimage formbuilder fredi importcsv minify piwik analytics procache batcher redirects version control template decorator modules manager page link abstractor sitemap xml admin custom pages markup simple navigation (for the sitemap) forum topics related to this site dev: Legacy Site URL redirects: http://processwire.com/talk/topic/3641-redirect-legacy-url-to-new-pw-page/ Clean up spelling: http://processwire.com/talk/topic/3519-use-api-to-spellcheck-whole-siteclean-up-spacing/ hashes in URLs on change selected product http://processwire.com/talk/topic/3496-help-with-url-param-change/ FormBuilder http://processwire.com/talk/topic/2904-how-to-redirect-by-id/ http://processwire.com/talk/topic/2821-3rd-party-send-conditionally/ http://processwire.com/talk/topic/2820-use-session-to-remember-form-selections/ Custom Menus http://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/ other notes: The skyscraper profile provided the example for how to get started with the advanced product search, a.k.a. the speaker finder. The standard search has been extended to show results in different categories. there is some use of Soma's word limiter for the news teaser text, and for making meta descriptions out of body fields, from this topic: http://processwire.com/talk/topic/3429-how-to-set-text-linecharacter-limits-in-templates/ the design is built on twitter bootstrap framework Fredi proved to be totally essential for the client, in being able to rapidly edit things without having to find things in the admin. This site is going to replace an existing site on a different domain (ohmspeakers.com). At some point we weren't sure if/how we would be able to handle the shopping cart element, and then found foxycart, which proved to be the best choice, very flexible, and easy to implement for this type of site. FC is hands down the simplest and easiest way (imho) we could achieve things like the legacy product pages, where there are various parts and upgrades displayed on 1 page. this version is sort of a "v1", and will be expanded/improved a lot for a v2, which would happen in about 4 months.. BTW - these speakers are really good; i now own 3 pairs ... they look great and do sound totally amazing...! -marc

Two days ago, an idea about a new admin theme came to my mind. Some hours later, I've crafted a first concept in Adobe Fireworks.... The look and feel of the admin is important Two months ago, I've introduced some teachers into ProcessWire. They were none-technically people. At the end, they knew how to use the admin panel to create content or update a gallery on their new page. However at some points, they got confused with parts of the admin theme -beside the problems with our concept on how to use fields and templates for creating content. I think one factor why Wordpress became so large, was the great Adminpanel. It works well and easy (as long as you have a blog and not a twenty-plugins-for-text-pages-site). Editing content on a daily basis is the main task of my customer. I've to take this aspect serious. Problems I wanted to solve Have the page tree always visible. If I do not click the right link, it will be closed after I've finished editing my site More visuals like icons. Simplify some workflows. Creating 3 or 4 pages can result in multiple unnecessary clicks. More focus on important links like the tabs. Guide my customer through some action. Help them to repeat simple tasks. The concept First: Nothing is perfect and its not possible to find one single solution for everything. This was just done in a couple of hours and it's only the first iteration. Quick action button Next to the ProcessWire logo is the quick "Quick Actions" button. It should be possible, to configure it like: "Create a new Page with Template X with page Y as a parent". Use it for skyscrapers, news or galleries. (Yes i know, the arrow is pointing upwards. This is wrong) Two column layout The page tree is always visible (as long as we are in the pages view). It can be navigated as the normal page-tree. If you click "edit" it will become highlighted. Every action that would take you to a new page, would be displayed in the other half of the monitor. Speaking of a "half monitor" - I think that most people use a screen resolution of atleast 1300px. The sidebar should take up to 1/3 of this. On smaller screens, it will become hidden by default or we just simply step back to single pages for each view. If the content is to long, the sidebar becomes scrollable. Page tree I like the Template Decorator made by mindplay.dk. It fits the concept well with black outline icons for every type of template. The same icons could be used in the Quick action menu. I'm note sure what to do with the "move" action. To Do list Think more about the behavior of the elements. Design the modules view. Rework the search and the top menu. Options to "brand" the panel for agencies while keeping the ProcessWire logos. What happens if we are on mobile (small screen) devices? Listen to your feedback.

Is anyone here a heavy bookmarker like I am? Typically I'll get most of my news from Hacker News and Slashdot, followed by some great blogs on a daily basis. I usually never have time to read an article in depth when I first come across it, so I'll bookmark it for later. Or, if I quickly need to get up to date on some topic, I'll do a search (usually by tags) and familiarize myself with important stuff I've bookmarked in the past. After having used browser native based bookmarking (Firefox and Chrome), then Delicious, then Diigo, then Pinboard and becoming frustrated by all of them for various reasons and limitations, I've decided to roll my own little single user (and non social) bookmarking system with ProcessWire (with Bootstrap 3 as the frontend framework). It's still a work in progress, but it takes the best of all those systems with my own power features. It also utilizes ajax for certain actions. I'll need to create a Chrome extension to tie it all together. I have to say however, after working non-stop on it for hours on end and not being able to think of anything else, it's looking slick. Damn you ProcessWire for making this so enjoyable. Jonathan

Table of contents Introducing the App and author Needs First version in PHP/MySQL without any Framework Why Processwire? App Version 1.0 Introducing the App and author Hi, my name is Luis and i´m a German based Web and Frontend Developer. I started 2010 with my own Internetbusiness and noticed at the very beginning of my business that it takes to much time to handle my accounting, invoices and clients. The main problem was that I needed for almost every task his own software solution, so the usual workflow in creating an invoice was something like open the CRM Software because the invoice software was good in creating invoices but bad in managing and searching clients, copy and paste the client into invoicing, create the invoice and handle it over to the accounting software. Not good at all... So I decided to create my own solution to fit my needs in the office management. Needs Invoicemanagement and creation Clientmanagement, very basic CRM Accounting Multi-User Simple financial stats about the Keyfacts of my business possibility to export the data for my tax consultant PHP / MySQL to work with it on intranet After pointing out my personal needs and writing down my usual workflow I started to develop the first version. First version in PHP/MySQL without any Framework In winter 2011/2012 I completed the very first version of my OMS (office management suite). The whole project was written in good old fashioned PHP from scratch. I´ve used this version till November 2012. Why Processwire? In mid 2012 I discovered Processwire and had no idea in how many ways this tool would change my life as webworker. After playing around with PW and developing the first little sites I had a little talk with my tax consultant, she said that my financial reports are pretty good and help to save money. (less time, smaller invoice from her) Why not publish the tool? Well, at this point my app was solely written for my needs, without possibilities for an Multi-User environment or for use in an companies Intranet. I finally decided to port the app to PW because of it´s flexibility, scalability and built-in user-roles. I had to dig deeper into PW at this point to see if I really could. Late 2012 I started porting the app in PW and was surprised how insanely fast developing could be. The whole database structure was ported into PW Pages, no SQL query is done by the app itself. It was possible to recreate the core functionality in about 2 weeks, implementing the Login and Multi-User functionality took another week. WebApp Version 1.0 https://youtu.be/PIgUMLZEcIU The app is now available for purchase @ www.misterui.de * also Processwire with an own eCommerce Script

This works for me $this->pages->addHookAfter('deleted', $this, 'deleteUser'); public function deleteUser($event){ $page = $event->arguments(0); if($page->skip) return; // to prevent multiple calls when using Pages::trash(ed) $page->skip = true; if($page->template == 'student'){ $this->message("Page name in trash $page->name"); $name = str_replace("{$page->id}_", "", $page->name); // strip out the id_ in name $u = $this->users->get($name); if($u->id) { if($this->pages->delete($u, true)) { // maybe recursive in case user has children $this->message("deleted user $name"); } } else { $this->error("user $name not found"); } } } This same code also works with this code $this->pages->addHookAfter('delete', $this, 'deleteUser'); $this->pages->addHookAfter('trashed', $this, 'deleteUser'); $this->pages->addHookAfter('trash', $this, 'deleteUser'); Just depends what you need.

I also tested this a bit...as reported.... this line is the one causing the nullPage error $this->pages->addHookAfter('save', $this, 'updateTheUser'); Without that, the page deletes fine but not the user. Btw, apparently, you can't trash a user; only delete them...I don't know if this is still the case though... Edit: Of course, in the post above, Soma was talking about trashing the page and not the user... Changing the code like this deletes the user but not the page and throws the error "This page may not be deleted" ... $this->pages->addHookBefore('trash', $this, 'deleteTheUser');

Kongondo, add continue; to your list http://php.net/manual/en/control-structures.continue.php Edit: you had two different blues. I chose the lighter if you don't mind

also, first thing to install for Sublime Text is Package Control From there it's as simple as SHIFT + CMD+ P to open package control and install nearly all of the items I mentioned above. It's like Modules Manager, but for ST packages.

I have installed NB and Eclipse b4 but am always overwhelmed by their looks (and I really dislike all those yellow warnings when coding PHP!; can they be turned off until when needed?). I have been using NP++ but feel I need something more robust, esp for PHP (class/methods detection, etc.) Never used ST or WeBuilder b4. Now, I have just downloaded their eval versions to, eh, check them out. Just done a quick test of WB. Stripped it down to no toolbars. This is how it looks like. From my quick test, it seems you can still reach all the functions that were provided by the buttons via the menu and shortcuts for some..Haven't finished testing.... Next, ST!

I think it comes down to user preference as Diogo says. Some people would rather have things streamlined by default rather than drowning under contextual menus. Most projects tend to be a combination of design and functionality and more often than not one side is stronger than the other. I think this shows through from the screenshots. Well designed applications tend to make the experience more pleasurable and conversely if something doesn't feel "right", then the user isn't going to stick around long enough to figure out that there's a button in a submenu that does X, Y or Z. EDIT: I'm not "liking" anything more Diogo says. He has too many likes already. The greedy so-and-so.

Hi everybody, I have a setup where I have to assign one or more categories to a page. After spending some time wondering how I could make PW fields store lists, I decided upon keeping a serialized array in a page field (type = "text"). Here's how: $categories = array ("brushes", "watercolor", "pencils", "charcoal", "acrylics", "egg tempera",); $p = $pages->get(9999); $p->of(false); // the usual stuff... $p->category = serialize($categories); // transform the array of categories into a string $p->save(); unset ($categories); // wipe the slate clean for testing purposes // Now Let's Get 'em! $categories = unserialize($p->category); foreach ($categories as $c) echo $c . "<br />"; The array with the list of categories becomes a:6:{i:0;s:7:"brushes";i:1;s:10:"watercolor";i:2;s:7:"pencils";i:3;s:8:"charcoal";i:4;s:8:"acrylics";i:5;s:11:"egg tempera";} It can be stored in a page field and fetched as an array when needed. Neat! (Just remember to set MaxLength to a higher value if you intend to use "text" fields for this purpose.) Thanks for reading!

Thanks, Adrian. I was not aware of the Page field until today, so thanks for this hint. I definitely like the way it allows you to link pages by fields without rearranging them hierarchically. However, I find this method more appropriate for large-scale structures of page relations, especially when they get updated often. My case is simple: plain list of post categories not longer than 20-30, and quite rarely updated. MySQL will live if I pull the serialized list out, update it and update every half a year Seriously though, those who are reading this topic should consider making use of the Page field for the purpose of linking pages by one or several fields. Iterating them is as simple as foreach ($page->page as $p) { $categories[] = $p->category; }

You're welcome. Just use everything until you find something that works for you

Dude, this is amazing! Good job! The interface is great! You logged in and I was expecting to see a tree, then boom! I see a totally diff app. . I like what you have done with this and taking the time to demonstrate it. It's nice to see how others have leveraged PW as a framework to build applications. We've been having this discussion whether PW is really a framework...well, there's your answer! I'd be interested to have this released, not so much that I'll use it (am not a heavy bookmarker - never used Digg and the like [gasp!!] ), but as a learning platform, inspiration and showcase of what PW can do. Of course, the decision is yours. Irrespective of whether it is released or not, am really impressed. Well-done! Cheers/k

@kongondo, thank you for your help. Basically what it boiled down to was my ignorance. lol. And my lack of patience and/or eagerness to continue development instead of reading instructions. But incase anyone that visits this thread is experiencing the same problems, here you go: So first off, if you want to use a remote MySQL database when developing locally you need to make sure that you create the DB so that you have outside access (this is an advanced option with godaddy). Once you do this, it is relatively straightforward. Just plug in your DB information into the config file and you should be okay. Even with relatively stock my.ini settings in the XAMPP config it seems to work... As for the reason its not loading on the live server, its because I failed to read the email that godaddy sent saying that the ftp server is ready, but my files/site won't be visible for another 24-28 hours... Hopefully it will work shortly. Anyways thanks again @kongondo for the help...

Hi i3i2uno, Welcome to PW and to the forums MySQL could indeed be the issue regarding the 500 error. As per the requirements, PW needs MySQL 5.0.15 or greater (later versions of 4.x may also work). It could be other stuff as well, .htaccess. Did that transfer correctly? is it named correctly? Maybe the rules there are conflicting with GoDaddy server? Missing files? As for connecting to a remote db, never tried that so can't comment Edit: Some GoDaddy issues here: http://processwire.com/talk/topic/1962-cant-reach-admin-page/ http://davidwalsh.name/mod_rewrite-htaccess-godaddy Possibly related/or for info http://processwire.com/talk/topic/82-install-pw-to-subdir/ http://processwire.com/talk/topic/3258-moving-website-from-local-server-to-a-sub-domain/

Greetings, This is a terrific discussion, which opens up a lot of ideas in my mind. Over the past couple of years, I have spent a lot of time using various PHP frameworks (especially like Yii). I would agree with Soma that -- for the most part -- ProcessWire allows you to accomplish the same goals as these frameworks. There is a lot to say here, but I'll try to summarize: ProcessWire's Huge Advantage: Querying and Syntax I find that the syntax of ProcessWire is far more concise and "expressive" (borrowing a favorite Laravel term) than these PHP frameworks. The ability to design very deep queries really quickly and easily is the greatest advantage of ProcessWire. "Framework" vs "CMS" I believe ProcessWire should be described as a framework with crucial pre-built CMS components. Currently, ProcessWire is described as a CMS with a framework behind it. The problem is that when it is described as a CMS, we naturally see comparisons with WordPress, Joomla, and Drupal, and anyone who spends time with ProcessWire immediately realizes it is not the same type of thing as these CMSs. If it were presented as a framework, it would attract a whole different set of people with (I believe) more accurate assumptions. Future Development and Framework Choices Nothing replaces ProcessWire, but I gain something using other frameworks that I often can come back and use in ProcessWire. My very rapid framework rundown... CodeIgniter is essentially dead. Laravel, which seemed great at first, has become overly convoluted. Yii has the best balance as a framework, but when I compared the time and effort to get an application up and running in ProcessWire vs Yii, ProcessWire wins. Lately, I have been experimenting with PHPixie (yes, I am always trying new things), and it is really nice. In fact, I see a lot of similarities between PHPixie and ProcessWire. What Do Frameworks Have Over ProcessWire? The only "advantage" of PHP frameworks over ProcessWire is that frameworks have no back end at all. ProcessWire's back end is extremely minimal, and really does serve the most necessary elements. But when building custom UIs, I often want to just go directly to the database with no assumed page concept at all. With that said, I have developed a set of methods that nicely takes care of this in ProcessWire. And ProcessWire has such an elegant query and syntax system, it saves massive time overall as compared with one of these frameworks. So there is a bit more time getting your custom UI CRUD going, but after that you save huge time using ProcessWire's data-handling system. Sorry if this got a bit far from the direct subject, but it seems that people reading this thread might be asking some of the same questions I have asked about PHP frameworks and ProcessWire. Thanks, Matthew

Repeaters & fieldsets take a lot of space. Most of the time I need fieldsets only for dividing fields and description & label is not needed. For several projects I use a module to remove label and set border and padding to 0 for. Also, the repeater can be way more elegant, if some space is givin back to the admin. (Did not make a module for this) (ps, if someone is interested in the FieldsetSchrink module it's here on github)

Philipp, looks great. Can you show how fields looks without that thin border/shadow and maybe with black/grey labels? I think we should aim for "less borders / boxes" feel. I really like your iteration, very clean looking!

To justify the optional sidebar: Screens under 1200px will not see the sidebar. It will be hidden by default. I've set the first offset margin to 15px and then increase the margin by 20px each level. On a 1280px Screen with 1/3 sidebar I get around 425px. On a 1920px Screen (24" HD Office) I will have 640px for the sidebar. The "problem" are different lenghts for the text + the edit|view|new buttons. Question: How many sublevels do you usually have? I like that aspect. In the next version of the concept I've stripped down some icons. I'm using them for arrows and the template type of a page. I think, it's the tiniest way to display the "type" of template of a page.If not, my customer just thinks of pages and not of galeries,blog posts, news, products,... The top bar is now white. I've chosen the pink/magenta color for everything that has an action, the blue colorto indicate things. The font size also went done from 18px to 16px and the overall look is now a little bit more compact. The second screenshot demonstrates a 1280px window size. This would be a great start. Especially with the theme switcher for the upcomming versions. We could quick build a custom view for a client. Another thing to the "Admin Kit". Maybe the admin-themes can get some sort of an option page where we can disable things like the sidebar. Not sure about this one...

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

Hi JoshoB and welcome to the PW forum - hope you like it! Hmm, interrobang, can you force the browser to switch the language it uses in the tooltips by sending the correct accept-lang header with the page?

I would go with ProCache and some MarkupCache here and there (forms with dynamic options, categories lists etc). And of course enough horsepower on server.

I would think you've got all the 'native' PW options down. If it's a 'little' project i would first see how things perform without any caching. Also remember the usual stuff for pagespeed optimizations, this can greatly impact the feeling you get when visiting a site. If you do want/need caching it's hard to say which one from your ts; this depends on the structure of the project and exactly what kind of dynamic stuff there is. For template caching there are also a couple of different cache expiration options; which may or may nor work for you in this particular project. Performance-wise i think it would be: ProCache > template cache > MarkupCache. Teppo's got a nice article on PW caching on his blog: http://www.flamingruby.com/blog/processwire-caching-explained/ Of course there's lot's more you can do (memcached, varnish etc.) but this is not directly related to PW, and probably overkill.

Hey all, I thought this might be useful for anyone who uses preprocessing tools (like the excellent CodeKit: http://incident57.com/codekit). I came across Prepros the other day: http://alphapixels.com/prepros/ I always used CodeKit up until recently. However, it's only available for mac and recently I have had to dip my toes into the waters of the dark side again with a PC laptop I needed something that would work cross-platform (Prepros works across PC, Mac and Linux). From what I have seen so far Prepros is growing quickly, free, supports nearly every type compiled CSS, has real time refreshes and works across platforms.

Ok, there is no need to change the core for this. I created a small module that allows it for those that really want to do it. https://github.com/ocorreiododiogo/ProcessHomeAdmin

Thanks Alan!

Ah, yeah sorry myself. I'm not a php developer at all, just html/css/jquery. Just trying to learn something new. Thanks man.

Somebody help!!! Pete is being attacked by a furry animal!! :o

Good question. I'm not sure there's a simple answer though. What you mentioned about migrating changes directly from the database of WordPress doesn't sound like a safe thing to do with any database-driven CMS. The nature of a relational database is that there will be records in different tables referencing each other, so when you've got two versions of the same database, they would be challenging to merge. As a result, it's a problem if you have two databases going off on different paths of changes if they need to come back together at some point. I use my staging servers for staging things like new template files, modules, new PW versions, etc. I don't usually stage actual content from one server to another. Or if I do, I'm copying and pasting it (in PW admin) from one to the other. But the way I usually stage major content changes is to make them on the live server, but in a staging part of the site (unpublished, hidden or otherwise inaccessible pages). When ready to migrate, I publish or drag the relevant pages to their live home. Note that this is for content, and not for anything that could interfere with the operation of the live site. Anything that could interfere with the live site (templates already in use, modules, versions, etc.) ideally should be staged on a different server. I don't know of a better way than that. It's not perfect, but it's always worked well for me. Longer term, I want ProcessWire to support a workflow that lets a staging server talk to a live server and publish from one to the other (using web services). I already use this workflow on a lot of sites with custom modules, but they are specific enough to the individual sites that they aren't suitable as a broader solution. However, I do think we'll have a broader solution like this in the next 6 months to a year.

This is my mistake, I sent in you in the wrong direction with regard to $user before. (Sorry about that) $user is actually still the one that was originally supplied to the template (guest). So you need to use the $user returned by the login function. Change your login line to be this: $user = $session->login($input->post->user, $input->post->pass); if($user) { // login success if($user->isSuperuser()) { // now this should work } } The only reason this is necessary is because $user was supplied to the template before the login occurred, so that user is still 'guest' unless you change it (like above).