ryan

Thanks Marty, You now have access to the form builder board. Also I'm posting a new version 0.1.9 tomorrow morning which includes some file field fixes discovered by way of mademyday earlier today.

Yes, the recipient email can be configured to change according to the value of any field in the form. You can say something like: if location=Savannah, email=midnight@garden.com

Thanks a lot for that great summary Christoph! Sounds like a great show. So PW's not sexy eh? Must be that admin theme... We need Renobird to share his CSS tweaks with us and/or have Soma and Nikola take over control of the core admin theme(s).

Thanks Pete!

Talking too much with the database is not what slows a site down. Reducing queries doesn't necessarily improve performance. You can have a few hundred queries that execute faster than one query. It comes down to good indexing and queries that use those indexes well. When optimized well, MySQL is not likely to be a bottleneck even with a lot of chatter. Now if data isn't indexed well, things get slower as the scale increases. Combine that with more unoptimized queries and it gets even slower. But this isn't ProcessWire. ProcessWire does support the 'autojoin' option for page references, which causes those references to be joined in the page-loading query. This has potential performance benefits if the quantity of joined page references is relatively small. But I don't recommend it unless you plan to use those page references on every single instance of the page. Otherwise, you are joining extra data for the times when you don't actually need it. Using the FieldtypeCache is yet another way you can join more data at once. This particular Fieldtype actually keeps a separate cached copy of the page's data encoded into a one-time-load bundle, bypassing load from the field_* tables. But ProcessWire is pretty fast in the way it works natively, so the situations where one benefits from autojoin and FieldtypeCache are fairly rare. But they are there when you need them.

Thanks Interrobang this is great! Perhaps so, but practically speaking I wonder if it's worth it. This being an API function rather than an interactive one, it seems like the developer be setting a default position and sticking to it. It sounds like you know the workings of these functions a lot better than I do. I've always been a bit confused by the various GD function names. But I'm good with whatever you think produces a better result.

The method I often use is very similar to what Martijn posted. I'm thinking about adding a new $config variable where we can specify what files should be automatically included before a template is rendered. That way we don't even have to do remember to do an include("./global.inc"); The result would be kind of like an autoload module, but one wouldn't have to know how to make a module to benefit from it.

Okay that simplifies a bit then. The second structure in my previous message would still be the best one to use, but you can use two multi-selects (categories and uses) without any repeaters. Checkboxes would definitely be nice for the uses, and either checkboxes or asmSelect should be nice for categories. Since all selected uses apply to all selected categories, your output method would be something like this: foreach($page->categories as $category) { foreach($page->uses as $use) { echo "<li>$category->title $use->title</li>"; } }

Steak sauce?

This is really awesome Philipp! Thanks for posting. Now I want one of these. I wonder if there's some way to do it without Tumblr. Would be great to have an app that you just take a pic, tap "looks good" and it shows up on the site. iPhone doesn't give us many options when it comes to uploading pics, so I'm guessing an intermediary like Tumblr really is necessary. Really a beautiful solution and site you've put together there.

Thanks guys. I've always liked the idea of a conference in Atlanta, as we're kind of a conference capitol of sorts, with the world's busiest airport and all. But there aren't any PW users in or around Atlanta as far as I know, so it doesn't make a lot of sense to ask people to travel here purely for my convenience. On the other hand, if we piggybacked on some other conference here (AEA comes twice a year) that might be greater incentive for people. Most of the ProcessWire team is in Europe, so always thought that made the most sense. But that doesn't mean we have to limit it to that. Certainly one in the US makes sense too (just not as much). Also, if folks still want to have a conference on the original timeline, I'd totally support it in any way I could even if I couldn't be there myself.

These are hilarious. Might be fun to get a collection of these displaying randomly in the footer of the forum sometime.

On your 'details' tab of the field, check to make sure that your field is a "Single Page" and not a "Multiple Page" field.

Can anyone tell me more about this? Since it's audio, I don't even have a chance of attempting to translate it. Though from the program summary it sounds like they had some good things to say about PW? I think it's great that people are writing and talking about PW so much this week.

It was getting noticeably slow to load that videos page here on my desktop, but that may because I'm on the other side of the ocean. I'd probably paginate every 100 items or something. Though the Google Images infinite scroll method may be nice too, but those still reach hard limits (at the client side) eventually too. Regular pagination is probably the safest bet, even if nothing more than a "show more" button.

I think it's a good idea. Some other good ideas for new boards have also been posted by mademyday and mindplay.dk recently (guys having names starting with 'm' know how to call 'em), so I'm planning to add them all before the end of the year. I'm going to be traveling out of wireless range all next week so won't be online. But will plan to add these when I get back unless Pete beats me to it.

