Leaderboard

First of all: welcome to the forum, @NoDice! Not that much really, though it naturally depends on your past experience and so on. With CushyCMS (as far as I can tell from a quick look at their video guide) you'll have to learn how their system works, insert special attributes within your HTML markup and stuff like that. With PW you'll be learning how to insert basic PHP tags within your markup -- not that big a difference. Before you install PW and dive into it's default templates, I'd suggest that you read the basics of working with PW from our docs. ProcessWire is a very simple system to learn: all you really need to understand in order to get started are the basic concepts of pages, templates and fields (and a little bit about querying them and their values with the API.) As an example, you could have a template called basic-page with fields "title" and "body". By default that template would use basic-page.php in /site/templates/ as it's template file. To print out whatever values those fields have you could do this in said template file: <h1><?php echo $page->title; ?></h1> <p>This is static content, not coming from any page field. This will appear on <strong>each page using "basic-page" template</strong> as-is.</p> <?php echo $page->body; ?> Doesn't look too complicated, now does it? Of course you will pretty soon need a few other tricks, such as using foreach to iterate through things like image field containing multiple images, but that's all described in the docs and it's also dead simple. As @MarcC pointed out, it's possible but since multiple pages typically share one template you'd be affecting all of those pages. Then again, if you have a special page for something specific (such as "contact us") you can always create a new template (and a new template file) for that page.. OR you could do something like this in any of your template file: <?php if ($page->url == "/contact-us/") { ?> <h3>Our office is located here:</h3> <iframe width="425" height="350" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="https://maps.google.com/maps?q=disneyland,+paris&output=embed"></iframe> <?php } ?> With ProcessWire your options are almost limitless. Don't worry, it'll all fall in place once you start playing with it It's a bit ugly and not something I'd recommend, but: you can also have a field (or a couple of fields) in your templates (all of them or just some) that spit out raw HTML, CSS, JS etc. I say it's "ugly" because it could easily lead to various problems, such as broken page structure and so on, and I certainly would like to avoid such a thing on a client-managed website -- but as long as the site is managed only by you and a few other all of whom know enough to be careful not to break anything and not to insert any dangerous, external scripts etc. it's feasible option. Edit: just wanted to point out that essentially you're wondering whether to use an easy-to-use yet full-blown CMS with almost infinite possibilities (PW) or something that's designed to be "an easy way to change content" (CushyCMS.) Think about it this way: getting used to PW will take more than those "few minutes" CushyCMS promises, but once you do learn how to use it there's absolutely no limit to what you can do with it. On the other hand, if you're a) certain that your needs will stay small and b) really prefer a hosted, service-free tool then you should definitely go with CushyCMS. All in all it depends on your needs and preferences

I'm all for more validation options, and generally add them as needs come up. But I want to point out that Fieldtypes define a database schema. That's something that differentiates the need for different fieldtypes, is the fact that most represent different storage needs for data. Behind the scenes, they represent a database table. You don't need different fieldtypes purely for validation reasons. Though FieldtypeEmail and FieldtypeURL (and I'm sure others) probably have very similar storage needs... and maybe they could really be the same Fieldtype if we really wanted it that way, but I'd rather have people choosing an "email" or "URL" field rather than a "email/URL" or generic "text" field. This is more consistent with the way HTML5 is going too, as types like "email" and "date" are being used over some validation attribute on text fields. Overall, I think it's easier on the user if they are choosing reasonably well defined types when creating fields, rather than abstracted "I can be anything" types. As for a "unique" validation, that's different from the others. This would best be handled at the Fieldtype level since it's a type of database index that enforces it. I've been planning to add this to the base Fieldtype class, so that it is available for all Fieldtypes. You may have seen the FieldtypeTextUnique, which was more about proof of concept and solving a need quickly, rather than a suggestion of what path should be taken overall. But we'll definitely be adding support for unique indexes in a manner that spans all Fieldtypes rather than just individually. Fieldtypes are involved in the getting and setting of page variables at the API level, making sure that the format is correct for the storage it represents. This is sanitization, just making sure that what gets set to it is valid in general for the type and suitable for storage. But specific interactive validations are the job of Inputfield modules. If there are any major validations we're missing on any of them, let me know and we can get it on the to-do list. I have been working to expand the validation options behind the InputfieldText module, as it now supports regular expressions, which will let you be as specific as you want with validation. New validations have also been added to several other Inputfields over the last year. Configurable error messages at the field-by-field level are something we don't have, but I would also like to see them. This is something I think we can add in the near future. They are currently configurable at the fieldtype-by-fieldtype level, but only if you have the multi-language support modules installed.

