Leaderboard

I added this to the dev branch last week, so that you can now pass additional things to $page->render(): https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/PageRender.module#L212 One of the things I wasn't thinking about before is that $page->render() was already capable of accepting an array of options (though not commonly used, mostly internal). So we weren't starting from a blank slate, and had to make something that was compatible and complimentary to what was already there. In terms of API calls, you can now do any of these: $page->render($filename); // $filename assumed in /site/templates/ $page->render($pathname); // $pathname is full path, but must resolve somewhere in web root $page->render($options); // array of options and/or your own variables $page->render(array('foo' => 'bar')); // same as above $page->render($filename, $options); // specify filename and options/vars, etc. The $options variable was already something that $page->render() accepted before. Only it was used to specify some little-used modifiers to render(). Those are still there (and they are necessary), but now the utility of $options has been extended. When you want to specify options (outlined in the link above) you only need to specify the ones you want to change from the defaults (of course). Typically you don't need to change them, so I'm guessing that most would use $options to specify their own variables. Every rendered template now receives a copy of that $options array locally scoped. That $options array contains any variables you passed to $page->render(). It also contains PW's default options, should you want to examine any of them. If you made this render() call: echo $page->render('myfile.php', array('foo' => 'bar')); myfile.php could access the 'foo' variable like this: echo $options['foo']; // outputs "bar" One other addition that I'm thinking people might like is $options['pageStack']. That is an array containing a stack of pages that called render(). So if you are doing any recursive rendering of pages, any template can access $options['pageStack'] to see what page is rendering it, and any others before it. Previously this was not possible, and the only way a template could tell what other page was rendering it (if any) was for that renderer to tell the renderee, via $mypage->caller = $page; or something like that.

This module generates a "stubs.php" file containing PHP-classes with documentation for the properties of each Template, based on it's fields - which means IDE support (auto-complete, inspections, documentation) for templates in modern IDEs that perform static analysis, such as PhpStorm. The output looks like this: <?php /** * Generated by TemplateStubs module 2013-04-13 15:29:33 * This file may be overwritten at any time. */ namespace tpl; use Page; /** * "basic-page" template * * @property string $title Title * @property string $headline Use this instead of the Title if a longer headline is needed than what you want to appear in navigation. * @property string $summary Summary * @property string $body Body Content * @property string $sidebar Sidebar * @property Pageimages|Pageimage[] $images Images */ class basicpage extends Page {} To use the generated documentation, start your template-file like this: <?php /** * @var tpl\basicpage $page */ Documentation and more details on this page: https://github.com/mindplay-dk/TemplateStubs You can consider this an alpha-release - I haven't tagged a release yet, and some details like template-class naming convention may change before I tag release 1.0.

keep stink.away siphon do . be.happy yous should two.have siphon inmy country.when i was young.man .we poop in ground hole when you look.at dark hole.careful must u be dark ground hole.look back consumes you it will no flush no.siphon=stinkers no girlfriend cloud every thing impossble to see.light love siphon.you shuld flush take all.mush

I've been making regular updates on the dev branch to the LanguageSupportPageNames module, so if you guys are using this, you may want to keep track of the updates. The good news is that this module is now running a production site: http://tripsite.com/cruises/ (only the /cruises/ site, as the rest of the site is running on a different copy of PW). This morning I pushed an update that makes it easier to tell if a given $page is viewable in another language. Now you can do this: if($page->viewable($language)) { ... } // Language object if($page->viewable('es')) { ... } // Language name That is basically telling you if the page has its "active" checkbox checked. Since these pages would already be excluded from search results, you don't typically need to use it except when on a given page and trying to determine what other languages that page is available in (like if you want to link to them, as the select box at the top of tripsite does).

The whole idea of a maintenance mode is something to be careful with on a site that depends on any kind of search traffic. It's not a great idea to make a habit of it, that's for sure. So if you need to put a site in maintenance mode, try not to do it for long. Personally, I have never had the need for a maintenance mode. Though there have been a couple times where I was pushing in a major update to a site, and I temporarily added the following to the top of the /index.php file: die("Go away! We are trying to upgrade the site.");

