ryan

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.

Thanks all for testing this! Next round of drinks is on me. @Sinnut, thanks for posting this .htaccess directive. I am going to try it out and take a closer look and perhaps look at including this in my sites, if not PW. I didn't realize it could be defined at this level, which is pretty awesome. That /regions/ page just has a blank template. I still need to do something with it (along with a few others) but hasn't yet been a priority since it's not a functional page on the site. But I agree that sooner or later people will test it out in their address bar... I'm prone to doing this on sites as a form of navigation myself. I'm getting 404s for all non-existing regions off of /regions/, like http://villarental.com/regions/lajelakjelj (which is what it should do). What's an example of a URL that's giving you a redirect? @Adamkiss, you are the man. Thanks so much for all your testing here! This is really helpful. Now I'm off to try and reproduce it myself. That "0" was not supposed to be in the masthead.css–that's an error, just fixed. Thanks for finding it. The -moz-border-radius is intentionally excluded. I don't want it to render the rounded corners unless the browser actually supports the native border-radius. The reason is that -moz-border-radius (in FF3 at least) only rounds actual borders, and not the boundaries of images. So when I was using it, I was getting some things rounded and some things not, and it just looked inconsistent in a bad way. I figured it looked better if everything was either rounded or not rounded in a consistent manner. Btw, you are the man.

Thanks for looking at these. I was thinking some css3pie might be a good way to go here. The only reason I haven't yet is that I like the squared off version almost as well (like in IE and other older browsers), so don't mind the variation. But I think the right thing for me to do is instead let the client decide... but that's after I figure out the rendering issues. So far I haven't been able to find anyone else that can duplicate it except for this client. But this client has been able to duplicate it on many computers running FF3, both in and out of their network. Their whole company is apparently standardized on FF3.6. They've only been able to duplicate it on one computer running IE8 (as far as I know). And we did play with the compatibility mode, that wasn't it. So the FF3 one is more of a concern. @Pete: while the compatibility mode isn't the issue here (we tried it both ways), the compatibility mode issue has come up on other sites before, so that header is good to know about–thanks (I didn't know about that one before). I did know about the meta tag (below), but the header really may be a better solution since it catches IE before markup starts flowing. <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Can you paste in the exact text? I just want to try and see if I can duplicate locally. Though I was assisting someone else with Cyrillic text a couple weeks ago and everything worked well for me. It turned out that their PCRE version was from PHP 5.1 (even though their PHP version was 5.3), and didn't support Cyrillic. However, that doesn't appear to be the case for you as your PCRE appears to be up-to-date.

I think that interpreting a license is kind of a tricky spot because lots of GNU software has components of other GNU software. And one author can't make the interpretation for another. So I think it may be best to take the license literally for what it says and the author has to accept it just like the users do. Though the copyright holder can always change the license, but then they have to make sure that's compatible with any other components in the software. For instance, if PW were to be MIT licensed, then I probably couldn't bundle in TinyMCE and Markdown with it anymore. I don't think there is anything in the GNU license that would lead me to believe that someone's original/custom plugin modules would fall under PW's license any more than your website itself would. The reason for this is that ProcessWire is a tool, like PHP is a tool. When you use the API to create your a website or supporting module(s), you are using that tool in the manner it was designed for. PW's license doesn't say what license your own code carries unless you go in and modify PW's code in the process. When you create modules or templates, you aren't modifying PW's code. After all, ProcessWire doesn't have to be released under the same license as PHP. I didn't think this was an interpretation of the GNU license, but I'm also not a lawyer, so somebody correct me if I'm wrong.

Can you describe in more detail: what behavior are you experiencing and can you paste in the text/label that's causing it to hang up? Also, view your phpinfo(); and look under the "PCRE" section and let us know what it says the PCRE version is. Lastly, look in your MySQL database for the table 'field_title' and let me know if it's charset is not utf8.