Leaderboard

in addition to pwired here http://processwire.com/talk/topic/3785-alternative-syntax-for-control-structures-a-tip-for-newbies/#entry37007 http://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/?view=findpost&p=35953 http://processwire.com/talk/topic/3754-proof-of-concept-processwire-admin-theme-switcher/?view=findpost&p=36621 http://processwire.com/talk/topic/3785-alternative-syntax-for-control-structures-a-tip-for-newbies/?view=findpost&p=36950

Thanks for this Tutorial. This is the thread that got me finally to take a closer look on PW. Meanwhile, I have been reading various posts and tutorials. I am impressed how easy and fast i get on PW, because im not really a hardcore php coder. But easier than I imagined it in Processwire. I think I've found my new favorite CMS and say thank you MODx for the nice years of cowork but I have to move on.

Hi, First, some introduction... I'm new on PW, just started yesterday evening and I'm very enthousiastic! I have 10 years+ enterprise experience in PHP (owning my own software company for 8 years). I have developed an enterprise CMS myself for lawyers, accountants and all sort of enterprise users which focusses towards handbooks (ISO and the likes) which is used by 2000+ companies (incl. government) in The Netherlands. Besides this, I just do some websites for friends and family in my spare time (which I do not have because I'm a dad of 3 too). I stumbled upon PW yesterday after I (again) completely freaked out at Joomla. I know this software when it was called Mambo 4.5.2 and I have created many componenents for it, knowing it from the inside. I always (after the first 3 months) hated it, but you know, when developing a small website it was the tool at hand for me because I knew it so well. And just every time I created a website I got frustrated, but well I got there and "OK, next". But this week, after 4 days of trying and reading and CCK extensions modules overrides custom layouts and all this stuff which makes me sick because its inconsistent as hell, I decided to just QUIT on joomla. It makes me cry. No joy in developing a small website. It's always about fitting in their model instead of the other way around. (And somehow, WP (which I don't know) feels the same way but different) Having said all this, did I mention I am very enthousiastic about PW? Well, I am. I have created in just one day (or half a day) what I wanted to do with Joomla and couldn't do it in four days. Even while I didn't got any sleep last night due to 5 weeks old baby etcetera. So, I'm happy with PW. Very happy. It just delivers. And I'm not familiar with the jQuery syntax (mostly used Mootools in my own software). It is just intuitive. I hope I stay this enthousiastic. But I'll gain some trust every step I make with it. Of course, there are a few things which I don't get directly, but I can search and read. But I wanted to just introduce myself and say a big THANKS for PW to Ryan and all the others. There is something I don't really grasp yet. Like this: I have several news items. These items are linked to from products. This works very nice But of course I want to have an index of all the news items. I can make a news-index template, and just make one. No problem. And then, I have a several review items, and several quotes. And I want them linked to products, no problem. But have an index too. Now, I can make 3 index pages. But somehow, they are similar to each other. Thus, Why don't create a 'polymorph' 'index' template. Which refers to a certain template (like, news, reviews, quotes) and loades all the items. Somehow, I just didn't came across this idea in the docs, wiki or forum. Perhaps I didn't read good enough, and I'm the first to admit I did not spent too much time with PW, but I'm curious if these kinds of concepts are 'the PW way to do things'. Another question/thought I have is about the data model. But thats maybe not the right place to ask right now....Is there something I can read about the thoughts and concept of the datamodel? Thanks in advance, I hope to use PW for my upcoming website projects and just want to finish my first stuff in the following weeks.. So you'll possibly see me some more on this forum. Ow by the way just one point of feedback: when doing my research yesterday, I thought that there were only video's available to get to know PW. After a while I stumbled upon the wiki and getting started links ! Wow. That saved time. But I wonder: why isn't that on the homepage? Every developer just wants to know about this I guess... After all the horrible forums with joomla 'experts' a forum isn't the first place I go look for documentation and help, you see..

Funny thing is I can't even get LoginThrottle to work as there's a bug/logik that won't save the attempts to DB, well it does but they get deleted immediately afterwards I filed a issue on github. https://github.com/ryancramerdesign/ProcessWire/issues/198 Back to your issue. You don't need to do anything if you use custom login form. Regarding the code in SessionLoginThrottle. When there's 3 failed attempts within the defined seconds limit it does: ... if(wire('process') == 'ProcessLogin') parent::error($error); else throw new WireException($error); // ensures the error can't be missed in unknown API usage ... Which means if you don't use ProcessLogin to login, it will throw an Exception not an notice! You know you also can render a login form using echo $modules->get("ProcessLogin")->execute(); But this will also result in a Exception thrown, as it's not really the ProcessLogin process running.

I just posted version 5 of Hanna Code. The primary additions here are: Predefined (default) attribute values There is a new Attributes field present in the Hanna Code editor. From here you can define what attributes your PHP or Javascript Hanna Code expects. This can also be used to set default values for attributes. Use of this is optional. However, I think it's a good idea to use it as it helps communicate what the options are for a given Hanna Code. It also saves you some code as you can assume your attributes will be defined as variables, ready to access. The main listing page now shows Hanna Codes with their attributes so that they can be copied/pasted into your body text with all attribute options known and ready to fill in. Support for Export and Import of Hanna Codes Now you can export any Hanna code and import it somewhere else using copy/paste. You'll see the Export option when editing a Hanna Code. You'll see the Import option on the main listing page. Below is a predefined Hanna Code you can import if you'd like: Jumplinks Hanna Code (example for import) This Hanna code is meant to be used in your body copy. It collects all the headline tags in the text and turns them into anchor jump links while outputting a linked table of contents. It will put the table of contents wherever you type the Hanna code. See the anchor jump links on this page for an example of what this Hanna Code does. Import Data: !HannaCode:jumplinks:eyJuYW1lIjoianVtcGxpbmtzIiwidHlwZSI6IjIiLCJjb2RlIjoiXC8qaGNfYXR0clxuZm9yPVwiaDIgaDNcIlxuaGNfYXR0cipcL1xuJGZvciA9IHN0cl9yZXBsYWNlKCcsJywgJyAnLCAkZm9yKTtcclxuJGZvciA9IGV4cGxvZGUoJyAnLCAkZm9yKTtcclxuZm9yZWFjaCgkZm9yIGFzICRrID0+ICR2KSAkZm9yWyRrXSA9IHRyaW0oJHYpO1xyXG5cclxuJGZvciA9IGltcGxvZGUoJ3wnLCAkZm9yKTtcclxuJGFuY2hvcnMgPSBhcnJheSgpOyBcclxuJHZhbHVlID0gJGhhbm5hLT52YWx1ZTsgXHJcblxyXG5pZihwcmVnX21hdGNoX2FsbCgnezwoJyAuICRmb3IgLiAnKVtePl0qPiguKz8pPFwvXFwxPn1pJywgJHZhbHVlLCAkbWF0Y2hlcykpIHtcclxuICBmb3JlYWNoKCRtYXRjaGVzWzFdIGFzICRrZXkgPT4gJHRhZykge1xyXG4gICAgJHRleHQgPSAkbWF0Y2hlc1syXVska2V5XTtcclxuICAgICRhbmNob3IgPSAkc2FuaXRpemVyLT5wYWdlTmFtZSgkdGV4dCwgdHJ1ZSk7XHJcbiAgICAkYW5jaG9yc1skYW5jaG9yXSA9ICR0ZXh0OyBcclxuICAgICRmdWxsID0gJG1hdGNoZXNbMF1bJGtleV07IFxyXG4gICAgJHZhbHVlID0gc3RyX3JlcGxhY2UoJGZ1bGwsIFwiPGEgbmFtZT0nJGFuY2hvcicgaHJlZj0nIyc+PFwvYT4kZnVsbFwiLCAkdmFsdWUpOyBcclxuICB9ICBcclxuICAkaGFubmEtPnZhbHVlID0gJHZhbHVlOyBcclxufVxyXG5cclxuaWYoY291bnQoJGFuY2hvcnMpKSB7XHJcbiAgZWNobyBcIjx1bCBjbGFzcz0nanVtcGxpbmtzJz5cIjtcclxuICBmb3JlYWNoKCRhbmNob3JzIGFzICRhbmNob3IgPT4gJHRleHQpIHtcclxuICAgIGVjaG8gXCI8bGk+PGEgaHJlZj0nJHBhZ2UtPnVybCMkYW5jaG9yJz4kdGV4dDxcL2E+PFwvbGk+XCI7XHJcbiAgfVxyXG4gIGVjaG8gXCI8XC91bD5cIjtcclxufSBlbHNlIHtcclxuICBlY2hvICcnO1xyXG59In0=/!HannaCode Usage Examples: [[jumplinks]] Locates all h2 and h3 headlines, turns them into anchors, and generates a table of contents. This is the default behavior with no attributes. [[jumplinks for=h2]] Here we specify a 'for' attribute. It produces the same behavior as above except only anchors h2 headlines. [[jumplinks for=h2 h4]] Same as above except only anchors h2 and h4 headlines.

Easily insert any complex HTML, Javascript or PHP output in your ProcessWire content by creating your own Hanna code tags. This module is based loosely on the WordPress Hana Code Insert plugin. A Hanna code tag looks like [[hello_world]]. A Hanna code tag with attributes looks like [[hello_world foo=bar" bar="foo]] using HTML style attributes or [[hello_world foo=bar, bar=foo]] using ProcessWire selector style attributes. After installing the module, you define your Hanna codes in Setup > Hanna Code. These Hanna codes that you define can then be entered within your body copy (or other text where you allow) and they will be replaced with the values defined or generated by your Hanna code. A common use case is to embed scripts or other bits of HTML or codes that would usually be stripped out by an editor like TinyMCE. However, Hanna codes can be more than just static snippets--they can be dynamic PHP or Javascript that outputs different things according to the request. PHP-based Hanna codes have access to the entire ProcessWire API. Hanna code accepts named attributes in the tag that can be passed as variables to PHP and Javascript Hanna codes. These attributes can be specified either in HTML attribute format or ProcessWire selector format. In either case, quotes should be used around the attribute value when the value contains whitespace or a comma. How to install Place the module files in /site/modules/TextformatterHannaCode/ In your admin, click Modules > Check for new modules Click install for TextformatterHannaCode Now to go Setup > Fields and locate the Textarea field(s) that you want to use Hanna codes with ("body" for instance). When editing the field, click the details tab, and select "Hanna Code" as the Textformatter. Save. Now go to Setup > Hanna Code and start defining your Hanna Codes! You may want to use one of the examples from this document to get started. Tag format Below is a Hanna code tag named hello_world with no attributes. If you pasted this into your body copy, you would get whatever the replacement value is that you defined. [[hello_world]] Below is a Hanna code tag named hello_world being passed attributes of foo, bar and foobar. If this were a PHP-based Hanna code, it would receive the variables $foo, $bar and $foobar: [[hello_world foo="bar" bar="foo" foobar="foo bar"]] Below is the same Hanna code tag as above, but with attributes more like ProcessWire selectors. You can use whatever format you prefer. Just note that unlike regular ProcessWire selectors, quotes (single or double) are required around any value that has whitespace. [[hello_world, foo=bar, bar=foo, foobar="foo bar"]] How to use Please make sure that you have completed the How to install section first. Then in your admin, go to Setup > Hanna Codes. Each Hanna code that you add has a type of either: Text/HTML, Javascript or PHP. The Text/HTML type is literally self explanatory in that your [[custom-tag]] is replaced with exactly the text you paste in. Anywhere that you type your [[custom-tag]] in your body copy will be replaced with exactly the static text you defined. More power opens up with the Javascript and/or PHP types of codes. These codes execute at runtime and thus can contain specific logic to produce different results. In fact, PHP Hanna codes have access to the entire ProcessWire API and are executed in the same manner as template files. Your PHP-based Hanna code should simply "echo" or "print" the replacement value. PHP example Create a new Hanna code with the name "children". Select "PHP" as the type. Paste in the following for the code: foreach($page->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Now go and edit a page that has children. In the body copy, enter [[children]] in the place where you want the output to appear. View the page, and you should see the rendered list of links to children. PHP example, part 2 Now lets take the above example further... Go back and edit your "children" Hanna code, as we are going to modify it to respond to a "parent" attribute. Change the code to this: if(isset($parent)) { // If $parent is an ID or path, lets convert it to a Page $parent = $pages->get($parent); } else { // otherwise lets assume the current page is the parent $parent = $page; } foreach($parent->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Go back and edit the page where you previously inserted the [[children]] tag, and change it to: [[children, parent=1]] (specifying the homepage) or [[children, parent=/path/to/some/parent/]] if you want to try something else. View the page and you should now see it showing the children of the homepage (or of another parent you specified). Please see the Javascript and PHP usage notes on the Hanna code entry screen. Security There are major security implications with a tool that will let you enter unfiltered text and code from your web browser. As a result, Hanna codes are meant for definition only by superusers and we recommend keeping it that way. Download Download the Hanna Code module from the ProcessWire modules page or from GitHub.

I just pushed ProcessWire v2.3.1 to the dev branch. This is a fairly major change in that it switches the DB driver from mysqli to PDO. It meant changes to a large percentage of core files. ProcessWire still supports mysqli, but doesn't attempt to use it unless a module or a template asks for it via the $db API variable. The new API variable (for the PDO driver) is $database. More about PDO at php.net If you are using the dev branch, be careful and test thoroughly with this latest commit to it. Before upgrading, you may want to double check that your PHP supports PDO by looking at your phpinfo (CMD-F or CTRL-F for "PDO"), especially if you are running PHP 5.2.x (where PDO wasn't compiled in by default). Though if you are running PHP 5.2 (vs 5.3.8+) then you may want to just stick with ProcessWire 2.3.0 and upgrade your PHP version when possible. If you are using any modules that use the procedural version of mysqli functions (vs. the $this->db object oriented versions), or type-hint mysqli in methods, then those modules will no longer work. If you come across any modules that don't work with 2.3.1, please let me know here so that I can assist the author in updating them. Note that FormBuilder is one of the modules that does not work with 2.3.1, but I have posted an update in the FormBuilder board that corrects it–so be sure to download that version if you are tracking the dev branch of ProcessWire and using FormBuilder. What this new version adds: 1. New API variable $database that refers to the PDO database. The old $db API variable is still there and refers to mysqli for any modules that continue to use it. 2. New API variable $log that lets you easily log messages or errors to the system logs. Usage: $log->message("This saves this line to messages.txt"); $log->error("This saves this line to to errors.txt"); $log->save("my-log", "This saves this line to my-log.txt"); // Get an array of the last few entries saved to the messages log $entries = $log->get('messages'); // Get an array of the last 50 entries saved to my-log $entries = $log->get('my-log', 50); Note that as always, log files are located in /site/assets/logs/. 3. Conditional autoload modules. In PHP 5.3+, modules may now specify an anonymous function OR a selector string, rather than a boolean for the 'autoload' property returned by getModuleInfo(). PW runs the anonymous function after determining the current $page, so your module can make autoload decisions based on the $page (or any other factor you'd like), if desired. Lets say that we have a module that we only want to autoload when the template is 'admin': public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => function() { if(wire('page')->template == 'admin') return true; else return false; }); } And the same example but using a selector for autoload: public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => 'template=admin' ); } 4. Addition of $pages->add() method. Actually $pages->add($template, $parent, [string $name], [array $values]); This function adds a new page to the database and returns it. This is for syntax convenience, but using the old method is still perfectly fine too. Here's a few examples of usage: // add a new page using template basic-page under /about/ $newpage = $pages->add('basic-page', '/about/'); // same as above, but named 'contact' $newpage = $pages->add('basic-page', '/about/', 'contact'); // same, but populate the title field too $newpage = $pages->add('basic-page', '/about/', 'contact', array('title' => 'Contact Us')); // you can also do this, specifying the values array as 3rd argument: $newpage = $pages->add('basic-page', '/about/', array('title' => 'Contact Us')); $template and $parent are required, but may be objects, IDs, or string identifiers (like name for template, or path for page). When you add a new page and don't specify a 'name', then PW will make one up, guaranteed to be unique. 5. Module files that end in '.module.php' are now supported. So rather than ClassName.module, you may use ClassName.module.php if you prefer it. The purpose here is to support text editors that determine their syntax highlighting based on the file extension. More updates being made almost daily. Please report any issues you experience. Thanks, Ryan