I develop all my sites of subdirectories on localhost, but when migrating them they usually aren't running off subdirs. I usually load the DB sql file into my text editor and do a search/replace "/mysite/" => "/", before migrating the DB to the live site. But it won't be long before we have this task taken care of internally without any need to do replacements.

When you get into sending POST data, ProcessWire has an http class that you can use rather than something like CURL. The benefit of using PW's WireHttp class is that it will fallback to sockets if it has to, ensuring the class works just about everywhere. Here's an example of the same web service we outlined above, except that this one posts to it: $data = array( 'username' => 'ryan', 'pass' => 'mypass', 'email' => 'info@grab.pw' ); $http = new WireHttp(); $result = $http->post('http://www.domain.com/path/to/service/', $data); if($result) { $result = json_decode($result, true); if($result['status'] == 'success') echo "Success! $result[message]"; else echo "Error! $result[message]"; } else { echo "error posting data"; } As a side note, this service is using the same password for the user to add, and the web service password. In reality, you'd probably want those to be different things.

The problem is scalability. Putting them on top wil give performance issues as it has to reassign the index for all siblings.

We have it build in. Thanks Ryan.

What any newbie should do first is learn Drupal. After 2 years of: awful theming, i.e. $element['#object']->field_video_embed['und'][0]['value'] instead of $page->field_video_embed searching through 500 line arrays to find out what module is injecting a certain markup in your code writing huge css files to deal with the divs nested within divs nested within divs nested within divs figuring out how to add a meta tag to your <head> using an API and an array getting carpal tunnel syndrome from constantly clearing the cache because Drupal is such a hog, everything has to be cached learning the Views module, a point and click interface that is 3X more annoying and difficult than learning and using straight SQL find a good host that is beefy enough to deal with the Drupal and has advanced caching capability After that, PW will be a walk in the park.

Well, ProcessWire is far more flexible than that! Starting at a very basic level, you could create fields in your main template that you would then use in a sidebar for instance: sidebar_title sidebar_text sidebar_image or whatever you wanted. If those are included in the templates you are using, then those fields are available for all the pages that use those template - if you don't use them, they wont display anything. Next level up! You can pull content from any page. So, you could create a specific page with a specific template (but no associated template file) and use it for some global fields. For instance it could have a textarea called "extra_info" into which you add something you want to appear on many pages. In the template file for those pages you would call that field in this way: echo $pages->get("/my-global-page/")->extra_info; Getting more complicated Next up, you can use a Page field to drag in an entire page, or series of pages. For instance, you create a block template (complete with file) and give it a handful of fields. In the associated template file, you would only put in the mark-up needed to render that particular block - no header or footer or anything like that. You can use that template to create a series of blocks. You now create a page field which you will use to select one or more of those blocks. You can set up the page field to look for pages under one particular parent, or by one particular template - so you can restrict what is selected. Add that field to the template for your normal pages. Edit one of those pages and you can select a block. In the template file for your normal pages, you can now grab the contents of that field as normal, but then render the output: echo $page->mypagefield->render(); That will output the selected page, rendered in its own template. From that point you can get really imaginative. You can use the page field to select multiple pages and then use a foreach loop to render them all out. You can set up your normal page templates so that you can choose blocks for individual pages, or by perhaps putting the page field in a central source (like I did at the head of this answer), maybe make it a global block system You really can do anything you want, render things as complete pages or just pull particular fields out ... and so on. This demo site I did is done completely with blocks that are then selected from a central source: http://pwdemo3.stonywebsites.co.uk/ So, yes - it is all possible, and without having to go near a plugin. Joss

Hi there! I just bought the formbuilder module (which is really great, thanks Ryan!), I was wondering if it was possible to access in any template directly the entries without using the page creation option. In other words is it possible to have something like this: $forms->formtitle->fieldtitle I searched for it but I have to say I'm kind of feeling that there is missing a little technical introduction in the readmefile provied at the download. Thanks for the attention, and again, thanks Ryan for having build this, it's really useful for us and our clients!