Have file permissions by any chance changed -- ie. does whatever user your web server is running as have write access there etc.? That would probably be the most common reason for something like this. If you're not sure which user that would be and your site is running on Linux, "ps aux | grep apache" (or echo shell_exec("whoami") in any PHP file) will give you good idea. .. oh, and of course there's always the possibility that there simply haven't been any errors ..

If you can wait, I'm currently working on a booking module for ProcessWire Currently it has specific needs for a specific job, so allows bookings on non-consecutive days, but will have consecutive days as an option by the time I'm finished (more useful for accommodation then). One thing I would say is that a restaurant booking system and a room booking system have very different needs. Both have been at the back of my mind when developing this module, but I need to look into the options required for a restaurant booking system when I get further along with this - the links in the first post here are helpful for that. There are some other nice features I don't want to give away just yet, but it might be worth waiting if you can for a few weeks.

You are right @Diogo, we should write in english here, most because I hate Nanni Moretti and I don't want to have his voice in here That said a little recap : Alessio Del Bianco is playing with the german site profile and he is porting it in italian language. We were deciding if the words "custom fields" should be translated in italian or be left as is. Just little personal decisions I suppose. I've noticed a strange behaviour of the ShadowBox script, the one that let the page scroll on nav>li clicks. It seems to snap badly cutting the transition as it get close to the target anchor. I don't know if this situation it's also present in the german site profile, I didn't check. That's all, no big deals by now

Take all my code and money too. Well the latter comes in form of code. Serious, I'm very proud to have played a role. I agree with what you said and will first go check it out and come back later...

Some fun stuff just pushed to the dev branch: the core now includes a Modules Manager "Lite". The screenshots below best describe how it works. But it lets you install modules from the directory just by typing (or pasting) in the module's class name. It also provides a 1-click capability to check for a given module's updates and upgrade it when necessary. Beyond that, the modules screen is now split into tabs: Site, Core and New. Site shows just your /site/modules/, and Core shows just your /wire/modules/. The New tab is where you can install modules. I really wanted a solution that kept the actual browsing for modules out of the CMS. Not because I think it's a bad idea (it's a great idea) but because I wanted the modules directory (modules.processwire.com) to serve that purpose as much as possible, at least as a default. That way I don't have to worry about scalability as the size of the modules directory increases. Plus less automation might make the newbies be a little more careful about what they are installing and where it's coming from. The power of the automation in ModulesManager here is so powerful it scares me, so think it's better for the users that know what they are doing. Lastly, ModulesManager is one of the best modules out there and Soma does an amazing job with it. Bringing a little taste of ModulesManager into the core I thought would help both projects. Most credit for the new core "Modules Manager Lite" goes to Soma (though he doesn't yet know that). It's all built around his code lifted directly from Modules Manager. Hope that's okay Soma? Your code now powers not just the new stuff in ProcessModule, but also the new WireHttp::download function, and the new wireUnzipFile() function, all added this week. People who want the most power will still want to use Soma's Modules Manager. That does a whole lot more than the built-in one does, including installation of themes, checking for updates en-masse, and browsing and filtering through the modules directory. But now you can install ModulesManager or other modules without having to manually FTP things to your server (so long as your /site/modules/ is writable). Please let me know if you guys run into any issues with it.

