teppo

... 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;
    }
}

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

In regards to the symlink, I am not familiar with them at all, so I will need to look into how to work one up. Thanks for the info and hopefully I will figure out the symlink part. If not I might just go the easy route and do a new pw install per directory. Although I will have a significant amount of directories and could see space being an issue.

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.

I understand everything you're saying, but I don't agree - having to add a separate field for images that belong to a different field, it just doesn't make sense to me.

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.

Basically, in my point of view, there are images (fields) and there are inline images - the latter are not independent documents, they are just part of a body of rich content.

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 

I don't like having to explain to a client why it works that way, especially if the explanation is "technical limitations". Is there a better (logical) explanation for the need (desire) to separate inline images from body content?

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

I have to add an ImageField to the page, and put in the description something like "these images are for use in the body field, and won't automatically display on the page". Looks and feels like a patch solution.

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

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/P...GIX/PixlrEditor) yet? Sounds to me like it already does exactly what you want..

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}";

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.

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?

The blocks can (and should) be defined by the developer in advance, but the clients/editors would like to combine them as they wish. The nearest close answer Processwire delivers to this request is the "Page" field. The pages can be build with that, but it's not very user-friendly: The editor has first to set up each of the child pages, and after that he returns to the page with the page field (I call it "master page") and adds the child pages one by one to the page field. If the master page is viewed, it renders the child blocks quite nicely - but the whole process of content editing takes just too long and it doesn't feel comfortable.

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

1. They hardly ever use it (The client is not to blame since they are focussed on other things like running their business)

2. They overuse it (The client is not to blame since they want it "all" and we need to decide what is really important - the goal)

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.