ryan

This topic has been superseded by the roadmap page. Please see that page for the latest items on the list. - Pete These are a few of the items on the short-term to-do list: Page preview before publish (i.e. page drafts) Autocomplete Inputfield for use with Page Fieldtypes Continue posting new documentation to processwire.com JSON page-selection web services for use by admin modules Customizable page "channel" view, in addition to the sitemap view currently in ProcessWire (Admin > Pages). This will enable browsing, viewing, editing of pages outside their parent/child structure. For instance, this view can match specific properties like having the same template, modified within the last day, or anything that you can match with a selector. Various improvements to the FieldtypeComments module(s), including documentation! Simplification of the roles/permissions system. Specifically making roles assigned to templates rather than pages as the default option, and giving permissions a more clear presentation and selected defaults. Google Maps Fieldtype module Conversion of some core code into plugin modules Some other items on the longer-term to-do list include: Tagscript parser that enables you to access most Page/Pages-related API capabilities via a tagscript syntax. Some ExpressionEngine users convinced me this is worthwhile, despite my preference for a pure-PHP based API. This will be developed as a module for those that want it, and it's already in the early stages. It is being patterned off of both ProcessWire 1.x and ExpressionEngine 2.x syntax. Plugin modules will also be able to define new tags. Built-in user form processing with admin tools to list/search/read/update/delete submissions, as well as the ability to import submissions directly to new or existing pages (with direct field mapping). Localization support for non-English languages. Strong versioning system for pages. This would also include multi-level undo and a page version comparison tool. Workflow functions whereby Templates can have custom statuses assigned which affect the state of the pages using them. Access to the custom statuses would be definable by Role (or User) so that any number of workflow possibilities could be supported. These lists are not complete, and I'll be adding to them regularly. What else do you think should be here?

Here's a function that would return all the children in a month. Replace the last param ($field) with the name of the date field you want it to look at, otherwise it defaults to the 'modified' field, which probably isn't what you want (but was what I used to test the function). <?php /** * Return all of the page's children where $field falls in $month and $year. * * @param Page $page The page that has the children we are finding. * @param int $month Month you want to match. * @param int $year Year you want to match. * @param string Name of the date field to check. * @return PageArray All the matching children. * */ function childrenInMonth($page, $month, $year, $field = 'modified') { $startTime = strtotime("$month/1/$year"); $endTime = strtotime("next month", $startTime); return $page->children("$field>=$startTime, $field<$endTime, sort=$field"); } Below is an example of how you might use this function in your template. This code shows examples for both URL segments and GET vars. If you wanted to use URL segments, you would need to go in to the Admin CP, click on Setup > Templates > Your Template > Advanced > URL Segments > Set it to an asterisk "*". That tells it to allow any URL segments to pages using that template. And here is code that first checks for a URL segment, then GET vars, and defaults to current month/year if none is provided. <?php if($input->urlSegment1 && preg_match('/^(\d{4})-(\d{1,2})$/', $input->urlSegment1, $matches)) { // A URL segment matched in the format of year-month, i.e. /news/2010-12 $month = $matches[2]; $year = $matches[1]; } else if($input->get->month && $input->get->year) { // GET vars were provided with the year and month $month = (int) $input->get->month; $year = (int) $input->get->year; } else { // No year/month provided, so display items from current month $month = date('m'); $year = date('Y'); } // display a headline with selected month/year echo "<h2>" . date('F Y', strtotime("$year-$month")) . "</h2>"; // find the matching pages $children = childrenInMonth($page, $month, $year); // output a list of the matching pages echo "<ul>"; foreach($children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } echo "</ul>";

To get things started in this forum, I'm going to post some of the Q&A from emails that people have sent me. That's a good question. For most cases, I would not try to create a different page structure for years/months because that's more work and it invites the possibility that the links will change over time as you move pages to archive them. After using different strategies over a few years, I think it's better to have a single container page under which all news items will be placed, permanently. Then set that container page's default sort to be by date, so that newer items always appear first. From there, the news page should focus on the newest items, and provide links to past news whether by pagination, month/year links, etc. In this respect, you can treat a page in PW2 in the same manner that you would treat a channel in EE2. There is no problem with scalability… PW2 will run just as well with 10k+ subpages as it would with 10. When following that suggestion, these are the only scalability considerations: 1. You may occasionally have to consider the namespace with the URL "name" (aka "tag" in PW1) field. For example, if you have two news stories with substantially similar headlines, you may have very similar URL name fields. But ProcessWire will enforce that namespace, so it's not going to let you create two pages with the same name under the same parent. What that means is it'll make you modify the page's URL name to be unique, if for some reason it's not. I'm talking strictly about URL names, not headlines or anything like that. 2. When dealing with news stories (or any place that may have a large scale of pages), you want to pay attention to how many pages you load in your template API code. If you are dealing with 10k news stories, and load them all, that will slow things down for sure. So the following applies: Avoid API calls like this: 1. $page->children 2. count($page->children) Instead, use API calls like this: 1. $page->children("limit=10"); 2. $page->numChildren $page->numChildren is something that ProcessWire generates for every page automatically, so there is no overhead in calling that, like there is in count($page->children). But if working at a smaller scale, it doesn't really matter what method you use. The most important thing to remember is just to use "limit" in your selector when potentially dealing with a lot of pages. That applies anywhere, especially when making things like search engines. So when you want to support unlimited scalability, these are the functions where you want to place limits: $page->children(...) $page->siblings(...) $page->find(...) $pages->find(...) The other reason someone might like archiving to year/month is because it makes it easier to link to since you could just link to /news/2010/04/ for instance. But it would be a fairly simple matter in PW2 to make your template look for "month" and "year" get vars, or a URL segment, and produce results based on those… See the other topic in this forum for one way that you might do that.

Have a question? Click the "new topic" link to the above right of this message.

To stay up to date with the project I recommend doing the following: 1. Subscribe to the e-mail list by entering your email in the sidebar box at http://processwire.com 2. Follow me on Twitter at http://twitter.com/rc_d - This is where I post general updates about ProcessWire. 3. Follow ProcessWire on Twitter at http://twitter.com/processwire - This is where all commits to the ProcessWire source code are "tweeted" from GitHub.

A couple people have mentioned that they installed ProcessWire, logged into the admin, logged out, and couldn't find where to login again. The default login URL to ProcessWire is: yoursite.com/processwire/ You can also change the login URL by editing the admin page (Pages > Admin) click on the "settings" tab and change the URL name to something else. Just don't forget what you name it otherwise neither you nor I will be able to figure out what the admin login URL is.