ryan

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.

You might try moving it out of the tab, just to see, though I doubt that's it. If you are using an admin theme other than the default, you might also try switching back to the default, just in case. Lastly, double check that there aren't any errors in your JS console. Since you are no longer stuck, as it all starts working after you save, and I've not been able to reproduce it here, lets wait and see if someone else can. That might give more clues how to reproduce it.

This isn't specific to ProcessWire, but HTML checkbox fields in general. When it comes to seeing if a checkbox is checked, the presence of the field in $_POST means that it was checked. If a checkbox is unchecked, it doesn't show up in the $_POST. Whatever value you assign to a checkbox field doesn't really matter, as that isn't the indicator of whether it was checked or not. Using some non-zero value in your checkbox does make sense though because a statement like this would indicate whether the checkbox was checked or not: if($input->post->my_checkbox) { // checkbox was checked } else { // checkbox was not checked }

That's great Joss! Let me know if I can set you up with a Wiki account. We need all the help we can get, even if some things are just stubs, etc. I like where you are going with your cms notes pages.

I let Google translate the article for me, and German is one of the languages that it does not do so well with in translating to English. However, I could understand enough to see that this is one of the best articles on ProcessWire I've seen. Michael Van Laar really has a gift with communication like this. He managed to cover a lot of territory there in a very accessible way, and it really draws in the reader. Thanks for writing this Michael!