teppo

The fact that any of your template files (controller or something else) get rendered means that ProcessWire has already triggered $page->render() behind the scenes. This is done by Process Page View. So, essentially, the code you've posted above is perfectly valid.. it just means that $page->render() get's called once for your controller and then once for each $page_id->render(). You can quite easily debug this by adding an echo as the first thing in /wire/modules/PageRender.module. So the answer is two-fold: yes, it is necessary for things to get cached -- but no, you don't necessarily have to call it yourself Not really sure about this one. If a page is rendered and it has caching on, it should get cached exactly the way it's rendered there. I may be confusing something here, but you should definitely make sure that you're not just viewing things while logged in -- in case that you have edit access and are logged in, cache gets automatically overridden and things may look a bit different. Like @Wanze pointed out above, you'll probably want to log out every now and then to make sure that everything is fine or use another browser at the same time while testing stuff related to cache.

Agreed -- though this is definitely something that needs to be documented properly and promptly to minimize the likelihood of unnecessary confusion (once it's final, that is)

If portfolio_categories is a Page field, you can't and don't need to use '*=' or '%=', use '=' instead. In the case of Page fields '=' checks if the value of said Page field contains specified page, not if it's equal to it, so you should use that and a page ID (or Page object) to see if one of selected categories is the one you're looking for: // this should work: $cat = $sanitizer->selectorValue($page->title); $cat_page = $pages->get("template=portfolio_category, name=$cat"); $p = $pages->find("portfolio_categories=$cat_page"); // .. though in this case you should do this: $p = $pages->find("portfolio_categories=$page"); // .. and you could even do this: $p = $pages->find("portfolio_categories={$page->id}";

Umm.. sorry, but you almost lost me with "I can define each basic template field set to be cachable". You are talking about template cache, right -- not Fieldtype Cache? If it's template level cache you're talking about, that will cache the final, rendered output of each page, naturally including any and all include files. Take a look at PageRenderer for more details. You should also take a look at Page Render at modules page after turning cache on and loading a few pages. It'll tell you just how many files are cached. Another thing you might want to do (especially during testing) is to take a look at the contents of /site/assets/cache/Page/ to see which templates are getting cached and what is being cached for them. That should provide a definitive answer to your question MarkupCache is useful if you have specific, smaller parts of pages that need to be cached, individually (and probably instead of) whole templates. I've used this, for an example, in the case of relatively resource-consuming queries to external (or internal..) API's that also need to parse fetched data to display it etc. Edit: just wanted to add that I've been working on a personal site that does similar things you've described above, such as using a front controller that all requests are routed through and various methods of selecting which view script (sorry, Zend Framework tends to stick) should be used to render that particular page / part of page. One problem I had was that once a page had first been rendered elsewhere (a list view) with very stripped view script and then rendered on it's proper URL as (supposedly) a full version, stripped version got pulled from cache and things looked very wrong. Long story short, $session->PageRenderNoCachePage can be quite useful at times -- it allows you to skip cache for pages rendered on the fly. Then again, this is mostly an issue if you're a) using page properties to determine which file should be rendered (URL segments and GET/POST variables can already be set to override cache via template settings) and b) rendering pages inside other pages with $page->render(). Might not be an issue for you at all, just saying..

Especially running these actions without supervision could lead to even worse results, so I wouldn't suggest it (or, at least, you should do it first with some test data and generate thorough report of what's changed.) Don't really know anything about spell checking tools, but I'd expect couple of those to be pop up once you Google a bit. PHP has some native features for this (but not sure how commonly installed those are) and apparently there are various custom methods available too. You'll probably also have to split field data to single words and actually recognize which items resemble proper words. Anyway, API part would be quite simple, something along these lines: foreach (wire('pages')->find('template!=admin') as $p) { foreach ($p->template->fields as $f) { // include fieldtypes you want to check (or check for $f->name == "body" if you prefer that) if (in_array($f->type, array('FieldtypePageTitle', 'FieldtypeText', 'FieldtypeTextarea'))) { $original = $p->$f; // do some magic here, such as this: $p->$f = preg_replace('/. [ ]+/', '. ', $p->$f); // some logging would be nice: if ($p->isChanged($f)) { echo "{$p->url} {$f->name} changed: {$original} => {$p->$f}\n\n"; } } if ($p->isChanged()) $p->save(); } } What could be somewhat problematic are fields with HTML in them..

There's at least one somewhat similar topic here. Piece of advice: forum search isn't very trustworthy, do a Google search and add "site:processwire.com/talk/" instead. Works so much better As for your question, I'm an Emacs user. If I had to work with something else, it'd probably be NetBeans. Both of those are simple yet configurable and extendable -- very important features for proper IDE. Most Windows IDE's (don't really know anything about Mac-specific ones) have way too much bloat right from the start. I simply can't stand all that noise.

