teppo

Update: Pushed new version to GitHub just moments ago. This fixes some minor glitches and adds new "quick diff" feature. See attached screenshot for more details. It's very primitive at the moment, but I'm hoping to improve it (and some other parts of this module) soon. This is first actual "feature update" for this module, so I'm a bit nervous and would very much like to hear how it works for you. Tested it here with multiple browsers and fields etc. but I've probably again overlooked some issues. Regarding the diff feature, Google did most of the heavy lifting there; all I did was integrate their Diff Match and Patch library (JavaScript version) to my code. For the record I was going to use jQuery PrettyTextDiff, but that really didn't feel necessary considering that it's just an attempt to simplify the (already simple) DMP API.

Looks like I got confused by their UI, sorry for that Taking another look at it, the Matrix field seems more like having multiple types of repeaters within repeaters. Not sure if that's the way I'd prefer it, considering that this could easily be (ab)used to create some pretty wild combinations, but I'll agree that it seems very flexible. To compete with that, our repeaters would need to support a) multiple templates and b) nesting. Doesn't sound entirely unreasonable request, though I wouldn't be surprised if that raised some new issues. I wonder what Ryan thinks of this?

@ceberlin: just a guess, but have you tried get instead of find? Find returns PageArray, which could be the issue here. Get, on the other hand, always returns Page. Edit: that didn't help at all. This isn't possible at the moment.

@Martijn: agreed.

I'm finding this interesting for perhaps a bit odd reason: In the past I've had quite a few times when I had to dig data directly from MySQL. Since a page there doesn't "know" it's full URL, just it's name and the id of it's parent, a) locating a page is a bit of a hassle -- which is why I've often let page edit do that for me -- and b) getting useful page-related data (with full URLs, that is) directly with SQL queries is even more troublesome. Sounds like this module, as a side effect, actually adds this "feature" I've been missing Note: as far as I know there's no simple way to do a recursive query in MySQL without stored procedures. I'd love to be wrong on this one, but so far I haven't found any other way to do it.

Agreed. Almost as nice as Repeaters in ProcessWire

Hi there, nice to have you here! I've got very little to add to Diogo's answer, apart from that there are quite a few of us who rely on ProcessWire for a lot of client work already. It's more than likely that someone would step up and catch the ball if anything like that was to happen. Have you seen the roadmap already? That should answer this question for most parts. Another thing to note is that, at least from my point of view, both Form Builder and Pro Cache are larger, more complex modules targeted for audiences with specific needs -- developers building sites for more than just fun and most likely getting properly paid for it and clients with some serious traffic (Pro Cache) or complex form-related needs (Form Builder). ProcessWire is very fast without Pro Cache.. and "regular" caching methods, i.e. without mod_rewrite method, are built-in features. There's also a built-in way to create forms, though only at code level, but if you really needed it there's nothing stopping you from building another UI level tool for creating forms, really. Personally I'm also happy to support the great work Ryan has put into ProcessWire by paying when I've got those specific needs, especially when both modules are of superb quality. Please refer to resources Diogo posted. Taking a quick look at WP Super Cache, it seems to provide very similar capabilities, including serving cached HTML via mod_rewrite. Main difference would be that it's built for WP, Pro Cache is built for ProcessWire where both the environment and needs are slightly very different. At the moment most PW modules are under GPL, but there's no constraint regarding this (not sure which you were after.) PW doesn't force developers to use GPL -- which is a very good thing considering that one license is rarely answer to all questions. It's better to ask now than regret not knowing later

@diogo: good call, though I'd argue that's an example of mixing design and style. I couldn't agree more with Zeldman in that those are two very different things Sacrificing big screens isn't really what mobile first is about. It's about design that works on as many different platforms as possible, prioritizing content and usability above everything else.. and only adding extra bells and whistles if you really think they are what desktop users (or any other specific user group for that matter) want and need. This definitely doesn't mean that you can't create unique or aesthetic designs, just take a look at some of these gorgeous examples of mobile first at mediaqueri.es. You're right that mobile first isn't a perfect fit for all cases, but I've found that for most cases that interest me personally (i.e. where design, usability and content are more important than looks) it's awesome.. but then again, I'm not aiming for any art galleries, web design showcases etc. with my designs -- my ambitions lie in whole another field

Emulators (mobilexweb.com has links to quite a few, by the way) can help, but they can never properly replicate actual mobile device UX, which is why an emulator should never be your only option. That's also why projects such as Helsinki Open Device Lab are being set up by folks all around. If you're serious about mobile testing, older devices are usually cheap and as a general rule of thumb if it works on an older device, it will most likely work on a newer one too.. or someone has failed big time When we're working on sites that need to look and feel great on multiple platforms, testing is done first with desktop browsers (scaling it up and down like you mentioned above) and then with default browsers of at least one Android phone, an iPhone, an iPad.. and often one Lumia. This gives us a good chance to "get it right", at least from UX point of view. To make sure that nothing "big" get's past our radar, we use services like BrowserStack to test with additional devices (and not just devices, browsers too.) I wouldn't consider myself a mobile expert either, but I've found that KISS principle often goes a long way. Media queries and JavaScript are well supported across mobile devices, but I still prefer mobile first approach: start with the simplest, most usable form and build whatever eye candy you need on top of that. Not only does this make it more likely that your site works on a wide range of platforms, it also tends to increase overall quality as it forces you to focus on the most important things -- content and how it's organized. Then again, personally I really dislike complex UI's, huge graphics and all kinds of bells and whistles even for large screens. If it doesn't add any real value, why should I even include it in the first place?

Antti, that should be fixed now, just pushed another version to GitHub. Looks like you can't set the value of inline CKEditor the way you'd set it for regular CKEditor, ie. find correct instance and use setData().. not even if you first "force" loading that particular inline editor. On the other hand, inserting value directly to inline CKEditor's container div with .html() seems to work but feels a bit hacky

@Joe: I gave ready.mobi a try too, and was actually about to write that it really proves why certain tasks cannot be automated Our company site was built from scratch with a mobile first approach. I'm not saying that it's "perfect", but I am saying that it works on mobile devices pretty damn well. According to that service "t will probably display very poorly on a mobile phone." Taking a closer look at the issues found, this service is actually testing things quite thoroughly and some of it's conclusions are similar to what a human might still reach.. just by looking at the source, that is. Yes, there's one table used for layout. Yes, CSS file contains pixel widths. What it can't see is where, how and in what role those elements are used and how they are handled in various situations -- something any robot, at the moment, would have trouble understanding.