Leaderboard

I want to say thanks to all people in the forums for being here and make this place so special and a great place to be. There's some spirit and drive going, I think many other CMS forums can only dream of. It's still small and the quality of people and their support to help in the forums always amazes me. Even newcomers help other newcomers in a manner it's quite unique I think. Not saying there's might other places that are the same, but I don't know of any. Thanks for the nice experience to all of you! Then the biggest thanks would go to Ryan our "Man on the Wire", always sharp and considered helpful, with brilliant ideas and execution. You build something very special here and while maybe some think it's not "sexy" enough, they don't know what's under the hood. I think people are really excited to get direct responses from you and this is what makes them feel at home, which ignited some friendly fire and spread all over the place. Quo vadis? This is for now and I really wonder how it will be when the forums grows to a place, where I hardly will be able to catch up with new posts. Every other day I wonder how long Ryan will still be able to do so for every question in the forum. Don't know how you do it but you do. So then where will ProcessWire be in a couple years from now? How far will this forum grow? Will there be lot's of PW sites spreading across the web and sharing places as with other big CMS'? Hardly think about it but I think it could very well happen. What could the PW web be? How many modules will there be and quantity > quality... While at it, Clouds! I can't hear stand it anymore, STILL we have moving clouds in the new ProcessWire website!!! Hope people don't think we go PW Cloud? Also I would love a horde of crazy new core php developers that help making crazy new stuff with this CMS/CMF. No I'm not drunk but after that post I'm wired. Keep it up, stay healthy and spread the word "ProcessWire". Peace. ( Ahhh, I reached 2000 posts and I didn't even notice yet! Well never used to post that much in a forum ever. Well mostly just BS nobody wants to hear heh )

First pw site... http://www.stokar.com/ composer's management agency. Processwire was great for this!; took on every challenge and request the client had with ease. Thanks to Ryan, and to everyone on the forum - it was an essential resource for working out all of the code to make this site work. -marc

Thanks Nik, So does it require a relationship unless it is called by id? The bit in the WIki I am working out is all about calling in pages (and rendering them) into another page. http://wiki.processwire.com/index.php/Including_a_page_in_another_page (only part done) So for the moment I am covering: Calling in a single page and rendering it directly in a template file. Calling in a single page via a "Page field" and rendering it Calling in a series of child pages and rendering them directly in a template file Calling in a series of pages via a pages field and rendering them. I have 2 and 3 sorted, have not thought about 4 yet and am a little puzzled by 1. I am being careful to explain in which circumstances if you move a page, you mess up your system, and when it is okay, for instance calling by ID.

So, besides little bughunting, I was thinking what would be the best thing to provide. And, I decided to focus on content creators. Check this super-cool thing out (you might want to go to youtube to see HighRes )

Greetings, Let me add my voice here! What makes ProcessWire different is that, not only is it a great CMS/CMF technically speaking, but it also generates a more subtle kind of inspiration that motivates people of all skill levels to get involved. But even beyond that, it has generated a unique "culture" here on the forum -- where people share ideas, are patient with each other, and really try to contribute and help. Then there is something else... Can't quite put my finger on it yet, but ProcessWire feels like a system born from something in Ryan that can be described as great technical knowledge mixed with an artist's conception of Web development. The point is, I deeply appreciate what Ryan has done and look forward to building great sites and becoming more involved in this community. Thanks, Matthew

Hi there, I just recently discovered ProcessWire and am still pretty exited about it and the ways it enables you to do anything. Thanks a lot to Ryan and everything who created it! What I was missing (or just overlooking?) recently, was some kind of char counter for textual input fields. Just an (en-/disable-able) are that shows, how many chars have been typed in. If you have some char limit defined for the field, it should show you, how many chars are left. Just think of the twitter online interface for writing new tweets. So, did I miss something here and this is already existing? If not, I think that this would make a nice addition to the backend modules. I'd give a try to develop it, if it doesn't exist, but since I'm quite new to the PW world, I haven't ever developed a module before and it will probably take some time. Please just let me know what you think of it. With kind regards, Marc Edit: Thanks so Soma, there is some Code there already. While still rough around the edges, it's definitely usable: https://github.com/boundaryfunctions/TextareaCounter

