teppo

... and if that's not possible, there's always full page iframe (No, seriously, please don't do that -- it'll screw you in so many ways.) Somas idea is probably your best bet here. Even if moving whole domain is for some reason impossible, you could always point just www (or any other subdomain of your choice) somewhere else and redirect all web traffic there (example.com => 301 redirect to www.example.com.) In any case you'd still require another host for the site.

One trick is to use Apache error page as a redirect to index.php and then forcibly fill in GET variable "it" (which ProcessWire uses internally for it's URLs) from REQUEST_URI. Edit: just realized that even though this would make your public site viewable, Admin still wouldn't function at all, partly because a 404 header would always be sent (not to mention that this would probably stop Google bot from indexing your site etc.) Like @diogo already said, this is not doable. Not with a host with such limitations. That's what you should tell your client. If they want to stick with Yahoo! hosting, they're not going to get a proper CMS no matter what they do -- hosting is cheap, so it would make a lot of sense to get another host for the site, even if they (for some unimaginable reason) want to keep their Yahoo! deal..

... and assuming that you don't / can't add all image field names in your code, something like this should also work: $allImages = array(); foreach ($fields->find("type=FieldtypeImage") as $f) { foreach ($pages->find("$f.count>0") as $p) { foreach ($p->$f as $i) $allImages[] = $i; } }

I agree that they (Linode) could simplify things a bit for "the common user." The way their service currently works is a bit rough on newcomers. Then again, the whole point of VPS (or dedicated) hosting is that you're in charge, you decide what to install (and what not to install) and how installed applications should be configured, so that's probably not very high on their list. Not to mention that it's a good idea to know how your environment is set up and their manuals are really quite helpful Still, offering an installation package for "common web server needs" -- Apache, MySQL, perhaps PHP / Python / Ruby preinstalled would make sense to me. As a slightly related note, just read an article regarding certain shared hosting provider, and right now I'm even more convinced than before that shared hosting just isn't worth it. I mean.. it's kind of OK if your service isn't going to be very important or contain any "private" or "classified" information, but I would never recommend one of these to a client.

It's all about not giving web server (in Ubuntu systems most commonly user "www-data") write access to anything it doesn't strictly speaking need it to. Web server is in direct interaction with outside world and can be tricked to do things on behalf of malicious users. This can be partly avoided simply by not letting it do any more harm locally than is absolutely necessary. Thus it's a good thing that it doesn't have that access by default. If it had (ie. you didn't need to set it during install or right after downloading / cloning install package), I'd be very worried, 'cause that would mean that your web server has full write access not only to /site-default/ but also the directory containing it (and who knows what else.) Obviously locally things are a bit different

Symbolic links are roughly the equivalent of shortcuts in Windows environment, if that's what you're more familiar with. They're just pointers to some other location. Having /wire/ as a symlink pointing to another location means that anything you change in that other place is instantly in use anywhere it's linked. This is most likely the easiest way to use one PW core (which, I believe, is what you're trying to achieve here) with multiple directories.. or sharing it with multiple sites in general Creating a symlink is as simple as doing this in your site1 / site2 directory: ln -s /var/www/your/primary/pw/installations/wire wire You'll still need to keep some files (in addition to a /site/ directory) in each subdirectory; most importantly .htaccess and index.php.. though I guess you could make those links to somewhere else too if it really matters.

This is a matter of view, really; textareas hold regular text (even if it's markup) and image / file fields hold images / files (binary data.) It's about separating content by type, even if not necessarily by purpose. Another important thing to note here is that an image isn't limited to one textarea. Current implementation allows one image to be used with as many other fields as necessary -- or none at all if that's preferred. Disagreed. In the context of web content images are never _really_ inline, they're separate entities loosely tied to content (markup) with <img> tags. In some other environments this might make more sense, but not here You're confusing "limitations" with "decisions" here. As always there's more than one way to do it and not doing it "the way most CMS work" doesn't mean it's somehow faulty. Not 100% sure if that's really what you meant here, though that's the message I'm getting. Regarding an actual solution, I'd suggest taking a look at Soma's image manager and perhaps extending on that. I'm certain that contributions would be very much welcome. If it's tags that are bugging you, perhaps this could be tied more strictly with TinyMCE / CKEditor image plugin or something like that? (Sorry, I'm not exactly familiar with this module, so I can't say if that's already something it does.) Edit: after some Googling justboil.me and couple of it's alternatives (TinyMCE image / file upload plugins) popped up. PlugoBrowser seems very nice too, though not free.. but if it's client work you're going to use this for, $20 price tag shouldn't make much of a difference. Perhaps it would make more sense in this case to integrate one of these locally, possibly coupled with a custom plugin / view for selecting images from that location -- unless that plugin already comes with these features, that is. Some plugins for sure do, I even remember using something like that in the past. (Umm.. iBrowser?) Not sure if TinyMCE within PW allows custom modules, but I believe there was an option for it.. haven't really had that need myself

In our case just explaining it once usually does the trick -- haven't really had the need to add anything about this to descriptions or stuff like that. It's a simple concept really and our clients have so far seemed to appreciate it, at least once they've been explained why this works this way. Personally I prefer to think of image (and usually file) fields as "storage spaces." If content in those fields should be visible on the page (note: this isn't automatically the case!) it should be added to one of that pages visible fields (in our case most commonly named after columns -- left, main, right etc.) Of course there are special cases where you could automatically show images or files on page.. or you could use repeaters to create fixed blocks with couple of options regarding text and image positioning or something like that. Depends a lot on the use case really. Anyway, my point is that current approach is very good for many situations and can be easily customized for various needs, image manager being just one example of this. Give it a good try, see how it works for you in some real life cases and if it still feels wrong, you can always implement something else for your needs. Regardless of that, one important thing to keep in mind when working with PW is that "page" is so much more than a "page" in some of the other CMS' out there and thus comparing some features between PW and it's competition doesn't necessarily make much sense. In our case a page is an object that can serve multiple purposes and hold all kinds of data for many different purposes.. you really shouldn't expect all of them to be public or even viewable

@lucas: take a look at http://processwire.com/talk/topic/745-module-want-related-pages/?p=16034 and https://gist.github.com/somatonic/3558974.

Just a quick tip: check out source for HookEvent.php. It should / could clarify things a bit, especially the comments there. Wiki article for module development isn't complete yet, but still worth taking a look at too

Sounds like a job for a module. There's a ton of material about module development around here, such as this Wiki article, that could be helpful for you in case that you decide to put it together. Then again, have you tried installing PixlrEditor module (https://github.com/PawelGIX/PixlrEditor) yet? Sounds to me like it already does exactly what you want..

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?