ryan

Pete, sorry for your loss. My last hard drive crash was in the mid-1990s (an 80-megabyte Western Digital drive), and still haven't recovered from that one. The good news is that your data is most likely still there, somewhere on that drive. In fact, it's downright difficult to truly remove data from a drive unless you take a giant industrial electric magnet to it. Depending on what type of crash it was, you may still be able to retrieve it. There are lots of utilities out there that can recover stuff from flash media (usually SD cards), but maybe something like that could help (?). You could also try the freezer trick. Put the drive in the freezer overnight (in a freezer bag with a paper towel, to keep the moisture out) and try it again in the morning. If it mounts, then copy everything off of it as quickly as you can because it won't stay working much longer. I think this freezer trick is actually for normal hard drives, but apparently some have had success with flash media too (I could be wrong). Apparently the freezing process can temporarily reconnect some things at the molecular electronic level, temporarily. That's a guess anyway. Anything is worth a try.

Robert–this has been updated in the latest fresh install of PW 2.1. The IDs now start at 1000, though 1000-1005 are used by the default site profile, so technically they start at 1006 unless you reuse the default site profile pages.

Barring any issues, I'm hoping to officially replace 2.0 with 2.1 as the current stable version this week or next week at the latest. The 2.1 version is currently on release candidate #2. Thanks to everyone for all the help with testing. I've just about worked through all the issues posted at GitHub. Please post new issues as they come up, even if they are minor. Initially, the 2.1 version will not include an upgrade function to go from 2.0 to 2.1. Instead, I'm treating that as a separate project. I want to get 2.1 released, and then focus on the upgrade utility for those that want it. If you are one of those that wants it, please let me know as I could use your help with testing. I'll also be keeping the 2.0 branch going indefinitely for bug fixes and such. I've reserved the "processwire" name at GitHub (per Adam's suggestion), so thinking about moving the 2.1 source over to that account. That means the GitHub account URL would be github.com/processwire rather than github.com/ryancramerdesign. I think this'll be a better fit for PW. Can anyone think of any issues with doing this? I'll of course update the README info at the ryancramerdesign account to point people over to the processwire account.

Wiping the entire cache on every page save is a good idea to at least provide. In a system like PW, a given page might pull from several others that are determined at runtime. So there's no way the CMS can know all the possible interrelationships ahead of time. As a result, expiring the cache on every page save is the only way to know for sure that the site is delivering fully up-to-date pages. On the other hand, it's rare that I actually need the entire cache to expire on every save... and if I really need it for some reason, I go to Modules > Page Render > Clear Cache. But caching can be a difficult concept for a client to really understand sometimes, so having the entire cache expire on every page save can reduce the support burden. So in one of these near-term commits, I'm going to go ahead and add an option to the Template editor that says: When I save a page: 1. Expire the cache for the saved page only. 2. Expire the cache for all pages. Being able to specify that at the template level will provide a lot of flexibility.

I know that you can achieve pretty much all the same things in the different windowing systems (and good tips, btw). I was just trying to say that the way the windowing system works in OS X is somewhat annoying, to me. I like to have the option of being fully focused in an app and not be able to see everything else (or the desktop) behind it... I get plenty of accidental clicks to the wrong app in OS X. But there are just as many people that have a preference for the way it works in OS X too. I guess it just depends what you grew up on... I grew up on Windows, so still have a slight preference for some of the ways that it works, even if overall I prefer to use OS X–not because it's mac, but because it's unix. I really disliked Macs before OS X (like OS 9 and before, which I had to use at my job but always snuck in my Windows notebook).

Yes, I think you are right that it has more to do with wives than Windows. I actually never had any security problems with my own Windows-based computer. But I did start to not trust my computer so much, and this was about the time that Microsoft was starting to be thought of as "evil" (now it's Apple). And the Macs were shiny and metallic. I only stick with a Mac because it's running on unix and it can run Photoshop, and that's the platform I bought Photoshop in… no other reason. Oh, and I also want people to accept me in the coffee shop (just kidding!). But the security concerns are what made me switch. I've always been paranoid about security (perhaps a good trait when it comes to CMSs), and my wife's computer blowing up was the end of Windows for us. I suspect I would probably like where Windows is now. I still prefer "dir" over "ls" as well (what does "ls" mean anyways?) Just thinking about "dir" brings me back to the days of DOS. We all knew Finland very well as the greatest country in the world because that's where Future Crew was from, the Assembly demo party and so on. I used to spend my entire income in high school ($300-$400/month USD) per month on long distance phone fees downloading demos and mods from Starport BBS in Finland, and others. So that my BBS had the latest/greatest stuff. I'm definitely nostalgic for the pre-internet DOS days, great times.

Sounds good, I'll plan to implement this – I think we're already almost there.

I also liked to work full screen in Windows, and that's always been one of the annoyances about Macs for me. There isn't really such thing as full screen on a Mac. It's especially a pain in something like Photoshop where you try to click on a palette and you accidentally click a little outside it and find yourself in another application (and this happens ALL the time). There are positives to this setup too (drag stuff between apps), but I've been using Macs for 5+ years and have never quite gotten used to this aspect... I feel more disorganized on Macs than PCs. On the other hand, I've not had any kind of major instability, crash, virus or anything of that sort in those 5+ years, and I might reboot my computer once every 3 months, if that (like for a thunderstorm). We stopped using Windows years ago because we discovered all kinds of spyware and a keylogger on my wife's Windows XP computer, despite a plethora of virus and spyware scanners. We had to change all our bank account information and passwords, etc. After that, I just decided I was done with the Windows platform. So even if I don't love everything about the way Macs work, I do love that I'm running on unix since I spend much of the day in VIM. And I value not having to think as much about OS security. But ultimately, computers were best pre-Windows (and pre-mouse) era when we all worked at the DOS and unix command line.

On a large site, there can really be a lot of cache files. And every page can support up to 1k cache files for URL segments and page numbers. So as the scale increases, it can really slow down the save to selectively clear some stuff and not others. I've found that good compromises are: 1. Use low cache times with the current system on pages you don't want to risk having old content (seconds or minutes rather than hours). 2. Or, Set the cache to wipe entirely on every page save. The second option was what PW1 used. It can be done without much overhead because PW's cache looks in a "lastgood" file that has a mtime timestamp of when the cache was last considered good. Any cache files older than the date of that file are considered expired, whether they exist or not. So PW can uncache everything just by updating the mtime of that one file. Given the above, it would be relatively easy for me to add an option to the template cache settings that says "When a page using this template is saved, clear: 1) this page's cache file; or 2) cache files from all pages." Anything beyond that could involve significantly more overhead, short of major changes to the current CacheFile class (which can certainly be done in the future).

