Pierre-Luc

This is the intended behavior of the AutoDetect Language module. It will only run on the first page load, to set the $user->language setting, which is created from a session variable. There is no need to detect language on each page load (and you really shouldn't, to be honest), as it's set once by PW and it will reuse it on each page load unless it's overwritten by setting $user->language manually. If you need to check if AutoDetect Language has run (and reuse its state somewhere else), there are two session variables I created (that you can read about in the documentation). If you want to force it to run again, you can set $session->languageAlreadyDetected to false, but I wouldn't say it's generally advisable.

So, anyone else up for the challenge?

Ryan accepted.

I didn't know about them either until a few weeks ago, I discovered that while thinking about documenting PW. I've also asked Ryan on GitHub https://github.com/ryancramerdesign/ProcessWire/issues/1015 to start using them. That would really help us out.

@teppo, providing version information (matched against PW versions) is one of my goals, among others. This is both for Cheatsheet and Docs. Ideally we'd have @since tags in phpdocs for classes/methods, but right now they ain't there.. so it might require some work to figure this part out. For those who aren't familiar with them, here's an example : /** * Example of @since usage. * * @since 2.5.20 Added the $b argument. * @since 2.5.8 Added the $a argument. * @since 2.4.0 */ I personally don't aim at using ApiGen, it's there but it's a totally different tool, though of course that's up for discussion as it's still useful but for different use cases. I wish we find a way to work on docs together, and decide how to organize things as a team. That said, I think right now our goal should be to arrange the docs in a more readable fashion, update the parts that haven't been updated and setup a good structure for docs content (this includes having info on which version the docs are for). My main inspiration is Symfony's documentation, it's just stellar; very clear with lots of code examples for common things. What Ryan has achieved so far is a very good starting point, let's improve on this. Definitely not!

@teppo, I've seen this comment already, and I must somewhat disagree. Some of us do work this deep when working on modules for example and some parts of the architecture could use quick explaining, without entering into a full on object/method reference. I wouldn't say it's a priority at all right now though, other higher level things need documentation badly before this..

I'm reviving this thread! This needs to gain traction! I would really like to improve the docs, and I propose we start a documentation team. I've already started a Google Spreadsheet (open for comments, PM me your Google account for modification access) with a tree of the current documentation with comments and improvements (see What's in and What's missing or needs improving tabs). Note that this is mostly made from memory and notes I have laying around. I haven't personally read 100% of the documentation (these days I just go straight to the source code), so I would appreciate your input/feedback/additions. I suppose a spreadsheet might not be the best way to go at it, let me know how you'd like to organize things moving forward. Cheers!

I typically do frontend+backend form input validation by hand to fit whatever I have set in the field settings, but I was wondering if you guys knew a better way? I'm thinking about something like this: // Validate explicitly, afaik this does not exist $page->field->validate($input); // Or maybe something like that try { $page->field = $input; } catch (WireException $e) { // do something } I don't personally recall ever having trouble with saving a page and I guess it's mostly due to efforts I put in, but I'd like to make sure to keep everything in good condition without too much housekeeping. Especially I'd really like to be able not to have to maintain validation code if at all possible. Cheers!

Do you also use the field descriptions extensively? My clients LOVE this, it makes it very clear what is used where and how.

For the sake of readability, I would format it somewhat differently. All those open/close tags make code hard to read : <?php foreach($page->children as $element) { echo "<h3>{$element->sp_title}</h3>"; echo $element->sp_content; } ?> {} are used to explicitly tell PHP to evaluate a statement in a string, note this only works in double quotes. This isn't typically required, but it's good to get used to use it. Avoids some headaches, and you don't need to use "string" . $object->property . "string", which can save quite a bit of time in the long run. This is called complex/curly parsing, you can read more about it here: http://php.net/manual/en/language.types.string.php#language.types.string.parsing.complex.

AFAIK there are some efforts being made to be PDO compliant to support other database servers, but there are many challenges. PW is highly optimized for MySQL, so it would probably not be something you can expect in the near future. As for neo4j especially, unless there are PDO drivers in the works, don't put any hope on this.

I submit a patch to Ryan a few weeks ago who applied it, it's live in dev but if you want it in stable just download the latest ckeditor full package and overwrite the current one. No need to send a bug report.

Well that's too bad… As for another weirdly named project, try Windows. http://nick-jonas.github.io/windows/ Also good luck finding it on Google.

There's way more than that.. AIOM+, Shop for ProcessWire and other very useful plugins deserve some support to stay afloat without becoming "Pro" fields..

@dazzyweb, I just saw your discussion, sorry about that! Well, instead of adding the feature natively, we could just as well have a link in the top-left menu where documentation/support links are. Leave it up to the dev to create his own donation process if they want.. I think that'd be plenty!

Hey, would gladly help on that one, but the bug tracker is empty so no idea what to fix/improve/implement. Too soon?

Yep, I don't advocate so much to clients, it's not what they need to hear. The development time and maintenance cost is what usually sells PW. If they're afraid it's too hard to use, I'll show them a previous website. The description field is something most of them feel like is a pretty good selling point! It's those little details that count.

Another thing you might be interested in is using ApiGen to generate docs for core. PW is fairly well documented in code apart from some places, and you'll find most of what you need there.

Just to drive the point across further, recently I've been forced to maintain a bunch of WP sites (medium-high complexity) that are simply unmaintainable clusterfucks of modules inherited from other agencies… PHP directly into fields and the like… Just this week, I've found ~5 SQL injection vulnerabilities in extensions that look like they are rather popular in the WP community, bunch of totally ugly code, no comments to be found. This is what happens when people think WP saves costs, it just simply doesn't! To be fair, WP can be used to do great stuff, but it's a rarity unless you throw an insane amount of $ in it. /vent off

Yes, I think we largely differ in the workflow there. If I was still a one man shop or working with other devs, I'd probably just use it the same as you. But I am the only really experienced dev with a supporting team of integrators, and it's faster/easier to provide them pages with fields they can insert html into (we have lots of those "brochure" websites too, with all pages all different), and not have them bother with inserting all the content correctly for meta (for example) and things that might be critical in terms of features or security.

I'm committed to make all my PW modules MIT licensed for the sake of seeing PW become more well-rounded, but it would be a nice touch to be able to link my Stripe/PayPal account to receive donations. Is that something you guys are interested in? I wouldn't mind putting in some time to add that feature on the website if desired.

This is something I'd like to work on personally in the near future. It might not be full-fledged for a start but I'd be interested to know what are your thoughts on implementing this.

Been trying out Middleman recently too, but I figured if I can generate a static site with ProCache and have all the power of PW if needed, why bother (that and nobody else at work knows Ruby..), and with Middleman clients absolutely need to go through us to update. I like static sites, but I got bit by them a few times, when the client eventually decides they need something dynamic added. PW looks kind of the best of both worlds there to me.

I would greatly suggest you post this in GitHub's issue/request tracker.

Mostly migration during staging on production websites when the content still continues being edited from the client so you can't just copy the dev folder and overwrite the database (I know there are ways to diff a database, but I'm not that versed into it). Especially, if there are changes to the model (template, field changes) / structure, things can get messy, although it is indeed manageable manually without so much effort… I might be overthinking this one! Migrating from other systems is pretty straightforward, most of the time a CSV import might be all that's required. That's nice to hear! You pretty much confirm my thoughts. I do agree there are some problems with the documentation on deeper aspects, but it seems there are efforts right now in improving that. I would gladly take part in this effort and will be taking notes as I take the team through the migration.