I am not sure how you have things set up, but I would have a page select field that contains all the city names. I guess each theatre would have a city field assigned to it via this field. For generating your select dropdown you could do: echo '<select name="selected_city">'; foreach($pages->get("/cities/")->children() as $city){ echo '<option value="'.$city->name.'">'.$city->title.'</option> } echo '</select>'; Then for your selector for limiting theaters to the selected city you might have something like: $theaters = $pages->get("/theaters/")->children(city=$session->current_city); All written in the browser and untested, but should be close, but again it depends on how your theaters and cities fields/templates are already set up.

If you do it simply with a page refresh, rather than ajax, you can simply do something like the following at the top of the page: if($input->get->selected_city){ $session->current_city = $input->get->selected_city; } else{ $session->current_city = $user->user_city; } You can use the $session->current_city directly in your selector. You can choose get or post for the action for your form depending on whether you want the selected_city passed via the url (good for bookmarking) or not.

Why not set $session->current_city = $user->user_city and then if they choose an alternative from the select box, change it using: $session->current_city = $input->get->selected_city or something like that, depending on how you process the select box.

Ya right! I like the badge though; might just use it as an Avatar!

If you look at FieldtypePage getInputfield() it's only InputfieldPage. Then in InputfieldPage you see protected static $defaultInputfieldClasses = array( // default options 'InputfieldSelect', 'InputfieldSelectMultiple', 'InputfieldCheckboxes', 'InputfieldRadios', 'InputfieldAsmSelect', 'InputfieldPageListSelect', 'InputfieldPageAutocomplete', ); InputfieldCheckboxes is only for InputfieldPage alternative input. InputfieldCheckbox is only the input for FieldtypeCheckbox. It's a single checkbox input while InputfieldPage can be multiple. It looks like you are mixing a lot of things up, and looking at your module, your "role_permitted_templates". You have a text field with comma separated values but want to use InputfieldPageName for sanitizing like a page name but which will remove ",". This wouldn't work anyway apart from that you can't use InputfieldPageName here. Just stick with a InputfieldText or InputfieldTextarea, to enter templates comma separated or per line. It would be cool to have a ASM select to select templates, but this would only work if you only use the InputfieldPage with a ASM select, and add templates as options with templateid=>templatename. This unfortunately isn't possible when using a real custom field added to a template, it's only for use when adding it through a hook to a fieldset and on saving take the selected option(s) to save it somewhere.

I don't think parenthesis affect the logic here. I like to wrap ternary blocks in parenthesis just for readability, containing it to a visual open "(" and close ")" to the statement. But I don't think ternary operators and/or parenthesis aren't the issue here. The original issue is that the poster was comparing an object to an ID, which was probably failing. Later it was followed up with one where "==" are being used to compare two objects. That's not an ideal way to compare page objects because that double equals goes in and compares all the properties of both objects. If they are two different copies of the same page, it will fail. The best way to compare pages is to compare the ID (per my post above). Though if one literally wants to compare that two objects are the same instance then 3 equals "===" should be used, since that will compare the memory pointer (efficient) rather than every single variable in the object (not efficient). But I recommend comparing only the 'id' property, just on the off chance that you've got two different instances of the same page. It's also easy to remember, always works, and adds clarity that you are dealing with page objects.

Beyond being a CMF/CMS, the goal of ProcessWire has also been to provide utility to PHP like jQuery does to Javascript. That means we accept PHP best practices as our best practices, rather than inventing proprietary, usually more complex and short lived alternates that do the same thing. It also means using very simple, yet tried and true PHP like functions and includes for code reuse rather than snippets, blocks, chunkers, snaggers, widgets, tagalongs, bangers or whatever concepts are being pushed out there. ProcessWire provides tons of structure when you want it to, and gets out of your way when you want it to as well. For me it means template files that rarely have much code in them (occasionally none), unless the output need is different from the rest of the site. Most of the site's markup gets generated either from a "main" output file, or from shared render functions. As a result, most template files tend to have limited or no markup and look like the example at the bottom of this post. It also means that I don't usually have more than 2-3 other PHP files, beyond the template files. See the template file structure section of this post for details on how I structure my template files–I've found this method to work best for me through several sites. The delegate approach and some of the others I've seen don't suit my needs as well, but seem to work very well for others. The Blog profile uses an MVC style approach that may appeal to those looking for lots of predefined structure, though I still prefer approaches that involve fewer files. For small stuff, the approach taken in the default profile (included with ProcessWire) is about as simple as it gets, even if it's not as elegant. But when it suits the need, I don't see any reason to shy away from it. Regardless of how you structure your site, the important thing is to aim for DRY (don't repeater yourself). home.php $body = renderSlideshow($page->features) . $page->body; $side = renderNews($pages->find("template=news, sort=-created, limit=5")); The example above uses the /site/config.php 'prependTemplateFile' and 'appendTemplateFile' options to include an _init.php (prepend) file that initializes variables like $body and $side with defaults, and a _main.php (append) file that outputs them in the predefined places within the context of an entire HTML file. The template files get executed in between those two and modify $body and $side as needed specific to the data and needs of the template and page.