Soma, this is so great, thanks a lot for your good (and amazingly quick!) work! This works like a charm and the best thing is, that you can literally read through the code and grasp anything that is done there. Not that I would have been able to do it like this, especially not in that amount of time. This really shows how much thought was put into the PW API. Are you going to submit this to the official module repo? There's are still possibilities for improvement, like but not limited to: apply to flat textfields as well, making it count words, and preventing the user from typing more than allowed in a more drastic way. With your foundation, I will definitely be able to implement this. By the way, did I thank you already?

Ok fixad tha issue, damn no off to some relaxing

Nice idea, I was also thinking about some time ago. One way is to not extend the InputfieldTextarea, and make a new Inputfield type, but Hook into the necessary methods to extend the config and rendering. Since this made me wonder how it would go, I gave it a try. It's a nice example showing how to archive it using hooks only. It will give you a extra Input setting "Max length" in the field setup. And a counter for all InputfieldTextarea (not tinymce fields) and add a attribute "data-maxlength" to the one that have a max length value. I had to use "maxchars" as the setting field name as there's already this attribute, but not used in the context of page edit. The script js is also added via a hook, and is a basic example of the script that counts backward while typing. Since I was already that far it was easy to add, but you might want to modify it and add features if you like. This took me roughly 30min, and little more to add the js. I think a year ago I wouldn't knew how and would have taken ages to figure out. But it grows on you after so many modules and insight. This module shows you some good practices and maybe helps understanding modules. If you have questions please bring them in. Module code: https://gist.github.com/4252958 JScript code: https://gist.github.com/4252962 Put them in a folder /site/modules/TextAreaCounter/.. Install, enjoy. Edit: just found an issue... will take a look again

Hi, and welcome to the forums! Not exactly what you are asking, but there is a TinyMCE plugin for wordcount. To enable it in any TinyMCE field go to the edit field "input settings", and in "TinyMCE configuration options" add "wordcount" to the plugins list and "theme : advanced" and "mode : textareas" in two different lines to "Aditional TinyMCE settings"

Hello netcarver, Thank you very much for responding... I switched to using the "normal" Textile, and everything is working great now. In fact, I discovered an additional benefit: Textile adds <p> linebreaks on "return" key entries, so we don't have to use an additional module to make that happen in the textarea fields. This is actually my first time really using Textile. It offers a terrific balance of giving end-users crucial formatting optoions, without resorting to problematic WYSIWYG editors. Great work on Textile! And it's excellent you are part of the ProcessWire community. Thanks, Matthew

I agree with all that everyone has said so far and would also like to thank Ryan for this and also everyone else who continues to contribute. I consider my programming skills mediocre at best and when I first joined the forum and saw the level of expertise here, I was a bit hesitant to ask questions. But I have quickly come to realise that no matter what level you are at you will always get the help you need without ridicule and I feel comfortable asking for help now. I am working on my first full-blown site in PW now and hope to share the finished item with you soon. I have spent many hours on it mainly due to my own learning curve for PW, but I have learned a lot along the way. This is a site for my local community and I am doing it for free. Everyone I have spoken with here has been very positive about it, so I just hope that it gets the use that it's intended for.

This is certainly a refreshing place. A lot of this is to do with Ryan who communicates naturally and clearly - far too many developers are reclusive or very possessive of their baby and have real problems climbing out of their cave into the wide world. For someone like me who does not have the background knowledge to use frameworks to the full much of the time, this is invaluable because I do not worry about looking idiotic by asking silly questions. So I learn and therefore am tempted to give back. A lot of other open projects could learn from that ever so simple bit of good psychology and very good marketing! Good on yer, guys! Joss

Nice writing Soma. I agree and I think this is what is happening here:

