teppo

Makes sense. That's also roughly the same thing as what Antti is doing in his Facebook Login module, comparing against custom facebook_id field instead of name

Thanks for this, Marvin! To answer your question, proper LDAP module is definitely something we need. Taking a quick look at your code, this seems like a reasonable tool for simple use cases, which brings me to my question: do you have any plans for incorporating slightly more advanced features, such as defining roles based on AD groups (including nested groups, which is surprisingly often missed altogether), automatically closing sessions for users no longer found from AD, etc.? In my opinion those are (some of the) must-have features in order for this module to answer those "enterprise use cases" you've mentioned Also, as a minor (?) detail, ability to specifically define search base would be great (and, again, a must-have feature in certain setups).

Just last week I had a case that would've required a "checked by default" checkbox, but ended up with "checking this checkbox means this feature is disabled" approach. Felt ugly, doesn't make much sense.. but on the other hand, adding a new module just to tick one checkbox felt like an unnecessary complication

It's not really getting any better with this, but how 'bout something like this? (Written in browser, not tested, might not work, you know the drill.) <?php echo "<img src='" . $page->images->get("name=logo.jpg")->width(200)->url . "' />"; ?>

Agreed with Diogo, the idea of using this to help clients (and especially new users we haven't been able to instruct yet) to get used to the basic features of ProcessWire popped in my head instantly. Anyway, this looks awesome and I'll definitely give it a try soon!

There's an issue at GitHub related to filename conversions: https://github.com/ryancramerdesign/ProcessWire/issues/305. Technically this would be an IRI, no longer an URI (like Martijn pointed out above), but supporting that in the specific case of files might actually make sense. Personally I'm more interested in supporting non-ASCII characters in filenames than uppercase/lowercase. I'm not familiar with the issues Martijn mentioned, but it would be interesting to know how widely spread they are. If they affect Windows > XP, then it's probably worth considering

.inc is sometimes (including in the "Essential PHP Security", unless my memory fails me) considered bad practice, mainly because it has to be separately handled by .htaccess rules. If .htaccess fails for whatever reason, your .inc files are suddenly world-readable. Though a lot has to go wrong before this can happen (and even then it's usually far from critical), so far I haven't heard any compelling reasons to use .inc instead of fail-safe alternatives, such as .php (or .inc.php, if that .inc is somehow really important).

@formulate: I wouldn't go as far as say that it's "flawed". That's still quite common workflow and more than enough for many projects. You didn't include wireframes, though -- that's a step I personally wouldn't leave out anymore The truth is that as fun and rewarding as working on prototypes and fine-tuning the UI can be, especially for more complex sites, for most "basic websites" that's simply overkill. When you already know how the site should behave in various situations (small screens etc.) reinventing the wheel every single time is more than unnecessary -- it's a waste of time (yours) and money (client's). ... unless, of course, the client wants to have strict control over every single aspect of the site, including how it works on various devices, in which case that prototype might be a huge time-saver for both of you

Joss, in case of Mail and Sendmail transports that "0" comes directly from your system / PHP and simply means that the message couldn't be sent to any recipients at all. I'm assuming that the same thing could happen with SMTP. The message could be a bit more descriptive, but technically it's not an error, so.. Mail / Sendmail failing usually means that your server isn't configured to send mail (intentionally).. or it's misconfigured and mail doesn't work. For SMTP tests, did you set proper SMTP server info etc.? How 'bout the "check connection now" option (using SMTP), did that work? Note: in any case, this sounds like a problem with your server. It doesn't seem to be capable of sending email directly, so your best options are to a) change that (reconfigure the server, contact administration etc.) or b) use external SMTP server (some hosts even provide these to their clients).

@dupalski: for the record, you might want to check out the "beginner site profile" Ryan has posted here. Just to be very clear: include files (.inc, .php, whatever) are definitely not a requirement.. and on very simple sites they just make things more complicated. On larger and more complex sites that situation changes drastically.

.. and Soma steps in to save the day. The simplest solution is usually the best

Try different method of storing the PageArray: $session->testResults = (string) $test; And on individual page: $test = $pages->find("id=" . $session->testResults); Trying to save PageArray in Session might not work here -- and even if it did, it could be quite a resource hog if this site gets a lot of use. Though I guess there are drawbacks to each method..

NullPage is an object, kind of a placeholder for non-existing page, and that is very different from NULL (PHP's way of saying that a variable has no value at all). They're not the same thing, so NullPage == null is not true. It's that simple, really.

@Joss: unless you actually need non-breaking spaces somewhere (and assuming that you're running a new-ish version of PW), the "beautify markup toggles" section of CKEditor field are pretty neat. "Remove non-breaking spaces" has saved the day a lot of times for me. Just saying

This is also good for lazy people like me. I've got some use for this module right away and you've just saved me some trouble researching solutions, so thanks!