Leaderboard

This is a profile I am creating for my own use (though I will make it available once a lot of the kinks are out of it) It is still Work In Progress! http://pwdemo1.stonywebsites.co.uk/ This is basically creating a CMS that would be familiar to users of Joomla and similar where a lot of the information is contained in blocks. Perhaps it should be called "Process-Drumlapress" It is also designed to be very localised where many "front" pages can be created reflecting postcodes in a local area and where a phone number is pushed heavily. It will contain a lot of SEO tools throughout - the PW page naming and URL base is really useful here! This is a Twitter Bootstrap based site, though I admit I need to tweak it a bit to get it working completely smoothly. There is a central site settings page where many bits can be configured: Above and below content global banners can be chosen some common side bar blocks can be chosen Common footer information can be added Site name and top banner can be added Bottom blocks can be selected from a list and their width as a span number added Blocks can enable/disable display block title And other bits and pieces. Each page created can choose whether to select the Global Above or Below banner, no banner or a custom banner text box. Each page can choose from additional sidebar blocks Each page can add an additional sidebar text block Products and Services work on a very simple category system where you create a category page (just for a Select option). You then create a display index for the category where you fill in some intro information and choose a category. That will automatically create a list of all products or services linked to that category. (At some point I would like to customise the admin to put some of these links and create buttons on the top menu, rather than navigating through the pages list). The Gallery used Fancy with a carousel - thanks for the Thumbnail module! The front slide show allows text to be laid over the images. Still to do: Add pagination to things like products and news Create a setting so the fixed footer can be un-fixed or removed Add some additional block customisation like border and background color/image Clean up some of the admin fields and improve labelling Sort out the admin permissions properly (they are a bit drunk at the moment) Clean up some of the template files The overall look of the site is intentionally basic and some of the CSS values (like padding and margins) are default rather than pretty. This is intentional as this meant to be a starting point rather than a plug-and-play profile - in other words, it would need to be customised for the specific client. The intention here is that you can change the structure of the site to a certain extent with just a few files without having to change the back end administration at all (though, some thumbnail sizes would possibly need to be changed. Edit: Forgot to mention a couple of tricks: The bottom blocks use JQuery so they are equal height all the time I have used JQuery to place an optional second image in a news article which counts the number of paragraphs for an insertion point. This means I do not need to use the image button in the TinyMCE. Edit 16/01/2013: Just updated the site a little. It now runs on 2.3 News can be sorted by year and has grown itself Bootstrap styled pagination. There are now potentially three rows of blocks at the foot of the site, which looks a bit mad at the moment, but in reality you would have one row of blocks, the next row perhaps a banner and the last row a normal footer. You can select blocks from a library and choose how many in each row and the span size of each. You can also select background colours for blocks. In the backend the forms are sorted out a lot more into tabs and field sets to make them neater - especially the Site Settings page which has a lot of parameters now. I have used Soma's wonderful Teflon Theme, but added a different, customised JQuery UI theme and changed the menu styles to suit my partner for her site. Other than that, it is as original. http://pwdemo1.stonywebsites.co.uk/admin1ss.png http://pwdemo1.stonywebsites.co.uk/admin2ss.png Next to do: Put some better content in it for demo purposes Create a second site using the same basis, but change the template round a bit.

b.efor after

be for: lissen after: (mabe nsfw) or lissen (sfw)

Hey Everyone, Having just migrated from another CMS, the "before and after" is fresh on my mind each day I work with ProcessWire. My comparison focuses on the experience of building sites before and after ProcessWire, This requires a couple of videos, as opposed to still shots. Here you go: Before ProcessWire Thanks, Matthew EDIT: Something is wrong with the forum embed function...

My thoughts about pw: If you just started with pw, maybe you created your First Page and saw how pw Works and handles data you think uh yummi nice CMS. Well thats fine and correct,pw acts, feels and looks like a CMS. You then dig deeper into the API, you understand how the different fieldtypes are working and you get a good overview. You probably think at this point: could I use pw like a Database? You Set your first page relation, count the arrays and you Play with the Data and you think: WTF!? Is this still a CMS? The longer you use pw, the deeper understanding of the API, you finally realise which great,strong and powerfull toolset Ryan just handed right into your hands. At this particullar point the term CMS would not come to your mind anymore. PW could be used like phpMyAdmin, just create tables,rows and data and work with them, but a Way more easier without even knowig what MySQL really is. Some of you might know my Intranet Application i'm working on, this is all made with pw and some little template php scripting. The next days I will Show a Little preview of an App i'm also working on, and yes everything PW driven.

Before After