Hi Grays, welcome to the forum. Even though I have been playing with PW for a couple months now, I too am still very green and new to it. I was in the same boat as you and still am trying to grasp the basics, but take the advice of everyone else above. The people here on the forums are very helpful and friendly. Don't be afraid to ask questions. There are a lot of smart peeps here and I find this is one of the most friendliest, most responsive CMS forums of them all. Make friends with other newbies (such as myself) and follow the questions they ask. Seach the forums for the ones asking basic questions and those will more likely be the newbies. I think for me, the best thing I could do was to take it slow and lower my expectations. I fell in love with PW right off the bat and wanted to be a a pro in it. But, even though I had read a few PHP books and took some courses beforehand, in reality I was lost and dissapointed. It's more a mental/confidence thing with me, but once I accepted the fact that it was going to take some time, and I wasn't going to be an immediate whiz, things got easier. So. I started off (still am) doing the basics, one thing at a time. Break up your site into smaller parts and work on each one by one. When you get something simple working, your pride will fuel the next challenge and before you know it, you'll be at the top. Analyze the code here in the forums and don't just copy/paste. Try to really understand it by cross checking with how PHP works. A great thread started not long ago on learning PHP is here. You may not understand it in one try, I know I didn't. Sometimes it takes days or weeks for something to "click" in your head. Read, re-read, read again. Things DO get easier but it takes time, and time is the secret. Practice helps. It's inspiring what you can do with PW and what keeps me going is knowing this is the best CMS out there. I have researched and tried almost all of them over the years, but nothing compares to PW. I am inspired every day to continue learning and not giving up because it's absolutely worth it. MY breakdown to how I am learning: Take it slow. Break code examples down line by line. Moving on to the next line only after knowing what each before it does. You'll get it! Don't attempt something expecting results the first time. Take pride in humiliation. You can only learn after making mistakes. Read this PW wiki Study Codecademy PHP course along with a couple PHP books. Try to go through every forum completly. Go through each page one by one, bookmarking where you left off. I do this before I go to bed. Before you know it, you'll have read all the forum topics and can know be updated when new threads post. ask questions. I know this can be kinda hard because you don't want to look like an "insert insult", but the truth of the matter is if everyone is afraid to ask then it's hard for newbies like you and I to find answers to basic questions. It's a win win for everyone and the CMS itself. breaking down basic elements of a site one section at a time and searching the forums for how to do it (navigation, multi-level navigation, photo gallery, forms, etc..) You may have to read multiple threads but it's all there. Good luck and don't give up! I can never look back at any other CMS, even during times when I'm frustrated or lost! I only get frustrated with PW because I do not know YET how to proficient. I was frustrated USING other CMS's because of how they were built and I knew their code. Says a lot right there.

Dear Ryan, Thank you! ProcessWire just keeps getting better and better! Peter

Hey, everyone is making siphon-related puns, can't I do the same? I think the last thing I should say about this whole situation is that most of the employees of the business (which were 13 at the time) did not ask for the split to happen, however as self-proclaimed "Acquia for MODX" (side-stepping that MODX LLC has been that commercial arm for MODX for years now), SiphonLabs did essentially take all the employees with it, minus Ryan and Jay. So this "other side" is not something people have chosen. Rather, people like Jason and YJ have chosen to go back to the OS side and Ryan T is working really hard on making that possible.

The best way to have pages appear at the top of a list when they are created is to set their default sort field to be '-created' (or reverse created in the admin). But as for having a manual sorting, PW's admin will only add pages to the end of a manually sorted list.

Apeisa is correct in that inputfields can be represented as arrays, and it's fairly simple to convert them to or from arrays. In the case of FormBuilder, the forms are converted to an array and then to JSON for storage. So far the only place I've found this useful is in FormBuilder, though I'm sure there's more potential. As for manually composing inputfields or forms via arrays, I don't really like doing that because there is no interface… just a faceless array. Reminds me a little too much of configuring forms in Drupal. But I'm fine with supporting the option if people like it.

