Leaderboard

Captain Hook ProcessWire Hooks Cheatsheet http://somatonic.github.com/Captain-Hook/ or on processwire.com http://processwire.com/api/hooks/ I created a simple list with a live search for all hookable methods available in the core. All methods prefixed with a "___" (3 underscores) are hookable. Methods can be made hookable by simply adding those ___ to it. ------------------------- I usually don't really need this, but thought it would be good to have an official list for reference. I used Sublime Text2 for searching and dumb a file with a search for " ___" in wire core. From this list I created a html file with a php script and added some fuzzy live search, similar to the API cheatsheet. If you use Sublime Text 2 like me you can simple use Goto Anything command super+p to show a fuzzy search for files. Enter a class name you want to search for. For example "fields" or "process page edit" you will recieve a list of files found in PW. Highlight the file and typ a @ to see the symbol list quickly or select the file and super+r the get the symbol list.

Part of the trick is defining the target market segment. There is an industry wide problem at the moment where market segments are very poorly defined. There are two reasons for this: Firstly, the majority of marketing is done by non marketing people, and secondly this is all very new and shiny and no one is totally sure what to do with it yet. This even shows with companies like MicroGoopple - with the lack of strict market segments, they have all tended to go for scatter gun marketing in every area all at once. With ProcessWire, the issue is "Is it a CMS or not?" Well, that runs into a problem almost immediately - what on earth is a CMS? Or, more precisely, who is a CMS for? Blogger is a CMS. It is a straightforward system that allows people to manage content in a very precise and defined way. Wordpress is a CMS. It works like blogger, except you can host it locally and make it work not like blogger at all. Joomla is a CMS, except they would like to point out that it is a Framework with a CMS on top of it. Drupal is definitely a CMS - it allows you to manage anything, but it is a hell of a long way off from Blogger where we started. ProcessWire is a CMS - except it is a CMS that allows you to imagine and build your own CMS on top of it. So, it is not a CMS then? Certainly, if all the other CMSs are defined by the fact that they are a central system where you can "theme" and build modularly using modules/plugins/whatever, then ProcessWire is possibly not a CMS - it is too flexible and does not have that same central construction mantra. To a certain extent, it is a misuse of the term CMS that is causing all the problems. Out of the box, Blogger, Wordpress and Joomla are probably not CMSs, but AMS - article management systems. Since, unless you stick all kinds of third party additions to them, managing articles is all they do. Drupal is a bit more flexible out of the box. So, it would help marketing if all those others would go off and re-brand themselves as AMSs and leave the more versatile offerings to use the term CMS a little more correctly. Well, that is not going to happen - and in addition, there is quite a gap between what Drupal and Liferay do on one side and what EE, ModX and PW do on another. We have seen in these forums a couple of newer people posting, with quite genuine reasons, that they are confused that PW does not have a theming system like Wordpress has. It doesn't, of course, because it is not doing what Wordpress does - at least not out of the box. You can build a Wordpress out of it (I am having fun doing one at the moment) and you could even build a theming system to go with that - but that would be what you can DO with ProcessWire, not what it is. To my mind, ProcessWire is, at the end of the day, not a CMS as such, or an AMS, possibly more of a CMF, but not even that totally. ProcessWIre is really, a very strong starting point. If you want to develop a web tool of some description, PW is where you start. It allows you to get your visual interface and core data together very quickly and tidily and then gives you enough tools to develop a fine-grained approach to what you actually want to do with that data. In a funny sort of way, it is, for the new browser orientated development world, what Desktop development tools were to users back in the late nineties. It does a lot of the heavy lifting for you while you get on with the presentation and fabrication. So, back to the market - PW is a professional's tool. It can be used by amateurs like me and even quite effectively, but those with better knowledge are always going to be able to take development with PW far further and faster. As such, I think it should be marketed in the first instance as a tool for developers/designers (I really do not like splitting those groups), while making sure it is accessible for those with less knowledge, but like to learn. In practice this means presenting it to the development community through seminars and user-group meets, as well as making sure that each geographical market area has a common focus point (like the German website this thread is meant to be about) that can be used to gather in and grow local communities. Now, this is where I lift the lid on what the marketing industry really thinks of this sort of product. Basically, promoting open source systems is no different to promoting a rock band - you need fansites, reviews, groupies, and everything that goes with it! I am sorry, but I would be hard pressed to put a Rizzla paper between the marketing brief for a highly regarded Open Source system and one for the newest boy band. And having seen the behaviour of some developers on "other" open source projects, there is little difference there either! Joss

