teppo

It's about the fact that we're developing solutions in our own environment where we have to consider long term performance, reliability, scalability and maintainability of every new solution we implement and mainly because of that I'm always very conservative when it comes to implementing anything that I don't consider "necessary" or (at least) "very advantageous." Everything we implement also has to support team work properly -- thus "write SASS / LESS code locally, compile and move to remote host" method is pretty much out of consideration. There are various other things to consider too, but the main point here is that I'm not comfortable implementing anything new without knowing thoroughly what it does, how it does it and what are the benefits / costs involved (and in my humble opinion there are very few web-related techniques with no costs at all) Edit: just wanted to clarify that while things like that mixin you posted definitely are neat, I would still argue that compared to raw CSS they are more complex and thus require more effort (which is multiplied if neat tricks like that are used on a regular basis) especially if you're not too familiar with SASS syntax -- thus they would need to provide some very real extra value to be considered "worth it." My point here is that just looking cool isn't always enough. I know that I'm being somewhat uptight here though, sorry for that This is exactly what I'm worried about, quite possibly because I just don't know SASS / Compass well enough and SASS documentation isn't very helpful. They did mention that I can run sass with --watch param (I think it was something like that anyway) but what does it actually do -- is sass going to run as a background process and grab any .sass / .scss files that have changed automagically, or..? If that's the case, then this sounds easier than I expected I was aware of this and this is not such a huge problem really, though it's still something to consider if I did (and I can't imagine any reason not to) use SASS-specific syntax. Everyone else would also have to learn at least the basics so that they'll know what to do when things need to be changed -- not that it would be difficult to learn, but still. In environments heavily relying on team work you just don't go changing stuff / implementing new technologies without discussing it properly with other members of the team. That's actually a shame, since this is one of the reasons why I've considered SASS / LESS so beautiful. Nesting FTW