I have some news about the potential conference in 2013. When I posted about this originally, I didn't know that we had another baby girl on the way, due around May. I am very happy about this, but it would also interfere with my ability to attend a conference. The baby would be too young to travel, and it's too much for me to ask my wife to be alone with a newborn + a 3-year old, while I travel across the world. So I have to put this conference plan on a back-burner while we figure out a better time to do it. Thank you for all of your interest in this conference. I'm really thrilled at all the enthusiasm this conference idea has received, lets plan to reschedule.

Just wanted to share what I recently used to create forms in modules and in frontend using the API and Inputfield modules PW provides and uses on its own. I think many newcomers or also advanced user aren't aware what is already possible in templates with some simple and flexible code. Learning this can greatly help in any aspect when you develop with PW. It's not as easy and powerful as FormBuilder but a great example of what can be archieved within PW. Really? Tell me more The output markup generated with something like echo $form->render(); will be a like the one you get with FormBuilder or admin forms in backend. It's what PW is made of. Now since 2.2.5~ somewhere, the "required" option is possible for all fields (previous not) and that makes it easier a lot for validation and also it renders inline errors already nicely (due to Ryan FormBuilder yah!). For example the Password inputfield already provides two field to confirm the password and will validate it. De- and encryption method also exists. Or you can also use columns width setting for a field, which was added not so long ago. Some fields like Asm MultiSelect would require to also include their css and js to work but haven't tried. Also file uploads isn't there, but maybe at some point there will be more options. It would be still possible to code your own uploader when the form is submitted. Validation? If you understand a little more how PW works with forms and inputfields you can simply add you own validation, do hooks and lots of magic with very easy code to read and maintain. You can also use the processInput($input->post) method of a form that PW uses itself to validate a form. So getting to see if there was any errors is simply checking for $form->getErrors();. Also the $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automaticly. It's also worth noting that processInput() will work also with an array (key=>value) of data it doesn't have to be the one from $input->post. Styling? It works well if you take your own CSS or just pick the inputfields.css from the templates-admin folder as a start. Also the CSS file from the wire/modules/InputfieldRadios module can be helpful to add. And that's it. It's not very hard to get it display nicely. Here an code example of a simple form. <?php $out = ''; // create a new form field (also field wrapper) $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); // create a text input $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr('id+name','name'); $field->required = 1; $form->append($field); // append the field to the form // create email field $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $form->append($field); // append the field // you get the idea $field = $modules->get("InputfieldPassword"); $field->label = "Passwort"; $field->attr("id+name","pass"); $field->required = 1; $form->append($field); // oh a submit button! $submit = $modules->get("InputfieldSubmit"); $submit->attr("value","Subscribe"); $submit->attr("id+name","submit"); $form->append($submit); // form was submitted so we process the form if($input->post->submit) { // user submitted the form, process it and check for errors $form->processInput($input->post); // here is a good point for extra/custom validation and manipulate fields $email = $form->get("email"); if($email && (strpos($email->value,'@hotmail') !== FALSE)){ // attach an error to the field // and it will get displayed along the field $email->error("Sorry we don't accept hotmail addresses for now."); } if($form->getErrors()) { // the form is processed and populated // but contains errors $out .= $form->render(); } else { // do with the form what you like, create and save it as page // or send emails. to get the values you can use // $email = $form->get("email")->value; // $name = $form->get("name")->value; // $pass = $form->get("pass")->value; // // to sanitize input // $name = $sanitizer->text($input->post->name); // $email = $sanitizer->email($form->get("email")->value); $out .= "<p>Thanks! Your submission was successful."; } } else { // render out form without processing $out .= $form->render(); } include("./head.inc"); echo $out; include("./foot.inc"); Here the code snippet as gist github: https://gist.github.com/4027908 Maybe there's something I'm not aware of yet, so if there something to still care about just let me know. Maybe some example of hooks could be appended here too. Thanks Edit March 2017: This code still works in PW2.8 and PW3.

