ryan

My Logitech MX Revolution mouse is on it's last leg... it's outputting double and triple clicks when it should do single clicks, causing all kinds of unintended problems in my workflow. Apparently this is a known issue and just means the mouse is done. :'( I went to go buy a new one, but found out they no longer sell it. Instead, they've replaced it with something called the Performance MX (same price, less features). Unfortunately that mouse has no thumb wheel, which reduces the number of button actions by 3 for me (I use the wheel to handle all of the OS X Expose window stuff, and am totally dependent upon it). So this Performance MX seems to be out of consideration. Looked at getting an Apple Magic Mouse, but sounds like this mouse is great to look a pain otherwise. Though it's still tempting because I can use the SteerMouse app to get all the button actions I need out of it (though with gestures rather than buttons). Now looking at Logitech G700, which is technically a gaming mouse (I'm not into games) but seems to provide all the programmable buttons I would need. Not OS X compatible, but again the SteerMouse app would let me program it. So am leaning towards this G700. Since we all do similar work here, I'm guessing we have similar needs for this kind of stuff. Anyone else found a really good programmable (preferably wireless) mouse that helps you work faster? I'm going to head to the store this evening because I can't get much work done with my MX Revolution now limping. Thanks, Ryan

Good thinking–I absolutely agree that getting this solved at the API level first will be the right way to go. Then the admin/interactive implementation can follow.

You are right about how the move works. Just a change of parent_id (and a cache clear). It doesn't mean that a copy is particularly hard, just that it'll involve a lot more overhead than a simple move.

Ryan, I haven't actually tried this FormBuilder module recently, so it's possible it needs an update. But first I wanted to check -- do you have any file fields on that form? Based on the error message, it sounds like that might be the case, but let me know... I was really only thinking of that FormBuilder as being for the more basic fields (like text and textarea), as the other types have more javascript dependencies making them really only appropriate for admin use at present. And of course, this FormBuilder is not a core module, it's more an example to build from. But a real FormBuilder will be in the works later this year.

<noscript><img src='Small.jpg' /><p><a href='Big.jpg'>Click to see bigger image</a></p></noscript> Good point, and great idea!

I searched for "responsive images noscript" and found this. Looks like they are using the same noscript fallback, though quite a different solution for the responsive image... kind of like what we were talking about before with a placeholder image that has the src attribute replaced with JS. Only problem I can see with this is that you'd be left with a placeholder and a full size image for the fallback, rather than just the full size image. http://www.jamesfairhurst.co.uk/posts/view/responsive_images_with_php_and_jquery/ As a side note, the ajax/PHP side of this article is pretty insane from a resources and/or security standpoint. If they aren't caching the files to disk, then someone could kill the server by making a a few hundred image requests in a minute (simplest DDOS attack ever). If they are caching the images, then they could feasibly end up with thousands of files per image, and fill up the server's hard drive pretty quickly.

Tested in FF5, Chrome (latest), Safari on iPhone4 and IE8 and none of them download the image from the <noscript> unless javascript is specifically turned off. Confirmed by watching the requests live from the apache log. Seems encouraging that this approach would work. I haven't tried in older browsers, but I suspect the result would be the same... this tag has been around since the beginning. I also tried other HTML elements with an inline style background image and display: none; but no dice... the browser still loads those. I suppose this is pretty much what noscript was designed for in the first place, so might as well use it. But most will [hopefully] be seeing the <script> version of the image(s) instead. The downfall is mobile devices that don't support javascript... they'll get the full size image when we want them to get the small image. But then again, those devices probably don't support CSS3 media queries either.

I found this in Drupal 7's source: /** * Some distributions of Linux (most notably Debian) ship their PHP * installations with garbage collection (gc) disabled. Since Drupal depends on * PHP's garbage collection for clearing sessions, ensure that garbage * collection occurs by using the most common settings. */ ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 100); I'm thinking perhaps we should add the same to PW's default config file.

The gc_divisor is one potential issue, though I don't think it would account for it entirely. But here's what php.net has to say about it: So in your case with a gc_divisor of 1000 there is significantly less chance that the garbage collection will run... perhaps such a small chance that it almost never happens. Though I've not experimented with this setting, so can't say for sure. Here's another thing I found: If I'm reading this right, we don't have to be concerned about this issue. But it seems a bit strange they way they mentioned "Oh by the way, Since PHP 4.2.3...", as a side note at the end, so I'm a little suspicious of this. Is your file system fat?

The way you'd detect it would be for the hook to see if the template or parent is one of the ones you are maintaining multiple languages for. When a page is added, it would check the other language trees to see if it also needed to create another page of the same name in those other trees. I think the implementation would be fairly straightforward. But manual cloning makes no assumptions so if there will be plenty of exceptions where you don't want things to be the same across the trees, then manual cloning probably can't be beat. A copy/clone that does an entire tree would certainly be convenient. Whatever solution we end up going with, we'll make it recursive (or at least have the option) so that it can also clone children and so on.

Thanks, that makes sense. You know more about building responsive sites than anyone else I know, so I definitely trust your advice here. That's a good link, though I'm not wild about their solution... <base> tags are something to be avoided, IMO. And something you'd have to be very careful with applying to an existing site. Even if inline javascript isn't kosher, wouldn't something like this be much more straightforward? <script>img('/path/to/large.jpg', '/path/to/small.jpg', 'unicorn stampede');</script> <noscript><img src='/path/to/large.jpg' /></noscript> Then there would be that img() function in an included javascript file: function img(large, small, alt) { var src = $(window).width() >= 480 ? large : small; document.write("<img src='" + src + "' alt='" + alt + "' />"); }

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.