Seems like all of the solutions here are shorter than mine and so they are better from a KISS perspective. Like i said i'm a beginner who just learned to use the hammer so many problems are starting to look like nails to me But just wanted to mention that with my solution you should be able to use renderPager() since you're not working with in-memory arrays. I would be really curious to know how DaveP's solution plays out and how it compares in processing speed with mine - right now i have no idea which would be faster. BTW, if you're looking to filter out all the pages who don't have the intro field from the module, just replace: // we can specify a certain template that this module should run for. As it is, it will run for all pages. Just uncomment the line blow and replace "template_name_here" with the name of your template //if($page->template->name != 'template_name_here') return; with: if (!$page->intro) return;

That could be useful but for now, I'll setup fields and templates by hand (not enough to bother with automation). Then migrate the items from system A to system B with help from existing modules. Do it by installing Pages Web Service on system A, Calling that from a script which takes the json info and write out a csv file representing the items. Then on system B using Import Pages from CSV files to create the pages from that csv. I have to stop now but I'll report back.

I've just discovered this app that should import web pages straight to photoshop files, and divide them by layers (following the DOM structure previously applied). I don't own a Mac (poor me..) but I think this is a great little tool to have, could be useful.

I think you could use your code (with an addition) to create a selector value to use with $pages->find. Then replace doSomething(); with $selector .= $page->id . "|"; and after the end of the foreach rtrim($selector, "|"); to knock off the last (redundant) pipe, should leave $selector containing something like 123|456|789 which you can then plug into $pages->find for renderPager(). (Completely untested, but should work, I think. (I hope.))

