Leaderboard

This is the only way I know to create different sizes when uploading images: <?php class ImageCreateThumbs extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'ImageCreateThumbs', 'version' => 100, 'summary' => '', 'href' => '', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHookAfter('InputfieldFile::fileAdded', $this, 'sizeImage'); } public function sizeImage($event) { $inputfield = $event->object; if($inputfield->name != 'images') return; // we assume images field $image = $event->argumentsByName("pagefile"); $image->size(120,120); $image->size(1000,0); } } https://gist.github.com/5685631 What I don't know is if it really makes a difference (I guess), and if using drag and drop ajax upload and old school upload would process image one by one. My suggestion is to also upload image already in 1000x* pixels because if they upload 3000+ px images it will just takes a lot longer.

@horst Yeah! Currently, when calling $page->next Pw calls $page->next() which then loads all siblings under the parent of $page. This is different from calling $page->next('selector') or $page->next($pageArray) - because you always want the next child in the tree (sort + 1). Therefore, I think that ->next (and also ->next()) could be optimized. @Soma $page->next($pageArray) won't execute my db query as this is also a direct call to the method I'm sure there are other side-effects I'm missing and there's a good reason for the current implementation. But interesting disscusion anyway, sorry for messing up this thread!

I think you first have to check where you are in the tree. If you have different templates for the pages p and subpages this is easy, but if you have not, you have to check for parents and childrens. Something like: if( count($page->children) > 0 ) { $url = $page->children->first()->url; } this is true if you are on p1 or p2, then you want to go to the first child-page. If the current page has no children, you want to go to the next page, but you also have to check if there is a next page or if you are allready on the last one: if( 0 != $page->next->id ) { $url = $page->next->url; } else { $url = $page->parents->next->url; } If it's the last one you want go to the next sibling of your current parent. But you also have to check if your current parent is the last one and there is no next one too: if( 0 != $page->next->id ) { $url = $page->next->url; } elseif( 0 != $page->parents->next->id ) { $url = $page->parents->next->url; } else { // do something when on last page, hmm, - yeah ok: $url = $page->parents->first()->url; } So, this is written in the browser and not tested, but something like this will work.

hi all, new PW site launch: http://www.ohmspeaker.com/ some of the modules that were helpful or essential for this: cropimage formbuilder fredi importcsv minify piwik analytics procache batcher redirects version control template decorator modules manager page link abstractor sitemap xml admin custom pages markup simple navigation (for the sitemap) forum topics related to this site dev: Legacy Site URL redirects: http://processwire.com/talk/topic/3641-redirect-legacy-url-to-new-pw-page/ Clean up spelling: http://processwire.com/talk/topic/3519-use-api-to-spellcheck-whole-siteclean-up-spacing/ hashes in URLs on change selected product http://processwire.com/talk/topic/3496-help-with-url-param-change/ FormBuilder http://processwire.com/talk/topic/2904-how-to-redirect-by-id/ http://processwire.com/talk/topic/2821-3rd-party-send-conditionally/ http://processwire.com/talk/topic/2820-use-session-to-remember-form-selections/ Custom Menus http://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/ other notes: The skyscraper profile provided the example for how to get started with the advanced product search, a.k.a. the speaker finder. The standard search has been extended to show results in different categories. there is some use of Soma's word limiter for the news teaser text, and for making meta descriptions out of body fields, from this topic: http://processwire.com/talk/topic/3429-how-to-set-text-linecharacter-limits-in-templates/ the design is built on twitter bootstrap framework Fredi proved to be totally essential for the client, in being able to rapidly edit things without having to find things in the admin. This site is going to replace an existing site on a different domain (ohmspeakers.com). At some point we weren't sure if/how we would be able to handle the shopping cart element, and then found foxycart, which proved to be the best choice, very flexible, and easy to implement for this type of site. FC is hands down the simplest and easiest way (imho) we could achieve things like the legacy product pages, where there are various parts and upgrades displayed on 1 page. this version is sort of a "v1", and will be expanded/improved a lot for a v2, which would happen in about 4 months.. BTW - these speakers are really good; i now own 3 pairs ... they look great and do sound totally amazing...! -marc

Hhm, what's exactly the problem? Have you tried the suggestions? What is the exact URL of your targetpage? --- Do you know the exact URL? [ ] YES [ ] NO If you have answered the above question with yes, your solution is as follows: - please type the known URL followed by a # and the anchorname exactly into the href of your link

You may also try to set_time_limit(30) in your foreach-loop. foreach ($page->images as $image) { set_time_limit(30); $output .= '<a href="' . $image->width(1000)->url . '" title="' . $image->description . '"> ... </a>'; } If your site are not running in safe_mode and your hostservice hasn't set this function on a blacklist, every image has a max of 30 seconds to get processed. BUT BETTER: the client resizes images before upload, as Diogo said!

One way is to tell the client to reduce the images size. I think we shouldn't try to solve everything, and put a minimum of responsability on those that edit the website. Just indicate them an easy tool to install on their computer http://www.addictivetips.com/windows-tips/image-resizer-powertoy-clone-for-windows-7vista/

No problem, I just confused by terminology I guess. This should get you there: $language->getUnformatted('title')->getLanguagevalue($language->id)

Minor glitch (if you can even call it that): your 404 page is a bit unhelpful. Had an old link to /de/, which ended up serving a blank page and confusing the heck out of poor little me. Site itself is just fabulous

@Soma As far as I understand, he has this setup already but wants to output always the same titles in every language. Meaning: Leaving the titles translated BUT not use the translated title in the language switcher ;-) Try this: foreach($languages as $language) { if(!$page->viewable($language)) continue; // check if page not published for this language $url = wire('page')->localUrl($language); $title = $language->title->getLanguageValue($language); echo "<li$class><a href='$url'>$title</a></li>"; }

$s is like one item which belongs to the group $skyscrapers. I prefer to name them $skyscraper so you have: foreach($skyscrapers as $skyscraper) { echo "<li><a href='{$skyscraper->url}'>{$skyscraper->title}</a></li>"; } See more about a foreach in the manual. If you want to limit the number of results you can do this: $skyscrapers = $pages->find("template=skyscraper, limit=10"); There are some great tutorials in this forum or on the wiki. I would recommend to do them all. I'm coming from TXP too and and while I still like it very much, ProcessWire is second to none when it comes to structuring data.

Minor addition to above: $page->parent->first()->url should be $page->parents->first()->url.. or just $page->parent->url, which already returns first parent. Also: you could use $page->child instead of $page->children->first() to get first child Other than that, this seems to work properly. Now, I'm sorry for taking this thread a bit off track, but there's something strange going on here I'd like to point out: I was actually going to suggest a very similar approach, but after testing it ran into a problem that kept crashing whole Apache. Seems to be somehow tied to recursive function in sitemap template of default site profile and also happens with solution provided above. Once I comment out sitemapListPage() call in template file everything works properly, with it in place Apache keeps dying on me. Just for reference, code I was going with for the original problem was this: $next = ($page->numChildren) ? $page->child : $page->next; if ($next instanceof NullPage) $next = $page->parent->next; echo ($next instanceof NullPage) ? "This is the end" : "<a href='{$next->url}'>{$next->url}</a>"; After using either my approach or the one @horst suggested above, this seems to cause massive headache to Apache: function sitemapListPage($page) { echo "<li><a href='{$page->url}'>{$page->title}</a> "; if($page->numChildren) { echo "<ul>"; foreach($page->children as $child) sitemapListPage($child); echo "</ul>"; } echo "</li>"; } sitemapListPage($pages->get("/")); What am I missing here?

Can you tell a little more what the field settings are set to? Ok it's a litte special with this field because it also supports "range" setting (min,max). So it has two values actually and uses outputformatting because is an object behind the scenes. To set the value in template code you need to turn it off and use $page->of(false); $page->range->set("min", 3); $page->of(true); or $page->of(false); $page->range->min = 3; $page->of(true);

You've been using MODX but now you've found ProcessWire. It’s totally amazed you and you can’t wait to get started. But…you are wondering where everything is. If this is you, read on… This guide is primarily aimed at those who are coming in from MODX and wish to know how to accomplish “MODX things” the “ProcessWire (PW) way”. This is not meant to be a full blown PW tutorial. It will focus on some key MODX concepts/tasks and how to accomplish those in PW. It will cover, whenever possible, both versions of MODX - Evolution and Revolution. The guide assumes that you’ve at least logged into a PW site and/or viewed a demo. The Table of Contents mostly reflects MODX terminology. Table of Contents 1. Manager 2. File System 3. Resources 4. Templates 5. Template Variables (TVs) 6. Template Files 7. Snippets 8. Modules 9. Plugins 10. Chunks 11. Miscellaneous 12. Examples - the PW way… a. Template Variables b. Snippets c. Modules d. Plugins e. Chunks 1. Manager In PW, the “manager” is referred to as the “Admin”. The default location of the Admin is www.yoursite.com/processwire. As of PW 2.3, you can rename the Admin to anything you wish during install. Just be careful to remember the name you use or you will be locked out! (If that happens, there are ways to get around it though). Logging into Admin, you will notice a tree just like in MODX. The Admin runs on jQuery UI and as you’ve seen, it is insanely fast! Don’t be fooled by its simple facade. PW is a really powerful CMS, highly extensible and very easy to use. Customising the PW admin is very easy. There are a number of custom themes available. It is also trivial to make yours. Custom Admin themes go into the folder site/templates-admin/. You can have only one theme at a time. On a related matter, if you wish to create a custom Admin page, it is easy to do so. See this thread for more info. 2. File System After installing PW, you will see two main folders; “site” and “wire” in your file system. Site is where all things related to your site reside. This is your playground and will survive an upgrade. Wire houses the Core. You will never have to go into that folder. 3. Resources In MODX, Resources can be many things (documents, etc.). There is no such term in PW. However, the most important “resources” you need to know about in PW are page and pages. Pages are a very powerful concept in PW. Page can refer to your website’s frontend pages, i.e. what can be viewable by your website users. I say can be for a reason. There are many uses for Pages in PW. This can be confusing to newbies but once you get the concept, you will appreciate the power of the system. Just because something is a Page does not mean it has to be viewable. It can have other uses such as a container that holds data for use by other Pages - in this case the Pages do not have to be displayed on the frontend. In fact, everything you see on the PW tree is a Page. That’s right; even the Admin and its components (Users, Roles, etc.) are all Pages! Still confused by Pages? Have a read here. Pages reside in the PW tree - you may have noticed . You can drag and drop pages to move them around. If drag and drop doesn’t work you probably have MySQL 5.0.5.1 installed. Upgrade your MySQL and you are sorted. The root of your site is the uppermost Page in the tree. In the default PW install this is called Home. You can change the name to something else. The default PW install comes with a number of Pages pre-installed. Try editing a Page. All those Fields you see on that Page when under the “CONTENT” tab? They are not default Fields. They are all Custom Fields! Yes, not even the Title! The only required Field for a Page is “name”. You find this under the “SETTINGS” tab on the page edit screen. More about Fields below… Other related stuff: Menuindex: As an aside, if outputting something like a menu, unless you state otherwise, it will reflect the tree hierarchy. Show in Menu: This functionality is covered by the Page status, whether hidden or not. Hidden pages do not get output on menus (more about menus later) unless explicitly stated so using PW API selectors (see below). Menu Title: No such term in PW. You can name your menu items what you wish to name them. Very important: All Pages must be assigned a Template. 4. Templates In PW, Templates mean something slightly different compared to MODX and many other CMS. MODX describes templates as: That is not entirely true of PW Templates. In PW, the term Template is used in the sense of the English definition of the term: PW Templates serve as a pattern for the foundation of your Pages. By foundation, I do not mean the HTML or CSS. Rather, the Template servers as blueprint for your Pages. What is available to the Template is available to the Page that uses it. Templates establish a pattern for the Pages by the inclusion of Fields to the Template. A Template can have as many or as few Fields as you wish. You can create as many or as few Templates as you wish. You can easily change the Template a Page uses when editing the Page. See under SETTINGS. Note that if you have Fields on that Page that are not in the Template you are switching to, those Page Fields will be lost! PW will warn you about this when switching Templates though. OK, so how do you show “Resources to the world”? That will be the work of Template Files which we’ll look at in section 6. 5. Template Variables A powerful feature of MODX is Template Variables (TVs). If you loved MODX TVs you will absolutely adore the PW equivalent. In PW, TVs are known as Fields. You can define your own Custom Fields. In fact, you will need to create your own in most cases. This is because PW does not have any required Field except for “name”. It is perfectly reasonable to have a Page with only the name Field! Many people do add at least a Title Field for such Pages. In the default PW install, the reason you see the Title Field in all Templates is because it has been set as a “Global” Field under the ADVANCED settings of the Field (edit the Field to see this setting). There are many types of Fields to hold all sorts of data - images, texts, urls, passwords, reference to Pages, etc. You can call your Fields anything you wish. You can call the Field for your main content “body”, or “stuff”, or “content” or whatever you wish as long as you follow the naming convention, i.e. “[a-z], numbers [0-9], or underscores (no dashes or spaces)”. Fields are reusable across different Templates. The order in which they appear on your Page follows the order in which they are arranged on your Template. However, it is important to note that: The order in which Fields appear on your page and/or the inclusion of a Field on your Page does not mean that: The Field will be output on the Frontend. The inclusion of a Field on a Page does not automatically mean it will be output; PW does not make that decision for you. It only makes the Field available to you to use as you require. You can output all or none or few of the Fields on your Page. The order in which Fields appear on a Page does not mean the same order will be reflected when you output the Page. You make that decision. Also note that you are able to arrange Fields side-by-side on your Page (via settings on the Page’s Template) to mimic your site’s layout or for other visual/ease-of-use purposes as you edit the Page in the Admin. You can also give each Field a label and a description. These will appear above each Field when editing a Page. In most cases, the content of Fields will be saved directly to the database. In the case of file related Fields, the path to the file will be stored in the database. There are no direct equivalents of MODX TVs “@Bindings” (data sources). These are inherently built into the different types of Fields. Note that you cannot run PHP code within Fields (so no @Eval). This is by design. Fields are a very powerful and much loved concept in PW. Just Google "custom fields cms" and you’ll see what comes up tops. 6. Template Files So far, we've seen that you create Fields, add them to a Template you've created and edit a Page using that Template to input your content into that Page’s Fields. So far so good but how do you output the content to the world? You do this via Template Files. Template Files live in /site/templates/. You have to create your own Template Files. In MODX, a Template will have both system fields, e.g. body, title, etc. and custom fields (TVs). Rendering a Template is achieved by adding MODX tags to your Template. In PW, in order for the content of your Page to be seen by the world, its Template must have a Template File (or there must be some other Template File associated with a different Template that is dynamically pulling and outputting elsewhere the content of a Page whose Template does not have a Template File). This does not mean that all content within a Page will be automatically output by the Template File. No; in the Template File you can choose to render all or some Fields present in the Pages using that Template or none at all! You tell the Template about the associated Template File when you create/edit the Template. PW assumes that there is a Template File with the same name as the Template in /site/templates/ and will tell you if it does not find one. However, you have two other choices. You can either enter an alternative name for your Template File or tell PW you do not wish to have a Template File for that Template. This means that a Template does not require a Template File. Obviously, in such a case, you will not be able to directly output the content of the Pages using that Template. In some cases, that is exactly what you want . As you get to know more about the system, you will find out how powerful and flexible the PW Template system can be. For instance, you can use your Template as a controller. That’s beyond this guide but feel free to search the forums for more info. Template Files are typically PHP files with logic to dynamically output your content. In most cases, Template Files are HTML with PHP tags inserted to output your content. The PHP in the Template File will in most cases be PW API. Hence, you will see things like $page and $pages in Template Files. The former always refers to the current Page and the latter to any other Pages in the system. These are very powerful variables in PW and give you access to ALL information about ALL pages including their Fields and whether those are empty or not, etc. See below for more info about these variables and have a look the docs too. Note that Templates do not care about what’s in your Template Files. In fact, they won’t even check. All they want is for you to tell them if and how you wish your Pages' contents to be rendered. Your Template Files can even contain pure HTML (although that won’t be dynamic!)! Your Template Files can have references to other things related (or not related!) to the Page using that Template File. For instance, within your Template File, you can pull in the 10 latest “posts” from your Blog or the Children Pages of that Page. There are just too many possibilities to list them all here. Don’t let the PHP in Template Files scare you if you are no coder. I am no coder but I am able to use PW. You will only need to know at least some very basic PHP to use PW. The most important are: echo; foreach; and if… Anything else is a bonus in most cases. In addition, you will need to know how to use the two most important PW variables - $page and $pages. With these two, most of what you would have done in vanilla PHP is covered. They are easy to use and to understand and very much follow the jQuery concept. Check out the docs to learn more. 7. Snippets In MODX, Snippets are the method by which MODX allows you to run dynamic PHP code in any of your pages. In PW, the term Snippets does not exist. What!?! Not to worry; in PW MODX-like Snippet functionality can be achieved in two ways: Template Files: Most PW Template Files are essentially dynamic PHP code. That’s Snippets for you right there. PW Modules: PW Modules do what MODX Snippets do and more (see below). It’s just an issue of terminology. For instance, the popular MODX Snippet WayFinder has a Module counterpart in PW. This is the Module Markup Simple Navigation. However, you do not need to use the Module to create a menu in PW. You can do the same thing using PHP in your Template File. See the default PW install for a simple example. Check out section 12 of this guide for example “popular-MODX-Snippets-to-PW-how-tos”. 8. Modules MODX Evolution defines Modules as “a program that can only be executed from within the manager.” There are PW Modules that fit this definition, for instance, the Module Batcher which is equivalent to the MODX Revolution add-on Batcher. However, there are other PW Modules that are executed in the frontend, e.g. Markup Simple Navigation previously mentioned. In fact, in PW, a Module is PHP that extends the functionality of PW. Modules contain PHP classes that adhere to PW’s Module interface. 9. Plugins In MODX Plugins are PHP code that are set to execute during certain system events. In PW, although the term Plugin does not exist (except maybe in reference to Modules), MODX Plugin functionality is easily doable in PW. This is achieved via Hooks. There is one difference though. In MODX, Plugins are standalone code you can download and install. You cannot download and install PW Hooks. Instead, PW contains many methods that you may hook into in order to modify the behaviour of the method. In other words, PW offers the ability to hook into its processes/events and manipulate them before or after the event or even replace them, etc. Hooks are usually invoked inside Modules. However, Hooks may be attached from anywhere that you use PW's API, for instance in Template Files. The average PW user will not need to use Hooks. For more info about Hooks check the documentation. 10. Chunks MODX defines Chunks as “bits of static text which you can reuse across your site”. There is no equivalent term in PW. You can, however, easily create Chunks in PW. You can create Chunks as a Page that contains various Fields each of which can act as a Chunk. This means you can have Chunks of all sorts of data. You can then set the Page you create to hold your Chunks as hidden (not available to searches). The Page can also be assigned a Template without a Template File to further limit frontend access. It can also be created as a child/grandchild of the page Admin. That will limit access by User (e.g. login required to view it in Admin). Accessing the Fields of that Page as your Chunks using PW API is quite trivial really. Since you can use labels and descriptions to further define each of your Pages’ Fields, this makes it quite easy to describe what each Chunk is for and/or give instructions on how to use the Chunks. See this example for more info. You can also simply use text files to pull into your content as Chunks. Personally I prefer using Pages as Chunks when I need to. In MODX, it is usual for many Snippets to use Chunks (HTML + placeholders) to structure their output (i.e. tpl Chunks). You do not need to do this in PW. Code output can be wrapped in HTML right within the Template File. The important thing to remember is that any Field in any PW Page is available to any other Page and any Template File. Cross-referencing Fields and Pages is child’s play. Seriously; it is that easy. 11. Miscellaneous Tag Syntax: PW does not use a templating language (tagging syntax) like MODX does. See this article why this decision was taken. I agree 100% with the approach and have come to realise its many benefits over using a templating language. However, there are two Modules that allow you to use template language tags in PW. I have never used them so cannot comment further. They are here and here. Settings Page: PW has no settings page like MODX. Many settings are set in the /site/config.php. Other MODX settings equivalents are interspersed in various places including caching content on a Template by Template basis and in Modules. You can also store custom settings needed for your site in the /site/config.php. You can even use Pages to store your settings as mentioned in section 10 (Chunks). Modularity: PW is a very modular system. The whole of PW is made up of Modules (Core Modules) that accomplish different tasks. 12. Examples - the PW way… In this section I will show you equivalent MODX versus PW add-ons as well as how to accomplish various task using PW “Snippets” equivalent. a. Template Variables As previously mentioned, MODX TVs are PW Fields (although PW Fields are more versatile). Outputting the contents of your Fields is very simple. echo $page->name_of_your_field; This gives you the contents of the Field in the current page. Works slightly different for image fields though. For other pages echo: One page $pages->get(ID or PATH or NAME, etc.)->name_of_your_field; //note replace ID with ID of the Page you want, etc. Many pages $pages->find("selectors"); //this will return an array. You can then go through the array using foreach as shown in the examples below to output the field(s) contents MODX - output main content of Page //MODX Evolution[*content*] //MODX Revolution[[*content]] ProcessWire - output main content of Page //ProcessWire echo $page->content;//note; this assumes you have a Field called content in the Template of the current page. In ProcessWire you can find Fields of other pages like so $fruits = $pages->find("template=yumyum, limit=10"); foreach($fruits as $fruit) { echo "<li><a href='{$fruit->url}'>{$fruit->title}</a></li>"; } //find 10 Pages that use the Template yumyum and echo their url and titles in a list. From these examples, you can see the elegance and flexibility of TVs done the PW way. Since there is separation between a Template and a Template File, you can conditionally echo out the contents of Fields found in Pages. b. Snippets Common MODX Snippets and PW equivalent Modules 1. WayFinder: Markup Simple Navigation or code in Template File (see head.inc in default PW installation for a simple menu). 2. Ditto (Evolution) and getResources (Revolution): Functionality inbuilt in PW. Use $page and $pages variables + selectors to find anything, anywhere. 3. Jot (Evolution) and Quip (Revolution): Comments Module is part of the PW Core. It is not enabled by default. You will have to enable it in the Admin. See also the related Comments Manager Module. 4. eForm (Evolution) and FormIt and FormItBuilder (Revolution): There are various Form parser codes in the Forums. There is also a commercial Form Builder Module. It’s not expensive, is developed by PW’s lead developer and proceeds support the PW project. 5. MaxiGallery (Evolution) and Gallery (Revolution): Presently, there is no equivalent. However, it is quite easy to build a photo album. See this tutorial in the wiki. There is also an Images Manager Module (still in alpha though). 6. AjaxSearch: Ajax Page Search Module. 7. Breadcrumbs: Quite easy to accomplish using PW API. See default PW install for an example. 8. FirstChildRedirect: Very easy to do using PW API like this: $session->redirect($page->children->first()->url); in a Template File. 9. getField (Evolution) and getResourceField (Revolution): Inbuilt in PW $page and $pages variables as shown above. 10. GetParent: Inbuilt in PW $page and $pages variables. E.g. $page->parent. 11. getPage: PW has inbuilt pagination as part of the Core (Pagination Markup Module). See this article for a quick tutorial. 12. UltimateParent: Inbuilt in PW API as rootParent. 13. if (Revolution): Use vanilla PHP with PW variable and selectors in Template Files. 14. VersionX (Revolution): Versioning for text-based fields is coming in PW 2.4 (release date summer 2013). Support for maintaining separate draft and live versions coming in PW 2.5 (Winter 2013/2014). Currently, there is also the Module Version Control for Text Fields. 15. getRelated (Revolution): No out-of-the-box Module for this. Has been previously accomplished using PW API in various ways. Have a look in the forums. 16. importX (Revolution): Import Pages CSV Module. 17. phpThumbOf: Thumbnail functionality is inbuilt in PW. There is also the Module Thumbnails that further extends this functionality. 18. getValue and getValues (Revolution): Inbuilt in PW. You can get the value of any Page using PW API - $page and $pages. 19. getFeed (Revolution): RSS Feed Loader Module. 20. MIGX (Revolution): Repeater Module which is part of the PW Core. It is not installed by default. You will need to do that yourself. For more info see this tutorial. 21. Articles (Revolution): See the Blog Profile Module. 22. NewsPublisher (Revolution): See below under Plugins. Examples MODX Ditto [!Ditto? &parents=`5`&extenders=`summary` &tpl=`tplBlog` &orderBy=`createdon ASC`&display=`6` &truncText=`Continue Reading This Article` !] PW equivalent $items = $pages->get(5)->children("sort=date,limit=6"); foreach ($items as $item) { echo $item->title; echo $item->summary;//etc. } //this assumes you have a Field called summary on that Page The first line in the above gives you all information about the 6 child Pages of the Page with ID #5. It returns an array. In other words, a basket of various documents containing all the info about those documents. Next, you traverse the array using foreach. In layman terms, you rummage through the basket picking goodies! In order to wrap HTML around the code output, we do it like this instead (there’s other ways to do it as well!) echo "<ul class='articles'>"; foreach($pages->get(5)->children("sort=date,limit=6") as $item) { echo "<li><p><a href='{$item->url}'>{$item->title}</a><br /> <span class='summary'>{$item->summary}</span></p></li>"; } echo "</ul>"; In this example, we have asked PW to grab the child Pages directly within the foreach rather than creating a variable $items first. MODX getResources // Output a list of child Resources of the current Resource, using the 'myRowTpl' chunk: [[!getResources? &parents=`[[*id]]` &tpl=`myRowTpl`]] PW equivalent echo "<ul>"; foreach ($page->children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } echo "</ul>"; //You might want to limit the number of child Pages you are getting if they are many! MODX getResources // Output the top 5 latest published Resources beneath the Resource with ID '5', with tpl 'blogPost': [[!getResources? &parents=`5` &limit=`5` &tpl=`blogPost` &includeContent=`1`]] PW equivalent echo "<h3>Latest Posts</h3>"; $posts = $pages->get(5)->children("limit=5"); foreach ($posts as $post) { echo $post->body; } c. Modules 1. Batcher and Docmanager (Revolution): Batcher Module (covers most equivalent functions). 2. DocFinder (Evolution): Inbuilt in PW default install. d. Plugins 1. QuickManager (Evolution): Several Modules can do this, i.e., Fredi, Page Frontend Edit and Inline Editor Modules. 2. ManagerManager (Evolution): Same functionality can be achieved using Templates, Access Control and the Modules Page Edit Field Permission, Page Edit Per User and Page Edit Per Role. e. Chunks See this example. Btw, the PW Cheat Sheet is you best friend... Hope this has been helpful! /kongondo

PW magic Yes !! Well thank you, it's not important, only to understand the concept...

The file displayed is always index.php, but the content being rendered depends on the url. It's like when you have a query string, like in domain.com/index.php?field1=value1&field2=value2&field3=value3, in that case all those pairs field/value can be pulled by get, and the content displayed can vary depending on them. Except that here, normal URLS are redirected to index, and via the URL segments the right page is displayed via some PW magic. I don't know exactly how it works, but maybe someone more informed can explain the details.

btw -the client loves pw and appreciates the community so is offering 20% discount, using coupon code 'processwire', until June 20.

Ok, got it - and I have to say once again: "Thanks, Soma!" Here the thread and the post with the solution: http://processwire.com/talk/topic/1272-new-page-nav-in-admin/?p=11276 The important part is the setting of the moduls permisson: public static function getModuleInfo() { return array( 'title' => 'Import Tabelle als CSV', 'version' => 103, 'summary' => 'Import CSV files to create ProcessWire pages.', 'singular' => true, 'autoload' => false, 'permission' => 'page-edit' ); In this way the modul is editable by a non-superuser and can be accessed through the top navigation.

@Jason & alanfluff -thanks for checking out the site, much appreciated. @NooseLadder - thanks for looking and yes, you're completely on point, the company is a very small business with limited resources...(basically a one-man operation) but there is a plan to photograph all of the products for 'V2'... For the veneers, there is a 'veneer gallery' for this version, and there will be a 'veneer picker' on the product pages for V2 which will be a popup lightbox that lets you see the veneers close up and select one, for which the selection will populate the veneer choice select box. also in the works would be validation for the veneer selection (to make sure a value is selected).... i haven't been able to figure out foxycart add-to-cart validation yet and am waiting on a reply to a post in the FC forum as to how i can use jquery.validate with FC, which would make things super easy.. -marc

How come not? Works with me on every browser I tried...

@Harmster, he means the ID of the page from where render is called. @sakkoulas, you can use any of these techniques http://processwire.com/talk/topic/3660-what-page-was-the-caller-of-render/

So, you should already know the targetfile, because you write the link ?? ok ?? (something like $targetpage->url) Now you only have to append your anchorname: <?php echo "<a href='{$targetpage->url}#anchorname'>MyLink</a>";

The site's been live for about 2 months now, but I thought I would share the first of many projects I plan to build with Processwire. http://romania-meubelen.nl is a site I designed and built for a small Dutch company specializing in Teak furniture. There's a lot of complex logic built into the calculating of the prices when combined with different sizes and finishes, but Processwire definitely made it a whole lot simpler to build.

Also as a beginner and I'm not sure if I understand Wanze right, but maybe he means that it should be different handling for $page->next and $page->next() $page->next() handles as it does actually but $page->next should be optimized for the cases with mass siblings. so, conclusion: next == next() ?? right ?? or not ??

It works well! Thanks guys

Fernando, Welcome to PW. In other words, that $s is a temporary variable created to hold information about all the pages found by this $pages->find("template=skyscraper"). In order to get the most out of PW, I recommend that you first learn some basic PHP. See this thread for suggestions about good PHP learning resources. Cheers

bluewithoutgreen, you didn't tell us what the problem is, so I just can guess. As far as I can see, your code outputs the same thumbnail four times, and you get as many unordered lists as you have got pictures in $feature->thumbnail. I think what you really want to do is: $output = ''; // holds the HTML to output foreach($features as $feature) { $thumb = $feature->thumbnail ? $feature->thumbnail->width(800)->url : 'http://i.imgur.com/1zxfxMW.jpg'; // if no thumbnail, replace by placeholder $output .= '<li><img src="' . $thumb . '" alt="" /></li>'; } echo '<ul class="bxslider">' . $output . '</ul>';

There is a warning about next() and prev() in Page.php regarding larger amount of siblings: How big a problem this will cause depends on how many sibling pages you've going to have in each branch there (and the number of branches, of course, if there'll be a lot of those.) I tried to implement next and prev on a site that, at that time, had around 1500 siblings in each branch and was growing fast. That resulted in significant speed problems for each page load. I didn't have caching on at the time, though -- that definitely helps a lot. With caching enabled PW only has to build each page as a static HTML file once. Even if it's a bit slow, it should only affect first page view of each page in that branch. On the other hand, if content is updated very regularly (which I kind of doubt would be a problem here) this would of course diminish the benefit of caching a bit. All in all, I'd suggest that you implement this, do some tests regarding speed and see for yourself if it's going to be a problem. If possible, add some extra dummy pages to see how things will change once your site grows.