Several weeks later... I have a Version Two of this which I like better. It's using the hook and module approach in Apesia's MarkupRenderHelper. The scenario I have is a bunch of pages in a tree, each of which uses a selector to select certain "item" pages which are all lurking under a single parent elsewhere in the tree. Any page can show any items. When rendering a page we recurse one level down to make little displays from the child pages, and we find the selected items and render little boxes for those too. Thus we have items displayed and informative navigation for drilling down. For anything more than very basic output I like to use a template engine (as opposed to straight PHP/HTML). I used Smarty for a long time, but now I tend to use a three part setup with a simple cut/paste/search/replace template engine in the middle. Driving it is a PHP method with just ifs and foreaches and lines of code to work the template engine. The third piece is the HTML template files. Many of the day to day "little changes" clients ask for get isolated in those places which keeps the other code clean. I'm using 2 modules. One is for configurable settings and some utilities. The renderer is in the other one, which is autoloaded (conditional autoload by template name soon). The PW template file gets an instance of the settings module, puts that in the $options array, and passes that to the renderer. The renderer starts with a "prep" method, one for each kind of page, to get data ready for the layout and stash it in arrays. Some of that is just grabbing fields but there's navigation and comments to get ready, etc. If that preparation resulted in lists of subpages and items to render, another method does that and finally a layout method works the template system. We pass a few things back and forth through the Page objects. That's how we pass paramters to influence the secondary rendering and then recover the rendered oputput. The filenames of (non-PW) templates are based on the PW template name. If we are recursing, the depth is added to that (we stop at 1 so that makes 4 different files). Finally, the pages and items have a "style" field which lets you specify an alternate set of these templates to use just for certain ones. That may be decided automatically too. The gift of Blog Profile: This is reaching the point where I show an early demo to a few people to fish for comments before I get too far along. What better way than to drop it into a Blog? So, I took the Blog Profile pretty much as is, put a fixed piece of content on the home page and messed with the commenting so it's off until you login. When you are logged in you only see comments that you or the admin posted. That makes it more of a one on one demo. If something comes up which needs to be shared I can write a blog postabout it. Eventually we end up with something like documentation. I'll let you know how it goes.

I included the unframework Flourish once to validate forms and send emails. Since PW now has validation and required options for inputfields I don't need it anymore. I used codeigniter for some years long before PW but haven't since used it or any other framework as I'm very happy with PW.

I think one of the harder questions here is how do you create a project proposal for a really huge site project along with a project 'budget'. I have been researching it and came across some interesting sites: http://redfoxwebdesign.com.au/blog/getting_your_website_designed/how_much_does_a_website_cost http://www.designquote.net/html/dq_estimate_wizard.cfm https://quoterobot.com/ http://www.pearsonified.com/2006/06/how_much_should_a_design_cost.php

Hi all, here it is the site we made for an european project with processwire! http://smartenergyproject.eu The project will continue for 2 years, and maybe will have 3 languages (EN, ITA, DEU), many editors, and maybe a linkedin integration so is a good start point to test all features of processwire! Alessio

A little confused here...are you saying the above is the code you are using? $page is a unique keyword/variable in PW and I believe should not be used in the foreach as you have done? Did you try this? foreach($pages->find("template=bustotorso-especial") as $brand) { $brand->of(false); // add this line $brand->save();

Think about pw as: once your mind has embraced a higher dimension, it will never want to go back again. PW destroys the paradigm cms because you can structurize, combine, templating and profiling your html/css/js in any way you want and hook it all up with a very powerful api - so - you will always have more freedom and win time with pw. PW is fast on the front-end and back-end, lots of modules and easy editable for clients, 4 very important issues. Yes - for someone with a design focus like you - you need to invest some time to get familiar with pw and it's api but it will pay off. People with a coders mind will have a very short pw learning curve. Here my must read pw starters link collection: http://processwire.com/talk/topic/1041-raydale-multimedia-a-case-study/ http://processwire.com/talk/topic/1015-switching-from-drupal-to-processwire/page__view__findpost__p__8988 http://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/ http://processwire.com/talk/topic/2296-confused-by-pages/ I found this also somewhere (it isn't mine) but can't remember where I found it. Well I think most people think page == what you see instead of page == container Well, you gotta understand the power behind pages. At first I didn't get it either - because I only saw pages as, well, normal pages, just like in other systems. Not as a content container which can be called via the PW API. So yeah - once you got it, you got it. But it takes a while, I think. Especially when you look at and test many CMSs for just a short time. So I think this power feature/USP got to be explained again and again - to attract new developers... And here some good Stuff to read about pw http://www.mademyday.de/why-i-chose-processwire-over-modx.html http://en.wikipedia.org/wiki/ProcessWire http://getsymphony.com/discuss/thread/79645/

