ryan

// assuming your images field is named "images": 
$pagesWithImages = $pages->find("images.count>0");

// now that you have all pages with images, you can put them all in 1 array if you want
$allImages = array();
foreach($pagesWithImages as $p) {
  foreach($p->images as $image) $allImages[] = $image; 
} 
 

I don't actually have any experience with IIS, and have only rarely come across it over the years. As a result, I'm not sure how to provide support for it, and that's why I've always kept Apache as a requirement for PW. But I know there are others here successfully running PW under IIS, so it certainly seems possible. The biggest issues will likely be centered around the .htaccess file. If there is something that makes IIS understand an Apache .htaccess file (including especially rewrite rules), that would be desirable for sure. 

- Admin Theme is not recognized
We installed the "Teflon Admin Theme" in the common way, but PW is still using the standard theme.

I don't think this could be an IIS-specific issue. Double check that you've installed the new admin theme in /site/templates-admin/ and that it is fully readable by IIS. 

- Page order is not saved
If we sort the pages in the Admin by using the move function, the new order is not saved. After logging in and out the pages have the old order.

This also doesn't sound like an IIS-specific issue. Instead, it sounds like the pages might not be set for manual sorting. Either that, or a potential browser issue. What browser/version are you using?

I really prefer to keep images in their own fields, separate from a textarea/TinyMCE field. It's not about any limitations at all. I've just found this to be the most flexible way of managing this over a long period of time. ProcessWire has always been built to what was ultimately most flexible rather than trying to do the same thing as other CMSs. But I do recognize that it's controversial and may seem unfamiliar if one is already used to a different way. I'm not against alternative patterns for this if it helps appeal to more coming from other CMSs, though not at the expense of the current one which I think is the ideal (at least for my needs). So I always try and keep an open mind about it and am open to supporting more options for those that want them in the future. 

Thanks k07n, I have applied that update. 

will have dependable select fields, processed through ajax, e.g. address (country->region->city)

Field dependencies are coming to ProcessWire and FormBuilder later this year, though won't be ajax driven. 

will have nested sub-forms, opened by click in modal window

This probably would not be a good use case for FormBuilder. 

will have custom CSS design

You can create your own themes with FormBuilder. They are based upon jQuery UI's theme framework. 

Would you recommend to use Form Builder for such kind of input form development or it is better to write something from the scratch?

What you are talking about sounds pretty custom, and seems to me more like something one would build from markup rather than with a form building tool.

IIS isn't technically supported by ProcessWire. Though I understand that several people are successfully using PW in IIS. But just want to point out that this is not the recommended environment for PW, and it would not surprise me if some things don't work. Actually, I'm impressed that it apparently works for the most part–maybe someday we can officially support IIS. 

After implementing the Language Support Module and the language.zip file can not be uploaded. PW shows the upload status bar, but after 100% are reached the field is empty.

This is one component that is LAMP-specific at present. You will have to unzip the language pack locally and upload the JSON files individually. I'm hoping to convert the unzip process to one that is cross-platform before long. 

This is a really excellent example of a job posting, thanks Jason! You included all the info that I think people would be looking for. I also think it's very good that you included a timeframe, budget info, and screenshot/mockup. I'm going to point people to this the next time someone asks how they should post a job. 

Is it possible for this to work with subfolders instead of sub-domains?

You don't really need any kind of multi-site support if you are just talking about subdirectories. If you want them to use the same database, then just make them all run from the same PW install. If you want them to run from separate databases, then just install PW in the root and the subdirectory… should you want to share the same core, then make /subdir/wire/ a symlink to /wire/. Though when I'm running more than one PW install on the same account, I usually just keep their cores separate so that I can upgrade and test them separately. But it's perfectly fine to run multiple PW installs on the same domain. 