Hi Luis, weird thing! I have tested a bit with PW Version 2.3 stable, and it seems that PW and PHP also does a right job. But MySQL could be wrong. I have created a float field and it works as you have described, but also when trying to save 10000.11 it store and retrieve 10000.1 !! But to be short, I have tracked the action until to PW saves the value: "INSERT INTO `field_test_float` (pages_id, data) VALUES('1109', '10000.11') ON DUPLICATE KEY UPDATE data=VALUES(data)" After that, I have looked into that field with a MySQL-Editor and it stores 10000,1 and not 10000,11 (When you use 10000,16, it will result into 10000,2) So, after that I have manually edited the field in the MySQL-Editor, typed 10000,11, save, refresh, and voila there are only 10000,1 in it ! It's definitely a MySQL-thing. But I haven't found a solution, only some posts on stackoverflow and mysql datasheets that I do not understand http://stackoverflow.com/questions/4520620/float-precision-problem-in-mysql http://stackoverflow.com/questions/2160810/mysql-whats-the-difference-between-float-and-double http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

Oh, that's good! Very kind, Ryan. So with the locally used PW-Version every works fine in PHP 5.2 and 5.3. When I switch to the last PW-DEV-Branch it only works with PHP5.3 (AddHandler php53-cgi .php), but with PHP 5.2 I get this Parse-Error: unexpected T_PAAMAYIM_NEKUDOTAYIM in /htdocs/wire/core/Modules.php on line 241, (but I also have installed all modules again). With the last stable PW-Version I don't get this Parse-Error in PHP 5.2. and everything works fine. If you are interested and want look into this you may do, but for me it is pretty fine to go with the stable Branch. If you want to look into this, you can switch PHP in first line of htaccess, and there are three wire folders to switch between versions: wire.dev, wire.orig, and wire (the last stable). I don't need to use this installation because I have setup allready a second one that I can use. So if you want you can do with it what you want.

