ryan

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')?

Good suggestion Brent. I'm not at a place where I can test it yet (on mobile), but you might just try changing the $sanitizer->fieldName() on this line to $sanitizer->name() (which allows dots), just to see if it could be as simple as that.

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

Here's some good coffee shop ambient noise: http://coffitivity.com/ I'm testing it out right now, trying to see if I can still focus with the noise.

It does seem odd to me that it started occurring after the server/PHP upgrade. The query that it says is failing "show columns from..." also reminds me a lot of a bug I just fixed this morning with FieldtypeMapMarker. Though I've never seen it occur with the images field, but the images field does do something very similar in terms of supporting DB schema changes to the field table. It looks like you are running PW 2.3.0 or earlier, based on the class names in the exception. I'd suggest upgrading to 2.3.2 (dev) and seeing if this resolves the issue. However, both PW 2.3.0 and 2.3.2 have the failing query mentioned here (FieldtypeFile.module line 261) wrapped in a try/catch block, which makes the exception here particularly unusual. You might want to wipe out your /wire/ directory completely and replace it with a brand new copy, then clear the APC cache.

This has never been the goal with selectors. I think we'd have an unusually complex selector system if it could entirely replace SQL. SQL is very powerful and–relative to it's power–probably as simple as it can be. So when needs come up that are more easily accomplished by SQL, that's the way to go. The goal with selectors is to remain simpler than SQL for the majority of cases, but not to replace everything you can do with SQL. No doubt we'll continue adding new options and capabilities to selectors in the future, but it's always got to be a balance in focusing on the things that will get the kind of usage and mileage that warrant their inclusion. If the sorting by date then reverse by time function that you mention comes up regular need for many people, then it may be worth adding at some point.

When you are running APC a good function to know is apc_clear_cache(). Put that in a file and run it, or maybe added it to your homepage template file with some code like this: if($user->isSuperuser() && $input->get->clear_apc) apc_clear_cache(); Then you could just access your site and do this: http://domain.com/?clear_apc=1. It's not often you'll need to clear the APC cache, but it's a good idea any time you see anything weird like this. However, I'm guessing that the table really doesn't exist and the error messages are correct. Though I'm also guessing the table creation process got screwed up by the APC cache somehow. I would go into PhpMyAdmin and create the table manually, so that you can either use it or delete it. Paste this into the PhpMyAdmin SQL tab and execute it: CREATE TABLE `field_event_image` ( `pages_id` int(10) unsigned NOT NULL, `data` varchar(255) NOT NULL, `sort` int(10) unsigned NOT NULL, `description` text NOT NULL, `modified` datetime DEFAULT NULL, `created` datetime DEFAULT NULL, PRIMARY KEY (`pages_id`,`sort`), KEY `data` (`data`), KEY `modified` (`modified`), KEY `created` (`created`), FULLTEXT KEY `description` (`description`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; After clearing the APC cache, try creating a new image field and see if it's still having problems?

Sorry about that guys. It turns out that it was trying to execute a query to update the schema of the DB table, before the table existed. The exception interrupted the creation of the field in the DB. I've fixed the issue and posted an update. This applies to new MapMarker fields only, no problem with existing fields (which is why I hadn't noticed). This update should also enable you to delete any fields you created that had this error (you'll want to delete it and re-create it, since it doesn't have a table). Regarding the "ENGINE=MYISAM" statement, that should already be getting added by the base Fieldtype.php. In your case, it probably didn't because the field creation process was getting interrupted. But I did double check to be sure: echo "<pre>"; $ft = $modules->get('FieldtypeMapMarker') print_r($ft->getDatabaseSchema($fields->get('map'))); results in: Array ( [pages_id] => int UNSIGNED NOT NULL [data] => VARCHAR(255) NOT NULL DEFAULT '' [keys] => Array ( [primary] => PRIMARY KEY (`pages_id`) [data] => FULLTEXT KEY `data` (`data`) [latlng] => KEY latlng (lat, lng) [zoom] => KEY zoom (zoom) ) [xtra] => ENGINE=MyISAM DEFAULT CHARSET=utf8 [lat] => FLOAT(10,6) NOT NULL DEFAULT 0 [lng] => FLOAT(10,6) NOT NULL DEFAULT 0 [status] => TINYINT NOT NULL DEFAULT 0 [zoom] => TINYINT NOT NULL DEFAULT 0 ) Please let me know if you are getting a different result or still needing to specify the engine separately?