That's great about the ProcessWire presentation. I really enjoyed the slides. I can't get the video to play more than one frame at a time, and I don't know what's being said either (I don't have multi-language support installed). But it looks like it went on for a good long time. Anyone that speaks German have a summary of what was said / how it went? Also, who did it? Big thanks to the presenter for taking the time to do this.  

The scope of the project you mention sounds pretty broad and will be a big investment on your part regardless of what system you build it in. I think part of your decision has to come from budget. If you are testing the waters rather than dedicating your full time to this project, then I would pursue whatever path has the most components already built, even if the result is not 100% what you want. I think that means looking into what's available and built through WordPress and IPS. I especially like the IPS option in your case. Maybe it's not perfect, but it does at least get you more than half way there and has the level of integration between components that you are looking for (including ecommerce). There's no doubt that you could build this all beautifully in ProcessWire, but I wouldn't recommend such a big project being your first in any CMS or framework. Whether ProcessWire or another platform, you'd want to have some significant experience developing apps/sites before pursuing such a big project in [x] platform. Unless you've set aside a large budget or don't have a full-time job already, find the tool that gets you closest to your needs before having to get into code. Then, once you've proven the concept or made it a success, develop it exactly the way you want it in ProcessWire or a full-blown framework. But stay with us here and start learning ProcessWire in smaller chunks and on smaller projects, and before long you'll be ready to build anything you can imagine. 

In future versions of ProcessWire, including the current PW 2.3 dev branch, you can also do this:

if(count($options['pageStack'])) {
  // don't include header/footer, etc.
}

$options['pageStack'] is an array of pages that called render(); before the current one. It basically gives a way for a page to discover the context it is being rendered in.

Is "sets output formatting to false" necessary since it's a new page/user?

It's not necessary, as anytime you create something new the output formatting state is off. Of course, there's no harm in a $user->of(false); call either, but it's not technically necessary.

Another way you can create a new user:

$u = $users->add('ryan'); 

Do we have to sanitize the password before storing?

The password is actually one thing (and probably the only thing) that you really shouldn't sanitize, because you don't want to change the password they entered. What you should do instead is validate it, making sure that it's a string with some length and at least [n] characters (whatever your requirements are). By validate vs. sanitize, I mean don't sanitize (clean) what they entered, but give them an error and make them enter something new if it doesn't validate. 

I'm not sure what's up but it looks like the caching from GitHub was failing, as I tried to reload it several times but no luck. That issue has turned up in the past too. I went ahead and made /api/cheatsheet/ a redirect to http://cheatsheet.processwire.com - major thanks to Soma for developing the Cheatsheet into a ProcessWire site. It's quite impressive the way he's got it setup with Fredi too. I'm going to start adding more new PW 2.3 functions to it today. 

You can enable this option by editing your /site/config.php and setting $config->advanced=true; Next edit the template (Setup > Templates > edit) that you want to be able to change the createdUser. Click on the "system" tab (this is only visible in advanced mode). You'll see checkboxes for various options–check the appropriate one and save. Go back to your /site/config.php and remove the $config->advanced line you added earlier… as you don't usually want advanced mode on (some settings can be dangerous). But you should now have the ability to change the created user for pages using that template. 

I've now got ProcessWire (local dev) fully converted to PDO and running with both PDO ($database) and mysqli ($db) available to the API. When in the admin, the debug mode info at the bottom highlights queries from each, so that you can more easily identify mysqli queries that you may want to convert to PDO. As a matter of efficiency, ProcessWire doesn't actually initiate the mysqli connection until you access something from the $db API variable. Meaning, the core and a stock install of PW doesn't use mysqli at all (or attempt a DB connection through it), but it makes it available if any modules or your site want it. In order to achieve this, I had to abstract the existing mysqli Database class behind a passthrough gatekeeper class. The only way you will notice that is if you are using any kind of type hinting for the old Database/mysqli class, OR if you are using procedural mysqli functions. I don't think I've seen any modules type hinting the old Database class or mysqli except for my own (like Form Builder). But I do think I've seen procedural use of mysqli at least once (I think it might have been in one of Teppo's modules?). Anyway, not sure if this matters to anyone, but just in case, here's the things to watch for with mysqli: 

// If you are type hinting mysql or Database like this…
function example1(Database $db) { ... } // this 
function example2(mysqli $db) { ... } // or this

// …then remove the type hinting:
function example1($db) { ... }
function example2($db) { ... }

// if you are using mysqli procedurally with a $db param:
$result = mysqli_query($db, "SELECT COUNT(*) FROM pages"); 
list($count) = mysqli_fetch_row($result);

// use it without specifying $db param…
$result = mysqli_query("SELECT COUNT(*) FROM pages"); 
list($count) = mysqli_fetch_row($result);

// …or better yet, use the OO version:
$result = $db->query("SELECT COUNT(*) FROM pages"); 
list($count) = $result->fetch_row();

Since PW 2.4 will be backwards compatible in terms of the database, lets not worry about switching our 3rd party modules over to PDO until 2.4 is actually out in a stable version, which is still months away.