Looks like that worked - at least with the limited number of pages I've got in the dev site right now. Thanks so much!

never mind. I get it now. just tried setting the labelFieldName to 'title' on a FieldtypePage and got the list shown on the field showed titles instead of paths. very cool

While working on a ajax driven web service of sorts, I found this exact same problem (on PW 2.3 / PHP 5.3) When I serve the page as JSON [ header('Content-Type', 'application/json') ] it throws a 404. This doesn't happen if I send html regularly, but it also doesn't happen if I send jsonp (setting header('Content-Type', 'application/javascript') ) Are these issues related? Or am I doing something very wrong? I couldn't find anything regarding issues setting the header, not even here: http://processwire.com/talk/topic/225-how-to-work-with-ajax-driven-content-in-processwire/?hl=%2Bajax+%2Bdriven Forget it, I'm a moron I'm rusty in PHP, spending my workday as a Frontend Dev... header('Content-Type: application/json') works just fine!

You are right. If PW would have lots of conventions, default support for same frontend framework (and therefore lots of generated markup), it would mean that sites build by different companies would be closer to each other. But philosophy behind PW is way different: pretty much zero assumptions, just super useful tool that you can use how you best see. It means you can use all the experience you have (php coding, front end stuff etc) and build upon those skills and processes that you already know.