May I ask the question: Why this setup? Makes no sense for me if you are redirecting Home to Root, why do you need Home?

I didn't plan anything yet I just wanted to check how many would consider joining. Looks good so far

too cold for beer!

full ack... never thought I could ever learn to code... With ModX, I had to hire programmers to write snippets I couldn't do anything new. With PW, I learnt some php, and piece by piece, with the help of this never impatient community, I can bring my ideas into life - by myself!!!

3. You can also adapt this method http://processwire.com/talk/topic/3551-small-tip-for-pages-that-will-be-used-with-render/ $path = str_replace ($config->urls->root,'/' , $_SERVER["REQUEST_URI"]); // so it works also when pw is in a subfolder $caller = $pages->get($path)->title; just to give more options

Greetings Everyone, Sorry I missed this discussion until now. Yes, I am working on a ProcessWire book and companion Web site. As a technical writer/developer/designer, ProcessWire has been an inspiration on multiple fronts: creating Web sites, going deeper with design/development, and writing/documenting the system. I've been working regularly on the book project, and I have about 175 pages completed already. I'll have much more to share in the coming weeks. Stay tuned, Matthew

boundaryfunctions, I've gone through it much of it and feel like I am somewhere in between understanding the basic site and understanding one of the more complex builds (skyscraper, or blog). I realize that with time I can probably piece all of this stuff together to develop my own understanding. However, I just feel like when you can get into the mind of an expert in a system (author of xyz book) then you get the best vision of walking down that path. It's like the difference between exploring a New York City on your own, asking people on the street where a good place to eat is -vs- getting a guidebook or spending the day with a local take you to spots and give you inside tips or ideas. One can just get up to speed faster the second way and not feel so overwhelmed. Appreciate the response, and I'll certainly dig deeper.