That's interesting that they are still selling it in Russia. Sure wish they were here too. Although, so far this G700 is working out pretty well so far. You guys don't know what you are missing with these 10+ button, geared flywheel mice. They are a small price to pay for the productivity they bring. Then again, I'm using OS X where there is always a mess of windows and icons everywhere, and–as a former long time PC user–this makes it possible to manage the mess. Maybe it's not as useful in Windows these days, I don't know. Ironically, these mice are Windows-only and don't even support OS X... I have to use 3rd party tools to make them work.

For coding, I've only ever used VIM so the mouse definitely isn't applicable to that part of work. But everything else I do is pretty mouse heavy, especially Photoshop and just general getting around the OS, browsing, etc. The MX 1100 looks like a great mouse, but like the Performance MX, it has no thumb wheel. I'm a little pissed at Logitech for just putting this on 1 mouse and then never doing it again... that thumbwheel is so tied into my workflow. For instance: Roll Forward = Exposé all windows from the current application Roll backward = Exposé all windows from all applications Push down = Exposé desktop (hiding all windows temporarily) So with the MX revolution, I can very easily jump to the desktop (push wheel), grab an icon and hold onto it (left click), push wheel again to get back and generally just jump around everywhere really easily (roll forward/back) while simultaneously holding onto some files, scrolling some window (top wheel) and throwing them somewhere... in one shot from the mouse. Maybe that sounds a bit cryptic, but it's one of those things that's simple to watch and hard to explain, but I do it countless times a day (as it sounds most people with the same mouse do). Having it in a wheel rather than multiple buttons just makes it so much simpler and more intentional. Strangely you can't do anything like this with Apple's mice. Though you can program it with SteerMouse to at least do some of it. Abu I actually did check out that Razer naga (with an entire numeric keypad on it), but couldn't find anywhere that I could actually test it out. I had tried Razer mice at stores many years ago and they never fit my hand quite right, so despite my attraction to all those buttons, I'm a little scared that it won't fit quite right. I ended up getting the G700, and am just charging it now. Has a similar feel to the MX Revolution. Lacks the thumb wheel, but adds several new buttons I didn't have before too. I'm sure it won't be quite as good as the MX Revolution, but hopefully will get close enough.

There's a couple ways you could approach it: Example 1: <?php $this->value->add($url); $image = $this->value->last(); $image->description = "some description"; $this->message("Added new image: " . $url); Example 2: <?php $image = new Pageimage($this->value, $url); $image->description = "some description"; $this->value->add($image); $this->message("Added new image: " . $url); I think you can replace line 108 and everything after with just this: return parent::___processInput($input);

Looking good! I used to think that a <noscript> could only appear if it immediately followed a </script> tag, but now I see that's definitely not the case. If the large image is always in the <noscript> tag, I suppose we could even get by not having a separate attribute for that one (the jQuery could just grab it out of the $("noscript").html("img").attr("src"); But then again, probably best not to make assumptions about what someone is doing inside the <noscript> (like if they are showing a thumbnail linked to the large image, as you mentioned before). One other possible thing to do would be to use jQuery to hook into the $(window).resize(function() { ... }); and change the src attribute consistent with the window size. But that's probably only useful when dragging small to large (unlikely or impossible on a mobile device), as there's little reason to replace the large image once it's loaded. On the other hand, it does make the effect easier to see in a demo.

If you ever get that message "Unable to complete this request due to an error", you can get more info about the error by looking at the end of this file: /site/assets/logs/errors.txt You can also set $config->debug = true; in your /site/config.php file, and that will make it report verbose errors to the screen (something you don't usually want to do for a production site).

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 + "' />"); }