teppo

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.

@Fokke: yeah, sure did -- and Toto was totally amazing. Only had time to see their gig, though. Person sitting next to me was quite literally sleeping (at least that's what it seemed like) and after they had stopped drumming someone commented that it was like "the Orient Express departing." Unique experience to say the least

Thanks Ryan! I've just pushed to GitHub a new version with your fixes (and another minor layout fix for long revision lists.)

That "$page->child->children->children" is the issue here; $page->child is a Page, $page->child->children is a PageArray and you can't ask for children of a PageArray. PageArray contains Pages, each of which has children -- PageArray itself doesn't have children. You'll have to iterate over all contained pages one by one and ask for their children <?php foreach ($page->child->children as $children) { foreach ($children->children as $child) { echo "<h1>{$child->url}</h1>"; } } ?> Does this make sense to you?

@Macrura: I'm planning to port this for TinyMCE at some point, though personally I no longer use TinyMCE anywhere, so this hasn't really been too high on my todo list CKEditor loading blank sounds like an issue with ACF so I'd try disabling it and see if it helps; usually you can find your way around it's quirks, but having had more than my share of trouble with it I'm no longer sure if it's actually worth it. That's a typical issue for something like not having "div" in available format tags list while having div tags in your content. Note: having these tags in extraAllowedContent doesn't seem to make any difference at all. .. and, honestly speaking, CKEditor is awful when it comes to error messages and exception handling. Usually it just disables all or some features seemingly without any logical reason. Just guessing, but they probably thought that showing nothing would be better than showing incomprehensible technical error messages -- or something like that

I really like the site, looks and works great both on desktop and mobile. It's awesome to see more Finnish ProcessWire sites too (Planning to visit the event opening night today, by the way.) @adrian: interesting point about "English" vs. "In English" -- latter is pretty much the de facto standard way for linking to English language version around here