Leaderboard

It's because of scope. This answer has been given atleast 10 times on this forum. In ProcessWire we have variables like: $page, $pages, $sanitizer, $config, $user, $input, $templates etc. Those can't be accessed directly in function or class scope. They can be accessed via wire('page'), wire('config') etc. etc. and you can access them inside a class witch $this->pages. ( depending on the scope of the methode inside the class ). The wire('') function can be from accessed everywhere. More information is given on the api docs an throughout the forum here. Don't understand me wrong but I think you should read http://processwire.com/api/ before or while exploring demo's etc. The next question could be, where can I find the methode whitelist. etc. etc. I've read the api docs many times. There's next to loads of information, a way of thinking. It's all written very well & it will make you understand the whole philosophy of ProcessWire and it's enjoyable. At first it's a puzzle, but when the first pieces are in place, the rest will follow.

One of the problems with using Joomla on an off since, well, since it started, is that I appear to have signed up for a whole heap of sites so I could download extensions and so on. For some reason, perhaps now would be a good time to try and delete myself from a few or more of those sites...... Oh, a new little collection of PW sites will be appearing shortly ....

.. and of course there's always GitHub. If you're really wondering "what is function x, where does it come from and what does it do", try searching

foreach($pages->get("/video-container/")->children as $p) { echo $p->folgeTitel . "<br>"; echo $p->folgeYT . "<br>"; } edit: Well, now you have two answers... find the differences

$items = $pages->find('parent=/video-container/'); // find retrieves an Pagearray while get gets 1 page object. foreach($items as $item) { echo $item->folgeTitel . '<br>'; echo $item->folgeYT . '<br>'; }

I think you should probably take a look at the concept behind ProcessWire first, then some of the other docs and the cheatsheet as Macrura suggest - start with the Concept page from here: http://processwire.com/api/ The Cheatsheet then gives you a look at most the possible functionality at your disposal in page templates to access your data and files. As for explaining the line of code you quoted: $skyscrapers = $page->skyscrapers->find("limit=3, sort=random"); From memory, "skyscrapers" is actually a "featured skyscrapers" field, so is just a Page field that links to other pages (probably the most useful fieldtype there is. Here is the exact translation: "For the current page (homepage in this instance), find 3 random pages from the skyscrapers field". The $skyscrapers = bit is just storing the results in a PageArray (it's in the docs linked further up my post here) that can then easily be iterated through to print whatever output you desire. If you're wondering why the demo doesn't seem to pick three random pages, I think page caching must have been accidentally left on here so it's always showing the same 3 in the demo, but that's easy to switch off The syntax is based on jQuery and aims to be human-readable. If you imagine that there are a few database tables and queries behind that code, you can easily see how quick that is to write and all without a line of SQL. You can make all sorts of queries like: $architectsCalledPaul = $pages->find("template=architect, title*=Paul"); // finds all architects (pages with the template "architect" with the name Paul somewhere in the title field // and so on... The idea behind ProcessWire is that once you've learned the basics you can build pretty complicated data structures in the admin quicker than you'd be able to writing database tables from scratch and you have a hugely powerful set of functions at your fingertips to do with that data as you please. Most folks here would agree that it has shaved hours/days/weeks/months off their site build times depending on website scale, but any time saved is good!