I launched it today: http://fyp.washington.edu/ I can't even begin to explain how excited I am by this software. It feels like I accomplished more in a month than in the last ten years of professional web dev work. Finally, a CMS geared to the needs of content publishing and information modeling (i.e. taxonomy and ontology) -- not news, widgets, or journaling. Like so many others I had been struggling with the Drupal/Wordpress dichotomy. Drupal feels like hitting myself in the head with a hammer and Wordpress is insecure and inflexible. And both their inner workings seem completely opaque, no matter how often I build with them. Enter PW, CMS of my dreams. The FYP site is combined with Zurb's Foundation Framework, which I am similarly enthusiastic about. Also above all jQuery + CSS3, which seem like a never-ending treasure chest of wonders. I did the interface design and development as well as the information architecture and all of the programming. My favorite thing about the site is the way I was able to give it gears that turn with the seasons -- for each season of the year I added tag "pages" and then tailored parts of the interface to match. The homepage image, the default header, and the selection of front page slides are all determined by what time of year it is. I was able to expose almost EVERYTHING to the content stakeholders through the flexible field system. I could totally get run over by a truck tomorrow and all would be well. I LIKE THIS. Maybe some don't. But I've always been in this field in the hopes of empowering people and making room for creativity. ProcessWire works with these goals, not against them. Cheers, Jenn p.s. the slider is RoyalSlider. I dig it too.

This is simple and you can do it like this: Have the subdomain dns point to the same root as the domain. In the Template you could use: if($_SERVER['SERVER_NAME'] == 'm.exampledomain.com'){ include('yourmobile_tpl.php'); } else { include('yourdesktop_tpl.php'); } or whatever you can make out of it, you can also just define a constat or variable to use in code.

Soma, You are removing all my excuses for not learning how to code modules. Dangit.

Another option that would bypass Pw caching, even ProCache is to send an ajax request to handle the counter. If you use jQuery, this would be something like this: //Javascript <script> $(document).ready(function() { var data = {'action' : 'handleCounter'}; var url = '<?= $page->url?>'; $.post(url, data); }); </script> //PHP if ($config->ajax && $input->post->action == 'handleCounter') { //... //put your php code in here //... exit(); //Quit since this was only a request to update the counter } To make this work you would need to disable caching for the POST "action" variable. This is done in the template settings under Cache > Cache disabling POST variables

Thanks everybody! I really appreciate the feedback and the suggestions.

VHS vs. Beta, BlueRay vs. HD-DVD, etc. -- These are winner-takes-all markets. The CMS market is a totally different landscape. But I agree with the premise of marketing and the importance of getting the word out there. I also agree that we can learn things from the marketing of other related products out there. Though word-of-mouth is the best marketing there is, so I agree with Kunane that making the product (and support) the best it can be are great ways foster good word-of-mouth. ProcessWire is a community project rather than a business, so we don't have the marketing resources of for-profit businesses. But as we grow I think we'll have more and more resources to pursue new avenues of communication.

Thanks guys, looks like I broke that over the weekend, but the fix was easy. Now fixed.

OK fixed! I had to reinstall a few things on my server, so it had nothing to do with this plugin. Just for anybody's information, I am on a freebsd server, using directadmin and had to go to: /usr/ports/graphics/jpeg and make deinstall, then I had to make reinstall then I went back into :/usr/local/directadmin/custombuild and run ./build php to rebuild php with all options, I chose to reinstall all options to get php compiled with GD supprt for jpeg This module is truly awesome!