Expanding previous reply a bit, once you've selected a page in this page field, "maths" as an example, you can of course do something like this in front-end of your site: <?php // if your page field is limited to one page and returns a Page object: echo $page->your_page_field->category; // if there are / can be multiple selected pages in this field and a PageArray object is returned: foreach ($page->your_page_field as $item) { echo $item->category . "<br />"; }

Thanks for the heads-up Ryan, just started converting one of my modules So far everything is just fine when it comes to simple queries (an extra "if" I can live with), but for complicated stuff this seems to result in either creating duplicate code with relatively minor differences or rewriting large chunks of existing logic to support both in a sensible way. This is most likely (at least) partly a result of my total lack of experience with PDO, but as far as I can tell there are also differences that make these two fundamentally incompatible. There are many advantages that come with PDO, but this transition has a negative effect on backwards compatibility for modules and possibly even some sites.. although in the case of sites simply not updating them to 2.4 is a viable solution, especially if they're something you know you won't have to expand / alter that much in the future and thus won't be missing all the goodies brought in by new PW versions. Anyway, I still can't help wondering one thing: Have you considered letting PDO and mysqli co-exist within PW, ie. by referring to them with something like $db_pdo / $db_mysqli and letting $db default to $db_pdo -- or perhaps just adding $db_mysqli / $mysqli as an alternative to PDO? Or is there perhaps a bigger plan behind this change, such as cutting ties with MySQL, that this co-existence would undermine? Then again, I'm not sure if this would help that much really. Obviously it would make converting existing code to 2.4 easier, but some work would still need to be done. I'm just a bit worried about this creating a wall between PW < 2.4 and >= 2.4 and can't help wondering if this could be somehow avoided or (more likely) conversion could be simplified a bit. Other than that: for anyone looking for a quick introduction to PDO, this tutorial on Nettuts+ really filled in the blanks for me (see the comments section for good point about prepare, though..)