I haven't actually ever used CURL other than copy/paste from examples, so don't know what the proper method is to make it behave the way we'd want. I've always avoided CURL just because the examples always look so darn cryptic. But PW now comes with a WireHttp class that uses sockets and should give us an independent way of handling this stuff that doesn't rely upon allow_url_fopen or CURL. Actually, it attempts to use allow_url_fopen, but if the option isn't there, it falls back to using sockets. Meaning, it should work anywhere. The equivalent of your CURL example would be this: $http = new WireHttp(); $data = $http->get($url); // for a GET request // ...or... $data = $http->post($url); // for a POST request Should any GET or POST vars need to be included, then they must be passed in an array as the second parameter: $vars = array('foo' => 'bar'); $data = $http->get($url, $vars);

I have some news about the potential conference in 2013. When I posted about this originally, I didn't know that we had another baby girl on the way, due around May. I am very happy about this, but it would also interfere with my ability to attend a conference. The baby would be too young to travel, and it's too much for me to ask my wife to be alone with a newborn + a 3-year old, while I travel across the world. So I have to put this conference plan on a back-burner while we figure out a better time to do it. Thank you for all of your interest in this conference. I'm really thrilled at all the enthusiasm this conference idea has received, lets plan to reschedule.

The wiki is too small and in too much of an early stage for us to say for certain what it will become. But I've been thinking it would (at the very minimum) serve as a interim place for content that could be pulled over into the main site's documentation. There is already some stuff in there we should pull over. However, if the wiki starts to become a great resource in it's own right, then we'll make it look like the main site and put it in the navigation.

I'm replying to the original message, as I'm not sure I totally follow everything after and trying to get through my message queue before 11. The structure you've got there I don't think is ideal because of the repetition. It looks like your products need to be able to appear in multiple categories and uses and various combinations, so I think you are better off taking the structure out of it until you've got some one-to-one relationship that would lend itself to the structure. Further, it looks to me like you need a secondary relation (use) related to the first relation (category), rather than independent from one another. Assuming I understand it all correctly, here's what I'd probably do initially: products product1 product2 product3 categories water-jointing water-repairing water-tapping gas-jointing gas-repairing gas-tapping water-jointing water-repairing water-tapping other1-jointing other1-repairing other1-tapping etc. Each product would have a multi-select page reference to categories. This works great if you don't have a huge amount of categories. But if you do have a lot of categories, then it the redundancy of having 3 pages (jointing, repairing, tapping) for each category may get annoying. In that case, I would take this route: products product1 product2 product3 categories water gas other1 etc. uses jointing repairing tapping Then you would add a repeater field called categories_uses (or whatever you want) to your product template that contains two fields: category and use. The category field would be a page reference to your /categories/, and use would be a page reference to /uses/. Both would be single select fields (not multi). Using this strategy, you could edit any product and add as many categories_uses items as you wanted. For each one you'd first select a category and then a use. You could cycle through them in your product template like this: foreach($page->categories_uses as $item) { echo "<li>{$item->category->title}: {$item->use->title}</li>"; }

That's something that we already have, as the comments appear in the page editor for every page. The purpose of this module is to provide all the other possible views. Though it could be said that this interface is better for managing comments in general, so we may eventually make it the standard and keep them out of the page editor. This is in part because the page editor doesn't scale well to situations where you start having hundreds of comments on a page. It'll work, but it's not designed for pagination, whereas the Comments Manager is. So a page-level filter probably will be coming to the Comments Manager.

Here's another way to do it: function switcher($str) { static $mem = array(); $items = explode('|', $str); $n = isset($mem[$str]) ? $mem[$str]+1 : 0; if(!isset($items[$n])) $n = 0; $mem[$str] = $n; return $items[$n]; } Usage: <div class="<?=switcher('left|right|center')?>">

I think you might need to name the function something other than 'switch', as that's a reserved word in PHP. http://php.net/manual/en/control-structures.switch.php

One of the things I was trying to get across is that the majority of cases of these "storing data" pages really do have a place in the front end of a site, whether for you or the users. This is one of a few reasons why we use page references for selection fields too. Any time you've got a page that you are using just as a data container, consider the potential of what more it can be. It doesn't have to be prominent or even linked to anywhere if you don't want it to be, but most data deserves a view, IMO. There was a time when ProcessWire required a view (template-file) for every template, and I often think it was better that way. Though flexibility wins, so had to make it optional. I'll consider ways to alter the style of such pages. But in the short term, definitely check out mindplay's module as it accomplishes what you are looking for, and more.

In TinyMCE, that span[style] just is a way of saying "allow a <span> tag with a style attribute." Since there aren't such things as a color, size or face attribute for a <span> tag, I think you can safely omit those and just specify span[style]. So that's all I was trying to say in the previous message, is that probably people need to specify span[style] rather than span[face|size|color] in their TinyMCE field. Though I could be wrong, as I've been fooled by TinyMCE many times before.