Making ImageSizer::resize hookable seems like it's a good idea for this need. I will go ahead and make it a hookable method and should appear in the dev branch after I test a bit.

Jenn, Wow! Excellent work. The site looks and works great! One quick thing: The "Parent Orientation" quicklink on this page results in a 404. http://fyp.washington.edu/getting-started-at-the-university-of-washington/ I work at a University as well. Most of campus uses WP or Drupal, so I feel a bit like a lone wolf using ProcessWire (sounds cooler than black sheep). I think that's starting to change though—ProcessWire powered sites are starting to spring up around campus. Anyhow, great site—thanks for sharing.

Actually I think you've got a fine solution here. Part of the reason that repeaters are built on top of the pages system is so that they could be accessible in a manner like this. So while it is relying on internals of the repeater fieldtype, these particular internals are meant to be exposed when you need them. Repeaters are pages so that they can benefit from that accessibility. The only thing that might need to be added to the selector is an "include=all" or better yet, "check_access=0", since those repeater items are technically access protected.

Maybe this custom upload script example does help?

Is it an alternative for you to set that variables in the .htaccess file ? <IfModule mod_php5.c> php_value upload_max_filesize 10M php_value post_max_size 20M php_value memory_limit 30M </IfModule>

Thanks - problem reported and resolved.

maybe. but it should grow by itself (grasswroots). "ambassador" ...*shudder* all modx managed to do, was to alienate the community, surround itself with cheerleaders and throw around with empty buzzwords. IMO, I feel that processwire got the right energy and momentum anyway. no need to force/push harder rather focus on making the product even better.

Same to me, installed ProcessWire 2.3 with Skyscrapers profile, Language Support 1.0.0, added new language. There is no possibility to add language files.

