Leaderboard

Hi all, I've finally managed to set up my website where I intend to post ProcessWire tutorials. The site (lessons) is very much WIP. I have tried to make the site as responsive as possible. I have only tested in Chrome and FF. I'd rather write more lessons than test in IE to be honest so I won't pursue that... I will try to post regularly but can't make any promises as to the frequency . I intend to randomly post some pre-planned lessons. I will update this forum post everytime I post something new. If you have questions, pointers, etc about any lesson, or a request for a specific lesson, please post them here. This way, other forum members can assist in answering the questions . Thanks. /k ==================================================================== Edit: 28 August 2014 - Fist Tutorial is up (OK, it's Blog Module documentation ) Creating a Blog in ProcessWire (Blog Module how to) - 28 August 2014 [99% done] Next: 'All you ever wanted to know about ProcessWire Modules [and other cool things]' - COMING very SOON

Pagination is now fixed on the dev branch. Also you can now translate the the prefix segment (i.e. "page[n]") used for pagination in URLs. By default it is "page" for "page2", "page3", etc. But if you want to translate that on a per-language basis, you now can in the LanguageSupportPageNames module configuration screen. For instance, in Spanish you might want to make it "pagina" for "/path/to/page/pagina2", "/path/to/page/pagina3", etc.

A little tip for anyone wanting a drop-down arrow on submenu parents, like after 'About' below - just add something like this to your CSS. li.has_children > a:after { content: "▼"; font-size: 70%; padding-left: .5em; vertical-align: middle; }

Sooo... I worked this out and it is now on the search results - might have to got to page 2 to see some though at the moment as newer posts tend not to be answered

Since you guys asked for it, I'll take a stab at a case study on the development process. Most of the development was done in about a week and a half. I started with the basic profile, but it ended up being something somewhat similar to the Blog profile in terms of how it's structured. Below I'll cover some details on the biggest parts of the project, which included data conversion, the template structure, the front-end development and anything else I can think of. Data Conversion from WordPress to ProcessWire One of the larger parts of the project was converting all of the data over from WordPress to ProcessWire. I wrote a conversion script so that we could re-import as many times as needed since new stories get added to cmscritic.com almost daily. In order to get the data out of WordPress, I queried the WordPress database directly (my local copy of it anyway) to extract what we needed from the tables wp_posts for the blog posts and pages, and then wp_terms, wp_term_relationships, and wp_term_taxonomy for the topics and tags. WordPress stores its TinyMCE text in a state that is something in between text and HTML, with the most obvious thing being that there are no <p> tags present in the wp_posts database. Rather than trying to figure out the full methodology behind that, I just included WP's wp-formatting.php file and ran the wpautop() function on the body text before inserting into ProcessWire. I know a lot of people have bad things to say about WordPress's architecture, but I must admit that the fact that I can just include a single file from WordPress's core without worrying about any other dependencies was a nice situation, at least in this case. In order to keep track of the WordPress pages imported into ProcessWire through repeat imports, I kept a "wpid" field in ProcessWire. That just held the WordPress post ID from the wp_posts table. That way, when importing, I could very easily tell if we needed to create a new page or modify an existing one. Another factor that had to be considered during import was that the site used a lot of "Hana code", which looked like [hana-code-insert name="something" /]. I solved this by making our own version of the Hanna code module, which was posted earlier this week. Here's an abbreviated look at how to import posts from WordPress to ProcessWire: $wpdb = new PDO("mysql:dbname=wp_cmscritic;host=localhost", "root", "root", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $posts = wire('pages')->get('/posts/'); $sql = " SELECT * FROM wp_posts WHERE post_type='post' AND post_status='publish' ORDER BY post_date "; $query = $wpdb->prepare($sql); $query->execute(); while($row = $query->fetch(PDO::FETCH_ASSOC)) { $post = $posts->child("wpid=$row[ID]"); // do we already have this post? if(!$post->id) { // create a new post $post = new Page(); $post->template = 'post'; $post->parent = $posts; echo "Creating new post...\n"; } $post->of(false); $post->name = wire('sanitizer')->pageName($row['post_name']); $post->title = $row['post_title']; $post->date = $row['post_date']; $post->summary = $row['post_excerpt']; $post->wpid = $row['ID']; // assign the bodycopy after adding <p> tags // the wpautop() function is from WordPress /wp-includes/wp-formatting.php $post->body = wpautop($row['post_content']); $post->save(); echo "Saved post: $post->path\n"; } What I've left out here is the importing of images, topics, tags, and setting the correct authors for each post. If anyone is interested, I'll be happy to go more in depth on that, but didn't want to overwhelm this message with code. Template File Structure This site makes use of the $config->prependTemplateFile to automatically include the file _init.php before rendering a template file, and $config->appendTemplateFile to automatically include the file _main.php after. So the /site/config.php has this: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; You may recognize this as being the same setup from the Skyscrapers profile. The _init.php includes files containing functions we want to be available to all of our templates, and set default values for the regions we populate: /site/templates/_init.php /** * Include function and hook definition files * */ require_once("./includes/render.php"); require_once("./includes/hooks.php"); /** * Initialize variables populated by templates that get output in _main.php * */ $browserTitle = $page->get('browser_title|title'); $body = "<h1>" . $page->get('headline|title') . "</h1>" . $page->body; $side = ''; $renderMain = true; // whether to include the _main.php file The includes/render.php file that is included above includes several functions for generating markup of navigation and post summaries, or any other shared markup generation functions. Examples are renderPost(), renderNav(), renderTags(). This is similar to the blog.inc file from the Blog profile except that I'm letting these functions generate and return their own markup rather than splitting them into separate view files. I personally find this easier to maintain even if it's not as MVC. The includes/hooks.php sets up any hooks I want to be present for all of my templates. I could have also done this with an autoload module, but found this to just be a little simpler since my hooks were only needed on the front-end. The main hook of interest is one that makes all posts look like they live off the root "/" level rather than "/posts/" (where they actually live). This was in order to keep consistency with the URLs as they were in WordPress, so that the new site would have all the same URL as the old site, without the need for 301 redirects. /site/templates/includes/hooks.php /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } }); Our /site/templates/_main.php contains the entire markup for the overall template used site wide, from <html> to </html>. It outputs those variables we defined in _init.php in the right places. For example, $body gets output in the <div id='bodycopy'>, $side gets output in the right <aside>, and $browserTitle gets output in the <title> tag. /site/templates/_main.php <?php if($renderMain): ?> <html> <head> <title><?=$browserTitle?></title> </head> <body> <div id='masthead'> // ... </div> <div id='content'> <div id='bodycopy'><?=$body?></div> <aside id='sidebar'><?=$side?></aside> </div> <footer> // ... </footer> </body> </html> <?php endif; ?> We use the rest of the site's template files to simply populate those $body, $side and $browserTitle variables with the contents of the page. As an example, this is an abbreviated version of the /site/templates/post.php template: /site/templates/post.php // functions from /site/templates/includes/render.php $meta = renderMeta($page); $tags = renderTags($page); $authorBox = renderAuthor($page->createdUser); $comments = renderComments($page); $body = " <article class='post post-full'> <header> <h1>$page->title</h1> $meta </header> $page->body $tags $authorBox $comments </article> "; if(count($page->related)) { $side = "<h4>Related Stories</h4>" . renderNav($page->related); } What might also be of interest is the homepage template, as it handles the other part of routing of post URLs since they are living off the root rather than in /posts/. That means the homepage is what is triggering the render of each post: /site/templates/home.php if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the blog post named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/posts/")->child("name=$name"); if($post->id) echo $post->render(); else throw new Wire404Exception(); // tell _main.php not to include itself after this $renderMain = false; } else { // regular homepage output $limit = 7; // number of posts to render per page $posts = $pages->find("parent=/posts/, limit=$limit, sort=-date"); $body = renderPosts($posts); } The rest of the site's template files were handled in the same way. Though most were a little simpler than this. Several were simply blank, since the default values populated in _init.php were all that some needed. Front-end development using Foundation 4 The front-end was developed with the Foundation 4 CSS framework. I started with the Foundation blog template and then tweaked the markup and css till I had something that I thought was workable. Then Mike and I sent the _main.php template file back and forth a few times, tweaking and changing it further. There was no formal design process here. It was kind of a photoshop tennis (but in markup and CSS) where we collaborated on it equally, but all under Mike's direction. After a day or two of collaboration, I think we both felt like we had something that was very good for the reader, even if it didn't originate from a design in Photoshop or some other tool like that. I think it helps a lot that Foundation provides a great starting point and lends itself well to fine tuning it the way you want it. I also felt that the mobile-first methodology worked particularly well here. Comments System using Disqus We converted the comments system over to Disqus while the site was still running WordPress. This was done for a few reasons: Disqus comments provide one of the best experiences for the user, in my opinion. They also are platform agnostic, in that we could convert the whole site from WP to PW and not have to change a thing about the comments… no data conversion or importing necessary. Lastly, ProcessWire's built-in comments system is not quite as powerful as WordPress's yet, so I wanted cmscritic.com to get an upgrade in that area rather than anything else, and Disqus is definitely an upgrade from WP's comments. In order to ensure that Disqus could recognize the relations of comment threads to posts, we again made use of that $page->wpid variable that keeps the original WordPress ID, and also relates to the ID used by the Disqus comments. This is only for posts that originated in WordPress, as new posts use a ProcessWire-specific ID.

/** * Admin template just loads the admin application controller, * and admin is just an application built on top of ProcessWire. * * This demonstrates how you can use ProcessWire as a front-end to another application. * * Leave this file as-is, do not remove. * */ require($config->paths->adminTemplates . 'controller.php'); This is in site/templates/admin.php Do not remove, doesn't mean you can add code there. It's a easy way to add admin only auto hooks without creating a autoload module.

I agree, I think export/import methods like this on Fields and templates would be nice. There's a lot of considerations though, especially on import. Like whether individual fields already exist or not, whether those field definitions reference external things (like page IDs). That's not to say it isn't doable, but just that there is potential for it to get quite a bit more complex than it first appears. But I would like to implement some API level expor/import functions for this soon, to at least get things moving forward. I've already been working on similar export/import functions for Page objects (which you see in the latest dev branch, though they aren't yet active).

Thanks for the likes It means a lot to me you guys seem to really like me. I don't know what this number means but it's a little scary... heh

It's hidden in the admin interface unless you've got advanced mode on. I've tried to keep the admin as simple as possible so that people can think of templates and fieldgroups as one in the same thing. But the reality is that they are actually separate things. The benefit of having them separate is that you can have multiple templates sharing the same group of fields. But currently we're not highlighting that behavior on the admin side just because I think there is more benefit to the clarity of templates just being a single thing. i had always thought we'd expand on the behavior on the admin side in giving people more options, but the need seems rare enough that it's stayed in advanced mode for now. Probably what I will end up doing is making the API itself abstract the behavior too, so that it adds a like-named Fieldgroup automatically when you access $template->fields and one isn't already there.

CKEditor for ProcessWire CKEditor is a web text editor like TinyMCE. This module can be used anywhere TinyMCE can be used in ProcessWire and it is generally considered one of the best web text editors out there. TinyMCE and CKEditor have always been the two big leaders of web text editors, and they've been equals for many years. Though lately it seems like CKEditor might be a little ahead of TinyMCE in some areas, so I thought we should give people the option of using CKEditor with ProcessWire. CKEditor has a nice inline mode that is desirable in the page editor when you may have lots of rich text inputs. The reason for this is that the page editor loads a lot faster. If you have this need, this would be one reason why you might want to use CKEditor over TinyMCE. Some also prefer CKEditor for other reasons. For instance, @apeisa prefers the table controls in CKEditor to TinyMCE's. Here are a few notes about this module: You already know CKEditor–it's what this forum is using. Though the version included with ProcessWire's module is significantly newer. It is currently beta test. You are advised to test thoroughly before using it in production. You may very well run into bugs, in which case please let me know so that I can fix. It is tested and confirmed compatible with both repeaters and multi-language support. It is now fully hooked into our link and image systems, like TinyMCE. Thanks to Antti for helping with the image plugin. If you want to use the inline mode, you'll need to install the HTML Purifier module first. The toolbar is fully configurable. It is multi-language ready and all text in the module is translatable. Like with TinyMCE, the module optionally supports definition of custom plugins and content.css file. How to install Copy all the files from this module into: /site/modules/InputfieldCKEditor/ Login to your admin and go to Modules > Check for new modules. Click install for InputfieldCKEditor. Now go to Setup > Fields and locate a textarea field that you want to use CKEditor (or create a new textarea field). When editing the settings for a textarea field, click the Details tab. Change the Inputfield Type to CKEditor and save. While still editing the field settings, click to the Input tab for CKEditor-specific settings you may optionally configure. Download ProcessWire Modules page: http://modules.processwire.com/modules/inputfield-ckeditor/ GitHub Repo: https://github.com/ryancramerdesign/InputfieldCKEditor Screenshots Screenshot of regular mode: Screenshot of inline mode, combined with multi-language fields:

Guide to installing ProcessWire on the OpenShift PaaS. Create an account at http://www.openshift.com.'>http://www.openshift.com. Next, select Create Application at the top of the screen and PHP 5.3. Once that is done, add a MySQL 5.1 cartridge to the PHP application. You'll get the following info from creating the PHP app and MySQL cartridge. Setup local Git repository Clone the application's Git repository to your local machine with following command. git clone ssh://51d12b59500446e0df000118@processwire-example.rhcloud.com/~/git/processwire.git/ Fetch the ProcessWire source and code and add them to the php on the local repository with these commands cd processwire git clone https://github.com/ryancramerdesign/ProcessWire'>https://github.com/ryancramerdesign/ProcessWire mv ProcessWire/* php/ mv php/htaccess.txt php/.htaccess rm -rf ProcessWire Push to the Openshift server Commit and push to the Openshift server with following commands: git add . git commit -m 'Setup ProcessWire' git push Complete the ProcessWire setup Acesss and complete the ProcessWire setup at your application's URL: http://processwire-example.rhcloud.com Use the IP address for the MySQL DB, in this case, 127.7.170.2 instead of the environment variable, $OPENSHIFT_MYSQL_DB_HOST

Yo dude, where do you find all that time to set all that up (plus the tutos) ? Amazing. We'll actually I am jealous I don't have that time my self that I would love to spend on pw. Ryan, I think it is time to make kongondo a tutorial pw ambassador !

Maybe there's something in this thread?

Updated version to 2.0.1 which adds a 'relative' option for the date/time stamp setting. That makes it display the time as strings like "5 minutes ago", etc. The other change is that the module can now be iterated with a foreach(), useful for people that want to handle all of their own markup generation. If you take this approach, be sure to read the example and notes in the readme file.

In order to do that, the "pwimage" plugin needs to come out of the TinyMCE plugins list. Since this one is hard-coded in the InputfieldTinyMCE.js file, you might need to edit that directly. You'd want to remove the reference to "pwimage" in the two spots where it appears: var InputfieldTinyMCEPlugins = ['pwimage', 'pwlink', 'advimagescale', 'preelementfix']; ... tinyMCE.settings.plugins += ', -pwimage, -pwlink, -advimagescale, -preelementfix' + custom_plugins;

When exporting with PHPMyAdmin, I sometimes have to uncheck the "use extended inserts" in order to get it to import somewhere else. Apparently the maximum query length can vary from server to server, and avoiding extended inserts reduces or eliminates that problem (at the expense of a slightly larger SQL file).

This one is fixed in 2.3.2 dev.

The case study that was in this thread (and following posts) have been moved to: http://processwire.com/talk/topic/3987-cmscritic-development-case-study/

Nice....btw, what's "kongondo" stands for? (Something very important if you've dedicated that huge space for the logo ).

Here are some excellent GIT tutorials: GIT: 01. 02. http://git-scm.com/book 03. http://try.github.com/ 04. http://sixrevisions.com/resources/git-tutorials-beginners/ 05. http://overapi.com/git/

You don't even have to do the first step that 3fingers referred. Knowing that the default class is "MarkupPagerNavOn" you could simply: $('.MarkupPagerNavOn').attr('disabled', true); or even simply replace all the content of that element (the link) by only the number: $('.MarkupPagerNavOn').each(function(){ $this = $(this); $this.html($this.children('a').text()); });

I've hit the 2000 mark! Thanks guys!

When I have LanguageSupportPageNames and MarkupPagerNav installed together I get only the first set of results returned from a page array. When I type the URL into the address bar with an added "page2" segment, the segment is removed also. The pagination works fine without LanguageSupportPageNames. I tested in a clean install of PW. I'm using the dev version. Possibly I'm doing something silly? If not I would love to help fix this. I realize that LanguageSupportPageNames is in it's early stages. Although I'm admittedly on the newbish side, I do like to jump into the deep end of the pool. As long as the adults are "keeping an eye out". Translate that to "please point me in the right direction".

Thanks ryan - used this at the weekend to replace a home-brewed bit of code I was using that didn't work after the Twitter API 1.1 update. The markup options were especially handy as it meant I didn't have to change my template code much at all

This works as with your example, there's nothing wrong with it except that you need to add include=all: search and return all repeaters "slides" pages (internally have template "repeater_slides") with disable_slide not checked $slides = $pages->find("template=repeater_slides, disable_slide=0, include=all"); And it returns a PageArray So you can loop them out or whatever. foreach($slides as $slide) echo $slide->title; If you want to only get the repeaters from the page you're on this is almost same: $slides = $page->slides->find("disable_slide=0");

I just made another update to replace the fields settings with a AsmMultipleSelect for convenience. If you update, you want to select the textarea fields you want to use IM on. You also have to save the module setting at least once to make it work. And maybe reinstall the module to get rid of unnused settings, but not necessary.

If you can give me access to the installation, I can take a look.

Hi davydhaeyer, welcome! One solution is to create every ingredient as page too and link as many as you want to your recipes. Your page tree would look something like this: - recipes -- recipe1 -- recipe2 ... - ingredients -- ingredient1 -- ingredient2 ... In your recipe template, you can create a Page field (autocomplete) to add ingredients. This way you can add as many ingredients as you want and create them on the fly, if they don't exist: http://processwire.com/videos/selecting-and-adding-pages-with-autocomplete/ (suppose the tags in the video are your ingredients) However, if you need additional data to an ingredient e.g. the number or weight, things get a bit more complex -> Repeater Cheers

Hi davydhaeyer, welcome to Processwire! this sounds like a job for repeater fields http://processwire.com/api/fieldtypes/repeaters/ cheers

PW puts no limits on your front-end design. Your resulting web site could be completely unstyled html, all laid out in tables or the latest cutting edge CSS3. That part is up to you. PW just organises your content and page hierarchy, if that is all you need from it.

One of the things to add to the excellent answers above is that a lot of what you will learn with PW is standard PHP, so it is a transferrable skill - not like a bespoke templating language that only works with one CMS, but a skill you could use in other circumstances.

I'm in the process of building a complicated module and was thinking that being able to create the fields in the admin quickly, then export as a JSON string to use in the installer function would be much quicker than what I'm faced with at the moment - manually typing out the code for all the fields I need to add is taking a long time, so aside from the uses when copying fields/templates to other PW installations it would be fantastic to be able to generate the JSON and in a module's installer just do something like this if we wanted to change some template details or add some additional fields: $templatedata = json_decode($jsonstring); $fieldgroup = new Fieldgroup($templatedata->fields); $template = new Template(); $template->name = "template-name"; $template->fieldgroup = $fieldgroup; $template->save(); Or if we were happy with the template name we'd exported and all the fields, then this: // Adding template "template name" $templatedata = json_decode($jsonstring); $template = new Template($templatedata); // $templatedata contains template and field information $template->save(); The second option means you won't even know what the template is called unless you know how to read a JSON string, but I like its simplicity, and we can just put a comment above it as in my example Just a thought.

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/

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

Actually autocomplete fields have never worked in tabs before... they always had to be on the primary/first tab in order to work. But a week or so ago, someone submitted an update that lets them work in tabs, so I went ahead and committed it to dev. It works here at least. If you are running the latest dev, you might just want to check that you don't have an old JS file cached or something (hit reload a couple times on the page). Here is the commit where it was added: https://github.com/ryancramerdesign/ProcessWire/commit/9a3bf9caa47f204e938213c8ff5cd31691a7c245 If the issue persists, please let me know what browser.

@Ovi: did you try what I've suggested above, ie. hooking into "CommentFormWithRatings::processRatingInput"? That actually worked for me (at least to the point that a die() statement placed in copyAverageRating() was getting executed), so I'm pretty sure it should work for you too Any chance that your method is getting executed but it doesn't work properly? Try doing something very obvious (like a die("foo")) in your copyAverageRating() and see if that gets executed. Whether it does or doesn't, you'll have narrowed the problem quite a bit already. Another thing you could try is doing something similar in init() method of your module. Try putting a die() statement there; if your page still gets rendered, whole module isn't getting executed properly. (You've omitted module settings, but just to make sure: that module is set as "autoload", right?)

See the cheatsheet documentation at http://cheatsheet.processwire.com/ and click the "advanced" button, then click "WireArray/PageArray". All the methods for WireArray are at your disposal for this. Specifically the section on "Setting/Modifying Items" is probably the most helpful. A WireArray only carries one of each item, so if you add/insert/etc. an item that's already present, it'll move it in the array rather than add another copy.

Thanks Soma, I figured it out, but now I'm just a little confused as to why. But I see that now that once the fieldgroup has already been created for the template and assigned to it, I can add another field simply by doing: $t = $templates->get('templateName'); $t->fields->add("fieldName"); $t->fields->save(); Which is much quicker. Is there any way to reorder the fields in a template through the API?

I think you need fieldgroup to add fields first and then add fieldgroup to template. Look at apeisa's shop module for examples. Oops or couple posts above nice guy soma has some example.

I am trying to create a basic setup script that I can use to pre-populate my new ProcessWire installs with the fields and templates I use on the majority of sites I create. To do this I'm bootstrapping PW in a php file I've created in my site's root: <?php // Bootstrap ProcessWire include('./index.php'); // Assign API variables to make things a little easier $fields = wire("fields"); $templates = wire("templates"); $modules = wire("modules"); // Edit existing fields $f = $fields->body; $f->rows = 30; $f->save(); $f = $fields->sidebar; $f->rows = 30; $f->save(); // Redirect template if(!$fields->redirect_page) { $f = new Field(); $f->type = $modules->get("FieldtypePage"); $f->name = 'redirect_page'; $f->label = 'Link to a Page'; $f->inputfield = 'InputfieldPageListSelect'; $f->save(); } if(!$fields->redirect_url) { $f = new Field(); $f->type = $modules->get("FieldtypeURL"); $f->name = 'redirect_url'; $f->label = 'Link to an off-site URL'; $f->noRelative = 1; $f->addRoot = 0; $f->placeholder = 'http://www.website.com/'; $f->save(); } if(!$templates->redirect) { $t = new Template(); $t->name = 'redirect'; $t->fields->add("redirect_page"); $t->fields->add("redirect_url"); $t->save(); } echo 'Default setup is complete!'; Everything seems to work except for the last bit on the bottom where I try and assign the fields to the new "redirect" template. I get the error message "Error: Call to a member function add() on a non-object" I know it's probably something simple, but I can't figure it out! Any ideas? Edit: As usual, I figure out my problem as soon as I post my question on the forums Here is the working code: <?php // Bootstrap ProcessWire include('./index.php'); // Assign API variables to make things a little easier $fields = wire("fields"); $templates = wire("templates"); $modules = wire("modules"); // Edit existing fields $f = $fields->body; $f->rows = 30; $f->save(); $f = $fields->sidebar; $f->rows = 30; $f->save(); // Create redirect template & fields $newTemplateName = 'redirect'; if(!$fields->redirect_page) { $f = new Field(); $f->type = $modules->get("FieldtypePage"); $f->name = 'redirect_page'; $f->label = 'Link to a Page'; $f->inputfield = 'InputfieldPageListSelect'; $f->save(); } if(!$fields->redirect_url) { $f = new Field(); $f->type = $modules->get("FieldtypeURL"); $f->name = 'redirect_url'; $f->label = 'Link to an off-site URL'; $f->noRelative = 1; $f->addRoot = 0; $f->placeholder = 'http://www.website.com/'; $f->save(); } if(!$templates->$newTemplateName) { $fg = new Fieldgroup(); $fg->name = $newTemplateName; $fg->add("title"); $fg->add("redirect_page"); $fg->add("redirect_url"); $fg->save(); $t = new Template(); $t->name = $newTemplateName; $t->fieldgroup = $fg; $t->save(); } echo 'Default setup is complete!'; I am still unclear on what a Fieldgroup is and why I need to create one in order to make any changes to the template's field assignments. It feels like a bit of a clumsy extra step to have to go through because it doesn't seem to have any representation on the PW admin interface. I'm sure there's a good reason for it, though, knowing Ryan.

Barry, using my MarkupSimpleNavigation module you could simply do: $nav = $modules->get("MarkupSimpleNavigation"); echo $nav->render(array( "max_levels" => 2, "show_root" => true, "current_class" => "on" )); Just in case. Edit: Ok the checkbox thing is not possible. But it would be possible using page "hidden" for page you don't want in mainnav. But your code is also nice and flexible if you need it.