Leaderboard

Hey, I just thought it might be helpful to have a guide for your module's presentation: The Title The title of a module is an important part of it. It should kind of make the main function of a module understandable after the first reading. So there are some guidelines for naming a module: (via http://processwire.com/api/modules/) Here is a more extended list of some "module prefixes" and a short description for each: (via http://processwire.c...-module-naming/) The Description A good description is another important part of your module's presentation. Here is a short list of sections you could (or maybe should) include in it: General: The main function of your module How to use: A description of how to use your module which maybe includes some details the user won't see directly. Installation: If there is something special about the installation of your module you should add this to your description. Screenshots/-casts: It's awesome if you would take a picture of your module (if it changes or adds something the user is able to see). Or maybe a screencast if you like to. (Great example: http://processwire.c...ncy-admin-mode/) Links At the end of your post you should add some links like where the user can download the plugin and if you've added your module to the module section you should post the link here too. Module Section If you've posted your module already to the modules section you can easily copy it's contents there and use them for your post here or - of course - the other way around. I hope this post was helpful to you. Greets, Nico

Hi, This is a complete server configuration block for NGiNX communicating with php-fpm. There are a few things that will require customisation: server_name root access_log and error_log fastcgi_pass - socket or TCP specification configuration blocks relating to 40x and 50x error handling Note the use of fastcgi_param HTTP_MOD_REWRITE On; which quiets an installer error about requiring mod_rewrite. You might also want to copy htaccess.txt to .htaccess in the ProcessWire top-level directory. server { listen 80 default_server; server_name localhost localhost.localdomain; index index.php index.html; root /var/www/html; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log notice; default_type application/x-php; ### SECURITY - Protect crucial files location ~ /\. { deny all; } location ~ /(COPYRIGHT|LICENSE|README|htaccess)\.txt { deny all; } location ~ ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) { deny all; } location ~ ^/site(-[^/]+)?/install { deny all; } location ~ ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php { deny all; } location ~ ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) { deny all; } location ~ ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) { deny all; } ### GLOBAL REWRITE location / { try_files $uri $uri/ /index.php?it=$uri&$args; } # pass the PHP scripts to FastCGI server on local socket # location ~ .+\.php((/|\?).*)?$ { fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTP_MOD_REWRITE On; include fastcgi_params; } # redirect server error pages to the static page /40x.html # error_page 404 /404.html; location = /40x.html { root /usr/share/nginx/html; } # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } In the php-fpm configuration you need to specify unix socket or TCP connection parameters and possibly the chdir setting. These are distribution-dependent values and you will need to determine the correct values for your scenario. My configuration is as follows: ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port' - to listen on a TCP socket to a specific address on ; a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ; specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. ;listen = 127.0.0.1:9000 listen = /run/php-fpm/php-fpm.sock ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 listen.owner = nginx listen.group = nginx listen.mode = 0660 ; Chdir to this directory at the start. This value must be an absolute path. ; Default Value: current directory or / when chroot chdir = /var/www/html Please note that I researched these configurations and the preceeding security configuration from original documentation. I did not rely on howtos available on the Internet. Each has been carefully implemented and undergone significant testing before going into production. Regards, Neil Darlow

Hi Sunny, There's nothing built-in but it's all achievable and there are already some examples on the forums. Which I'll try and track down for you. You can start by extending the built-in "user" template. If you go to templates and then filters->show_system_templates. Like that you can add images and other things to the built in "user". You could equally add new members as new pages as well as setting them as a new user, this may be a better way to go long term. You will need to create front-end forms to allow people to register/edit/login. It is reasonably straight-forward to add new pages from the front-end in PW. You can find more info here: Custom logins: http://processwire.c...7-custom-login/ Creating new pages with API: http://processwire.c...-pages-via-api/ Also there's loads of people on here, including me who'd be happy to go through it all with you step-by-step but definitely check out Ryan's Form-Builder module too EDIT: Removed code as Soma's right, it's probably best to go step-by-step and end up with a lot neater code! As Pete says, there'll be people here to help you at each step but once you break it down, it's all very achievable and ten times easier the second time around.

@panictree There is an underlying problem with so many of the alternatives and that is the use of the term CMS. As time has moved on and some, like Ryan, but many others too, have looked at web applications as tools that can achieve more than just allowing someone to edit something. Consequently, the term CMS has come into its own - it is not just about a news article, it is about managing and manipulating all kinds of content. However, some systems, and I put Joomla and Wordpress into this category, are basically just AMSs - Article Management Systems - that are bent and broken to make them work in other ways as well. As time moves on, this is going to prove to be more and more of a limitation and if they don't break free of that model, their usefulness, especially for businesses, will dry up.

Hello, Why did I feel a buzzing in my ear this morning? Oh, I see! Let me get this straight: I have to take responaibility for Joss being here? Quick story... I learned about ProcessWire over a year ago, through a ModX forum discussion. I was very impressed that in that arena a lot of people expressed respect for Ryan's achievement. But I did not start using ProcessWire then because I had invested heavily in a Joomla CCK system (long story). But then, just a few weeks ago, I saw a discussion on the Laravel forum where -- again -- a community of people not directly interested in ProcessWire expressed respect for what Ryan was doing. It was the right time for me to take the plunge. It took only a couple of days for me to replicate everything I was doing with the CCK -- and to be able to do a lot that the CCK could not do. So here I am -- fully into ProcessWire. OK, that was not such a quick story. But remember, I am responaible for two people here! Thanks. Matthew

I'll stand at the gates as part of the welcoming committee.

Now it actually happened. There are too many unread topics to read them all! This must be biggest leap in forum activity since 1997 when Soma joined. And it's a pretty amazing and great news!

Protip: Leave the ending php tag out and it wont happen again.

Thanks, I will look into this right away. Did a search for membership without much luck. I would much rather jump into PW then wrestle with WP/Buddypress for the simple site I have in mind.

Tested here and works great! Thanks for making this Boundaryfunctions and Soma! I look forward to seeing this in the modules directory. This is a very useful module for sure. Minor point, but longer term, I wonder about the hooking method and whether that might present problems for future InputfieldTextarea derivatives. This one specifically excludes TinyMCE, but feasibly there are future others it might need to as well. It makes me wonder if this module might better exist as an Inputfield itself (InputfieldTextareaCounter) or perhaps as a module config setting where you check boxes for which Inputfields it should apply to. Or perhaps as a core addition to existing InputfieldTextarea. These are just ideas for the future, but seems like what you've got here now is working great and I look forward to using it!

I first learned about ProcessWire on this blog post: http://bit.ly/U9VugH. After reading it, I went straight away to ProcessWire.com, downloaded a copy and started to play with it. Can't say I regret it!

If someone wants to write an article about how to make the move from EE to PW, I will gladly edit it and give it some spin. It can go on the Wiki as a useful article and then you can all put it on your blogs everywhere! I am not talking about how to move an actual site, but rather if you do this on EE, this is how to achieve the same thing in PW .... that sort of thing. Joss

I came here from EE and agree that EE users looking to go elsewhere won't find a better fit than PW. Bit of a shame for them though, I also found it a nice system to use and in the main real enjoyed using it. The cost for my small sites had begun to get prohibitive as well as the need to install modules to do simple things. I'm just delighted that PW is here to offer all of the advantages of EE without the drawbacks And it response to Claudio's final question, I think the answer is "talk about PW in their forums". Not sure whether or not that feels right though...

Greetings, I'm glad someone is talking about this here. If it was April 1, I would think that Ellis Labs' decision was a bad joke. But, apparently, it is serious. I have used EE for a couple of projcts. I stopped using it a few months before I discovered ProcessWire. It's a great system, maybe the best out there after ProcessWire. But the new pricing scheme will drive away all but the most lucrative design studios. Just to lanch an EE site costs about $2,000. With middle-of-the-road support, the first year for that project starts off at about $4,400, with recurring minimum service fees at $2,400/year. To have same-day support, the first-year cost of a site is -- not kidding -- about $26,000, with recurring minimum service costs of $24,000/year. Some of my customers could bear that, but I would clearly have to reject all arts organizations, non-profits, community concepts, not to mention any of my own "pet projects." But the real damage will come from the fact that in the famed Ellis Labs forum there is an understandable reaction from many valuable and active members who are obviously not willing to continue offering free advice to support Ellis Labs. I'm puzzled by this move. It's too bad -- seriously. I think it will not only drag down EE, but may also take CodeIgniter with it (and CodeIgniter has been having enough trouble lately as it is). But yes, to the main point of this discussion, it might bring new people over to ProcessWire. Thanks, Matthew

Hi, I use ProcessWire under NGiNX on both FreeBSD for production and Fedora for development. My security configuration is as follows: ### SECURITY - Protect crucial files location ~ /\. { deny all; } location ~ /(COPYRIGHT|LICENSE|README|htaccess)\.txt { deny all; } location ~ ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) { deny all; } location ~ ^/site(-[^/]+)?/install { deny all; } location ~ ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php { deny all; } location ~ ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) { deny all; } location ~ ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) { deny all; } I can share rewriting and php-fpm configuration also if required. Regards, Neil Darlow

This module installs a page on your Setup menu in the admin where you can manage comments (assuming you have a comments field installed). Download from the modules directory at: http://modules.processwire.com/modules/process-latest-comments/ Features include: Easily find the latest comments needing approval or moderation. Shows comments from all pages on 1 screen, paginated and in chronological order. Enables you to change the status of any comment, edit the text or delete. Filtering by status/type, cite, email or IP address Screenshot: I've been wanting to build this for a long time, and something like this should have been there from the beginning, as it's a bit tedious to keep track of all your comments on a large site without this. So this module may be moved into the core for version 2.3, in which case it'll be renamed to ProcessComments, so as not to conflict with those that may have this installed.

Greetings Everyone, I've been meaning to get into this here, so... I'm getting into this here. Before coming to ProcessWire, I spent quite a bit of time getting familiar with PHP frameworks. First, it was CodeIgniter, more recently Laravel and Symfony, and Yii. I really like these frameworks (especially Yii, even though Laravel is getting all the attention lately). However, I can't help but feel that ProcessWire takes care of all the same things that these frameworks do, and it has the core user, database, and other capabilities taken care of. There are still a few actions here and there that I can pinpoint better in Yii or Laravel, but it feels like ProcessWire could definitely close those last few gaps. Of course, we refer to ProcessWire as a CMF, which clerly indicates "framework." But are my instincts correct in saying that ProcessWire is built on a framework that is equivalent to something like Yii with core CMS capabilities built on top? Thanks, Matthew

I've been working on a blog profile that we can have as an installation option for ProcessWire. The goal is to have a profile that someone could download and setup a pretty nice website/blog without having to touch any code (i.e. it's ready-to-run and populate). I'm hoping that this is something that may help us to grow our audience beyond the web development community. The requirement is that it must be as easy (or easier) than WordPress, both to install and use. This profile is also for web developers, as it's a blog profile ready to be styled and enhanced -- a good starting point. It uses the Zurb Foundation CSS framework, so it is fully responsive and mobile-ready. It's not much to look at now, but should be fully functional. I'm making progress and wanted to post a preview. The content you see here is from one of my client's blogs and the content is just here to test things out. http://processwire.com/blogtest/ I'm hoping to get this up on GitHub next week. I've never really done much blogging, so am seeking feedback on what others would suggest to make the blog profile as good, powerful and simple as it can be. Right now it's pretty much a generic Zurb Foundation "look and feel", so it probably needs at least some color tweaks and integration of some masthead photo(s) or something.

https://github.com/apeisa/Thumbnails Template usage: echo $page->cropImages->eq(0)->getThumb('thumbnail'); Better docs coming soon. Development sponsored by: http://stillmovingdesign.com.au/

Fancy Admin Mode Just had a little funwith fancybox iframes, and created a little module that opens all admin links (topnav links, edit, view, new, copy actions) except "Pages" screen and "Site", "Search" in a FancyBox, so you'll never leave the page tree. It even works with inherit editing child pages. Download: https://github.com/s.../FancyAdminMode Little screencast to se it in action:

addd wiki.acct for me user willyc pls wants to add sum articlas.and edit.for typographey, note.foots, changes makes,etc

Joss, thanks for your outstanding work on the Wiki! I am making my way through it and posting comments on the "Discussion" tab of each as I go through them. Here's what I've got so far: http://wiki.processwire.com/index.php/Talk:Basic_Website_Tutorial And just one or two comments on these pages: http://wiki.processwire.com/index.php/Talk:Pages_Overview http://wiki.processwire.com/index.php/Talk:Page_Field http://wiki.processwire.com/index.php/Talk:Article_Listing_Page

I Would like to throw a huge, hefty spanner into the works here! (Just for fun) If you split PW into two piles, in one pile you have the Site directory. Here is, or will be, your CMS. PW gives you a starter, but once you get into it, you are going to build your own content management structure in there on top of the base. In the other pile is the WIRE directory. However, this is NOT a CMS, or perhaps even a CMF .... I have a suspicion that it is really a CME - a Content Management ENGINE! Joss PS: I have this great want to rename the SITE directory to PROCESS ... just to round off the gag.

I've always liked the CodeIgniter docs too, though haven't had experience with the others, but they also look nice. I found this rather humorous though: http://ellislab.com/codeigniter/user-guide Note the lack of a trailing slash in the URL above (copied from onejegolders post). Click it, and then click "table of contents" and click on any item in there. You will get to a page with some Arnold video. Apparently EllisLab hasn't accounted for the trailing slash vs. non-trailing slash.

Greetings, Just to warn everyone... I am in touch with a couple of other Joomla power users, urging them to check out PW. Speaking for myself, I believe the main barrier to switching CMSs is the legacy stuff you already developed. It's amazing how you can go for a long while knowing that the system you're using is not right, but you keep using it because... Well, because you have been using it. At some point, though, you just close your eyes and make a leap. For me, I was poised for a switch for about a year, but I had to wait until I had just the right bit of downtime between projects. In this way, ProcessWire has another big advantage: we can honestly say that switching from your current CMS is not painful, because PW is so clean and intuitive. There are other CMSs that are also good -- and you know they are good -- but it takes a bigger up-front time investment to become familiar with their quirks. Of course, all systems have their quirks. There are just fewer of them in ProcessWire. And the payoff is so much greater! Thanks, Matthew

I just liked ProcessWire on alternativeto.net. I also wrote a review, couldn't help it!

I think this would work: $someModule = $modules->get("someModule"); echo $someModule->doSomething();

I see an autoload there. Process modules don't need that as it is an admin page and dont need to be loaded on every request. Remove autoload, reinstall it and it should work.

Hello everyone, As others have said, it's too bad about EE. At one time, I thought EE was the best CMS, and I still think it is pretty amazing. But I like to experiment and develop ideas freely. Even with the old pricing structure, this was not really possible with EE. Under the new stucture, it's even less feasible. But what's most relevant is that I can replace everything I did in EE with ProcessWire, and in ProcessWire it feels more "natural" and closer to pure PHP. I also really liked CodeIgniter. It was the framework that introduced me to frameworks. But even here, Laravel has taken the framework role. I think that with Ellis Labs making such pricing decisions, a lot of excellent and generous CI contributors will feel that their contributions make more sense in the Laravel community. And by the way, there were hints about the licensing issues over a year ago, when Ellis Labs changed the license type for CodeIgniter. Regarding posting in the EE forum: I would personally be against that unless a discussion had already developed over there about alternatives. I think that posting blog entries and commenting on other blogs is the better way to go. Thanks, Matthew EDIT: I added my "like" to alternativeto.com!

I'm not sure I got your question right, but that doesn't seem very unefficient to me. The first two lines could be replaced by this though: $find = $pages->find("has_parent=1134, template=subcategory"); So no need to get the ancestor first but go straight to find any page it's parent or grandparent of. Maybe this was what you were after?

Yeah, doesn't really feel the done thing. However, I am sure people will be talking about it on their own sites - go and comment on their blogs!

Sorry to enter this conversation (as I am no pro), but wouldn't it be simplest just to set it to 22 digits instead of 21, which seems to work everywhere? (I may not fully understand the conversation, though

I stopped using EE about a year ago. I didn't see all these EL changes coming but the multiple pages of ongoing bugs and having to install a multitude of add-ons to do simple stuff just got tedious. That and the painful upgrade process/add-on compatibility made maintaining a site excruciating. It made selling it to clients a no go. EE is generally a good product and the developer community have created a wealth of good add-ons. But that has inadvertently stifled any EE development. I can't think of a new feature they've brought out in the last two years whilst the bug list keeps growing. I think it's become a platform for developers to make a few bucks - and not that much from what I've read. The EE community can be really one-eyed too and the loudest are those that have hinged their business on using EE and don't/won't consider using anything else. While it's not a particularly healthy thing, they're generous and helpful as well. I don't miss using EE one bit and I'm honestly impressed beyond belief that I can do 99% of the work I used to do in EE (and add-ons) now with PW. Cheers Marty

Greetings, I think re-using fields makes most sense, as long as the fields are really equivalent from one template to the next (as apeisa says). With contexts, you can re-use fields and still have them be unique for each template! Thank you for this, ProcessWire! One advantage I am seeing with re-using fields is that I can regularly create "inc" snippets that can be inserted into different templates that have identical sections (same set of fields). For example, in my current project for an arts organization, they have "events" that fall into several categories. I have separate templates that reference the same core "event" submissions, and using a $pages reference, each of the templates filters the results according to what someone checked off on a check-box (event category), but many other parts are identical across the templates. Just an example. Thanks, Matthew

Just thought this would be a good time for bumping this thread

I was just about to say "that sounds good, go for it". But then I decided to give it one more test, just a quick one. Yeah right, like one of those ever existed in the middle of the night. So now, a couple of hours and a few installed PHP versions later, I'm about to lose my mind. I've tried all the PHP versions I was able to find pre-packaged (for that Ubuntu 10.04) and the only one I got working was the very latest 5.4.9. Both 5.3.6 and 5.3.10 (!) failed for me. Well, these results combined with the previous ones and I was about to say the problem was introduced somewhere between 5.3.10 and 5.3.14. But. A handy tool at http://3v4l.org/ comes in to "rescue" (allows to run a piece of PHP script in 80+ different PHP versions). I ran that script given in my previous post, just to get results like this: After comparing all the results with each other, the only conclusion I'm able to come to is that there actually is no problem with a plain PHP. The problem does exists, but only when there's Suhosin-Patch around. I'm just not able to find out the exact pattern. I was able to test with three different versions of PHP with Suhosin-Patch: 5.3.2 (failed), 5.3.15 (ok), 5.4.9 (ok). So this few hours didn't give that much new information after all . And besides PHP version there's actually another parameter now: Suhosin-Patch version. I did come up with a simple test though. If the next line run from the shell gives a result of "*0", it's run on a problematic combination of PHP and Suhosin: php -r 'echo crypt("test", "$2a$11$12345")."\n";' Then run these to get the version information for comparison: php --version php -r 'phpinfo();' | grep Suhosin Got to go and get some sleep now. I think this will haunt me all night though...

I take the same approach as Soma, which is to use browser tabs when I need to keep tabs on more than one thing at a time (like the Page List while editing another page). Basically I'll be in the page tree, and CMD-click the 'edit' link, when I want to keep my current Page List handy. I think there are a lot of good and welcome ideas here, and I'd like to do anything I can to support implementation of them in other admin themes. For the default admin theme, I feel like I've got to keep it immediately understandable and infinitely scalable. It's got to be something that will accommodate any situation. I have no doubt that other implementations are possible that would have more appeal to some (especially power users), but it would be a compromise in some other respect. What I'm trying to avoid is a sidebar tree because that gets awkward when things grow. I've been turned off by the way that Silverstripe and MODx handle this. Likewise, I'm reluctant to introduce any kind of frames in the default admin theme (other than modals) or accept the overhead of executing PageList on every request. I do like what Diogo demonstrated about a sidebar that pops out only when you hover (or click) it, but only if it were a top (or bottom) bar instead that can span full width. But there's lots of baggage to consider. Example: if taking the frame route, adding a new page wouldn't be reflected in the PageList. If not taking the frame route, then PageList is getting executed on every request. There may be simple solutions to these that I'm not aware of, or there may be other issues to consider as well. If anyone is interested in working on an admin theme (or variation of one) that accomplishes any of what's been mentioned in this thread, then I'd be very interested and glad to help in any way I can. If there's anything that needs to be added to the core in order to support, I'll add it too.

I've just redone a charity website for a charity we're involved with, using the "profile" I'm developing. It will fill out more as they add content. Icons are added when they specify twitter ids, RSS etc. There are also events pages, testimonials, partners, categories but they are by default unpublished. Latest blog posts are populated lower down when they get round to doing some, so it's not in it's finished state! http://www.madhatterscharity.com

Oh, missed the "Contents Page" bit. So .... Forward (by Ryan - why he made PW, short history) Stepping Stones - How to cross the river using PW. Basically, how PW uses the relationships between pages and templates to allow you to find your own path and create solid applications and websites. Quick - do something before it gets boring! A bit like the Planets Tutorial, this is a short, silly one page site that proves the system is actually working. Overview of the learning process - How this book will work, what steps it will take you through, what experience you need (not much) and what you should get out of it. Creating the Tutorial Site - Effectively this is the tutorial I have just written on the Wiki, but more nicely laid out. It creates the basic starter site that the reader will use for all subsequent tutorials and explains some of the most commonly used techniques. From that point on the book gets more and more complicated. Every technique is explained via a proper working example added on to the core Tutorial Site. The reason for doing this is that the writers CANNOT shortcut and suddenly assume that the reader can read their minds. It also means nothing is suddenly in isolation and is not properly explained. These should not just be about creating things like galleries, forms and so on, but about how to manipulate data - a basic accounts system, a complex directory system, a forum built using ProcessWIre? If it is possible, we should demonstrate at least the basic building blocks. The latter half of the book would have a lot of reference material (different coloured pages, in an ideal world): The Data Model - a full description of how the data structure works, why it is designed like that and how it can be used to meet high standards of data integrity and portablity. This should also include best practices for creating fields that that keep associations between types of data without over fragmenting. (For instance, if you have a field called article_body, it makes sense to use it for anything that could properly be called an article, but would not make sense to use it as a description field for a product listing) The API Snippets reference - this would possibly be repeats from within all the tutorial text, repackaged and represented as a reference (an electronic version would do some of this automatically, I suppose) Index ... and so on. Another thought: Is PW enterprise ready? If so, that is an issue that should be looked at separately, since that sort of audience would need a different approach. Possibly not yet .... but maybe worth planning for. Joss

Pete, you are spot on. As a sound engineer and advertising producer/copywriter over the years, every product launch I was involved in never happened until the the user manual was completed - even if that was just how many spoons of the product you put into your tea cup! It was right up there on the top of the todo list. Open source products have a huge problem with documentation. The first is unsolvable: Any product that is basically one person working on the project more or less as a hobby (they have a full time job) and not having any proper way to finance it, simply is not in the position to write a full, properly crafted, user manual on top of the basic technical documentations. As a one-person cottage industry they quite possibly don't have the skill-set either; Ryan has good communication skills, but that is rare. Just to compound the problem, there is a high chance that they don't speak the most useful language, English, as a native language. (To be honest, some of the stuff I have read over the years sounds like someone struggling with the language, only for me to discover that they ARE English!!!) The second is a sort of bad habit .... the more users you get, and therefore the more experienced users you have, the larger the group gets that doesn't have a need for a proper user guide/book. The trouble is that it is easy to forget that you have a growing number of users on the periphery that are simply struggling, that really could do with the help/education. Even wonderful cross-referenced documentation (some people have listed some great examples that they have found) does not do it. That comes into play once you have really got your head into the system and now need to know how to programme up those one thousand and one ideas you have just had. So, I agree. A book. And you could go the whole way here - a proper book. There are several advantages: Those that are involved in writing it can get a little bit of income from their hard work. (probably not very much!) The project itself can get a small amount of finance from the publication. It becomes a marketing tool that by being promoted, promotes the initial project. By making the system incredibly accessible to a huge range of people with different skill levels, it broadens out the user base, which inevitably promotes the project again, with all the spin offs that can engender. So, three sets of information. 1. Core Documentation Definitely free - built on the API (or expanded from it), that gives basic examples in a small chunk fashion. Matthew Scheneker has started playing with an idea using PW for that, which could be interesting. 2. Basic Start tutorial Free again - a walk through on the lines that I have been playing with on the Wiki that takes the user from nothing to a fully working site with a couple of tricky bits thrown in. 3. A complete book Probably sold through something like Manning or Kindle, that not only takes the user on a journey using ProcessWire from just listing planets to creating full, complex applications, but also teaches them the basic PHP/PW knowledge they need to achieve that. The only assumption it would make about the user is that they have some basic working CSS/HTML knowledge and are keen to learn using good working practices. This sort of book does not need to alienate the more advanced user (very, very advanced users probably would not buy the book anyway), because it can be structured and laid out with sidebars and so on that can be skipped by those who "know how to do that." As someone who would benefit from such a book, I would also be very interested in collaborating on it with someone who had all the necessary technical knowledge.... (hint) Is ProcessWire ready for this? If I look back over the last 15 years or so of playing with the internet I do seem to crop up in a rather large number of forums, beta testing lists, the odd article and so on .... Can be quite embarrassing (and thank goodness most of those have vanished along with the projects) .... . So maybe I have a little more industry experience than I sometimes admit too.... purely from the edges, you understand. (and it is true about having bugger all programming skills!) So, I was reading a long forum post on the Symphony forums from 2011 by Ryan - http://getsymphony.com/discuss/thread/79645/ - which included a little bit of the History and gave me a little more insight into the product and it's creator than I got here. My gut feeling is that PW as a concept and an application is well and truly ready for the big time. But some of the bits that surround it (official knowledge base, outside user knowledge, expansions) are not quite ready. But all that means is that this it the time to do them, not that PW should wait for them. I think a book should be written by a couple of idiots, that the community should get behind more docs and stretching the API out to its logical conclusion, that more people should be encouraged to create modules (with some good, strong QA behind the system), and that LOADS more profiles should be created or donated (or even sold!) that can show what it possible and can be used as learning structures. There you go Pete - you asked the question, and that was my short little answer .... Joss

Funnily enough I was thinking that this would make a good module the other day. There are instances on larger sites where you are likely to have many templates and not add other user roles til the end, so a permissions matrix would come in handy. Where I think it would be even more useful is in conjunction with the module that allows you to give per-page access, but every time I think about how that might work I get a major headache. I need to mock up some examples of how this might work. A template permission matrix is a far easier prospect by comparison.

What is probably needed is a permissions map where you can look at all permissions belonging to a group or a single user. So, you could show permissions for a group for templates - then either change permissions individually or select the entire lot (or multi select some of them) and change the permissions. Probably hell to programme, but as PW sites get more adventurous and larger, possibly very useful.

Sneaky Niki you. I didnt even notice this thead before. Nice! Havent tried but at least a dozen optones are missing. ;-)