I apologize for my English (or GoogleTranslate's English ). Tried to search, but found nothing. Revealed the following problem: AutoComplete does not work if the page title contains Cyrillic characters. Checked by creating a page with English titles - they are displayed normally. Just tried in the advanced settings autocomplete select the "^=" mode. This leads to the fact that the list displays all the Cyrillic titles, regardless of the characters entered. Maybe I'm doing something wrong. Please help. -------- I found this: https://github.com/ryancramerdesign/ProcessWire/issues/129 It helps me. -------- One else question: can I use Autocomplete to select single page? What should i do? Thanks to all who participated in the development of this great CMS!

Thank you guys. Yes I love doing the simple things and I loved to cheat in school. Anything more than list causes me headaches.

You should copy/paste these explanations to the wiki - this is important stuff.

Really lovely!

You like doing this kinda stuff, don't you. Thanks and saved the list.

Right, thanks. I missed that I needed to re-install from scratch. Deleted everything and re-installed. Works fine now.

The markup depends on a few factors (page the user is on, current time, etc) so caching the data as a PHP array saves quite a bit of database lookups and even some processing (like price calculations etc), while still allowing me to do the needed markup changes per request. Regular markup cache would not work in this case or would require many markup caches per page. Still using MODX (I'm even a "MODX Ambassador") so maybe we indeed met at a meetup or MODXpo in Utrecht last year. Having both MODX and ProcessWire really makes web development fun. Both are great systems to work with.

Version 0.9.2 of this module (just pushed to GitHub) introduces support for multi-language fields. See commit details for more info. I've also brought in some minor fixes etc. during this weekend, so if you've installed this module you should consider updating.

See Wanze's ProcessBatcher module, I think that would be helpful to you: http://processwire.com/talk/topic/2811-processbatcher/

You should be able to iterate through fields without knowing their names - the Cheatsheet should help you there. Something along the lines of get the page template, iterate through template->fields and then you have access to do something like $page->($field->name)->removeAll(); Just typing that quickly on my phone but hopefully you get the idea.

I'm going to jump in, hopefully not just to mess things up . One dirty way to achieve what you're trying to do would be going straight to the repeater items. This gives you the top 5 highest mountains across all reports: $topFiveMaxElevations = $pages->find("template=repeater_mountains, sort=-stats_maxElev"); Technically repeater items are pages and thus you can use find() as you'd do for normal pages. But as I said, I'd consider this a dirty way because it relies on the internals of the repeater fieldtype. It does get you there but at what cost, that I don't really know. And if you'd need any data from the parent page (the report itself), you'd need to get it via getForPage() which returns the page a repeater item belongs to. And like Soma pointed out, there's some redundancy. That could affect the top 5 lists the very moment some mountain ends up in two different reports (unless it's absolutely impossible scenario?). No matter which method you use to collect for example the altitude data, you'd probably need some check to filter out duplicates. And that would make things a bit more difficult as you wouldn't be able to limit to 5 results right away. Oh well, just wanted to mention it. Actually that's what the manual says it will do . See http://php.net/manual/en/function.usort.php where it says "The comparison function must return an integer less than, equal to, or greater than zero" with an additional caution on using for example floats. Your solution is fine though, now you've got it returning integers. Hope I was being helpful, rather that confusing. Time to get some sleep now.

No, unfortunately you can't. That's the "either-or selector" mentioned in roadmap for ProcessWire 2.5+ (Winter 2013/2014). Those examples from the documentation SiNNuT refers to do mention the or-operator, but it can't be used quite like this. "Or" is fine within a single selector but currently there's no support for having an "or" between two or more selectors, it's always "and" which is denoted by a "," (comma). On the other hand, if you don't need native pagination for the results of this kind of query (and there won't be too many results!), you could use something along these lines: $results = $pages->find('fieldA=xy'); $additionalResults = $pages->find('fieldA=z, fieldB=x'); // this leaves no duplicates to the PageArray $results->import($additionalResults); The resulting PageArray can be also sorted and sliced to get exactly what you need. But again, by now you've already fetched all the matching pages from the database into memory, so this is merely to tidy things up - or the core of a custom pagination of course. // sort first by fieldA ascending, then by fieldB descending and leave only 10 items starting from index 50 $slicedResults = $results->sort('fieldA, -fieldB')->slice(50, 10); So for small amount of data there's quite an easy way to get around it. But for larger amount of data you'd need to come up with another kind of method, probably one that depends on the nature of the data you're dealing with.

Short info about progress: I've setup a test with nearly 30 very different images: downsized from original dimensions to 1200, 700, 300 px in one step and for following qualities: 100, 96, 93, 90, 85, 80 there are no differences in filesize or they are less than 1% to my surprise the quality of GD2 is much better than I have had in mind (maybe I've remembered the GD1 ??, - to my apologize: I've done all image processing locally with Photoshop for the last - ?? - oh god, it seems to be true: for the last 6-7 years) In very dark parts of images both libs show good differences with details, also details of highkey parts are nearly equal with both image processors. Only the sharpness of Netpbm is a little bit better than with GD. But it's that little that it is hard to see when placing to images besides. (when switching in an imageviewer one can see it). (a table comparing imagesizes is here) --- intermediate conclusion: I will focus on GD2 and do some tests with sharpening and multi-step-sizing, also high prior is on Metadata reading and writing on schedule with less prior maybe Watermarking with alpha-transparency-png. I think, best way to writeback metadata is to build a module that hooks in before image-size process starts and once again after image-sizer has finished: public function init() { $this->addHook('WHAT IS THE RIGHT HOOK FOR THIS?', $this, 'readMetadata'); $this->addHookAfter('AND FOR THIS?', $this, 'writeMetadata'); } Is this the right way? And if yes, how are the names for the HOOKs? Any advice is welcome.

Hi Ryan, well in this scenario (multiple sites with the same backend), it's more convenient to have them stored and maintained in one place so when we add some 'core functionality' which should be available for all sites, it would be more time consuming to update all of the different language-folders instead of just one. But I'll look into a way to use the symlink-option, thanks

Okay, sort of worked this out. Just had a look at the tinyMCE iframe inside one of my Joomla sites and in the head section of the TinyMCE content inside the iFrame is has: <base href="http://www.dancingbear.co.uk/"> Now, that is missing in the PW TinyMCE iframe. I assume it is getting it because in the JS for the TinyMCE in the head of the whole page my domain is set up as the base_url parameter. If I go to the php script that is initiallising the editor, it has this: document_base_url : \"". JURI::root() ."\" JURI::root() being the defined root of the installation. So, that is being set up explicitly for TinyMCE (and whatever else needs that value) What I don't know, is how the constant is being defined - or rather, how it is working out what the root is. It might be something to do with this: http://api.joomla.org/__filesource/fsource_Joomla-Platform_Environment_librariesjoomlaenvironmenturi.php.html#a273 Anyway, so possibly with PW, it is a case of creating a constant for the root of the installation that can be used anywhere that is required. Modules, Editors, Templates - whatever. Then everything can be treated as if it is in the root directory and have relative paths or direct paths without suddenly leaping out of the installation, however htaccess or other things are set.

Thank you, Ryan. Your tip regarding the console.log made clear that the vars weren't lost. They were still there. After a lot of Google searches I found that the reason was a change in the Google Maps API (it worked in 3.9, but stopped working in 3.10). I also found a bug report with a solution, so now everything is working again. The bug report: https://code.google.com/p/gmaps-api-issues/issues/detail?id=4594 /Jasper

I haven't done much front-end user stuff but the API and flexible role/permission/user system makes this pretty easy. Of course, depending on the exact needs it could get more complex. So for example you could create a new permission called frontend-edit. Create a role called frontend-editor and give it page-view and frontend-edit permissions. This will keep a user with (only) the role frontend-editor out of the back-end but allows you to log him and check for permissions in templates, allowing stuff you want. if ($user->hasPermission("frontend-edit")) { echo "<a href='{$page->url}edit'>EDIT</a>"; } else { echo "you are not logged in or you do not have permission to edit this page"; } if ($user->isLoggedin()) { echo "here you go, view this awesome page"; } else { echo "plz login if you wish to view this awesome page"; A front-end login could be as simple as creating a page, why not name it login, and putting this into the template file: <?php /** * Login template * Based on a forum contribution by Ryan, can't locate it, but the are many examples of login forms. * */ if($user->isLoggedin()) { // user is already logged in, so they don't need to be here $session->redirect($config->urls->root); } // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect($config->urls->root); } } include("./inc/head.inc"); ?> <?php if($input->post->user) echo "<div class='alert alert-error'>Vekeerde combinatie van gebruikersnaam en wachtwoord</div>"; ?> <form class="" action='./' method='post'> <label for="user">Gebruikersnaam</label> <input type="text" name="user" id="user" placeholder="Gebruikersnaam..."> <label for="pass">Wachtwoord</label> <input type="password" name="pass" id="pass" placeholder="Wachtwoord..."> <label></label> <button type="submit" name="submit" class="btn btn-primary">Login</button> </form> <?php include("./inc/foot.inc"); ?> These are just some examples but most if not all what you need is already available. It's up to you to code it the way you want. The API cheatsheet gives a nice overview of available building blocks. For the Create, Update and Delete stuff i think you would need to roll your own forms, populate them via the API and do with it what you want. Of course making sure you properly sanitize the inputs, maybe do some of your own validation etc.

Thanks guys. I'm someone that likes to think a lot before I respond to questions, and didn't have time to do that here (it was a Skype interview rather than by email or something). But I'm happy with how it worked out. And perhaps the "live" nature makes for a more interesting interview. Very appreciative to Mike for inviting me to do this. I'm really liking the huge ProcessWire logo at cmscritic.com too.

The logic you've got there seems to make sense to me. One thing to note about this sort of counter is that it would not work if you had page caching enabled. But so long as you don't, it should be fine.

Looks like my local version of PHP (5.3) wasn't compatible with mySQLs authentication approach. I rolled back to PHP 5.2 and the error is resolved.

Good morning/evening/night or whatever! I just commited to Version 1.0.2. Here are the new Features: Permission Checking: Don't show pages that aren't editable by the current user. Also removed all actions that the user doesn't have permissions to execute. You can directly edit a single page over Fancybox by clicking the small "edit" link after a page (thanks raydale) Added Batch-Creating of Pages Batch-Creating Screenshot taken with Soma's great new Teflon theme Includes permission checking and Family template restrictions. This means in detail: The selected parent must accept children and their template The pages template must accept the parents template User needs the permission to add children to the selected parents template User needs the permission to create Pages for the chosen Template How does it work? 1) Select a parent where your new pages will be added as children 2) Add as many pages as you want by clicking "add Page" 3) Click "Create Pages" You must enter a title and choose a template. The name is optional: If left empty, Pw will generate this for you. Batch-creating tips The chosen template and the statuses are always cloned from the last row. So if you need to add 30 pages with the same template, define it first and the click "add Page" - i'll make your life easier ;-) You can drag & drop the table rows should you want to change the order. The draging looks ugly but it works. For the lazy dogs and keybord hackers among us, you can add a new row by pressing "ctrl+n". This works (at least in firefox) only if no input has focus. After adding a new row, the title input gets the focus. By pressing 3 times tab you arrive at the published-checkbox, here the short-cut works. Restrict Batcher for a user to only allow editing or creating Create permissions "batcher-edit" and/or "batcher-add". As soon those exists, the module checks if the current user has those permissions. Good night

The answer is both Inputfields and Fieldtypes, but they are validating in totally different contexts. Inputfields validate user input. Fieldtypes validate data set to a $page, regardless of where it comes from. Think of Fieldtypes as API-side type validation, and Inputfields as interactive/user-input validation. Here's more detail: Inputfields only come into play when there's interactivity, i.e. a form and a user inputting something. Input should be validated by Inputfields so that the data is valid enough to echo back to the user, or for something else to pull the value from it. Inputfields should always be validated server-side where appropriate, but can also optionally include client-side validation. Inputfields can be used separately from Fieldtypes (they are used throughout ProcessWire in all forms). If there is some kind of input validation that isn't specific to a page or fieldtype, then it should be done by the Inputfield. Meaning, most validation responsibility goes with the Inputfield and an Inputfield shouldn't assume there's going to be any more validation beyond it. Inputfield sanitization/validation is done in $inputfield->processInput() or $inputfield->setAttribute('value', ...). The processInput() method is the first line of defense for values coming directly from a form. Whereas the setAttribute('value', ...) will see values sent from the form as well as values sent from the API to the $inputfield, like an $inputfield->attr('value', 'some value'), call. Where you put your sanitization/validation depends on what you are trying to account for. You may see some Inputfields have a setAttributeValue() function. This is not part of the Inputfield interface. It's just a methodology I sometimes use to isolate setAttribute('value', ...) for more readable code. Inputfields report errors by calling $this->error('error message'); The user will see that error message within the context of the field. Fieldtypes come into play every time a value is populated to a page. This could be from the API, the core, modules, importers, Inputfields… really anything. They need to validate that the value sent to the page is consistent with the type of data the Fieldtype is responsible for (type validation). So if the Fieldtype only stores a string, then it needs to make sure it's a string. If you set something invalid to a $page, the Fieldtype needs to either convert it to be something valid or if it can't, throw it out. For the most part, they should do it as quickly and silently as possible, because they get such a high volume of traffic. Not to mention, Fieldtypes can't assume there's a user present to see anything. Fieldtype sanitization/validation is performed by $fieldtype->sanitizeValue(). Every value set to a $page gets routed through that function, for the appropriate fieldtype. Whatever you do in there needs to be fast. That would be the correct behavior for the Fieldtype, but not for the Inputfield. The scope for Inputfields goes beyond just pages. They don't know what they are being used for. If they did, then their usefulness would be much less. But that's just "in general". There are some cases where you are building a Page-dependent Inputfield and your Inputfield needs to know about the $page being edited. Core examples would Inputfields related to files and repeaters. In that case, make your Fieldtype pass it along to the Inputfield. Each Fieldtype has a getInputfield() method that gets a copy of the $page and $field being edited. It has to return the appropriate Inputfield to edit the provided data. So you can easily send it along to the Inputfield right from there: public function getInputfield($page, $field) { $inputfield = wire('modules')->get('InputfieldSomething'); $inputfield->set('editPage', $page); // inputfield now has a $this->editPage property return $inputfield; } They can report error conditions, but technically they aren't the place for it. Yes. In general, Fieldtypes can't assume there's anyone there to see an error. But if you have some need where you think it is necessary to do from the Fieldtype, try $this->error('message') … it will only be seen in an interactive context. If you want to report an API error, throw an Exception. But if you can keep all of your error reporting in the Inputfield, that is the right place for it.

Oh, I see - you're right. The .htacces-file mostly would be not writable and also more often isn't the problem. Maybe only test with HTTP-HEAD for the admin-page and inform the user if it is not reachable. So he get warned and frustration isn't that big as it could be now And yes, I would like if you add the additions to the class. ( afterwards I can tell everyone who wants to hear about or not, that I've provided code to the core of one of the best CMS out there! ) ( but I wouldn't tell that it actually was a total of 6 or 7 lines )

here is an nice article: http://www.statstory.com/some-reasons-to-choose-piwik-analytics-over-google-analytics/ The main difference is, like Luis said, the data is on your server (and not on a third-party server). Also there are some terms about data collecting you have to keep an eye on, especially in Germany the rules are more or less restrictive.

Do you get paid for the sites that you would with PW? When you come to the forums to get help, do you limit your questions purely to development work that you are doing for free? I originally developed PW to help us all create better sites in less time, and with more fun. I'm hoping that PW is helping others to be more competitive in all ways, including financially. But recognize that PW did not come into existence on its own. Years worth of time and money has gone into making ProcessWire happen. If you are using ProcessWire to develop sites you get paid for, then you are profiting from ProcessWire. And that's fine with me, no ROI is expected or wanted--I've never asked anyone for anything. But it is disheartening to hear a user make a statement with the implications yours makes. Form Builder is not about making a profit. I don't expect that I will ever make enough on it to offset the actual time investment on it. My hope is that eventually it will be something where the community and myself have split the cost to create. If I wanted a profit, I would go make a Form Builder for WordPress or Drupal where the user base is large enough for that potential to exist. Form Builder is a tool that wouldn't exist if I had to fully self fund it. It's also an experiment to determine if I can reduce my client workload and substitute some of it with ProcessWire-related development that benefits all of us. But I can't substitute something that supports my family with something that doesn't. Form Builder is here to benefit you, not me. If you build sites for a living (or even a hobby) it's going to pay for itself the first time you use it. If you previously spent half a day building a form, now you can spend minutes and get a better, more secure and capable result that can do all sorts of things with the results it collects. Also want to note that Form Builder is something completely different from the original subject of this thread and I don't view them as similar products at all. Likewise, Form Builder is completely different from something like Zend Form or others like it. One does not preclude the use of the other and we should all keep more than one tool in our forms toolbox. I fully support Clinton's project and any others that benefit forms in ProcessWire. Forms are one of the most diverse and important aspects of web development. I feel very confident about the value of Form Builder in your toolbox, so have made it 100% refundable if you find it isn't for you (this type of return policy is pretty rare with digital products).