Solved it. I just throw the exception at the top of the page, before the head.inc of that page is included. Now I can call head.inc in the 404 template without worrying.

You'll need to close the foreach, so something like this will work <?php $drinks = $pages->find("template=drink"); ?> <h2><?php echo $page->title; ?></h2> <ul> <?php foreach($drinks as $drink): ?> <li><?php echo $drink->title; ?></li> <?php endforeach; ?> </ul> Note that I've used a colon ( : ) after the foreach and then closed with endforeach. You could use foreach(){ and then <?php } ?>, but endforeach makes it clearer where the loop finishes (and which loop it is). Bit more info here. Edited re @nik's comment below and to change the colon back to a colon from being a smiley.

I'm guessing that's the case (a blank <p></p> added by Markdown). Can you try replacing your /wire/modules/LanguageSupport/LanguageSupportFields.module with the attached? I think this may fix it. LanguageSupportFields.module

After working with blocks in Drupal, I now find it easier and more maintainable in PW to hard code the blocks using includes (or direct code) in the main template and wrapping if/else logic around each block. Sometimes you may want a block to be configurable by the client. So in PW, create a template and render an instance of that template directly in the sidebar of the main template. This way, all the logic of what gets output in your sidebar can be easily traced and version controlled rather than being set in the database. Because PW uses page hierarchy, there are cool things you can do like query which section you're in ($page->rootParent() I think) and output a certain "block" based on that section. You can also use a page reference in a "block" template and and pass your current URL to a query of those template instances and output anything that matches. If nothing matches on that URL, ask the current page's parent if there is a match and do on up the tree until you get to home. That's how I let a client override a header image on let's say Home / About / Our Team. They create an instance of "header_image" template, upload an image to it, and choose Our Team as the page reference. The code checks to see if there is a match on /about/our-team. If there is, output the image. Else ask to see if there is a match on just /about. Else default to the header image for the homepage. You actually use a for loop to do march up the tree and end if you hit a match or the root.

I'm a little confused by how the whole thing works, despite reading the code a couple times. But if it works, then seems like it should be fine. The only thing I'd worry about here is scale, as you have potentially numerous find operations going on in these loops. But if you don't need it to scale too large, then it may not be an issue. Since I'm confused by the code itself, let's step back and go to the original question: Another option here would be to go ahead and implement a template file for your 'person' pages, and just let your search connect with the output of those pages. If you didn't want to go that route, you could always just make your search output loop handle pages using template 'person' differently: if($m->template == 'person') { foreach($m->categories as $c) { echo "<li><a href='$c->url'>$c->title</a></li>"; } } else { echo "<li><a href='$m->url'>$m->title</a></li>"; }

I think Ryan has pretty much build this kind of behaviour with form builder form export/import. Here is children (= fields) part of one form: { "children": { "your_name": { "type": "Text", "label": "Your name", "required": 1, "columnWidth": 50, "maxlength": 2048 }, "your_email": { "type": "Email", "label": "Your email", "required": 1, "columnWidth": 50, "maxlength": 512 }, "tours": { "type": "Page", "label": "Tours you are interested in", "columnWidth": 50, "template_id": 59, "labelFieldName": "title", "inputfield": "InputfieldCheckboxes" }, "accommodation": { "type": "Page", "label": "Accommodation options you are interested in", "columnWidth": 50, "parent_id": 1046, "labelFieldName": "title", "inputfield": "InputfieldCheckboxes" }, "size": { "type": "Text", "label": "Size of your group", "required": 1, "columnWidth": 100, "maxlength": 2048 }, "information": { "type": "Textarea", "label": "Other information and questions you might have for us?", "columnWidth": 100, "rows": 5 }, "minimum_budget_available": { "type": "Text", "label": "Minimum budget available", "columnWidth": 50, "maxlength": 2048 }, "maximum_budget_available": { "type": "Text", "label": "Maximum budget available", "columnWidth": 50, "maxlength": 2048 } } }

