ryan

Why not? The way I would solve this is to create pages for shared assets, probably with a one-one relationship between pages and images. Something like /shared/images/... Give each of the shared image pages a title and an image. Then use a page reference field, perhaps with an asmSelect (multiple selection) to select the header images you want shown on each of your pages. In situations where I have image selection like this, I also like to provide a default/random selection in cases where nothing is selected (or too few are selected). So I might do something like this: $limit = 3; // number of images required $imagePages = $page->header_image_pages; // page reference field $n = $limit - count($imagePages); // n=number of images we need to get if($n > 0) { // not enough images selected $imagePages->add($pages->find("parent=/shared/images/, sort=random, id!=$imagePages, limit=$n")); } else if($n < 0) { // too many images selected $imagePages = $imagePages->slice(0, $limit); } // output the images foreach($imagePage as $imagePage) { $image = $imagePage->image; echo "<img src='$image->url' alt='$imagePage->title' />"; }

The client doesn't even want a CMS (and presumably isn't paying for it) yet you choose to built it out in ProcessWire for convenience. I like that. I would do the same thing, but it makes me smile to hear that others are using ProcessWire even when the project doesn't call for a CMS, simply because it's more convenient than building it without.

Soma's solution will work for typical inputfield forms, but fieldgroups are actually stored in a flat manner rather than a tree. So you'd have to iterate them to find all fields in a fieldset (unless I'm forgetting something, as I don't need to do this very often). $children = array(); $record = false; $name = 'your_fieldset_name'; foreach($template->fieldgroup as $field) { if($field->type instanceof FieldtypeFieldsetOpen && $field->name == $name) $record = true; if(!$record) continue; if($field->type instanceof FieldtypeFieldsetClose) break; $children[] = $field; }

When you specify PHP as the type, then the Hanna code is a block of PHP. But you should be able to specify a closing PHP tag like ?> and then be in your HTML. If that does not work, start your Hanna code with: <?php ?>, which should prevent Hanna code from automatically inserting an opening PHP tag, and leave you in HTML.

I don't think the voting opens till September, but you can still click "like" for ProcessWire, if you want to. That "like" system is the same one we use in the modules directory, and something I plan to release as a module soon.

That's correct, that would require shell access. Anyone know if symlinks can be created via FTP? I'm guessing not, but haven't researched it.

Adrian, regarding 'name': I like your solution in post #7. I've added it to my code and will test locally and commit it soon if all works well. Regarding the 'title': There is no 255 limit for 'title'. Like WillyC mentioned, the only limits to title are those that you introduce in the field settings. If your title is getting truncated at 255 chars, then it's likely configured for a max length of 255 chars. The default max length setting for title is 2048, but this can be increased or decreased as desired in the field settings.

You can assign language-specific labels or descriptions to fields by setting either $field->label or $field->description with the language ID appended to it. Since the string value of a $language is its ID, this you can just do it like this: $es = $languages->get('es'); $fr = $languages->get('fr'); $field->set("label$es", "Spanish Label"); $field->set("description$es", "Spanish Description"); $field->set("label$fr", "French Label"); $field->set("description$fr", "French Description"); The above is resolving to something like this (where 123 is the ID of Spanish and 456 is the ID of French): $field->label123 = "Spanish Label"; $field->description123 = "Spanish Description"; $field->label456 = "French Label"; $field->description456 = "French Description"; When setting for the 'default' language, make sure you are setting just "label" and "description" without anything appended. For instance, this won't work: $en = $languages->get("default"); $field->set("label$en", "English Label"); // this is incorrect because default language has no ID appended $field->set("label", "English Label"); // this is correct $field->label = "English Label"; // this is also correct

Not yet, but it's good to hear the request come up again. When the same request comes up more than once, it gets bumped up the priority list. I will plan to look at this in more detail soon.

I'm open to this sort of thing in selectors, especially if it can be added on as easily as you mentioned. But it probably belongs as a module rather than part of the core selectors, because selectors don't imply "database". That is just one of the contexts of selectors, and we've been working hard to make the system as consistent as possible across contexts. So I'm a little reluctant about introducing database-specific functions into selectors in the core. But would be enthusiastic about providing new ways for modules to hook into selectors to add their own functionality, if possible.

This is the nature of how the ajax uploading works, as it triggers a page save (though saving only the field you upload to). One way we could solve it is to add a status field to the file/image fieldtypes, giving them a way to identify a file as unpublished. Not sure how simple it will be to implement, but this is one of the things I've had on my list for awhile. If it comes up more often, I'll definitely bump it higher up the priority list.

Can you guys tell if the issue is in the core or with CropImage? If a large image is causing it to fail and leave an untracked file, or something broken, then that's something we'd want to fix. Though when an image is so large that it consumes all memory and goes fatal, I'm not positive if the usual error checking will work. So the option of defining some reasonable maximums, as mentioned above, seems like a good idea.

CMSCritic just launched another part of the site which is a directory of CMS products (powered by ProcessWire of course). Hope you guys enjoy: http://www.cmscritic.com/dir/ While you are there, maybe click the "like" button for ProcessWire if you are so inclined.