I'm on XAMPP version 1.7.7. Avatar: Thx...yeah...thx to Horst for the avatar

Can I have a 3d animation? :-D

Thanks Macrura - I love the detail of the first link in your post. That chap has done an amazing job breaking it all down The second link is... interesting. They have 3 hours down for a contact form and only 12 hours for an Android/iPhone app. I think the app could take longer than the rest, but then I'm not an expert in that area. The rest I suppose depends on your CMS as a contact form should technically take under an hour. Quoterobot looks like it could be a great timesaver, but however you do your quotes, charge what you think you're worth. Somebody linked to this in another thread here, and whilst it's all useful info, there's a bit at the end where someone has thanked Mike for giving them the confidence to charge more - like Mike says, they were almost certainly charging too little: http://vimeo.com/22053820 And the last link - I only realised recently that what he says is true and applicable to anything to do with web development. Another way to look at his statistic of 9/10 clients think the price is too high is that which would you rather have? 9 clients who have a hard time parting with $350 for example, or 1 client that is happy to part with $1500? He would need 4 of the cheaper jobs to cover what he makes in 1 at the higher price. Obviously I made some of those figures up for illustrative purposes, but you get the point. Of course, that's only workable if you can get away with charging that much and are comfortable enough financially and in general that you can turn away a job and wait for the next one if it's not quite right.

I think the problems inherent with a table booking system are as follows (and this is with no real research by the way): Do restaurants have a good grasp of how long a table will be occupied for? If so, give them an option (maybe default to 2 hours per table) Different table sizes will affect the booking. You need to enter your party size ideally to see what is available. That or the restaurant may be able to push tables together in many cases - how do you deal with that? If you're using a web booking system for a restaurant and it needs to be up to date, the system needs updating whenever walk-in customers come into the restaurant. Either that or you can only book online X hour in advance (4 hours default maybe?). Basically, what I'm getting at is that there are far more variables in play than other booking systems. Booking a holiday cottage is easy - it's got a fixed number of beds - no problem. Booking a hotel room is slightly trickier - you have more options, not just with how many beds per room, but type of room. The more I think about it, the less likely every eventuality will be covered just by the module I'm creating. I think it far more likely that each scenario needs to be tailored and that they might be best as site profiles since there will be a lot of templates with them. As such, the module I'm working on may help as a starting point for accommodation/asset-based booking, but won't be much help for table bookings and other time-of-day based scenarios. At least, not in version 1.

The only InnoDB table I'm aware of in ProcessWire comes from the DB session storage module, which is able to perform better with InnoDB than MyISAM. ProcessWire uses ascii_general_ci in some cases where the field can only ever support characters from the ASCII set, like "name" fields for instance. Everything else in ProcessWire uses utf8_general_ci. If you are seeing latin1_swedish_ci, chances are it came from an old version of ProcessWire or from a module that didn't specify collation. In some cases it matters, in others not. You may even want to change the collation in order to affect the way it sorts, for example. Ultimately I don't think you need to worry about it unless you have something that doesn't work properly or you want to change away from the default behavior of something. The defaults that we've chosen are what you want at least 99% of the time.

It is, though I figured most would use the "check for updates" link in the module settings. But it uses the same function as the install, just for DRY reasons. Felt weird? Maybe be a little more gentle... lightly tap, don't hit. Good idea, I'll add a $this->message("update is available"); or something along those lines. Also a good idea, I'll add it this morning if possible.

Looks good to me. I never changed any of the default settings for a simple sql export Cheers

