ryan

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?

I'm not–I've only ever used PHP on their servers as an Apache module (the default way they have it setup).

Usernames are just page names. If you aren't using them for user login, and don't want to append numbers, etc., you can always do something like this: $user->name = $user->email; The "@" will get converted to a "-" (as will less commonly seen email characters like "+").

I wouldn't consider it a bug necessarily, but it sure would be nice if it would throw a JS error or something. This was a difficult one to track down.

I wasn't able to duplicate this one. What browser? Any chance I could get a look at what you were pasting? Inline mode actually puts the contents directly in the HTML document (which is why it's called inline mode) rather than in a safely iframe'd window like regular mode. As a result, something as simple as an unmatched tag can break the entire page editor, and make it very difficult to fix–you'd have to switch back to the regular CKEditor, fix and save it, then switch back to the Inline editor. That's why something like HTML Purifier is so important in inline mode.

Ryan, glad to see you working on this module! It looks like you already figured this out, but /site/assets/cache/[your dir] is usually a good place to store things like XML cache files. If connected with a page, then just use the page's files dir ($page->filesManager->path or $page->[your files field]->path). Horst is right that you can add files to pages and manipulate them using PW's methods from there. He's also written an excellent manipulation module. If you just need to resize images, also look into PW's ImageSizer class, which is ready to operate on any file (doesn't need to be connected to a page). In the dev branch, I'm about to push some updates to that class from Horst that add sharpening and auto rotation among other tweaks. Lastly, I wanted to mention that the dev branch also has the WireHttp class, which you may find more convenient than CURL.

I like to solve it by having a lot of specific templates, and only 1 basic-page type template. This is in part because I really like to keep pretty strict family settings for each template, so that the client doesn't ever have to decide what template to use when creating a page, and they don't have the option to create pages where they shouldn't. It also opens more options for current or future access control. But the actual template files are pretty spartan, and many of them totally blank, some set or modify a few variables, and others simply include another. I rely on my prepend/append template files to handle all of the common stuff (_init.php and _main.php) leaving the other template files focused purely on any components that are unique for the template. In terms of scalability, I also like having lots of template files, even if there isn't much in them, because future additions and modifications are very simple. So far this way has worked really well for the last few sites I've used it on, but I don't think any one method works best for everyone because we all have slightly different needs.

Also take a look at the Foundation site profile that uses both $config->prependTemplateFile and $config->appendTemplateFile options. It also takes the approach of defining a bunch of shared functions, similar to what you were trying to do. I have no idea why yours didn't work though, as if you include a file with functions defined in it, then those functions should be available to any code that follows it, regardless of what file the code is in. I think that either the Skycrapers or Foundation profiles would be good examples to look at.

I haven't run into that here. But we are using TypeKit. Please let me know if it continues or if anyone else runs into it?

You actually don't need or want the "sort=sort" at all when it comes to a children() call, because it's already assumed, given that parent pages already specify a sort. You would only specify a sort if you wanted to modify the default sort. But there would be no condition under which you'd need to specify a sort=sort to a children() call simply because if the default sort is something other than sort=sort, then "order in the admin" doesn't exist by definition. I don't know why specifying it is breaking it without looking into the code (not in front of it at the moment), but my guess is that it's canceling the default behavior in this case. As a result, I think if you simply omit that part, it should work the way you want.

I'd consider that a bug. There are reasons to install language support even with only 1 language, like if you want to take advantage of static translation capability in template files. I've added this as an issue on GitHub, and I'm hoping to get through the current queue of issues here over the next few days.