Haven't tested, but adding this, or something like it, to your .htaccess (after RewriteEngine On) might work: # skip over URLs with a period (possible filename) or your admin URL RewriteCond %{REQUEST_URI} !(\.|processwire) # skip over requests to files that physically exist RewriteCond %{REQUEST_FILENAME} !-f # redirect to the same URL with a trailing slash RewriteRule ^(.*)([^/])$ http://%{HTTP_HOST}/$1$2/ [L,R=301]

Hey rob. What diogo said. You can create a admin page using the "admin" template. It would be placed under the locked "admin" page tree. The admin template has a field "Process". After creating the page you'll see it under tab "content". Now you have to create a process module to serve functionality for the newly created admin page. Once installed it can be selected from the field "Process". I did a quick example that shows such a module, and even how to use the ProcessPageList module of processwire to create a tree. The id set will be the parent page (your Architects) for example. ProcessPageListCustom.module create the module under /site/modules/ and install it. <?php class ProcessPageListCustom extends Process{ public static function getModuleInfo() { return array( 'title' => 'Custom Page List', 'summary' => 'List pages in a hierarchal tree structure', 'version' => 100, 'permission' => 'page-edit' ); } public function execute(){ $pl = $this->modules->get("ProcessPageList"); $pl->set('id',1001); // or any other parent page return $pl->execute(); } } You can, of course, use any code to generate a list of pages.