------------------------- Update November 2018: This language pack has now a new maintainer. Please see the new thread for updated versions and discussion. ------------------------- Well here's my first try to translate it to german ("de-de") All of the the translations are right but I'll change some later to sound nicer. And, I don't know if the nativ english speaking people here will understand it, but this translation uses "Sie" to address the user formally. (There's a difference between "du" (means you) and "Sie). But I guess "Sie" is the better choice. UPDATE: - Improved some translations to sound nicer. UPDATE 2: - added some new translations UPDATE 3: - added translations for new functions (like cloning) UPDATE 4: Please see this new thread from the new maintainer @jmartsch de-de (updated 1323468757).zip

Hello folks, The next release of textile (v2.5) is going to see some major changes to the codebase and a few minor additions to its abilities to handle text. The changes outlined here are not yet committed to the dev branch of netcaver/textile but (Now committed) I want to post about this in advance so any developers here can get a feel for what will be changing and see if it impacts them (to track what is already committed to the dev branch for v2.5 you check the changelog.) As I'll be taking over responsibility for maintaining the textile text formatters with this release, I'll also take care of making sure these code changes don't impact end users of the textile in PW. However: if there any devs reading this who use textile in other work they might be interested in the rest of this. To facilitate textile’s uptake in other projects & to make it plain easier to read, I'm moving the code towards PSR-2 compatibility. Although I don't necessarily agree with everything in the PSR-2 standard, I will be adopting it for textile because... textile has used no coding standard to date and has had many contributors who have all used different styles & consequently the coding style (or lack of it) reflects this and needs some sanity restored to it. It gives people who may contribute to textile a standard to work to. I have been advised that a minimum of PSR-1 compatibility is required for textile's uptake in at least one other CMS. So how might these changes bite your installation? Here's a few ways... First potential problem: Are you overriding textile's defines to customize something? As PSR-1 (needed for PSR-2) doesn't particularly like code declarations & side effects (such as the #defines that pepper textile) in the same file, I need to know what use, if any, folks are making of the existing txt_ defines listed here as they will be going. If you are using them, you will need to start calling a new method setSymbol('name', 'value') prior to calling TextileThis() or TextileRestricted() and drop the defines as textile will no longer be using them at all. NB. the 'name' to pass into setSymbol() is as shown in the link above without the leading 'txt_' which is no longer needed as the names will no longer be in global scope. If you are using textile in exactly its default configuration with respect to defines there is nothing to worry about so far. Next: Using a define called 'hu' to make all relative image paths absolute. This is only likely to impact the use of textile in Textpattern CMS (it's original parent project.) Textpattern CMS uses a define called 'hu' to point to its root path and if textile finds a define called hu it uses that to prefix all root-relative image paths turning them into absolute paths. Now that textile is breaking free from its Textpattern CMS heritage, I think it's time to break this hidden coupling between the two and instead replace it with a generic (and explicit) setRelativeImagePrefix() method, allowing other projects to use relative image path prefixing if they need to without resorting to using the 'hu' define and without the possibility of a name conflict if they already happen to be using a define called 'hu' for something else. If your project doesn't use any define called 'hu' the above won't be a problem for you. Finally: Still using PHP4? I thought not, but I have to cover this anyway. Next up is PSR-2's requirement for explicit visibility on all properties and methods. As textile comes from a PHP4 heritage it has never had these. A quick look at my stats for PHP versions across hosts show that ~79% of hosts run PHP of some kind and that ~76% are PHP5 or better. Needless to say, PHP4 support is going. But even if you are running PHP5+ this change to the textile codebase will bite you if... you are calling any methods other than the constructor method, TextileThis() and TextileRestricted(). you are accessing any of the class properties. These will all become either protected or private and most will have no set or get methods. I figure that for most projects using textile there will be no issues but please let me know if you are going to get bitten by any of the above and if you know of other devs who use textile in their projects, please give them a heads-up.

Feel free to take it and improve it. Make it your own whatever and be sure to submit it to modulers page. You're welcome. Glad if it helps people.