Soma, thanks for posting this, and on a personal level, thanks for all your patient and kind help. I'm just smiling, because I can't express my thoughts/feelings any better than many of you have already done.

Hi Soma The wiki is, or can be, very useful for the moment. It is a good way of getting information all in one place. Once a good amount is in there, then those who are brave enough can start putting together something a bit more logical and solid - and yes, with ProcessWire! However the more refined version is written, it should also be available in several formats - some sort of searchable help system, PDf/Book style, Kindle, etc (not sure what the etc is...) Joss

Just a quick update. I've now pushed a preview of the changed code to a new 'nr' (next-release) branch. Feel free to post comments, suggestions or questions here or raise issues over on the repo itself. I've actually started documenting the methods too -- something that will be ongoing over the next few point releases.

My english isn't so good, so I can't express my thoughts (and requests ). I love ProcessWire, the forum and the contribution that Ryan and the PW gurus give to the community. I hope I will be able to return this in future. Thank you all, guys.

According to the developers, they're using breakpoints.js to load in additional content dynamically depending on screen size: https://mobile.twitter.com/murtaugh/status/275643312877207552 http://xoxco.com/projects/code/breakpoints/ It does look great and loads fast. It's responsive in every way.

I found out about ProcessWire from the symphony forums. I've always loved the control symphony offered, but hated the odd path that was necessary to get the final output I wanted.

Yep, as I told some times before, symphony is also great! XSLT is quite easy to learn and is extremely flexible, but is a pain to write... and it's quite annoying that you just can't print "<!doctype html>". Besides, it feels like you are fighting all the rest of the world by using it... I guess, at the time, I was also looking for something like symphony, but written on a wide spread language.