Leaderboard

Something like this should work: // First iterate through all of your categories (I'm assuming they all have a template called "category", but this could be changed to suit $categorycount = array(); foreach ($pages->find("template=category") as $category) { // Now I'm assuming that the portfolio pages have a template called "portfolio" and are tagged against a category using a field called "category" $categorycount[$category->title] = $pages->find("template=portolio, category=$category")->getTotal(); } And that should be it - an array of category titles and their corresponding portfolio page counts. In the above code, we're first iterating through the categories, then finding all pages in the portfolio with a category that matches the current category we're looping through. Note that it seems like you would have to use $category->id, but if you omit the field you are outputting for a given page object it will default to ID anyway Oh, and the above is untested but should hopefully work EDIT: It's also worth noting that I had to refer to the cheatsheet as I couldn't remember the correct method to get a total - turns out it was getTotal() The cheatsheet is an invaluable resource even to those of us who have been here a while so if you've not seen it yet then check it out.

Thanks I've update the Authors list in the source code too

I added mcmorry to the author too.

Btw: this module has only Soma as author on module directory: http://modules.processwire.com/modules/language-localized-url/ - Ryan, is it possible to support multiple authors for a module?

Hi, thank you for your suggestion. I had some difficulties to find the documentation that you reported, because you was speaking about the "inline" documentation. Instead I was searching on online documentation where the steps are described in details: https://github.com/mcmorry/PW-language-localized-URL#readme Anyway I've fixed it as you suggested. It will be easier for all users to setup the modue. Thank you

Awesome module, it’s working very well. One small note for the documentation, it currently says the following: ‘Create a page field i.e. language_published. Set the template to the one you use for the proxy pages. Set inputfield type to checkboxes.’ Being a bit of a novice user, it took me some time to figure out that with page field you mean a field with type ‘page’. So maybe even more clear would be if you’d rewrite it to the following: ‘Create a field i.e. language_published of type ‘Page’. Under Input > Selectable Pages, set the template to the one you use for the proxy pages. Set input field type to checkboxes.’

I wondered about the ?page=2 because when I checked out the architects example, it said page2. Given what you said, I had put the page numbering against the child items template because that's where I assume it went. When I moved it to the summary page template, in this case 'news', it started working just fine. Thanks for pointing me in the right direction

I didn't really mean it, but I thought it's something I would search first and then ask if nothing found. And as I know there was such a thread already I wanted to search it as I know it can be hard to find things here sometimes. I also suggest to use google "site:processwire.com keyword" search as it will be much more successful.

I've put together a Process module skeleton that may be good as a starting point for any Process module. It is well commented and fully functional as a demonstration. It also includes instructions on what to do with it when using it as a starting point for another module: http://modules.proce.../process-hello/ I'm planning to make more skeleton modules to cover all the bases.

I got tired jumping through hoops using WordPress and Joomla and started looking for an easier solution. I searched for about a week, testing CMSes that I've never used before. I first looked at Concrete5, and then someone at Concrete5 forum swore allegiance to ExpressionEngine, so I searched for it and found it was a paid subscriiption, so I turned to MODx as an OpenSource alternative. It was decent, and I thought that it might work, but then I ran into a problem, and while searching for a solution, I read someone bragging about ProcessWire, and how easy it was and how it was the simplest most, most powerful CMS he's ever used, and I thought, hey that's exactly what I want. Within an hour, I had the basic install running on my wamp stack. 5weeks later, I have 2 sites running perfectly, and 3 on the way. I'm never using any other CMS again if I can help it! Thank you Ryan, and thank you ProcessWire community!

The $event->arguments is just an array of arguments that were passed to the function you hooked, in the order they were passed to the function. You can also retrieve them by name if you prefer, i.e. $event->arguments('page') would retrieve the argument named '$page'. In addition to being able to read these arguments, you can also change them if your hook is a "before" hook… letting you modify what ultimately gets sent to the function you are hooking. There's also $event->object, which is the object instance containing the function you hooked. So in the example from my previous post, $event->object would be $pages. That's probably not very useful, but when dealing with hooked methods on other things (like a Page or a PageArray) it might be exactly what you need. Lastly want to mention $event->return. If your hook is an "after" hook, then $event->return will contain the value returned from the function you hooked. Like with arguments you can modify this value if you want to. If you add a hook somewhere, and there isn't any function to hook, then you've just added a new function to that class. When someone tries to call that function, it'll call your hook instead. There are other things you can do with hooks too, like add properties to an object (rather than just methods) and entirely replace a function with your own. But these are less used things.

