ryan

Based on what I understand so far, I think responsive is probably the clear way to go if you are starting from scratch on the entire site. Though that's not the case in my situation. The interest in the mobile version of the site came up after we were nearly done with the site. If using javascript is acceptable, I suppose all the <img> tags could easily have their src attribute changed to reflect the screen width and one of a few different image sizes. Though the src attribute would probably have to point to some common placeholder initially since the browser initiates the image http request (I think?) right after it sees the <img> tag. Or of course, the <img> tags could just be written with javascript. But of course such a site would lack images if the client had no javascript... so less than ideal.

I got to play with the new InputfieldFlickr today – it's fantastic. Everything worked perfectly and this is such a cool option to have. It opens up all kinds of possibilities. Only question I ran into is on the search: If I typed in multiple words like "disney dream" I didn't get any results. Whereas if I typed "disneydream" (1 word) I got plenty of results. So I think it must be a tag search, but just wanted to make sure I was using it correctly? This module is so nicely put together and useful–Thanks for building this!

I agree that we need a good page clone/copy module of some sort. I'm conflicted as to whether this should be a Process of it's own (a separate add-on tool), an option in the PageList like "edit | new | move | copy", or an option on the 'add page' screen. In PW1, it was accomplished with a separate tool (see attached screenshot). For your particular need, another good option might be to create a module that hooks to $pages->save and creates the copy automatically where you want it, when it detects that it's a page that should have multi-language versions. I'll be happy to guide you through creating this if you are interested.

I've had the same issue once, and was able to reproduce it on one server and not another. It seems to be related to some MySQL setting. MySQL seems to ignore the case when renaming a table, but then pays attention to the case when trying to select from it (resulting in an error). I ended up having to rename the table (field_Something) to something completely different (field_tmp), and then rename it back to the lowercase version (field_something), because MySQL did nothing when trying to rename field_Something to field_something. I'm thinking we can avoid the problem entirely just by having PW enforce lowercase table names, regardless of the actual field name's case.

But that's just for assets loaded from CSS. On a dynamic and image heavy site, those images are usually coming from <img> tags, not from stylesheets. All the images would still get loaded in full, even if they were resized in CSS. My thought is that CSS image resizing would be really inefficient for an image heavy site... it doesn't seem acceptable. Is there a responsive solution for this? I can think of some hacks to achieve it, but am interested in best practices and am not yet full up-to-speed with RWD. I'm posting this as a real question because we're in the process of trying to determine whether to go responsive or mobile for villarental.com. I want to go responsive rather than mobile, but am concerned that I have to make major sacrifices to the mobile experience OR the desktop experience in order to do so. So I'm really conflicted as to what approach I should recommend.

