teppo

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

IMHO anonymous users shouldn't be allowed to make edits. Requiring users to register can keep some of the spam away and it also enables us to see who's created / updated / edited / removed what (in other words proper version control and all of it's benefits.) It's possible to block individual IP addresses or IP address blocks in MediaWiki. If certain pages are targeted more often than others, it's also possible to protect those, though if I recall correctly only sysops can edit protected pages. EDIT: Just wanted to add that even though blocking IP's is possible, it's not much of a solution; you can always find another public location, open WLAN etc. or simply use a proxy and thus IP blocking is mostly just wasted effort

Admittedly the topic of this post was a bit.. alarming. Not that PW wasn't secure and all, of course, but banking software would throw in some extra tension Just out of curiosity: footer area links (employment + privacy & policies) are linked to .html files, though both seem like redirects (and the page that privacy & policies is redirected to, /info-desk/, doesn't exist) -- if I may ask, what's that all about?

I'll add one more to that list, and that would be Zend Framework: http://framework.zen...rvices/overview. ZF being backed by Zend Technologies itself is one of the reasons why it's so popular. Short quote from a 2009 blog post by Jim Plush titled "Why I chose Zend Framework for Enterprise" where he explains why they decided to use ZF at Panasonic: "After a few weeks of evaluations I settled on Zend for a few reasons. #1 It has a company behind it. It means a lot to me to be able to pay out some budget money to get proper training for developers or have people on the ready for support issues." -- http://www.litfuel.n...ush/?postid=177 That's right; there being a company with paid services behind ZF was their number one reason. Just saying. Healthy community is a must for any proper open source project and community support is enough for most small to medium companies - especially if they have enough technical expertise available in-house - but when it comes to enterprise level applications you really need to know that if you're in trouble, there's someone who can help you right there and then (and even when your own CMS guru happens to be on a long vacation at Tahiti.)