Erm... Yeah... "review". I see what you mean. Not intending to offend the author, but why start off talking about something by essentially stating you don't have time to look into it, presumably then look into it only as far as the video and a list of sites and then draw the conclusion that it's for more complex sites?It saves me hours over any other system even on the simplest of sites, and indeed brings me a level of enjoyment and a sense of fun whenever I use it because it has few-to-no limitations. But again, the exposure is welcome.

Greetings, I felt a needle-like pain in my head, and wondered where it was coming from... Ah, there it is -- Joomla and Artio. All jokes aside, it is true that in Joomla there are ready-made components that take care of a whole range of actions. But then you have to override what you don't want or need, wage mortal battles where various pieces of baked-in Joomla code conflict with your modules and plugins, and spend hours trying to get a developer's attention long enough to figure out where in the world they placed the code for a particular action you need to customize, and why they put it there. And let's not forget that no Joomla component can be used without... Joomla! Which means you are also inheriting its migraine-inducing template system, admin area, lack of custom fields, mind-numbing dummy menu entries and plugin ordering (Joomla people will know what I mean by these last two). OK, let me take a breath... I understand the idea of using something that has "been done already." But since I started using ProcessWire, in all seriousness, it takes me less time to create something from scratch than to wrangle with any of Joomla's "ready-made" code. Two better ways to go: 1. Get part-by-part help from the community 2. Find ready-made JQuery, PHP, and other components that can hook into ProcessWire Thanks, Matthew

And now, for something completely different http://line25.com/inspiration/line25-sites-of-the-week-for-june-28th-2013

I think this is answered here http://processwire.com/talk/topic/3938-adding-total-field-amounts-based-on-child-fields/

This is a little bit of a tough one because dates are basically sortable integers. So a 0 is considered end of 1969 (or somewhere around there). You can query for those with a 0 date value and those with a date>$now with separate children() calls. But when it comes to pagination, the question becomes how you would want to sort those with no date value and those with a date value. If one or the other can be consistent at the front or back, that will make pagination simpler. Also you can manually set the pagination limits on a PageArray with $all->setLimit(); $all->setTotal(); etc. Another option is that you could always query the database manually to find the IDs of the matching pages, then bundle that into your children() query. Here's two example, one using PDO (PW 2.3.1 and newer) and one using mysql (PW 2.3.0 and earlier): // using PDO $now = date('Y-m-d H:i:s'); $sql = 'SELECT pages_id FROM field_expiration_date WHERE (data IS NULL OR data=0 OR data>:now)'; $query = $database->prepare($sql); $query->bindValue(':now', $now); $query->execute(); $ids = $query->fetchAll(PDO::FETCH_COLUMN, 0); $expired = $page->children("limit=20, date<=$now, id=" . implode('|', $ids)); // using mysqli $now = date('Y-m-d H:i:s'); $sql = "SELECT pages_id FROM field_expiration_date WHERE (data IS NULL OR data=0 OR data>'$now')"; $result = $db->query($sql); $ids = array(); while($row = $result->fetch_row()) $ids[] = list($row); $expired = $page->children("limit=20, date<=$now, id=" . implode('|', $ids));

There are long pages in my project, and I'm tired to scroll up/down to save the page. So I've installed this module again and added this little fellow - "return false" "e.preventDefault()" to the function savePage in AdminHotKeys.js and browser doesn't fire "save dialog box" any more on Ctrl+S. if($('button[id*="submit"]').length > 0){ function savePage(e){ $('button[id*="submit"]').trigger('click'); e.preventDefault();}; $(document).bind('keydown', hkconf.hk_save, savePage); } Soma, thx again 4 the module. upd: fellow changed %)