Hi Joss,Is there a site profile, where you can watch your solution (http://pwdemo3.stonywebsites.co.uk/)?. Thanks

I haven't used form builder with files upload yet, and I can't find any "file" field in formbuilder 0.2.0, maybe I'm missing something. An php array is accessed array[key] same as in Javascript or other languages. You can get the created like this: foreach($forms->get("contact-form")->entries->find() as $e){ echo "<p>{$e['e_mail']} - {$e['created']}</p>"; } If your 'file' field is itself an array you could try using echo "<pre>"; print_r($e['file']); echo "</pre>"; and you'll see the array printed out recursively and you see all the entries and its keys and values. Once you know the key you access it for example: echo $e['file']['filename'];

As Soma points out, the issue must be that you have specified to allow multiple pages to be selected, which you shouldn't because you're using the repeaters to handle the adding of widgets, and you have an additional field in the repeater item related to positioning the widget. So it makes sense to limit that page select to 1 page;

Thanks for letting us know. That's cheap enough to make me jump. Already had a namecheap account, so went ahead and registered a few that were still available: runs.pw (maybe a sites directory?) grab.pw (fwd to the github maybe?) mods.pw (fwd for the modules dir) processwire.pw (why not) skyscrapers.pw (for the demo site) skyscraper.pw (for the demo site) wires.pw (who knows?) Anyone else find or buy any good ones?

$group = $page->widget_group; foreach ($group as $item) { echo $item->widget_group_name.'<br>'; // this works as I see the id# $widget_page = $pages->get($item->widget_group_name).'<br>'; // get the page using the id - doesn't appear to work? echo $widget_page->block.'<br>'; // Shows me nothing - (block is the name of a field on the widget page) } if "widget_group_name" is a page field you don't need to get the page, as you already got it! Though if that page field is set to multiple (PageArray) it would be always an array even if only one page selected in the field. So you'd have to threat it as PageArray and use first to get the first page selected. echo $item->widget_group_name->first->title Or if you change the page field to single page you can use echo $item->widget_group_name->title

@adrian: that would be far too simple. Looking for a more difficult method. Thanks will go give it a try. Solved Thanks @adrian, it worked like a charm!

I haven't looked over the shuffleAssoc function properly, but you can probably just use PW's shuffle(): $randimages = $bannerimages->shuffle();

@3fingers: The default .htaccess in PW blocks access to PHP files in certain locations: # Block access to any PHP-based files in /templates-admin/ RewriteCond %{REQUEST_URI} (^|/)(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ [OR] # Block access to any PHP or markup files in /site/templates/ RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ [OR] # Block access to any PHP files in /site/assets/ RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/assets($|/|/.*\.php)$ [OR] # Block access to any PHP files in core or core module directories RewriteCond %{REQUEST_URI} (^|/)wire/(core|modules)/.*\.(php|inc|tpl|module)$ [OR] # Block access to any PHP files in /site/modules/ RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ [OR] I'm not sure what the situation was back in 2011, but at least currently you can access php files directly under site/ or in any custom directory (like site/process/). The rules in .htaccess are just to block direct access to files that are supposed to be run/accessed via PW. So if you want to put some standalone code (or a script bootstrapping PW of course) in site/ directory you can, as long as it's not inside directories used internally by PW itself.

AHAH! Thats it!! At the most logical of places. Thanks for the tip Soma!

What are you missing again? Paths prefixes? you mean like /de/... /en/... ? Those are set on the homepage name.

Glad to hear this. We have so many here that are part of the MODX community too that it seems like a family, and I really want to see MODX do well.

I think it should be $settings = $pages->get("/site-settings/"); ie get [one page] rather than find [any number of pages] (and you don't need the == 1 in the if because if $settings->mycheckboxfield is 1 then it will evaluate to true.)

Thanks for the explanation Ryan. I had never thought it about it as a lazy way, but I certainly see your point. I initially used to write my little custom CMSs to retain original filenames, but changed to auto-generated because most of my work is for sites which provide lots of materials designed to be downloaded by end users. Having clients upload files with names like: Final ReportV6 web version for John Feb 23.PDF started to drive me a little crazy though. Not very useful or meaningful to the poor end user who downloads it. No amount of training or explanation could get them to make meaningful filenames. Thanks for the example module code - I will definitely make use of that. I really can't believe how easy you have made implementing custom modules. The lack of ability to do this with other system (whether real or perceived) is why I never went the CMS route for so many years It always seemed like I would be hacking away at things to make the functionality I needed.

I'll ask here, think my question is similar. I want to add ID to pages's name in 1 template (exactly like on this forum "/3276-change-auto-bla-bla-etc/"). So I need to write a module with hooks for this or what? Please, push me to the right direction. upd: made it this way: <?php class PrefixToPagename extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Add prefix (id) to the page name', 'version' => 100, 'summary' => 'Add prefix (id) to the page name', 'href' => '', 'singular' => true, 'autoload' => true, ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { // add a hook before the $pages->save, to add prefix if needed $this->pages->addHookBefore('save', $this, 'addPrefix'); } /** * Hooks into the pages->save method and sorts pages with a certain template based on certain criteria * */ public function addPrefix($event) { $page = $event->arguments[0]; // Only run if the page we just saved has the "vacancy" template if ($page->template == 'vacancy') { $oldname = explode ('-', $page->name); if ($oldname[0] != $page->id){ $page->name = $page->id . '-' . $page->name; } } } } thanks guys from this thread.

Grüezi Daniele, you will get access to the form builder support forum once Ryan sees this. I'm not sure what you need to archive, but since the entries are stored as json you can't search for entry fields. If you want to use API to find entries you need to store them as pages. You can access the entries in DB through $forms foreach($forms->get("contact-form")->entries->find() as $e){ echo "<p>{$e['e_mail']}</p>"; }

.. and one more take for the same subject, from slightly different angle: ProcessWire is both CMS and CMF in one package, ie. by installing ProcessWire CMF you also get "admin" which is essentially a CMS built on CMF provided by ProcessWire. The line can be a bit blurry at times Anyway, admin uses API behind the scenes, so it's not really that different from any other application you might build with PW (expect for the fact that it's probably larger.) You'll most likely want to keep it available even if you build something similar yourself -- if not for any other reason, at least to give you a nice way to view and manage templates and fields without having to do everything via API (which is of course possible too!) From my point of view there are two main ways to use ProcessWire as a platform for your applications: Bootstrapping (like Pete explained above) enables you to use it's features from strictly outside PW, ie. you could build whole application yourself and then make PW store (and fetch, sort, sanitize etc.) your data. You could also use more of the framework provided by PW by creating your application as a PW site, using template files for your application / view logic and so on. You don't really have to build modules to use PW (as a framework or a CMS) but they're a handy way to package some feature you need often into one reusable tool you can pull out whenever there's need for it. They also enable you to tweak how PW works out-of-the-box; you can, for an example, add new methods to PW objects such as Pages, without hacking core code (which is unbelievably useful at times.) Process modules (one type of modules you can create for ProcessWire) are a bit different in that they integrate directly with admin tools, providing new features there. These let you extend default admin features a lot and more often than not whatever control panel your custom application needs could also be built this way Generally speaking there are many similarities between PW and various web application frameworks like CodeIgniter and CakePHP, but PW doesn't venture quite as deep in the "generic utility" category and also forces as few restraints on you as possible. It's more focused on handling content and data types than providing you tools for general tasks (strings and numbers, email, FTP, complicated image manipulation etc.) and doesn't force a strict application structure (MVC, MTV etc.) on you (unless you build one yourself, like I've done for my own projects.) I hope this helps understand a bit what PW is, how it relates to other frameworks.. and whether it's the tool you're looking for Extra tip: cheatsheet is good place to start digging in PW. Turn on the advanced mode and you'll get pretty good idea what PW can offer.

Like Joss once said: you can also think of Processwire as a CME - content management engine. In other words, it does anything you want to the degree you understand how to extend on it.

Technically CodeIgniter and CakePHP are also "pure PHP" and a framework simply gives you a way to get a headstart on development using pre-defined classes etc. I think what you're really asking is if you can use it as a framework and just access its classes directly as with those framework and the answer is definitely yes, but there is no single correct way to work with it which is the beauty of it In ProcessWire, to use it as a framework you would bootstrap it and use the API to get stuff done. Here are some helpful links on that side of things: http://processwire.com/api/include/ - The first few lines show how simple it is to include and get started, then this one shows you the vast majority (maybe all?) of the API functions on one page: http://processwire.com/api/cheatsheet/

The beauty of ProcessWire is that it approaches content management without any assumption about what kind of content you're storing, or what you're going to do with it. Content is data, and data is content, and are accessible equally through the API and the GUI. You don't need to build modules to take full advantage of PW, or even make templates -- you can just include PW in any PHP script and have full access to its API. So yes, it would be extremely easy to build a custom web application on PW. You can just think of it as a way to interface easily and safely with MySQL. It also happens to have a wonderful GUI backend, objects for santizing user input, and managing sessions.

Thanks everyone about the support. I have implemented this on few of our demo/test sites (takes about 2 min per template) and it was total breeze and the speed and simplicity of editing is amazing. Even better than I thought. Thanks for the great words. And yes, all ideas are welcome You don't happen to have adminbar installed also? I have noticed that behaviour when I have adminbar installed (it does that redirect). Without adminbar it should stay on same page. I have been thinking wheter I allow creating new pages with Fredi or not. It shouldn't be that hard though. Syntax might be something like $fredi->renderNew("template", $parent_page); I might give this one a go. I am not sure I understand the relation from AdminBar to CKEditor. Biggest "idea" of Fredi is that because it fields on modal (using iFrame), we get all the candies from admin for "free". Meaning ajax uploads, datepickers, repeaters... you name it. With adminbar you get same goodies, but you always edit whole page. So you cannot click close the relevant content and you have to "find" the correct field from admin view. Adding special treatment for ckeditor fields doesn't fit for Fredi I think. That is the direction I have been thinking about long time, and it always meant lot's of work and end resolution would always be "halfway there" - meaning support only for textfields (or even more work to make any other fields working). For the same reason Fredi does "full reload" after each edit. It is close to impossible to have ajax refresh, since Fredi cannot know all the places where content is used. That is a good idea. Though syntax will be $fredi->renderAll($another_page);

I use modal frontend editing in PW since the beginning. It's as easy as providing a edit link that open in a iframe modal and add ?modal=1 to the url.. I wrote and showed even code example in this thread. http://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/ Just seems nobody really bothered about it, but go all crazy with this module.

Ok, starting from the end. Put very roughly, $page represents a single page while $pages represents all pages. The methods from $page http://processwire.com/api/cheatsheet/#page can be applied to any object that represents a single page. $page, when used simply like this, represents the page that called the current template (usually by being viewed in the browser), but the $page methods can be applied to any Page object (other pages, even if they didn't call the current template). How do we get all those pages that are not represented directly by the variable $page? You guessed, using $pages http://processwire.com/api/cheatsheet/#pages $otherPage = $pages->get("/about/"); The get() method of $pages, returns always only one page. Meaning that $otherPage, is now an object equivalent to $page. Because of this, you can apply to it all the methods and call all properties of the object $page: echo $otherPage->id; While get() returns a single page, find() returns an array of pages, to be more precise a PageArray, and to those arrays you can apply any of the PageArray methods and call it's properties http://processwire.com/api/cheatsheet/#wirearray $pagesList = $pages->find("template=basic-page"); $pagesList->shuffle(); //same as: $pagesList = $pages->find("template=basic-page")->shuffle(); and because $pagesList is now a list with lots of $page equivalents inside it, you can go to each one individually and apply the same methods and call the same properties as with $page: foreach($pagesList as $individualPage){ echo $individualPage->id; } Disclaimers: I did an over simplification of the terms (same as in the cheatsheet). To make it clear: $page is a variable that holds a Page object that represents the current page. The methods I keep referring and that are on the cheatsheet, are in reality methods of Page objects, and not $page itself. The same applies to $pages and Pages. I must have some errors there because I'm far from a PHP specialist (even less concerning OOP). edit: Ryan, I saw that you answered before me, but I think to the first part. I will read now

This sounds like a good solution to me. I can see this being useful. Though I'd probably want to make any relative paths relative to the /site/templates/ dir, just to prevent any ambiguity about the starting point.

I agree that this can already be done with code - no question. To use a practical example, let's say we have two templates, "author" and "blog-post". The "blog-post" template has a reference field, crediting one or more authors for the post. An "author", when rendered as a page, is going to display detailed profile information about the author, and maybe list his most recent posts. A "blog-post", when rendered as a page, is going to display who the authors are, but probably in a short summary format. Now currently, the way I would implement the template for "blog-post", is I get the list of authors, and I loop over them inside the "blog-post" template. As opposed to calling $author->render() for each author, because that would render with the full template with all the details and listing other posts. So you've got the "blog-post" template now in charge of actually rendering bits and piece of "author" pages, but not using it's template, and avoiding the render() method, because it renders a full document view, where in this case, all I want is a partial. What I'm seeing, is that you actually have multiple views of the same information in different contexts. Let's say we also have an "article" template, which also has a list of "author" references - now I can either duplicate the snippet of code that renders the authors in the compact format, or I can move that code into an external include file, e.g. a separate view. But there's currently no way to formally associate an alternate view with a template. Another example would be a template that requires two different views - for example, an "article" template might have both a "teaser" view and a different (default) full article view. Currently, we can model that with an extra URL argument, and an if/else statement in the template, making the decision about which view to render. But again, there is no formal way to associate the alternative view(s) with the template. I'm not saying there has to be - it just seems like a rather common requirement, and possibly one of those things where it might be beneficial for a non-programmer (designer) to be able to add multiple views for a template, without having the programmer (me) become a bottleneck in those situations...

If you have a robots.txt, I would use it to specify what directories you want to exclude, not include. In a default ProcessWire installation, you do not need to have a robots.txt at all. It doesn't open up anything to crawlers that isn't public. You don't need to exclude your admin URL because the admin templates already have a robots meta tag telling them to go away. In fact, you usually wouldn't want to have your admin URL in a robots file because that would be revealing something about your site that you may not want people to know. The information in robots.txt IS public and accessible to all. So use a robots.txt only if you have specific things you need to exclude for one reason or another. And consider whether your security might benefit more from a robots <meta> tag in those places instead. As for telling crawlers what to include: just use a good link structure. So long as crawlers can traverse it, you are good. A sitemap.xml might help things along too in some cases, but it's not technically necessary. In most cases, I don't think it matters to the big picture. I don't use a sitemap.xml unless a client specifically asks for it. It's never made any difference one way or the other. Though others may have a different experience.

i.am first you can puut this in your head.inc tamplate or some includeded file before.u are doing $page->url $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'article') $e->return = "/blog/$page->name/"; }

This template was made before the column feature was introduced. So look in the code, the columns have a special class (guess something with "column", I am not at my computer now). Just apply a "float:left;" to that class in the admin's CSS. edit: I think it is the class "InputfieldColumnWidth". Look for that in the ui.css or add this: .Inputfields > li.InputfieldColumnWidth { float: left; clear: none; margin-top: 0; margin-left: 1%; } .Inputfields li.InputfieldColumnWidthFirst { clear: both; margin-left: 0; }