I have built pretty complex sites with PW and I remember feeling ankward of having similar template file per listing page. I thought that I would use alt-template filename all the time, but haven't actually used that much. And I don't see myself using it much in future neither... After revisiting sites after year or so, I love the fact that when I want to extend something, I always know the "starting point" (consistently named template file). And important to notice: having separate template file for each of your "index templates" doesn't mean you have to do any code duplication. Includes, modules, functions... what ever suits your workflow best Oh and welcome! You will definitely enjoy PW!

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/

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.

The way you do it is to first add a new integer field to your 'brand' template. Call it something like 'num_products'. You might choose to make it hidden, so that it doesn't appear in the editor (if you prefer that). Next edit your /site/templates/admin.php and add this above the include() line that's already there: $pages->addHook('saveReady', null, 'updateBrandQuantities'); function updateBrandQuantities($event) { $page = $event->arguments(0); if($page->template == 'brand') { // a 'brand' page is being saved $page->num_products = wire('pages')->count("template=product, brands=$page"); } else if($page->template == 'product' && $page->isChanged('brands')) { // a 'product' page is being saved and 'brands' changed foreach($page->brands as $brand) $brand->save(); } } The trick is that if you already have a populated site, then you have to establish the quantities for the first time by saving all the 'brand' pages. You could temporarily add this code to one of your site's template files and view the page to populate them. After that, remove the code as it would no longer be needed. foreach($pages->find("template=brand") as $brand) { $brand->save(); }

This is great! Thinking loud here: If you add tags to images, (lets say: cars, beaches or skyscrapers) then you could easily create albums. [[gallery tag=skyscrapers]]

Just wanted to let you all know, I updated the module to 1.1.9 , with another new hook method to manipulate or add your very special case classes that will get added to list_tpl's "%s". To use this, here a little example to make it clearer. I want to add a class to my page with id 1001. Ok here we go. $nav = $modules->get("MarkupSimpleNavigation"); function hookGetListClass(HookEvent $event){ $child = $event->arguments('page'); // current rendered page item (in naviation) $class = $event->arguments('class'); // the class string, may be empty or filled if($child->id == 1001){ // add your checks, use API or whatever... daytime... $event->return .= " yourclass"; // add your class names } } $nav->addHookAfter('getListClass', null, 'hookGetListClass'); echo $nav->render(); Added this to readme

@PWired. Thanks. I am humbled. I try to do my bit. Though, truth of the matter is that I've taken much more than I've given back. There's some great people in this community; I am awed by their generosity.

And we have you to thank for hiring him in the first place which led us to Hanna Code! Thank you!

What kills me about this module is that Ryan literally decided to make it because I had something similar in WordPress and needed a substitute solution in ProcessWire (as part of the move of CMS Critic to PW) otherwise I'd have a ton of weird shortcodes in my posts for no reason. He made this module, imported my code from the other module (called Hana Code in WP) and named his Hanna Code (after his daughter) and Poof! a module is born. I am insanely jealous of his mad php skills (but glad they can be bought!)

The current approach makes it possible to share images between Pages - that's nice, but what happens if I delete a Page that contains images reference by a body-field in another Page? I see at least 3 different common image use cases: Inline images belonging exclusively to the body-field where they're used Inline images shared between multiple body-fields Associated images for specific purposes (non-inline use) You can handle number 1 with the current approach, but you can't guarantee the images won't be shared with other pages, hence you can't be sure it's safe to delete a page that contains images - or worse, you may have to delete a certain page, and you will need to first somehow recover the images, place them somewhere else and update you references to those images. You can handle number 2 with the current approach, but it forces you to create dud pages to hold the images. Number 3 is handled perfectly, and that seems to be what this approach was really designed for - basically any inline use-case seems like a bit of an afterthought and the solutions aren't really ideal. I looked at soma's module, but it kind of seems to solve a different set of problems. Ideally, I'd like to have some sort of media manager, not only for images but for audio, video, documents and links to external media, as the same set of problems apply to all of those - in particular, the ability to share and track the usage of all media items. I think this is why most other CMS have a media management component of some sort? The ability to organize a media/image library into categories etc is a nice bonus, but simply being able to manage and use media in a controlled way seems more fundamental to me...

Hi Jan ProcessWire is hugely more flexible that Wordpress and you don't need to know much php at all - in fact, the ability to copy and paste is probably more important! (Especially with all the help round here). There is no strict theming system for ProcessWire in the way you would think of for Drumlapress (!) - basically because that would limit the creation of bespoke websites far too much. The system as it works now means that as long as you can write good HTML and CSS, you can create a brilliant site, without having to learn a templating system. You can more or less approach it in the same way as you would a static site - though, of course, you can get a lot more clever too. If you are looking to integrate it with a framework, then that is as easy as it is with a static site. But, so you get the idea, here is is a veyr stripped back basic profile using Bootstrap: http://modules.processwire.com/modules/bootwire-starter-profile/ As for things like galleries and other plugins, because of the way the site is constructed you can integrate ANY plugin without worrying about it having to fit in with the way the system works. Since there is NO JQuery or anything else for the front end until you actually put it there, you wont run into any conflict trouble with anything supplied by ProcessWire. You simply go and install the plugin in the way the developer says and then learn some very basic php and PW syntax to encorporate your data. Galleries are so simple that it is a joke. As for things like blogs - if you want something very simple (a basic "post some news" sort of thing) then it is so easy to create your own system to work the way you want it to. So, all in all, although it would not be of instest to the average Wordpress user, for any designers out there, it is the perfect way for them not only to design what they want, but in the process learn some basic development skills, which never goes amiss! I am a prime example - I am a copywriter, composer and advertising guru, and yet I am creating my own, very complex blog profile, have created several complex brochure site systems and am learning like mad. I strongly suggest you read the following: Showcase: http://processwire.com/talk/forum/9-showcase/ Detailed beginners tutorial: http://wiki.processwire.com/index.php/Basic_Website_Tutorial (written by me who is not a dev) Explanation of Pages: http://wiki.processwire.com/index.php/Pages You will also find that although there is some serious knowledge amongst the community here, not all of us are developers - but all of us have been surprised how much we have learned. Stay and enjoy! Joss