The recursive loop comes from your $p->save(); which is again triggering your pageSaved() hook, and continues doing so infinitely to a deeper and deeper level. There's probably a bunch of ways to solve this. But here's two really simple ways. First is to just set some landmark variable (we'll call it skipMe) so that your hook will know to skip over pages that it is creating itself. Your landmark variable (skipMe) doesn't need to be a PW field or anything, as you can make up any name/value on the fly and set it to a $page for temporary use like this. public function pageSaved($event) { $page = $event->arguments[0]; if($page->skipMe) return; $p = new Page(); $p->template = 'basic-page'; $p->parent = '/about/'; $p->status = Page::statusUnpublished; $p->title = "This is the pagename"; // set some landmark so pageSaved knows to skip this one $p->skipMe = true; $p->save(); } The next option would be to just have your $p->save(); skip over all hooks: $p->___save(); When you call the function name with 3 underscores in front of it, it does so without executing any hooks, thereby preventing the infinite loop. However, this may or may not be what you want, because it would also skip over any other Pages::save hooks that might be present.

This is little different, since you are creating a new page. My comments below with code: public function init() { // now we want to hook after page save, since we are not manipulating the saved page, but creating/removing others $this->pages->addHookAfter('save', $this, 'afterPageSave'); } public function afterPageSave($event) { // $page will keep the page that user has just saved $page = $event->arguments[0]; // you probably want to have some conditions whether or not to do something. If you don't have any conditions here, then you go into a loop. if ($page->id == 12345) { $p = new Page(); $p->template = $this->templates->get("basic-page"); $p->parent = $page; $p->title = "New page under the saved page"; $p->save(); } // Removing of pages, could be in the same if or then some other conditionals. Now we check if field "delete_children" is checked (or has value of 1) if ($page->delete_children == 1) { foreach($page->children() as $p) { $p->delete(); } $this->message("Children removed."); $page->delete_children = 0; $page->save(); } }

If you add a hook before page save you don't need the last line where you save the page (it'll do that anyway), otherwise it will infinitely loop as you're making it go in circles. Take out $p->save; and it should be fine.

Never heard of it.

This is something that a lot of us do because it's fun, not because it's something that we have to do. We might make a module so that we can do something like this because it's fun, satisfying, and efficient (plus it looks good) … echo $pages->find('brand=/brands/audi/, mpg>25')->renderCars(); But the reality is that it's also not necessary. You could perhaps more easily just package it into your include file and do this: $cars = $pages->find('brand=/brands/audi/, mpg>25'); include("./render-cars.inc'); And in your render-cars.inc: <?php foreach($cars as $car) { echo "<p>{$car->title}: {$car->mpg} mpg</p>"; } What I'm trying to get across is that much of the things we all create and use modules for is optimization and fun. Perhaps others feel differently, but in my case, most of my sites don't even use any modules other than what comes with PW. I create modules when I want something I can re-use on multiple sites or share more easily with the PW community. Another point about modules is that they are a whole lot simpler than you would ever imagine, once you get going with it. But the lack of ability to create modules is not going to limit your ability to use ProcessWire in any way. You can make it do pretty much anything without having to even know about modules. But when the time comes that you become interested in it, it will only increase your enjoyment of development. So when you see what appears to be complex development conversations about modules and such, don't worry. What you don't know isn't going to hold you back in ProcessWire. It already seems like you have a really good understanding of development and using ProcessWire. Based on your past posts, I feel confident you can push ProcessWire to do what you need when you want to. And we're always here to help with questions and problem solving. If I were you, I would keep using ProcessWire for everything that you are comfortable using it for. When situations come up that you feel can't be as easily solved with ProcessWire, then investigate services like what Pete mentioned (Lemonstand, Shopify, Google, Facebook, Flickr). There are services out there for nearly everything and this is where a lot of functionality is trending. For instance, look at the quality of a comments service like Disqus... it makes you wonder if we aren't far off from the time when built-in comments are no longer considered a required core feature of CMSs. When we had to setup a forum for ProcessWire, I never considered trying to create it myself in PW. Instead, we went with SMF, and then IP.Board. Services like these and others are better than what you can reasonably expect to build on your own, or what you could expect to come with (or be added-on to) any other CMS. Honestly, if you use ProcessWire and then utilize services for the things you don't want to build, then you will be able to do everything you could ever want. And more quickly, more securely and easier to support, than if you were trying to leave it all to a CMS. For the rare cases where you need something that won't be easy to do in PW, and your service options are limited, then bring WordPress into the mix. Not that WordPress can do much on it's own, but it's following is so much bigger than anything else that literally every possible thing has been coded for it. I certainly wouldn't want to use WordPress as my CMS, but I have no qualms about pulling it in when something that I need is available as a WordPress plugin. You aren't going to find any other CMS that has as much 3rd party stuff built for it. WordPress is easy-enough to figure out in a day (from a development perspective) that you also won't find yourself as frustrated as in Drupal (at least, this was my experience). It's not much prettier than Drupal from an output generation perspective, but it will be much more respectful of your time.

As for Perch, yes, they are doing a great job, not only in presenting their product. Given the fact that it's maintained by two people, Perch is just great, especially in terms of support. However, it's not really suitable for bigger sites as it gets rather complicated to add and handle a large number of editable fields, which are the key ingredient of Perch sites. Still a good option for small sites, especially for clients which are not very experienced in using a CMS. MODx is huge in every aspect. Very powerful, but also very complicated in some areas. Setting up users and permissions is especially painful. It has the "total freedom of markup, CSS and JS" factor, but it also has an ExtJS backend which is anything but fast and lean. In fact, MODx is pretty close to PW in my opinion, but PW makes almost everything which is painful in MODx easier and better. As for Contao, I'm using it in 3 projects, but I won't use it for new projects. I'd still recommend it for non-professionals which are looking for an easy-to-use CMS, but it doesn't work well for me because of the template system and integrated CSS framework. It's just too much work to customize even a fresh install to the point where I can work with it the way I like to do. I get why it's being developed in the direction of a "better Joomla", and it's probably the right choice for their target audience, but I'm just not part of that audience. I haven't really worked much with Drupal. I like it a lot better since v7, but I always feel it's a bit clumsy. You asked for the CMS we'd use if we had to choose something other than PW, that's why I mentioned it – I don't have many reasons not to use it, and the ones I have are probably related to the fact that I don't know it very well. Also probably takes a looong time to get to know it really well, which is something I never had the time or patience to do. That's actually another area which PW won by a landslide. I have rarely gotten accustomed to a CMS that quickly.