Tested on a couple of sites here and PHP's garbage collector seems to be doing it's job. I don't have any session files older than 24 hours. If it helps, I've attached a screenshot from the phpinfo() session section on one of those sites. It might be good to compare to yours and see what's different. I'm guessing it's something in the garbage collection (gc_) options. Please let me know what you find. We can always override PHP's values for these (currently we don't override the gc_ options).

Adam, your original selector would have worked, but it's an oversight. Technical explanation: That the second find() is going through WireArray::find() rather than $pages->find(). The WireArray::find is all done in memory, whereas the $pages->find() actually translates to a database query. The two are supposed to function similarly from API, but the WireArray version is missing a few things present in the $pages version (undocumented things, see below). The "sort=random" is one of those things, but no longer… I just fixed that in the latest commit, so your original selector should now work in the latest P21. https://github.com/ryancramerdesign/P21/commit/f083f7d4d433d6c0919101f2c17b15059b6ab2b4 For reference, the other [undocumented] things not yet implemented in the WireArray version are: status=hidden status=unpublished status=locked status=max include=hidden include=all check_access=1 sort=a, sort=b, sort=c (sorting by multiple fields) These will all be implemented, and then documented once consistent across the $pages->find() and WireArray::find() versions. Beyond the above undocumented items, the two should otherwise function the same at present. Also note that Pete's version is a good way to go, and perhaps more efficient than using a second selector.

I've not had to build a multi-language site myself before, but based on what I've read of your needs I tend to think you should take the multi-page-tree approach. This leaves you with no concerns about search engines as every URL is going to be unique and indexable without you having to consider URL segments or session variables. It also means you won't have to maintain multiple versions of each field. On a site as small as what you've indicated, I think that the disadvantages of the multi-page-tree approach really aren't going to matter much. If you were working on a site where the number of pages was a lot higher than the number of fields (including all language versions), then the multi-field approach would probably start to make more sense. But if my understanding of your case is correct, I think the multi-page-tree will be better.

I'm back! Had a great trip. Thankfully, I didn't get seasick–actually really liked being on the ship. The last day we hit that hurricane Emily in the Bahamas and the motion of the sea became a little more noticeable. Actually I still feel like I'm on the ship as my mind seems to think everything is still rocking back and forth. Kind of fun actually. Here's some photos from the trip. http://goo.gl/IQ1ma Thanks all for keeping an eye on things here while I was gone. And thanks especially to Adam and Antti for running the forum! I'm hoping to get all caught up with email and forum posts over the next 2 days. Thanks, Ryan

@slkwrm: That's interesting to see what you mentioned with the "open core" vs "open source", even if it's just different terminology for the same thing. Though my opinion for ProcessWire is that I don't want to blur the line about it being fully open source, and a term like open core seems to add some ambiguity to that line. But what 3rd parties do is separate and I want to encourage anyone that wants to develop modules to run in PW. @pete good idea on the jobs board. I'm sure this will be one of the things we'll want to have once reaching that critical mass.

Shane--hold off in upgrading for another week or two. There are major core changes from 2.0 to 2.1 so an upgrade script has to be involved. This upgrade script is in production and it's not quite ready. Stick with 2.0 for a little while longer. Don't do any manual table changes with PHPMyAdmin, because that's just a small part of what's changed. So in the short term, I'd recommend removing the 2.1 /wire/ dir and putting the 2.0 /wire/ dir back in place (as well as /index.php, if you replaced that too).

Both versions just uses PHP's session functions, so ProcessWire isn't involved in the clearing of the session files. PHP's garbage collection should take care of them. But it sounds like it's not? I'll check around on some of my sites to see if the same thing is happening there.

Thanks guys, I'm about to get cut off the internet till Sunday... Though today is the first I've been online since we left (I'm on a cell phone).. We were in Orlando for the last couple of days and now on board a ship called the Disney Dream. We're at a port in Cape Canaveral (can see the shuttle launch pad). I've never been on one of these things before and hoping I don't get seasick! Can already feel the boat moving and we haven't even left port. Apparently the Internet is crazy expensive and doesn't even work half the time, so probably not going to try once the 3G signal gets out of range. Our baby is sleeping so I'm just chilling on the cell phone trying to be quiet. Thanks again for keeping an eye on things here.

Just to clarify, fieldtypes handle data to/from DB (not inputfields). Every field in your site has a type (where the name fieldtype comes from). Part of that type is a database schema and methods to load/save the data from the db. Though most fieldtypes just use the inherited load and save functionality from the Fieldtype base class. Whereas inputfields just handle interactive input in the admin (aka input widgets). At their simplest, they are just an HTML form field like a text or textarea. If you were working just with the PW API, inputfields would never come into play (unless you wanted them to for some reason), because there would be no form or user typing stuff in. Of course there are no rules about any of this, so just describing the way the core and core modules work. Something like the flickr importer obviously goes far beyond a typical input widget, so approach changes with needs.

Thanks for making this, i can't wait to check this one out when I get back! Congrats on this module, based on the video I saw before, this is a pretty awesome thing you've put together.

The PageListSelectMultiple is supposed to work with parent, at least that was the intention. If it's not working (not saving your descendent selections), then chances are it's a bug... An over-validation. As a temporary solution till I get back, try what Antti suggested, or just set no criteria at all for the pages, and see if you can just let it work with the entire site tree, temporarily.

I'm going to be at sea without internet access for a few days (till about August 9th). Though I'm hoping to come across some random wireless networks here and there, but that's uncertain. Adam and Antti are running the forum, and please click on their +[karma] links when you get the chance. Hope everyone has a great week, and I look forward to officially replacing PW 2.0 with PW 2.1 in August.

Adam I'm actually saving bottles right now to do my first homebrew, so if it's legal to send beer in the mail I can send you a bottle or two.

My opinion is that the marketplace should support those that want to provide free modules and those that want to sell commercial modules. I don't want to give preference to one over the other. I am thrilled anytime someone wants to build something in–or for–ProcessWire. Our audience has some crossover with ExpressionEngine, and that community has attracted some very skilled add-on authors that are producing software far better than EE itself. I'd like to have these folks develop their add-ons for ProcessWire too, but I think they need to have a financial reason to do so since it is their full-time job. I'm not interested in bringing any commercialism to ProcessWire itself, just want to see the ecosystem represent the level of quality add-ons that our audience deserves. So I think this is probably somewhat similar to Concrete5's approach, though I've not researched their approach in any depth. If someone wants to sell an add-on, we will have expectations from them that we won't have from those providing free add-ons. They will be have to agree to provide a certain level of service and support for a given period of time (like that C5 agreement). If someone wants to provide a free add-on, then their level of support will only be limited to that of the license they've chosen (which basically means they don't have to do anything). Like anywhere else, people will be able to rate and comment on these things, which will help to separate the quality from the crap. Though I think the nature of PW is such that there will be a lot of quality and very little crap. I'm not so worried about people building 3rd party modules for stuff that should be in the core. PW will always be a fully featured, free product on it's own and not require 3rd party modules any more than it does now. This is unlike something like Drupal which is quite limited without 3rd party modules (CCK, Views, etc.) I'm not sure I've stated anything new here, but just thoughts on what's been written so far. Random off topic stuff, but this discussion made me think of it… When I first started coding stuff, like around 1989 or 1990, most software was based on a model called shareware. This was mostly pre-internet, so you'd download it from BBSs. Most software was compiled (EXE files), so open source wasn't an every day term. But with this model, you could download and use the software, but you agreed that you would buy it after a 30 day trial if you wanted to continue using it. Or in some cases you could use it for free forever, but had to buy it if you wanted to use a version with extra features. Some software stopped working after 30 days, while other software was just based on the honor system. I partially paid my way through college with a shareware software I wrote called DataView (an archive viewing utility for BBSs). Also made another free software called "one-liner" which was basically Twitter, but for the BBS age. That term "shareware" doesn't seem to be around anymore, at least I've not heard it in quite a long time. I'm not suggesting this model has relevancy to our discussion, just reminiscing.

I have the same issue, which has had me miss new messages a couple of times. I figured it was just the behavior of the forum. I haven't seen any options to change that behavior unfortunately.

I can upgrade this when I get back, but if you want to upgrade on your own it's really easy. Just download the latest jQuery and save it to this file (overwriting the old version): /wire/modules/Jquery/JqueryCore/JqueryCore.js That's all there is to it. Though if you want to make it official, then edit the jQueryCore.module file in that same dir, and set it to have the correct version number. If you opt to upgrade your jQuery, let me know how it goes. If all seems good, I'll commit the upgrade when I get back (or do a pull request if you prefer). I will probably look at the jQuery UI version at the same time, just to see if there are any upgrades there we should include as well. Thanks, Ryan

You guys give me way too much credit. If you saw how many clips were recorded and how many umms and uhhhs were edited out, you'd laugh. I eventually realized that I had to write down whatever I say on the video, and just read it off the screen. Luckily the macbook has a camera built into the screen, so it doesn't really look like you are reading off the screen. There's a reason why I don't make many of these videos... it takes half a day just to do a short one. But it is true that I can build skyscrapers with my bare hands– as long as I've got enough legos to do it. ;D

I'm responding from phone so keeping it short: $image = $pages->get("template=page-headers, sort=random")->images->getRandom();

Thanks for letting me know – Looks like I had "allow URL segments" turned on in the homepage's template. I don't need that on the homepage, so turned it off, and problem solved.

Looks like your server is forcing a Windows-1251 charset header, overriding ProcessWire's UTF8 charset setting. Try the following: Add this to the top of your .htaccess file: AddDefaultCharset UTF-8 If that doesn't fix it, try adding this to the top of your /index.php file: <?php header('Content-type: text/html; charset=utf-8'); Hopefully we can override the Windows-1251 charset that the server is forcing in Apache.