hahahah I do have a long established nick name that goes with a plasticine model I made many years ago - Gurubear The model is looking a bit worn and crumbly now and his dreadlocks have fallen off. Actually, I know how he feels. One day I will remake him, or at least try. The trouble is that in some ways he and I look uncomfortably similar!

And a slightly more sensible one

Round 1 in Battle of the Swiss. Soma wins. $soma +1

Preview of RC1. https://youtu.be/PIgUMLZEcIU almost ready, time for bugfixing .

Hi Alex, For the sensitive data, maybe the secured pagefiles introduced with PW 2.3 are an option for you. Here's what ryan posted in the 2.3 announcement thread:

Before After

Update to 0.1.1 information - Changed the method to parseUrl and page rendering into the module. This is to prevent the infamous "double render" issue and also make it work with prependTemplateFile, appendTemplateFile config introduced in latest PW 2.3. (Skyscraper profile anyone). - Added gatewayTemplate option in the module confiuration. For this to work, the gateway template used to create the gateway pages /en/, /de/ etc, must be named to "language_gateway" (default) to make it work, or change the name in the module configuration to fit your template's name. The template file is now just a empty file and you can remove the code. Thanks

We haven't accounted for a site-wide count in the API. But you could still do it fairly easily with an SQL query: $result = $db->query("SELECT COUNT(*) FROM field_comments"); list($numTotal) = $result->fetch_row(); echo "<p>There are $numTotal total comments</p>"; $result = $db->query("SELECT COUNT(*) FROM field_comments WHERE status=0"); list($numPending) = $result->fetch_row(); echo "<p>There are $numPending comments waiting approval</p>"; $yesterday = strtotime("yesterday"); $result = $db->query("SELECT COUNT(*) FROM field_comments WHERE created>=$yesterday"); list($numNew) = $result->fetch_row(); echo "<p>There are $numNew new comments posted since yesterday</p>";

ryan, you are right, the installation has been completed successfully after I upload processwire using another ftp client. Filezilla is used for upload processwire before with problem for some reason that i will firgure it out what i did wrong. Now my processwire site is work and running. Many thanks.

To get all pending comments you'd have to loop through all pages that can have comments and have more than 0 comments. Then find the pending comments (status=0) and count them. $total = 0; foreach($pages->find("comments.count>0") as $p){ $total += $p->comments->find("status=0")->count(); } echo "$total comments pending";

That's exactly what the regex functionality is for. The regex /^nav.two.(.*)/ would remove all related parts. This can be useful (for example) when caching the top navigation per page. Because the markup of the the top navigation is different for each page (because of the current/parent classnames) you could cache it per page with $cache->get("TopNavigation_" . $page->id). Then you could expire all all TopNavigation caches with the /^TopNavigation_(.*)/ regex when needed. It would also allow us to cache things for specific users $cache->get("TopNavigation_" . $user->id) or even $cache->get("TopNavigation_" . $user->id . "_" . $page->id).

I think all you really need to do is make sure people have to log in yo view the content and use an SSL certificate for the intranet for good measure to encrypt the flow of data from the site to the users. Then it can just go on normal hosting. Of they're running im am Active Directory environment on their company network then this could be useful for authentication but it's not straightforward to set up:

In marketing terms it is a subtle emphasis, to be honest, because when you open the box it is not initially easy to see where the framework ends and where the CMS utilisation begins. I suppose, as was said earlier by Soma, the admin as it stands is the CMS, since it has some familiar CMS type labels like "pages" and "Templates" But, if you went and changed the admin and used different terminology, then it would be much less CMS looking. When it comes to introducing the system, I like Matthew's thought process. Being able to say "here is a core system" and then saying "and here is it implemented as a CMS" is a nice way of laying out the philosophy. Because from that point it is easy to say "using the CMS tools, you can build your basic CMS enabled site" but then add "and be able to use the power of the core and the API to extend your site in any which way you wish" So, yes, it can be broken down into two ideas, while being careful to not split the brand, or course. I don't see why using profiles (and extra admin tweaks) you cannot then create ProcessWire Intranet, ProcessWire Blogging, ProcessWire Community and so on to add to ProcessWire CMS. Just give users slightly different starting points for particular projects to help them find their way in.

No problem - if something seems too hard in ProcessWire there's usually an easier way

The reason I like these kind of snippets so much is the freedom they offer. If you want to show the dev page to anyone that is logged in, change the conditional to: if($user->name='guest') If you want to give a special url like domain.com/?version=dev change it to: if($input->get->version!='dev') with the url version you can also make all the links work wth sessions like this: if($input->get->version!='dev' OR $session->version != 'dev') and inside the else: $session->version = 'dev';

