ryan

I'm assuming that the directory replaces those pages, as they seem to now be redundant (though Mike is the only one that can answer for sure). But if they are capturing some search traffic that the directory isn't, or need to stick around for one reason or another, I'll request a listing for ProcessWire there.

It's hard to say without actually looking at it. But if one of the solutions mentioned above solves it, I think all the mentioned solutions here seem perfectly safe.

Using field labels on the front-end of your site isn't a very common usage, so they aren't automatically adjusted by language the way page fields are. But you can still get the language-specific field label pretty easily, like this: $language = $user->language; $fieldLabel = $field->get("label$language");

I'm wondering if your code that does the login might have overwritten the $user API variable provided to the template file? If so, you might want to change your use of $user to $u or some other name. Either that, or you could use wire('user')->isLoggedin() rather than $user->isLoggedin().

Antti's right that it does sound like something going on at the server side (mod_security?). But I don't think there's any reason to use 2.2.9 anymore, so if it's as simple as using PW 2.3.0, why not just do that? However, don't be surprised if the issue turns up again, as mod_security can be a real pest when used with a CMS.

I also replied to this in another thread this morning, not realizing Soma had already answered.

Chances are that the CSV file is not UTF-8? If you can confirm that it is in fact UTF-8, no-BOM, PM me a copy of the CSV file and I can give it a try here to isolate the issue.

I still can't duplicate the issue here. Let me know if you guys can think of any other factors that would enable me to duplicate it. Also, double check that your InputfieldCKEditor directory was replaced in full (rather than replaced into) when upgrading the editor. I noticed this too, though didn't realize why it was doing that (thanks for figuring it out). Maybe I should leave CodeMirror out of the installation, as it sounds like the current version is missing some things. Though I'll try updating the assets that you mentioned, but these types of errors make me wonder if there might be other problems with the current version of CodeMirror.

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.