You could also do this: if ($page->is("name=slideshow18|slideshow28|slideshow38") { I prefer this method, since it's slightly shorter, bit more readable and doesn't need to fetch any additional pages just for comparison.

Congratulations, Ryan! Excuse accepted

Actually, @diogo, your proposal made a lot of sense, just saying. Doesn't sound like a very common need, but I don't see any harm in it either.. and it would definitely open a window for clean (and "codeless") customization of admin. Thumbs up for this.

I'm not sure what you're exactly trying to say here, but the answer is "definitely not." There's nothing WordPress can do that ProcessWire can't do. Actually I'd go as far as claim that it's quite the opposite. Articles or blog posts? Just create templates for those and start writing. In case that you need help for specific problems and/or parts or ideas, ask. If you'd prefer to start a proper blog from the scratch, check out Blog Profile. Did this answer your question or is there still something you're wondering?

You could achieve pretty interesting results by taking this idea a bit further: Define areas on front-end where new elements (widgets, nodes, blocks, whatever) can be dropped and create new page fields for each of them, set up a collection of pre-defined blocks (templates, including proper template files for this purpose) you want users to be able to drop in, create a clean way to add new pages / edit existing ones via front-end (edit/add button, something like Fredi), store newly created pages somewhere and attach them to page field on current page automatically. Preferably you would also let the client re-arrange these blocks by dragging on the front-end side, to make it all function properly. Perhaps even drag blocks from one area / column (page field) to another? That's all very much doable, though I would imagine that it could take quite some time to work all the details out (such as where to store those pages to keep things smooth and stuff like that.) I'm definitely not advocating anything like this, based on similar reasons others have stated above (such as the fact that pages created this way usually end up unbelievably messy in the long run and no longer serve any real purpose, other than perhaps making some content editor very proud of herself) -- just saying that ProcessWire can be used for it if it's what makes you happy. If you're into it, why don't you give it a try yourself? See where it takes you and ask if you need any advice Been there, seen both of those happen more than I'd like to remember. For a very long time I believed this to be "the best way" (partly because it worked for us and made our clients very happy), but after listening and seeing all those problems it caused for our clients at the same time, I've come to one conclusion: this model is in reality one of the worst enemies of properly structured, usable and logical web content. It requires serious mental fortitude to keep things in order when you've got all the tools you could ever ask for right within your grasp. This is true especially in the long run.. and especially when there are multitude of editors to deal with. Ever been asked to re-organize a ten year old site for a client, one that's seen hordes of editors, various shifts in content strategy etc.? Not a trivial task and each and every page having a very different structure doesn't really help. It's rare for there to be someone who could keep it all under control either -- that kind of thing is too often limited to huge organizations only and even then resources tend to be scarce. From my point of view the most obvious (even if still only partial) solution for this is a clearly defined structure that editors must stick with, even if it doesn't please them at all times -- which is exactly what ProcessWire provides tools for. Clients may not "get it" at first, but that's why we as designers, developers and professionals should explain and teach them why this is a good thing. I rest my case.

Awesome.. and already useful by introducing me to jQuery Github which fits perfectly a project I'm working on right now

Just to make sure: does /site/assets/cache/MarkupCache/ directory exist and if it does, is it also writable (either 777 permissions or writable by web server?)

@Eltom: you're essentially describing a new minimum size setting here, which as far as I know doesn't yet exist but would admittedly be quite nice at times. So yes, @horst is right in that you'd currently have to create a new module to implement this. You could also submit this as a feature request to Wishlist & Roadmap section here on the forum.. though posting here may already be enough to catch Ryan's attention Taking a look at the source of InputfieldImage.module, there's a ___fileAdded() method (three underscores means that it's hookable) that could be used by a module. This method actually handles resizing image if it's larger than given max size, so something like this should work: hooking before InputfieldImage::fileAdded, checking if image size is smaller than minimum size given (settings of this new module or perhaps within field settings, though I'm not sure if there's a proper place to hook and add something like that there by hooking after InputfieldImage::getConfigInputFields and adding new field to returned InputfieldWrapper object.. or it could simply be a hard-coded value) .. and if it is, removing file and outputting error (like @horst already described above.) Sounds relatively simple to do, really. If you're even remotely interested in PW module development, you could give it a try yourself.. and please don't hesitate to ask if you face any problems! Extra tip: HelloWorld.module is great starting point for a module that adds hooks

Yes, $page is same as wire('page') and so on

Check out Page References Tab, sounds like you're trying to achieve a very similar effect at least.

Great idea, will definitely try it out! One minor thing I noticed after taking a quick look at your code: you should make sure that $_SERVER['REQUEST_URI'] actually exists before doing that strpos() at init. When bootstrapping ProcessWire for local use (shell scripts etc.) it won't be there and you'll get a PHP notice for that. Not fatal, but annoying in the long run

Note: you've mentioned that this should be done when page is added. I'm a bit confused about that, since your field shouldn't have any value at that point yet. If I'm confusing something here and that is actually the case, you'll probably want to take a look at ProcessPageAdd::execute -- pretty much everything else after this should still apply.. Execute method of ProcessPageEdit.module returns rendered edit form. By hooking after it you'll get access to $event->return, which contains said form markup. This way should be able to modify it before it gets sent to browser. I'm assuming that you're familiar with how hooks are added. If not, wiki has an (unfinished) article about those and HelloWorld.module provides very good examples. Hope this helps.. and that I understood properly what you're doing there

Little bit of background information would be useful here: you're saying that you've got a field you're using to create an image. What type of field is it, what kind of content does it have, does it store that too or is it cleared after image has been created? Is created image always at same location and does it's name vary? Depending on what you're doing exactly you might want to a) create new inputfield and/or fieldtype for this purpose or b) create an autoload module that hooks into ProcessPageEdit::execute (or something more appropriate) and if an image is found from pre-specified location renders it somewhere (positioning could be done with JS, if that's necessary.) Like I said it all depends on what you're trying to achieve and what's the whole context here

Title would be nice, agreed. About the alt text I'm not so sure. First of all, you'd have to take into account that an image used within text content and an image in image field are practically speaking two separate entities. Currently you can use same image over and over again with different alt texts, depending on context -- and that's good thing. From technical point of view image field doesn't know where it's content is / can be used, so you'd have to keep up with that data somehow. This is actually something that Image Manager (to certain extent, ie. when using special image embed tags and after specifying related fields) already does. Extending similar features to regular image tags created by TinyMCE / CKEditor isn't necessarily worth the trouble. At least not as a native feature, that is

"Hook*r, directly from the creator of After Shave Actions".. yeah, that sounds just about right

Not that it matters much, but you might want to reconsider that statement: http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html. Quotes don't matter, but concat method ("foo" . $var . "bar") on the other hand does tend to be slightly easier on eyes because many editors won't actually recognize a variable inside quotes (ie. string interpolation) as something that should / could be highlighted. So, essentially, use whichever you prefer. Just wanted to point out that micro-optimizations like these are a) futile and b) often misunderstood -- and thus generally not worth even thinking about