ProcessWire is a content management framework, which is still a "framework", but more focused on a particular thing. Whereas the framework scope of CakePHP, Laraval, CodeIgniter, etc., is more broad and cover more territory. ProcessWire isn't meant as a replacement for one of those frameworks, but I think there are probably many instances where its focus might make it preferable. And an equal number of instances where the opposite is true as well. There's also something to be said for bringing the two together in some instances. Another big area of difference is that traditional frameworks enforce a particular approach to build on top of, whereas ProcessWire aims to be a lot more transparent, like jQuery. Frameworks set you up with a place to put your models, views and controllers, whereas ProcessWire puts in you in a plain PHP file (template file) that is given a location context ($page) and lets you take over from there. We think MVC is a good approach to take with ProcessWire template files, but don't enforce anything, as it's up to the developer. For better or worse, the possibilities are wide open in the same way they are with a PHP file on its own… though with a full CMF API at your disposal.

This module -- actually pair of modules -- keeps track of login attempts to your site, both successful and unsuccessful. The point of this is to give you better understanding about users' activity and environments they use and favor; browsers, browser features such as Flash and Javascript, devices, screen and window sizes. Based on my experience it could also prove out to be rather helpful when debugging error reports by users. Since most of this module was written during one weekend (short time for someone like me who way too often gets stuck trying to make meaningless little details "perfect") I'm very much aware that there are still quirks and even missing features I'd consider "very important." If anyone finds this module interesting enough to give it a try, any and all ideas, comments and problem reports would be very much appreciated! http://modules.proce...-login-history/ https://github.com/t...essLoginHistory How does it work? Process Login History itself is pretty simple and focuses on showing logged data. Probably only thing worth mentioning is that user agent strings are saved to database in their original format and converted here run-time into human readable values. Currently this is done with a private function that tries to identify most common platforms, device types and browsers, but I've planned to add support to either phpbrowscap and/or PHP's native get_browser(). Login tracking is achieved by hooking after Session::login and ProcessLogin::buildLoginForm, though latter is only used to add some extra fields to login form in order to collect slightly more information about user agent. Hooks are added by separate autoload module Process Login History Hooks to avoid loading unnecessary stuff all the time. I'm not sure if this naming convention is correct though.. it's not a process module but still very much related to one -- ideas, anyone? How do you use it? When installed this module adds new database table (process_login_history) for storing data and new page called Login History under Admin > Setup. What this page should look after couple of logins / login attempts is visible in the screenshot below. For more information and some ideas I've planned for later revisions, see README.md.

ProcessWire Concatenate Fieldtype Fieldtype that concatenates the values from one or more other fields at runtime. The value can contain additional formatting and/or words as needed, which you define in your Concat field settings. Example Problem: Your system has a first_name and last_name field, and you want to have a separate full_name field composed of first_name and last_name, without redundancy. Solution: You would create a new Concat field, click the details tab, and enter "first_name last_name" (the fields you want to concatenate) in the settings. Other Potential Uses Having a field that combines the value of two or more others, without the redundancy of separately stored data. Defining a custom “label field” for select boxes, like those used with the Page field. Defining a custom label for your Page List that includes your own formatting. Defining an alternate variation of a text field that uses a different text formatter. Considerations The value for this fieldtype is generated at runtime and thus no data is stored in the database. This is good because there is no duplication. However, it also means that you cannot directly query a Concat field from $pages->find(), for example. If you happen to change the name of a field being used in a Concat field, you will have to update the name in your Concat field settings as well. By design, Concat fields do not inherit the text formatters of the fields they concatenate. You define these separately with the Concat field. Because this is a runtime-generated field, there is no Inputfield associated with it. How to Install Install the module by placing FieldtypeConcat.module in /site/modules/. Check for new modules on the Modules screen in the ProcessWire admin. Click Install for the Concat Fieldtype. How to Create a Concat Field Under Setup and Fields create a new field using type Concat. After entering the new field name and label, click Save. Click the Details tab and enter one or more field names. Separate them with whatever spacing and punctuation is appropriate. Optionally choose one or more Text Formatters. If you are not sure which, “HTML Entity Encoder” is a good default to use. Save. Add your new field to one or more Templates. How to access the value of a Concat field This is no different than accessing the value of any other field. If your Concat field has the name “full_name” then you would output its value like this: echo $page->full_name; Download PW Modules Site: http://modules.proce...eldtype-concat/ GitHub: https://github.com/r...FieldtypeConcat