I have implemented TinyMCE, AlohaJS (when it still had ExtJS dependencies) and now CKEditor 4.0 in various projects and I have to say that I really loved how the CKEditor 4.0 works. It was very fast to implement, easy to customize, works fast and it supports both inline/textarea... It has brilliant documentation (http://docs.ckeditor.com/#!/guide) and as a cherry it looks very pretty. After I have implemented it in this project (I use it for frontend editing in this case) I will definitely look for implementing CKEditor Inputfield. I think the table editor alone is so much better than what TinyMCE that it is worth it. But also looking for some nice scenarios to implement CKEditor on frontend - maybe with AdminBar 2.0... (there isn't yet a thing called AdminBar 2.0, but who knows...)

Thanks Martijn Okay, so there is a relationship there. If it is moved from /blocks/ it will break. Which reinforces the point I am making that unless this is part of your template structure (for some reason) it is better to pull a page in via a Page Field so you are not messed up when it moves and you can change the source page easily. Ta much! (PS: Last time I met someone called Martijn, I wrote a whole pile of music for his fantastic animations for the Dutch government. Good money too!)

thanks all for taking a look at this. As i said, this was the first PW site done for a client, and despite the learning curve, it all went relatively fast, and what was especially important was how i was easily able to respond immediately to any request the client had; is seemed that the answers to virtually all of my questions were already in the forum, and when i couldn't find a way to do something, the forum came up with solutions. The site has been live for over 3 months, and none of the content has gotten messed up..(thanks to PW fields, and limited use of WYSIWYG..!) Which is very refreshing, after coming from the world of mostly Joomla, where all of my clients seem to go especially wild with fonts, bold, italic, spacing, font size, (and makes it look AWFUL!) and then i have to periodically go in and do spring cleaning for spans... Also - I haven't had to provide any training, tutorials, or support for this site since the site went live, which also illustrates how easy, and user-proof PW is. As far as why no women composers...ha... that's an interesting question, and i'll have to ask Howard about that next time i speak with him.. but it is a statistical reality in contemporary music that men outnumber women... and I once heard a conjecture from my freshman music history professor, who said that males are more driven to compose because they can't biologically propagate the species...

Why is koding.com going to Soma's module manager?

You would have to build a module that extends InputfieldTextarea, limits the amount of characters, and that calls the necessary javascript counter.To know how to do this, have a look at these two examples on github AceEditor and TinyMCE. Notice how the configuration fields are created with ___getConfigInputfields() on both of them. You will need it at least to set the limit on a per field basis.

That sounds pretty much right. After moving PW from public_html/folder to public_html things should (mostly) work instantly, but one thing you will need to take care of are in-bound links; if you've created links to local content, they're probably relative and pointing to /folder/whatever-link-target/. You could either change these links directly from database, install Page Link Abstractor to handle this for you or use this little snippet by Soma. Another option, of course, is to export a page profile and re-install PW at public_html with that. This won't take care of the link problem, but in that case it would be quite easy to replace all "old" links in MySQL dump before running install process.

I think you nailed it there, Matthew.

Hello there! Just wanted to say that I like what you're doing -- I've actually built something quite similar and found it very useful for (especially) larger projects, so I'm certain that this kind of module has a lot of potential I'd also like to make some suggestions, if you don't mind: * First of all, you might want to consider adding a separate directory for view files -- or perhaps making this configurable via module settings. Currently there's a small but still existing chance that view and template names could conflict. Making this user-configurable would also make this module usable out-of-the-box for those of us who prefer their own folder structure instead of flat templates directory. * Second suggestion / observation is that the way you're currently handling template names might not work as expected for templates that have been set to use alternative template filename via advanced template settings. I'm not sure if you would really consider this a problem, but I felt I should mention it anyway, in case you didn't remember that this kind of option existed. Anyway, with this setting in some cases a) multiple templates might have same filename and b) filename might not contain actual template name at all. This might cause problems, since your code seems to expect that it always does: $template_obj->filename = str_replace($templateName, $view . "-" . $templateName, $template_obj->filename) To be honest I'm not even sure that I understand why you're using str_replace() there -- wouldn't it better to simply set $template_obj->filename as $view . "-" . $templateName? This way alternative template filename, if given, would simply be ignored and view filename would always be consistent with actual name of that particular template. * And finally a quick comment on something quite subjective: code readability. The cleaned up version Some presented above is actually quite a bit easier to read and understand, partly because those comment blocks are (somewhat unnecessarily) taking some serious screen estate, but also because it seems generally speaking more polished. One very specific thing I'm having hard time wrapping my head around is your variable naming convention: $templateName = (string) $page_temp->template; // We pick the template name... $template_obj = &$page_temp->template; // ...and the template object associated. In that short code sample you're already using two naming conventions, first camel case and then delimiter separated. Picking one of those and sticking with it will make your code more predictable and readable in the long run. Trust me, I'm really not trying to be condescending here -- this is just one of those little things that will really help other programmers understand (and appreciate) your code. And that's it for the nagging. All in all it's really nice to see people posting (especially) these kind of proof-of-concept modules here. Pushing boundaries is always admirable, and that's exactly what you're doing here. Keep up the good work!

Welcome henriette. There's several ways to archive what you want. Your ideas are on the right track, you definately want to create some "/footer/" page where you could enter the content for your footer then output the content of that page. http://processwire.c...-settings-page/ Single page approach: If you create a template "footer" and in the php file you just would output the markup and data of the page. You can make this page "hidden" to not show up in navigation. Then in your main template, where you would include you just render the "/footer/" page like this. echo $pages->get("/footer/")->render(); and the footer page template would be this (just example. <div id="footer"> <?php echo "<h3>$page->title</h3>"; echo $page->body; ?> </div> Subpages or repeater approach: You could use repeaters or just subpages to create the 3 blocks. Repeater module is a great way to "repeat" a set of fields. It is not installed by default. See infos here: http://modules.proce...dtype-repeater/ If using subpages you would create children pages under maybe a page "/footer/". Then output them like this. $blocks = $pages->get("/footer/")->children('sort=sort'); foreach($blocks as $block) echo $block->render(); If using repeater, it would be slightly different, but the repeater field is like a field that holds pages, but since you can't use render you'd have to output markup too. If repeater field is named "footer_blocks" with title and body field inside you'd do it like the following: $footer = $pages->get("/footer/"); foreach($footer->footer_blocks as $block) { echo "<h3>$block->title</h3>"; echo "<div class='footer-body'>$block->body</div>"; }

Hi Henriette I have done a similar thing on a site I am currently working on. There are a lot of ways you can do this. Here is a very basic version: Create the fields for your three blocks - call them Block Title 1, 2 & 3 and Block Body 1, 2 and 3. Create a template that includes these fields. Now create a new page Called "My front Blocks" (I am being really predictable here) and use your template. Go to Settings on the page and make it hidden (it should be published, however). Now fill in your information. That has given you the block content. You now need to call it into your footer. In each position You need to call in the fields from My Front Blocks: <?=$pages->get("/my-front-blocks/")->block_title_1 ?> <?=$pages->get("/my-front-blocks/")->block_body_1 ?> And so on. I leave the layout to you! You can do the same thing with a lot of other info while you are about. I create a page called Site Settings (with a matching template) and I put things like meta keywords, banner, blocks, site title, reusable phone number, anything that I may want to use all over the place. And then just call them into a template. Getting really clever If you want to go completely mad, you can create blocks template ( and associated blocks.php template file) and then create lots of blocks as pages, preferably as children to a hidden page like "blocks" In your Site Settings template or where ever, you can then create a Page field type for each block (choose single and null on the details tab) and set the parent to Blocks and the field to select - a drop down, basically. Now, one your Site Settings page, you can use the dropdown to choose which block you want for each position. Your blocks.php template file will take care of the layout of the block information, you just need to call the pages fields into your footer. For instance: <?php echo $pages->get("/site-settings/")->name_of_pages_field->render(); ?> The render() will then render the entire contents of the blocks page. Does that help? Joss

It sounds like a fantastic idea, Matthew, and I certainly agree that Codeigniter has some of the best documentation I've come across with, so it could act as an example to aspire to. In my opinion, and as Soma mentioned in another thread, the main problem novice users face when looking for information is that, more often than not, they don't really know what to look for, so the odds of them finding the right info are pretty slim. I really believe that having 'how-to" articles that address a wide array of different case scenarios would help diminish this problem, and make the current documentation more beginner friendly. The small project walkthrough tutorial that Ryan posted some time ago is a superb example of how this can be implemented. This tutorial helps ProcessWire newcomers understand how the most basic actions are executed in the system, and provides information that will be of use in projects that go far beyond the scope of the case study Ryan proposes. I can say this tutorial helped me understand the system. In my opinion, ProcessWire's documentation is already quite good, but I think, looking at the future, we should go the extra mile to make things easier for those users with less experience with PHP. As it turns out, the number of designers using ProcessWire seems to be growing, and this can only be regarded as a good thing. Adding a collection of project walkthroughs, or how-to articles to the documentation, be that through processwire.com or through any other website, is going to make ProcessWire much more attractive to a much wider audience. This is just my opinion, anyway. Claudio

I somehow wanted to write about the documentation part but left it out in hope it will come up naturally. Thanks for bringing this up again Joss! Exactly sums up what I think about the subject. A software raises and falls with its documentation and support (and some other factors as well). There's a good bit documentation Ryan put together. For people like me it's enough to get started quickly and hardly have to ask questions. This seems not true to most of the audience that ProcessWire seems to attract now which are more design orientated never had to code PHP until now. I'm almost surprised that it really is a good main audience. Though one could arque there's a lot of advanced technical user that haven't even joined the forum yet, but use to search for answers or figure them out them self. Reflecting back the year and a half on this forum, it showed clearly where people are having problems understand the basic principals, and although there's already some documentation there, they don't seem to find it as they don't know how to look for. I always feel a little bad to see so many good threads and QA are hidden in this forum that are hard to find (though with google it is possible) and most of them should be just collected, prepared and put into a place where it can be sorted and searched and listed in a easy way. There's TONS of snippets and code examples! Some are really great information you can't find elsewhere in documentation. I would have started any day building something and only the fact it would take a lot of time is why I haven't started yet. And I'm surprised nobody has yet started something more serious apart from the wiki (which obviously involves some problems). So and you guys tell me you have something on your own! Damnit, then why wait and not make it a movement people who are willing to help and dedicate some free time to the project. I don't think making it wiki style for writing for everyone is a good idea, but make it with a small group of people who have access. ProcessWire can be used to build something easily! But I see it just takes time and the right people to join to get this rolling. I'm happy to see that there's people like Joss understanding this fact and take initiative without even asking them! Thanks to all who decide to help and join the lonely nut to make him the leader.

One of the reasons that a Forum can get overwhelmed (which can lead to posts getting unanswered and the forum feeling cold), is because users, especially new ones, are having trouble getting to grips with the system. And that is normally a failing of Documentation. Documentation is the Hell waiting for every open source project that does not have gratuitous funding sitting behind it - so most of them. Some projects (Joomla is a great example) produce huge amounts of Documentation, but the mix of very technical articles with some more useful bits shoved in the cracks can make it daunting. In consequence, the Joomla forums are stuffed with dead simple questions (often with rather confusing answers) that are the first thing that pop up on Google when you go searching for your particular problem. Open Source is not alone in this - I would argue that both Microsoft and Apple suffer from similar problems. The ideal solution is to make sure that the primary documentation is weighted to the "how do I do this?" Sort of writing. How to I change my site title? How do I change the background colour of my home page? How do I create another user? How do I give my image a caption? How do I get the cat fur out of my disc drive? Even when the question does not make complete sense to the system (like the second question) it will get asked. So, "The back ground color of your home page is set by you by creating your own look and feel. Read 'how to make a template' for more....." The real test is Stackoverflow. The site is completely crammed with questions that are not answered in the docs of the software sites, or are buried so deeply or written so obliquely that they are impossible to work out. "The refractive nature of the landing page of your dynamic web application has implications to the coding criteria implicit in the opening statements of your primary head of page include. Thus, a proprietary approach must be undertaken as part of the design policy and fabrication so that the appropriate tonal qualities can be defined and stated with a style classification ...." People write stuff like this! (And get paid for it, Yee Gads!) While the ProcessWire community is small, happy and generous, this is the perfect time to sort the problem out before it happens - simply by creating great documentation that not only gives expansive answers to deep questions and technical information for those that need it, but also spends lots of energy answering the little questions that come up time and time again. Then, when it all gets busy, new users can be faithfully pointed to the right page in the manual and not only get their question answered properly, but get to enjoy the whole experience that much more (and not have to suffer from the poor, over worked moderator who is answering the question for the 50th time that day) Here endeth the advert for the Wiki! Joss PS: Another idea that can help is what I call "half an FAQ" (or perhaps a Q)- Basically, it is a huge list of searchable questions which are then linked to the right bit of the documentation The reason for this is to encourage users to use the docs rather than fragment the information all over the place. It also keeps the doc writers on their toes making sure the questions actually get answered!

Thanks to you too Soma, and Diogo and Apeisa and all the other people who make this such a welcoming place for newcomers and help out when we inevitably get stuck. I agree that Ryan sets the tone, he's unfailingly helpful and polite and a bonafide genius at just about any web issue I've ever come across! I do wonder, like a few others, how this place will evolve when it grows, will we still be able to maintain the same "intimate" feeling? (Joss I need your help here with the wording!) I agree with Pete that there will probably need to be moderators for different forums. I love this community! PS: I also think the timing of Soma's post is spot on. It does feel like PW is growing by the day.

Ryan definitely set the positive tone on the forums, whether by answering to every kind of question or by cutting any discussion with a more negative tone (toward other open source projects for instance). This kind of attitude is somehow very contagious I'm very pleased to see new people coming and becoming quickly part of the project, and the last two weeks were great in this matter. A big welcome to every one!

Ditto from me to all of the above. I've visited a fair few forums over the years and I've not seen another software-related forum as friendly as this. It definitely has to do with ryan always reading and helping out on the forums from day one. I agree with Soma that there will come a day when ryan can't read or offer code examples in every post and that's when people start getting more selective and eventually you need Moderators for different forums that are fairly specialist in those areas (I'll moderate the Pub forum ) but we're a way off that yet and it's good to see that the friendliness and helpfulness rubs off on new members and everyone helps each other out where they can. The trick is that no matter how fast or big the forums grow, we need to maintain this sense of community - so far it's working just fine!

I couldn't agree more with you, Soma. As a newcomer to this forum, I already feel part of the community, part of this family that is ProcessWire. I really can't think of another online forum I've been a part of that is as friendly, open and helpful as this one. I think this might be due to the fact that we are all so passionate about ProcessWire and that we just don't mind to devote some of our time to help others that are as passionate as we are about this system. I would also like to thank Ryan, our man on the wire, for being so kind, patient and helpful. As for the future, well, only time will tell. We might as well just enjoy what we have here and what will be, will be. @apeisa: pretty relevant example, haha.

Thanks Soma this is really nice of you. Thank you also for all the great work that you are doing here! Now I have to logoff for a few days, so this is a great last post to read before I head out. Hope that you all have a great weekend and week! Also please no more Ektron licenses on my credit card.

Is it just me or are processwire designer/developers a classy group of people? All these sites I keep seeing are well designed, expertly executed, all around quality work!

Hey all! Finished 1.0 version! Updates for version 1.0 [add] Added Textile mode, with huge number of enhancements [add] Added auto mode select (yes!) [add] Added PHP mode, even though there are no means to invoke that yet [enh] Enhanced quote rendering in markdown [enh] Added many styles (sup,sub,cite,code,ins,del,…) [fix] Fixed the default values (and saving the default values) [cng] Show invisibles is off as default Note: Still testing in various browser Please, let me know on github, what works and what doesn't. Thank you!

So here we go: http://siebennull.com/PWfileReference/ I hope it gets clearer ;-)