This is a little off topic, but since it involves headphones, it's probably more in topic here than anywhere else in the forum. If you haven't heard 3D stereoscopic sound (I hadn't), you need to try it, it's really quite cool. To experience it, you need to use stereo headphones. Virtual barber shop (this one works best if you close your eyes): Thunderspace (put headlines on and click play on the video): http://thunderspace.me/ What's cool is also how simple 3d stereoscopic sound is to achieve. You just record the sound with two microphones: one where each ear would be on a person. Your mind apparently does the rest in making it 3d/spacial.

Thanks guys, glad that you like how this is looking. Though you are giving me more credit here than I deserve. I didn't realize there would be so much interest in it, otherwise I'd have worked on it sooner! It's been on the to-do list for awhile (with a million other things), but didn't become urgent till I remembered/found out it was needed by the end of August. So figured I better get busy! I like the way they define them there too. Longer term, I'd like to make a new Selectors inputfield that lets you build selectors this way, because it's a little more friendly in some ways, even if less flexible in others. But it's a good option to provide in addition to text input of selectors. However, I'll build that Inputfield later as something separate from field dependencies, so that it can be used elsewhere and by other modules, etc. I agree, especially in the context of the video. Though I also think subtlety is important so that required labels don't become a distraction (especially for common required fields like 'title'). If a field is required, and the user missed the visual que, they will still find out about it when they save. The field dependencies just add (or remove) the "required" class to the .Inputfield container, so the actual look of required fields is dependent upon the admin theme. But I think the field dependencies could do a quick fade-out/fade-in to indicate that something has changed about the field's state. I appreciate the compliment. But this is just not true. There are always bugs to fix, and I'm sure there will be several to find and fix with field dependencies, just like anything else (perhaps more so, given some of the complexity in it). So when those of you on the dev branch start using this, don't expect everything to work perfectly. Instead, experiment, test and tell me when you find something that doesn't work quite right. There are so many scenarios that could happen with field dependencies that it may take a few iterations till we've covered them all. There are also some fieldtypes that may not be compatible with field dependencies. For instance, we don't currently have a way of polling the value from the rich text editors, since they don't update the related <textarea> elements on the fly. We could do it by accessing the TinyMCE and/or CKEditor API functions, but I'm not sure that I want to bundle TinyMCE or CKEditor-specific code into the field dependencies–that's the type of dependency you usually want to avoid in code. So you'll be able to show/hide rich text fields based on the values from other fields, but not based on the values in a rich text field. To be honest, I'm not sure that's a problem though, as I don't see rich text fields as being likely sources of dependencies anyway. Those 3 fields are configured in the template for 33%, 34%, 33% width. Without field dependencies they would all fit on one row. When a field is removed from the mix as a result of a dependency, it simply expands the width of the last remaining field to fill out the row. The concept is really simple. It came about because I didn't like the look of the uneven rows when I started dynamically removing fields as a result of dependencies. While the concept is simple, the implementation proved to be a challenge... it's one of those things I thought would take 30 mins, and it ended taking much longer. Though a good part of that is just that I don't use Javascript every day (I'm definitely not an expert at it), so it can take me awhile to get things right.

I can't seem to duplicate this one (using same version of Chrome and InputfieldCKEditor). I've tested both regular and inline mode. Are there any other factors, modified CKEditor settings, etc., you can think of?

Makes sense to me, I'll add it. Thanks.

I think that Pete actually was pretty far along with his IP.Board module. I had done some testing with it here and it was quite nice. Pete are you still working on this?

The system actually does rename the htaccess.txt to .htaccess for you, and when it can't, it gives you an error message asking you to rename it. In your case, it sounds like there may have been some other factor interrupting your installation, or maybe something about the way grabpw works? Grabpw is a handy tool in many situations and in environments that support it, but it's an alternate option, not the default one. So for anyone else reading the thread, if you attempt install with grabpw and get a 500 error, try installing using one of the methods outlined in the readme file.

Awesome site! You create some of the most beautiful ProcessWire-powered sites I've seen.

In that case, you would't need the function at all. Your code could just do something like this: if($input->get->sort == 'floors') { $sort = 'floors'; } else { $sort = 'title'; } I think that putting them in a select box is a good way to go. See the modules site for an example: http://modules.processwire.com/modules/?sort=-created

If you select FastCGI does it put you on PHP version 5.5.1? I've not tested PW with PHP 5.5 yet, would be interesting to know if there is some issue there. I'm using MediaTemple accounts already via existing clients, but haven't seen any issues like this, but it sounds like this is a newer grid server than the ones I've used.

All fields are assumed to have at least a "data" field, so you can also query it just by specifying the field name without "data", i.e. $p = $pages->get("images%=mode");

Dev branch versions aren't official versions, other than version "dev branch", so we don't keep separate downloads of them. The version numbers are primarily so that when we apply some big change, we have a way of being able to track it with bug change reports.

Soma, is it necessary to pass the $userid in the URL since you'd already know the user from the wire('user')?