A very simple tip, but that might be useful for someone that didn't think of it... This is what I usually do if I want to change something on a live site. if($user->name!='diogo'){ // live code }else{ // my new code } Like this I'm the only one that sees the changes. More examples: // test new javascript. do the same for styles <?php if ($user->name!='diogo'){?> <script src="<?php echo $config->urls->templates?>scripts/main.js"></script> <?php }else{?> <script src="<?php echo $config->urls->templates?>scripts/main-dev.js"></script> <?php }?> // test new head file if($user->name!='diogo'){ include(head.inc); }else{ include(head-dev.inc): } and so on... edit: corrected the first block by Nik's suggestion

so meta

For the usage you're talking about I agree with Antti. Using the $db class this would be pretty straightforward as well as you're not talking about a complicated table either I think this will come up in lots of scenarios where the number of invisible pages far outstrips the number of visitor-facing pages by a huge percentage (and it's not due to form entries) - that's the time to seriously consider whether to use an external table.

Ok. (didn't understand much, I just spilled my coffee.. heh heh). Can you provide example usage which would be most helpful for you. Pseudo-code or js. Something like along these lines I assume: for(var i=0, l=files.length; i<l; i++) { var urlToFile = HTML5Uploader.uploadFile(files[i]); } Where HTML5Uploader would be provided by ProcessWire? I assume you would need a way to poll the upload progress also?

haha, thanks Willy! I have new favorite artist and definitely inspiration for my personal endeavor in music.

We currently published a site (www.martat.fi) that has about 100 000 pages. This is mostly because we use my Discussions module, which has each discussion reply as own page. We did hit on one performance problem, which was quickly fixed by Ryan (https://github.com/r...71f76dba734c955). Usual $pages->find() selectors were fast as always, but when there were $page->rootParent->find() with multiple fields using *= selectoror it slowed down very badly. I don't understand the actual reason, since the slow query should actually be really fast (explain says just simple and simple - so maybe it is bug or something very strange behavior on mysql - no clue). After the fix Ryan provided things are rolling very smoothly. I am pretty confident that PW will scale quite easily for 1 000 000 pages - but that scale might limit the way you can use the API. Because of that I wouldn't probably store that kind of data you have (hits counter) in pages, but in separate database table. Millions of rows are nothing for MySQL, especially if you query data from single table and with simple index (like page_id). But in your scenario I don't see that much benefit of having them as pages and therefore would probably keep them out of there. You don't probably need more than few simple sql queries anyway. Just my 2 cents and I am most definitely not a DB schema designer... There are people who do know this kind of stuff much better (Ryan and Nik for example).

Thank you very much for this code Soma, I imagined it would have something to do with finding the pages, then getting the fields, but I had no idea about the 'status' and how to find the pending ones. Thanks again. Ryan, thank you so much... I would've never been able to sort out this part and surprisingly, I can make sense of it. Thanks for the query snippets and for ProcessWire. I'll test and post back to tell you how it worked.

I don't think there's any need for selectors to contain question marks here. While it's feasible someone may use one for performing an exact search on something like "title=why eat pastured eggs?", I really don't think that's a likely selector need in this context. I think we can safely not worry about question marks in selectors here. For separating selector from the name/regex, I was initially thinking just an explode('?', $line); but that won't work since regex's often contain question marks. But something like this should work: $pos = strpos($line, '?'); $selector = substr($line, 0, $pos); $line = trim(substr($line, $pos+1)); // reduce line to the part after the ? if(substr($line, 0, 1) == '/') { // if it starts with a slash (delimiter) we assume regex $regex = $name; $name = ''; } else { // otherwise we assume cache name $regex = ''; $name = $line; } The test to determine whether it's a regex or a name would just be to see if the first character us a slash "/" (the most common PCRE delimiter). So the way for the user to say they want something to be a regex would be the same way they'd do it elsewhere, which is to start and end it with a delimiter. Though in this case, we'd limit them to "/" as the delimiter, which seems like a perfectly fine limitation here to me.

Joss, please rename your account to Papabear. Everytime you Post, the forums becomes such a nice athmosphere of a dark forest with a tiny warming fire place, the little ones sitting around the fire, listning to the warm and comfortable voice of Papabear. I really enjoy your posts, well you allready know what I´m thinking about you

If you uncheck the checkbox separating the address and the lat/lng boxes, you can adjust the coordinates separately from the address, or vice versa.

The two different Swiss Army Knives of coding, eh?

I use this excellent golden module by apeisa master: http://modules.processwire.com/modules/process-redirects/

Well the rule of thumb is that if you're doing anything consisting of simple manipulation of tree (like getting X children of a parent Y), it should not be more than ten lines, otherwise you're solving the problem the wrong way. And yes, there are multiple things people usually go at the wrong way with PW. and yes, I just pulled the number ten out of my… anyway. Note: and by wrong way, I mean "doing it the hard way you'd do it in other CMS"

See a lot of changes already in 2.3. I'll love it. So far, I don't see issues. Sites i'm building now start with the 2.3 branche, cause I have lots of trust in all the work you've done. And I thank Soma, Nik, Teppo and all the others who contribute to make such a great product. Hope there's wil be a list of all changes there are when 2.3 is final.

See? It's just that intuitive

Let's try with a couple of pointers and such first. Take a look at site/modules/HelloWorld.module (included with default installation) for an example of an autoload module and hooking methods - example 1 is really close to what you need. As Ryan said, you're aiming for Pages::saveReady with your hook. See http://wiki.processw...Module_Creation for more details on creating modules. This information should be enough to make an autoload module of your own, and have some method there run every time a page is saved. Of course you also need a field for the total price. Create a new field and set its visibility to hidden. Save the field once first to see this option in input tab. Then just add it to your product template. Getting further, you'd probably want to do your magic only for pages with the product template. And sanitize the price and vat before any calculations. You can set fields for the page in your hook like this (and they get saved magically): $page->nameOfYourField = "this is the value"; Now just go and try to create the module. . . . And now that you've tried and got it actually working (right? ), you can see an example of a working module here: https://gist.github.com/4462130. This calculates the area of a box with given width and height on a page with certain template - sounds a bit familiar, doesn't it?

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.

This is great, thanks guys. Just thought i would add Git download link: http://git-scm.com/ EDIT: Using Git is a revelation! Love It

I'm using MAMP here, and I don't use vhosts... I just use subdirectories. So when I want to install a new PW, I do this: 1. Make a new database using MAMP's PhpMyAdmin. 2. Open a terminal window and go to htdocs dir: cd /Applications/MAMP/htdocs 3. Make a directory for your new site: mkdir new-site 4. git clone the latest PW into there: git clone git://github.com/ryancramerdesign/ProcessWire.git new-site 5. Load http://localhost:8888/new-site/ in your browser to complete the installation.

I have just made a little update to 101. The limit was hardcoded to 100. Since there's more than 100 now and some get filtered out, it wasn't showing all modules anymore. Added config option for apikey and limit and set limit to 200 by default. You should be able to update Modules Manager by Modules Manager.

Actually, you can control the parent-child relationship, restricting children (or parents) to a certain type (or types) of template. If you edit a template you'll see a tab called "Family" (in the English version) and that's where you can setup restrictions on the relationships.

Wordpress and Contao are examples for what can happen to a CMS (or blog engine), if it gets too many modules or plugins – every tried finding a good contact form or lightbox plugin for WP? Good luck with that. It'll cost you days. Modules are great for non-expert users (which is why a blog system like WP is more likely to have a lot of them than a "real" CMS), and I admit that there are things I couldn't do in PW in a reasonable amount of time without modules. But in case of simple stuff like a lightboxed gallery, I prefer to have a CMS emit the markup I want and use the lightbox script I want instead of using a module which never seems to emit the code you'd want it to. I'm not sure this "module proliferation" is something you can control beyond a certain point of growth of a CMS or blog system. But as long as it's possible, "one module/plugin per purpose" is something a CMS can really benefit from. I would like to see PW's users adapt such a philosophy – if you intend to write a module, first take a look at the existing modules and see if you can extend one instead of adding (maybe duplicated) functionality via a new plugin.

Ah yes, that's what I needed! It turns out $image->width() and $image->height() are actually rendering functions, so I was able to just do this: $mainimage = $page->image; if($mainimage->width >= $mainimage->height) { echo '<img src="' . $page->image->width(768)->url . '" alt="' . $page->title . '" id="displayimg" />'; } else { echo '<img src="' . $page->image->height(575)->url . '" alt="' . $page->title . '" id="displayimg" />'; };

There is no built-in support for pagination of comments at present. Though it's certainly possible to paginate them, but not without doing the pagination yourself. The $page->comments value is a CommentsArray, which is a WireArray. You can see all the WireArray methods here: http://processwire.com/api/arrays/ So your comments pagination would probably be something like this: <?php $limit = 10; $start = ($input->pageNum - 1) * $limit; $comments = $page->comments->slice($start, $limit); echo $comments->render(); if($input->pageNum > 1) { echo "<a href='./page" . ($input->pageNum - 1) . "'>Previous Page</a> "; } if($start + $limit < count($page->comments)) { echo "<a href='./page" . ($input->pageNum + 1) . "'>Next Page</a> "; } The above is an approximation written in the browser, so may not be a working example, but should be close.