@yellowled, I think you've proven your point; that looks really neat and (even better) re-usable. That said, I'm still not 100% sure that this is something we need enough to justify the hassle involved. I'm painfully aware of the fact that most developers are always tempted to make everything look and feel cool and re-usable code wise (or markup / stylesheet wise) even if there's very little (or none at all) real, measurable value to be gained. Lately I've been trying to eliminate any and all extra steps in my own work -- as hard as it can sometimes be. Will have to go through some older projects to see just how much trouble this could've saved me though. Hopefully I'll come to the conclusion that it's well worth it, since it really does make things much more beautiful (and to be completely fair I have to add that there's some real value in that already.. )

Just my two cents: First of all, when I first started to get into LESS and SASS, I found LESS documentation more "newbie-friendly" -- or perhaps just "friendly" in general -- and that's a big part of why I was instantly drawn into it instead of SASS. Not the best way to choose your tools, but that's still how it often goes.. The main reason why I haven't used LESS (or SASS/SCSS) in customer projects is that we have multiple people working on same projects, sometimes at the same time, so 1) compiling locally and just uploading a compiled CSS file isn't really an option (I'm not even considering letting JS handle compiling on a production site) and 2) I can't just jump in the LESS/SASS/SCSS bandwagon by myself without discussing it properly with others or I might have some serious explaining to do later on. I do know that LESS can be compiled server-side with the help of Node and now that the PHP version was mentioned (thanks Marty!) I'm likely going to check that one out too, although the final deployment process still requires some thought. Anyway, I'm sad to say this but all the hassle has already made me somewhat cynical about whether we really even need the added complexity and overhead compared to plain old CSS. Is it really THAT difficult to keep pure CSS files up to date? In my experience the answer is "very rarely" and I'm saying this even though I've worked with some seriously bloated relatively big stylesheets before. LESS/SASS/SCSS/whatever are definitely an improvement over plain old CSS, too bad they're not natively supported by browsers but require various tricks and gimmicks to run smoothly. Just saying. Sorry for the rant and sorry for getting sidetracked. This is an interesting subject both in technological and theoretical sense and those always tend to get me on my toes. One of these days I'm definitely going to try LESS on a "large-scale" site just to get a better view whether or not it's really worth it -- until then the rant above pretty much summarizes how I feel By the way: have you guys already seen the W3C draft for CSS Variables? It's not the same thing as these frameworks mentioned here, but it is a small step to the same direction: http://dev.w3.org/csswg/css-variables/.

I do realize that you're suggesting that having the checkbox on the selectable page itself would be better UX wise, but I'd still suggest using a Page field on homepage. This way you can easily allow the user to select only one page AND all required features would already exist -- no need to reinvent the wheel Anyway, if you really want to have that checkbox on each individual page then the module you're suggesting might be the only solution. I'd probably just create a new module and add a hook before Pages save ($this->pages->addHookBefore('save', $this, 'checkFeatured') or something like that) and there (after checking if the value of this checkbox has changed for current page / if current page is a new page and has that checkbox checked etc.) make sure that no other page has the checkbox checked. Edit: Ryan beat me with his answer and pretty much posted the precise code you'd need in the hook I mentioned.. Another option would naturally be allowing multiple featured pages, with some kind of Javascript slideshow enabled to only show one at a time.

This does actually look like a bug to me. If I'm reading this correctly, there should be .. Tab titled Location (location_tab) Inside that fieldset titled Location Description (location_content) which only contains two fields: location_title and location_description All the other fields here should be inside tab Location but outside fieldset Location Description (location_content) What's happening instead is that fieldset Location Description has "swallowed" even those fields it shouldn't contain. Actually I've seen something like this happen previously with similar settings. Can't honestly remember if that was fixed by some random trick (re-adding fieldset, saving template again or something like that) or if I just decided to go with simpler layout. Anyway, would be nice if someone else could confirm if this actually is intended behavior (I very much doubt that) or some odd bug within Admin.

@Pete: seriously, this is what I'd call a great timing! Just a few days ago I pushed my own jQuery placeholder plugin to Github (https://github.com/t...put-placeholder) -- wasn't aware of this one before but it sure seems like something I'll have to take a closer look at. Thanks for the heads-up My plugin does essentially just the same as this one with a few differentiating features. In some ways it's a bit more simplified as I've focused on the particular needs I've encountered in client projects so far, such as need to set specific styling for placeholders etc.

As the title says, I'm trying to get multiple checkbox values via PW: <form method="GET"> <input type="checkbox" name="bs[]" value="1" /> <input type="checkbox" name="bs[]" value="2" /> <input type="submit" /> </form> <?php var_dump($input->get->bs); When I submit that form, it results in URL like this: "...?bs%5B%5D=1299&bs%5B%5D=1300". URL encoding makes it a bit hard to read, but that should still work. Var_dump outputs following: string(5) "Array" It seems that PW converts GET array to string "Array". Same thing happens if I use $_GET['bs'] instead of $input. When I tried putting a simple test script that doesn't use PW this is the result of same query (with URL encoded and all) - and this is exactly what I was expecting PW to give me too: array(2) { [0]=> string(4) "1299" [1]=> string(4) "1300" } So, does anyone know how to bypass this behavior? Edit: this has been solved -- the problem wasn't ProcessWire, it was the way I was passing variables around, which eventually ended up flattening arrays to strings. Long story short: ProcessWire itself handles multiple checkbox values / GET (and probably POST) arrays just fine. Sorry folks, my mistake!

Sounds reasonable (and standards-vise valid), though I'm not sure I see whole lot of use for this. Depends on the situation, of course. (In your case I'd probably rather redirect unauthorized users to a page containing custom login form and proper description of what's happening.) On the other hand, 404 is most of the time exactly what I want to show in these cases, cause there's usually no reason to let the user now that there's something here but she/he just doesn't have the right to access it -- kind of a "security through obscurity" thing really..

You have probably already read this, but there's quite a bit of discussion about this subject (video content) here: http://processwire.c...de-processwire/. I've implemented similar solution as discussed there; user copies video URL from YouTube (or any other supported service) and some regexp magic converts it into embedded video. That works for me very well, especially since (in my experience at least) users quite often want to embed videos here and there, mostly within other content, and thus video field wouldn't be sufficient solution. TinyMCE plugin (also discussed in the thread above) would be an interesting option, though I'm not sure if that's possible yet. Long story short: video field is a nice idea and might actually meet some of our clients needs too - I'm sure a lot of folks here will be really happy if you find the time to create something like that. And naturally if there's anything we can help you with regarding this module (or just about anything else) just ask By the way, are you thinking about adding certain hard-coded video services, or could there perhaps be an option for administrator to add new services / remove those that already exist? I'd consider that a nice addition, especially for handling smaller, local video sharing sites - and perhaps even in-company video editing + sharing services, seen couple of those popping up lately. Of course this could also be solved, especially early on, by implementing service-specific stuff in a way that makes it easy to developers to modify, add and remove new services at code-level..

@Pete, I'm afraid that you're absolutely right with that point about larger sites, so I wouldn't suggest using same table for version data either Clearly Ryan has different path in mind already, but I just wanted to throw in this article about MySQL versioning I read some time ago and found quite interesting: http://www.jasny.net...ing-mysql-data/. The idea there is to utilize MySQL triggers and that way move (most of) the versioning logic to database layer, which IMHO is a great idea. Naturally there are some drawbacks with this method too: "There are some situations where this solution as a bit to basic. A record might span across multiple table, like an invoice with invoice lines. In that case, we don’t want to revision each individual invoice line, but the invoice as a whole." (etc.) Anyway, just throwing in some food for thought