@Chris Rosenau I also had a similar question to yours though I got there via a different route. Although what I've said below has already been answered by @Martijn I'll answer in the way that I 'got' this in case it also helps. I had been cheerfully using code such as: $input->whitelist('sort', $sort); (and $input is of course detailed in the API). But my uses had been in 'in-line' PHP code (not in functions). Then later I started to write functions and all of a sudden stuff stopped working, which is when I had what Martijn notes above explained to me, that the scope matters. In other words to do as I did above but in a function I needed to replace the 'special' / ProcessWire $input with wire('input') so the following is the same but will work in a function (or in in-line PHP code): wire('input')->whitelist('sort', $sort); Now when writing a function I automatically just see myself writing $something and replace it with wire('something'). And many just write the wire('abc') way all the time, whether in a function or not as it makes the code transportable (work whether it's used in a function or not).

Or check with a string: `hidden, locked, unpublished, system, systemID` $page->is('unpublished'); (Teppo was quicker !)

Try $page->is() with status code flags. Example: if ($page->is(Page::statusUnpublished)) if (!$page->is(Page::statusUnpublished))

Everyone learns different. I tend to think I'm like you Martijn. First read as much as you can then explore the code. Some others dive straight into the deep. @Chris: you can use Google to search the forum. I.e. the query "site:processwire.com wire function" would have given you loads of information.

http://php.net/rmdir should take care of that. And while you are on that page, read through all the "Filesystem Functions" in the left sidebar. Also, if you haven't seen it before, PYDIO is the best php/ajax driven file manager out there and it's free and open source: http://pyd.io/

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/

Sorry but i stuck a litte bit with that. Can you please write the complete code to retrieve the data?

MODX with getResource is slow & inflexible compared to ProcessWire, take a look at this traversing heaven. Something like this might work: foreach($pages->get('/CONTAINER/')->children as $p) { foreach($p->fields as $f) { echo $p->$f . "<br>"; } }

Hey Martijn, Thanks for taking the time to help sort this out. I applied your fix and it works for page editing, but there were still notices if editing anything under the Admin page. I have to admit I haven't spent the time to fully understand the module and your fix, but I have added the following to line 97 and it seems to take care of the other notices: if(in_array($data_key, array('required', 'textformatters', 'size', 'maxlength', 'description', 'collapsed', 'required', 'moduleTypes'))) { $array = $data_value; $data_value = ''; if(is_array($array)) foreach ($array as $id) $data_value .= $this->pages->get((int)$id)->name . ', '; $data_value = rtrim($data_value, ', '); } $settings_str .= "<span>$data_key:</span> $data_value<br/>"; Not sure if there are any side effects.

How should CKEditor or ProcessWire get to know if you want to insert a link to another site? For example, www.mysite.de/testpage.html could be another website, or simply a relative link to the page "testpage.html" in the folder "ww.mysite.de" of my own site.

@gebeer: Have you tried if "Unpublished" (capital "U") works? Just a guess, but it could be that Edit: my guess was wrong; lowercase would work just fine. The issue is that the code Martijn posted above is from dev branch. If you're running stable (master) branch of ProcessWire, that won't work for you.

you can make up your own config vars, like $config->my_special_frontend_login_url = '/login-here/'; i think that is what martijn was implying?

Tnx Teppo, learned another great thing

One minor thing to mention about owlcarousel is the lack of circular slides. I prefer carousels which continues after the last slide. what's realy great about the owlcarousel is the fine-tuning between different screen widths. This could save you a lot of custom JS. When I'm in a hurry with a project I will consider owlcarousel.

@dragan: take a look at ProcessChangelogHooks.module and especially it's logPageEvent method. It does a bit more than this, but you could probably use parts of it pretty much directly.

When a client asks for "a website" with "easy management", explaining that ProcessWire is "an awesome framework for building just about anything" feels plain wrong and is unlikely to yield desired results. On the other hand, when client (or fellow developer) does mention the need for "an application", "framework" or "software platform", it's good to be able to match those needs too. Personally I really like the fact that ProcessWire has the ability to be both and would like to avoid emphasizing either *too much* over the other. If I needed a CMS, there would be a huge amount of other options available, and if I simply wanted to build an application I could (for an example) turn to Zend Framework and get the job done.. and so on. What ProcessWire brings into this equation is a well-balanced combination of features from both worlds. Each part supports the other, eventually making it more than the sum of it's parts. I especially love how easy and fast built-in admin makes mocking up data structures -- in fact it's such a smooth experience that the times I've built mock data manually for HTML wireframes etc. have been almost nonexistent lately. I find it faster to make fully functional features using ProcessWire than writing dummy directly with editor. And that, in my opinion, is why it's so damn good. Not that I really needed to explain it to anyone here, but my point is mostly that I don't see ProcessWire simply as a CMF or CMS or application framework or whatever. It's all of these combined.. and that's a good thing. I hope we don't get stuck discussing which one it is when that question can't (and shouldn't) have one single correct answer

Depends on the client a bit. Certainly with my music it is often a case of "look it works, you are selling more biscuits - here is the bill" I could tell them exactly how my harmonic fifth on the cello adds that sense of pathos that just gives the brand that edge more authority, but you would be amazed how often clients glaze over and pay the bill just to shut me up. I have that effect on people - very useful.

I have the same conflict right now for my current project. HTML5 boilerplate suggest just sticking to sans-serif, not specifying a font at all. The vision behind it is simple but clever. (maybe I go this route) Not assigning a font and let the system decide what font renders best. It's logical because the people who build the operating system did lot of font research.

It's a bit late to suggest this, but I'd like to seriously question if we really need Arimo. What's it's greatest benefit here? Is it more usable, readable etc. when compared to "web-safe" alternatives or is it purely a visual thing? Personally I can't see anything being so great about it, not even that visual part, but what I can see is a pile of issues. I prefer my fonts to load fast and be readable, that's all, and at the moment I feel that neither of those has improved (quite the opposite really) in this new admin theme. To summarize this, it just seems questionable to me if Arimo is really worth it. I can't see any real benefits, but then again, I'm not the typography guru here either (Note: having to rely on a very slow mobile connection for a while has definitely affected my opinion, as you can see from the attached screenshot. That's not even funny anymore and I've been seeing it a lot lately. Not saying that it's a typical situation, but it's not unheard of either.)

Hello, I don´t know if it is posible to find pages that have a children with name, I mean, something like: $parent = $pages->find("template=opciones, child.name=tarjetas") This of course doesn´t work, but something similar? Thanks in advance, Alejandro.

Actually you should be able to use "children.name=tarjetas", but I tested it out here and it behaves the same as "parent.name=tarjetas", so that is a bug. Looks like this is the first instance I've seen of needing to use something other than children.count. I've now fixed it, but am doing a little more testing locally before committing to dev.

You obviously don't know owlcarousel then

Dear Ryan, Please accept my appreciation on the system that you have created. Processwire is amazing. We were planning to redesign and make our Film Magazine more attractive and easy to manage, especially as it was run by a very short staff. We had been lagging behind in deadlines with each issue. We started the process about 5 months ago, when I started searching for the most suitable system to trust the work to. I have been a wordpress developer for sometime, but I did not want to take that path, frankly very annoyed with the huge amount of mostly defunct and dead plugins and other things that makes it tedious to run a website for a developer ( those are just my thoughts ). The process was gradual, and I was tremendously impressed by the conciseness of the entire Processwire system and the support forums, suffice it to say that, I did not have to ask any questions in the forums to work things out, the answers were all there. This is the first forum post that I am writing and this is after the job has been completed. I invite the community and especially Ryan to please have a look at the Magazine, its available here: PROJECTORHEAD Although it is still a work in progress, but we feel glad to release the magazine with the new issue. The magazine has been in existence for more than 2 years and this is the ninth issue. The blog section on the website is still running wordpress. I would love to hear feedback about the website, both in terms of content and design, and ideas about making it more reader friendly. We present this magazine to the community. Thank you. Suraj Prasad Web-Architect PROJECTORHEAD

If you like, please check out our latest project powered by Processwire: http://www.gasthaus-stuhlmacher.de/ A small website to the well known Restaurant Gasthaus Stuhlmacher in Muenster, Germany. It is one the oldest restaurants in town with a long tradition and a great historical background. Processwire is absolutely stunning! It is just unbelievable how fast and clean we are able to develop our projects. The backend is so easy to use. All of our customers are in love with it too. Especially the ones who are coming form Typo3, Drupal or Jomla! Thank you so much for all your efforts and support.

Will see tonight if I have the time to debug. I'm not very handy with that git stuff. // start at line 160 if(in_array($data_key, array('editRoles', 'addRoles', 'createRoles', 'roles'))) { $array = $data_value; $data_value = ''; foreach ($array as $id) $data_value .= $this->pages->get((int)$id)->name . ', '; $data_value = rtrim($data_value, ', '); } $settings_str .= "<span>$data_key:</span> $data_value<br/>";

Greetings, What makes ProcessWire so excellent is the ability to do all kinds of work at the API level, so that you can essentially create a custom admin for your projects. Editing a page is of course a crucial part of any custom admin. NOTES: Of course, you must cutomize this to your project. Also, in my code I am editing the page directly inside the page itself. In other words, you display a page as usual, but inside it you have your edit code, as well as code to save the page after editing. The other option would be to link to another page just for editing. Editing does get rather involved. Below is a technique I've used. I'll break editing down to several steps, then later I'll put it all together as one. Here goes... Step 1: Isolate Who Has Editing Rights You don't want anyone who can view the page editing it! I use code like this to limit editing to people with either an "editor" or "superuser" role. We open it here, and close it later in Step 6: <?php if ($user->isSuperuser() OR $user->hasRole("editor")) { Step 2: Set the $page Variables (Except Title) to Hold Edited Values Take inputs received from a submitted form and use those values to replace current $page values. For this example, I am only using two fields to keep it simple. And they are text fields. We hold off on setting the title, since that needs special handling: <?php if ($input->post->title) { $page->set("first_name", $sanitizer->text($input->post->first_name)); $page->set("last_name", $sanitizer->text($input->post->last_name)); } Step 3: Edit Title Field, but Only if the Title is Unique, Then Save the Page You need something like this so you don't get an error if the title you apply to the edited page collides with the title of an existing page. The code below confirms that the title is unique and allows you to set the title, and only then save the page: $thistitle = $page->title; $matchedtitle = $input->post->title; $checktitles = $pages->find("parent=/[path]/[to]/[parent]/, title=$matchedtitle|$thistitle"); $titlecount = count($checktitles); if($titlecount < 2) { $page->of(false); $page->set("title", $sanitizer->text($input->post->title)); $page->set("name", $sanitizer->text($input->post->title)); $page->save(); Step 4: Refresh URL Think about it... If while editing this page we changed the title, the URL you are on is no longer valid. Here's a simple bit of Javascript to handle this. The code below also closes out the conditional set in Step 3: $refresh=$page->url; ?> <script type="text/javascript"> window.location = '<?php echo $refresh ?>'; </script> <?php } Step 5: Handle the Scenario When the Page Title Collides In Step 3, we edited the page title because it passed the "unique" test. But what if it fails that test? We would move to this section of code, where a message lets the user know there is a problem. A bit of Javascript helps make the warning fade in so it is more noticeable: else { ?> <div class="admin_error_box"> <p>Sorry, there is already a page using this title: <?php echo $input->post->title?>!</p> <p>Please enter a different title in the form.</p> </div> <script> $(function() { $('.admin_error_box').hide().fadeIn(3000); }); </script> <?php } Step 6: The Edit Form We need a form to capture the submission of edits. It would look the same as your page-creation form, but would have to be pre-populated with the current values of the page, which will also change upon submission of the form. The last bit of code closes out the check on user roles set in Step 1: <div class="page_create_form_box"> <p class="form_heading">EDIT THIS PAGE USING THE FORM BELOW</p> <form action="<?php echo $page->url ?>" method="post"> <ul> <li><label class="label_class" for="title">Page Title:</label> <input type="text" class="input_class" name="title" value="<?php echo $page->title ?>"></li> <li><label class="label_class" for="first_name">First Name:</label> <input type="text" class="input_class" name="first_name" value="<?php echo $page->first_name ?>"></li> <li><label class="label_class" for="last_name">Last Name:</label> <input type="text" class="input_class" name="last_name" value="<?php echo $page->last_name ?>"></li> </ul> <button class="admin_submit" type="submit" name="submit">SAVE EDITED PAGE</button> </form> <?php } ?> Step 7: Putting it all Together Now let's put all of this code into one continuous routine. <?php if ($user->isSuperuser() OR $user->hasRole("editor")) { ?> <?php if ($input->post->title) { $page->set("first_name", $sanitizer->text($input->post->first_name)); $page->set("last_name", $sanitizer->text($input->post->last_name)); } $thistitle = $page->title; $matchedtitle = $input->post->title; $checktitles = $pages->find("parent=/[path]/[to]/[parent]/, title=$matchedtitle|$thistitle"); $titlecount = count($checktitles); if($titlecount < 2) { $page->of(false); $page->set("title", $sanitizer->text($input->post->title)); $page->set("name", $sanitizer->text($input->post->title)); $page->save(); $refresh=$page->url; ?> <script type="text/javascript"> window.location = '<?php echo $refresh ?>'; </script> <?php } else { ?> <div class="admin_error_box"> <p>Sorry, there is already a page using this title: <?php echo $input->post->title?>!</p> <p>Please enter a different title in the form.</p> </div> <script> $(function() { $('.admin_error_box').hide().fadeIn(3000); }); </script> <?php } ?> <div class="page_create_form_box"> <p class="form_heading">EDIT THIS PAGE USING THE FORM BELOW</p> <form action="<?php echo $page->url ?>" method="post"> <ul> <li><label class="label_class" for="title">Page Title:</label> <input type="text" class="input_class" name="title" value="<?php echo $page->title ?>"></li> <li><label class="label_class" for="first_name">First Name:</label> <input type="text" class="input_class" name="first_name" value="<?php echo $page->first_name ?>"></li> <li><label class="label_class" for="last_name">Last Name:</label> <input type="text" class="input_class" name="last_name" value="<?php echo $page->last_name ?>"></li> </ul> <button class="admin_submit" type="submit" name="submit">SAVE EDITED PAGE</button> </form> <?php } ?> My apologies for any problems with the formatting of the code above (please use your editor to assure proper tabs). Notes: - If you include checkboxes or other field types in your page, the editing is a bit more involved. - If you have image fields, you would have separate actions connected with those. For more information on handling image fields in custom forms, take a look at this: http://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/ That should get you started! Follow up if you have more questions! Thanks, Matthew

rather then namen "nofile_*" u.cann also do $this alsos $tamplons = ''; foreach($templates as $t) { if(!$t->filenameExists()) $tamplons .= $tamplons ? "|$t" : $t; } foreach($page->children("template!=$tamplons") as $babby) { // $babby.not tamplon } cd ..