teppo

When I started working on my first ProcessWire site I liked that by simply opening the basic-page.php template file (obviously connected to basic-page template), I could instantly see how everything worked. It was easy to start from there, building more complexity and adding those "advanced tricks" if/when needed. Things like delayed output, appendTemplateFile/prependTemplateFile, etc. raise the bar of entry, that's just how it works. They're things you won't simply "get on the first sight". You'll have to dig through other template, config and README files (or docs) to understand what's going on. However you look at it, things that "just magically do something" may be helpful and ease your workload once you understand how they work, but also tend to add to the frustration a new user feels getting used to the system. Personally I believe that the "first dive" into a new system should be as easy and enjoyable as possible. Anything that complicates things is likely to increase the bounce rate.

@sunlix: you might want to take a look at how I've handled this issue in the Changelog module. The approach I took there was adding new configuration option ($this->schema_version, which refers to the schema version currently used) and a constant (SCHEMA_VERSION, which refers to latest available schema version) and until those match it'll run updateDatabaseSchema() method, which takes care of schema updates. In that case the install routine actually uses an "outdated" schema version, so that module update (on existing installation) and fresh module installation behave exactly the same. That's definitely a question of preference. This is actually a simplified version of ProcessWire's own SystemUpdater.. and pretty much what @netcarver mentioned above too

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