Dear Soma, I really appreciate your help. Thank you! I do believe that your advice has made a few of my little grey cells go ding! My form seems to be working now. I'm using an array of field names (stored in $field_array) that has fewer fields than the page, so I only create the vars necessary for the form. This is my code, as of now (condensed): $field_template = file_get_contents('./member_account_fields.html'); $page->setOutputFormatting(false); $inputfields = $page->getInputfields(); foreach ( $field_array as $field_name ) { $field_tag = ':!:' . $field_name . ':!:'; $field = $inputfields->get("$field_name"); $field_value = $field->render(); $field_template = str_replace($field_tag, $field_value, $field_template); } $out .= " <form action='$full_page_url' method='POST'><br> <input type='hidden' name='a_' value='u'><br> $field_template <input type='submit' name='submit' value='Update Account Data'> </form> $cancel_form "; I think the fact that I can loop through an array of field names, and get all the fields, in their editable format, with the correct values, including Page type fields, with just these two lines: $field = $inputfields->get("$field_name"); $field_value = $field->render(); is really, really cool. (Ryan, I join with many others in saying, you've done a great job with ProcessWire! You can be proud. ) Soma, and Adrian and Matthew, thanks very much for your help! (Of course, if I've missed something above, or done it incorrectly, please feel free to send me hunting for more little grey cells.) Peter

Thank you so much, guys, for responding fast and being such great helps And I am excited to start my first project in processwire, will probably come back for more answers

Is this what you are looking for: http://processwire.com/talk/topic/519-pagelistselect-issue/

Ryan, Just implemented this for the 3rd or 4th time now — I've been meaning to say thanks. Dead simple, and works like a charm.

Hi I know this is an old thread now, but I'm hoping I can provide some useful information relating to this error, as I encountered it myself recently when installing ProcessWire on Vidahost Cloud hosting. I eventually managed to trace the problem back to a probable cause, and a solution - please bear with me The "non-object" mentioned in the error was the "type" property (which was NULL) of the fieldtypes list for a template (the loop in Pages.php). It was NULL because fieldtype information was not set when initialised. ... because the list of modules could not be loaded and returned to the functions relying on them. I think this was caused by the findModuleFiles() function. Although it seemed it could create the file on the first call of this function, the combination of network file system in the cloud hosting (which introduced a delay in file access) and the LOCK_EX parameter meant that the data couldn't actually be written to it. On next calls to the findModuleFiles() function, the cache file "exists", but its empty contents are returned - resulting in the error. From testing, my proposed change removes the LOCK_EX parameter, which allows the data to be written to the file correctly. In addition, if the cache exists - the content is only returned if the array isn't empty. My proposed code changes are a pull request on GitHub if anyone else encounters this problem.

Problem now solved! I should have used the site profile exporter module from the start - I started fresh with it, and it did the trick without any problems at all (though I did make sure to change htaccess.txt to .htaccess before I ran the installer.) Thanks for the great module, Ryan!

Found the solution myself, I can't just set the second parameter of pageName to true, I have to set it "Sanitizer::translate". Correct code that works: $page->name = $this->sanitizer->pageName($page->title, Sanitizer::translate)."-".date("d-m-Y", $page->getUnformatted(date));

First of all, create a template called "tags". It is totally fine to leave as it is, just a "title" field, no need for a PHP-file (for now). To be sure, only allow children with template "tags" in the template "family" tab. Then create your hidden "tags" page. Put same tags in it (that means: create children pages with your tags as title) if you like. Correct. Template for selectable pages is "tags". You can also define your hidden tags page as parent. No template file needed (for now). Not necessarily. or from the page select field itself (very convenient). So for that you need to have a .php file as template for the template "tags". First, create your tag list like this: echo "<ul>"; foreach($pages->get('/tags/') as $tag){ //iterate over each tag echo "<li><a href='{$tag->url}'>{$tag->title}</a></li>"; // and generate link to that page } echo "</ul>"; (totally untested, but you'll get it). Since the tag pages have no template yet, this will throw an empty page (or 404, don't know). So let us create a template for the tag pages, which lists all pages with that tag: // Beginning of your template here (head etc.) // select all pages with the tag of this tag page $thisTag = $page->title // Current clicked tag $tagPages = $pages->find("Tags.title=$thisTag"); // select all pages where page field "Tags" contains a page with title of our tag foreach ($tagPages as $tp){ // iterate over the pages with that tag // and generate some teasers (or what you like) echo " <div class='teaser'> <h3>{$tp->title}</h3> <p>{$tp->summary}</p> <a href='{$tp->url}'>Read more...</a> </div>"; } // Rest of your template here (footer, javascripts etc.) as I said, totally untested, but this should point you in the right direction.

I've been lurking these waters for quite some time now, being a mildy inactive frequenter of the forums. Almost everything I do on my own is PW-based now (I work as a frontend developer for a University, on my "day job"), but I just realized I had never published any work here! This is a website for which I did the implementation (it isn't my design). PW makes creating specific hierarchies amazingly simple, so I can build a very specific html history-driven website in a snap, which is amazing... So here it is: http://mmbiotechnology.com/ (It is all in Portuguese, I'm afraid. On a related note, it uses the amazing language localized url module... Or rather is doesn't, as no one bothered to write up the english version -,- ) Cheers

Name is a special property not a field same as other fields, so you need to tell it what language you want. echo $page->localName($user->language); or echo $page->get("name$user->language");

You mean like this? I just enabled it in this forum for a test, as well as Getting Started, General Support and Modules & Plugins. I can see it needs some styling though so it stands out a bit more.

Once you have gotten your hands dirty enough, you will want to read this classic (if you haven't seen it already) http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/

Give three programmers individually the task for a specific application and you'll get three complete different solutions. Ask them to look through each others code and all will correct each others.

pwired: if docs would have all those examples, one by one - it would be just the same that you bought a box of legos and got 3 000 000 pages long manual that would show all the possible combinations that could be done. When you learn the basics: $page, $pages, Page/Wire Arrays, selectors etc and learn how to use cheatsheet (and soon source code), you really can find combinations like that. But, to answer your question: DIOGO: $pages is explained here: http://processwire.com/api/variables/pages/ ->find() (and selectors in more common, ie. what to put inside find) is explained here: http://processwire.com/api/selectors/ (also first item here: http://processwire.com/api/variables/pages/) ->has() is explained here: http://processwire.com/api/arrays/page/ TEPPO: $page is explained here: http://processwire.com/api/variables/page/ ->is() is explained here: http://processwire.com/api/variables/page/ (and again, concept of selectors) SOMA: Operator (^=) that Soma uses in his selector is explained here http://processwire.com/api/selectors/

Big picture: Reminds me of the "Cathedral Story"

I think that this is for folks that prefer to copy/paste stuff. But for people that fully read and understand the docs, they can make their own examples, tips and tricks. They are the ones here having the most fun and responding to all the questions. Many assume the system to be much more complex than it actually is simply because they are giving more weight to tutorials and copy/paste snippets of code from the forum rather than the bigger picture that is emphasized by the docs. Though I know everyone learns differently. For me personally, I don't learn well from tutorials or snippets… even I get lost in most of the ProcessWire tutorials I've tried to follow. I need to know the big picture. And ProcessWire's big picture is really, really simple. Other systems are far more complex… I think an issue is that people aren't used to understanding the big picture because they assume a level of complexity that isn't there with ProcessWire. They want to know how to do this or that little thing, without considering that they really can know how to do everything. The closest path to knowing how to best develop in ProcessWire is to read the docs. The pre-requisites are knowing front-end development (HTML & CSS), and optionally a little PHP. Though even people that don't know any PHP can do more than they could with a template engine. But for people that do know a little PHP, anything is possible. If I recall, Diogo mentioned that he printed out all the pages in the /api/ section of the site, took them to a park, and read them in an hour or so. Despite not starting out as a coder, he came back here knowing how to do anything. He can literally answer any question because he knows the big picture. This is a good way to put it. My opinion is that even someone with no understanding of PHP will still be able to create more on their own with ProcessWire than they could in another system. But for those that really want to "drive fast" and see how far they can push it, they'll have a much stronger engine at their disposal than they might in another system. For those people, php.net becomes a valuable documentation resource too.

I don't know how to config ck-editor on processwire in order to accept attributes in common HTML tags like <p class=='myClass'></p>, i look into edit field but i cant find the way to do this. Thanks in advance.

Thanks guys I've setup this one to redirect to processwire.com