I haven't noticed any speed issues on the site here. There are all kinds of factors that can affect the speed at which a site loads, so best to track down what it is first. If the site loads quickly for one person and not another, chances are there is a network issue between the host and user, or there is a factor on the site where performance is affected by the users' software or hardware (i.e. JavaScript execution speed). If a site is consistently slow for most users then more likely the web host, server or the site itself and it's use of server resources. When browsing the site I monitored the request times in firebug and there is an above average 'wait time' between request and response on the page's URL. However, it's not something I would have noticed. But that may point to some heavy lifting happening at the server, whether in PW or any number of other factors. When it comes to PW, it will let you consume a lot of resources very easily, so you do have to take care sometimes, especially with larger sites. For instance a call to $pages->get('/blog/entries/')->children could load all blog entries if you didn't specify it with children("limit=n"). Likewise, siblings/next/prev functions are good to avoid on a page with hundreds of siblings. With great power comes great responsibility. PW will happily load up a few hundred or more pages, but it's not something you want to do if you don't need to because it will affect performance. And even when you need to, it's good to reduce the number of times. One way is by using the MarkupCache module, especially for things you are having to generate on every request. Likewise, the template caching is good to use in instances where you don't need to change something on every request of a page (ie don't need randomization or second by second updates). But my opinion is that it's best to use caching only after you've made your other code as fast as it can be and have made sure you aren't loading pages you don't need to. These are just general guidelines and aren't much of a consideration until things get big. This site is at a size (with several hundred blog entries) where some of these scalability considerations should be observed. But it may or may not be applicable in this situation. The site performs reasonably well for me and I would not have ever noticed it as slow. But then again, maybe I was the only one accessing it at the time. Anytime anyone wants me to look at your code for potential bottlenecks I'm happy to. Feel free to post in the forum or privately to me. Most issues that would affect scalability are simple to fix because PW is designed to really sing at the larger scale and just requires occasional tweaking to how you use the API.