ryan

Absolutely! That's one good use case for it.

Form Builder markup is going to look verbose relative to a singular-purpose form you'd create yourself. But verbose is not the same as messy -- it's actually very clean and optimized relative to the context. I've spent a good deal of time making sure that is so. That context includes everything from simple contact forms to giant application forms, while supporting nearly any kind of input type (known and unknown), in any possible layout, with any level of nesting. That's a whole lot of flexibility. Think of a singular-purpose form as a propeller and a Form Builder form as a jet engine. Both are well optimized for their context. One is more complex than the other, but will take you much further and faster.

It only won't get processed if you are asking the form to process the input, i.e. $form->processInput($input->post); When you do that, it goes through all the fields and processes them. From there, you can retrieve any value from it, which is now a validated value. Like this: $value = $form->get('your_field_name')->attr('value'); So if you had a pre-rendered input in an InputfieldMarkup, that would not have been processed with the form, nor could you retrieve it specifically from the form (since it only knows it as markup). However, I sometimes use Inputfield forms just for markup generation, and I grab the resulting value from $input->post (or $_POST) myself... Especially for something like an integer or checkbox where I don't need any validation beyond just type casting. In this case, it really doesn't matter how or where your inputs were rendered, because you are using the form just for markup generation, not processing input. There is still the benefit of being more hookable and extendable if you let the form render as a group though. But there are sometimes instances where I have some one-off input need that I can only accomplish easily with actual markup, like this one below, so it's InputfieldMarkup all the way there.

Page references aren't designed to contain unpublished pages. Granted, you can trick them into doing it, because the referencing page doesn't necessarily have control over the state of the page being referenced… a published page can become unpublished, among other situations. Likewise you saw that an unpublished page reference can be stored (if the input will let you select it), but unpublished pages get ignored when a field is loaded/presented. The only reason you can add unpublished pages at all is purely for the API. But now I'm wondering if that's more confusion than utility. Maybe I should just prevent unpublished pages from being stored at all--will have to think about this more. When using a PageListSelect input and you see a page with a line through it like this that means it's unpublished and you shouldn't select it. As far as I know, this is the only input that will let you select an unpublished page. It's only selectable so that you can access children, should it have any. I may be able to find a way to enforce this further, but PageList has to do a lot of things so I'm a little shy about going beyond visual indicators for this one. I'm more inclined to modify the behavior of Page references to just refuse unpublished pages completely. Thanks for your feedback--I'll experiment a bit more here.

I've pushed an update to this module so that it now recognizes any youtube query string variable. So you can use rel=0 or whatever you want from the link that Diogo posted. To use it, just append them to your youtube in your body copy, i.e. https://www.youtube.com/watch?v=Wl4XiYadV_k&rel=0 Note the extra "rel=0" at the end. Of course, you can also specify multiple things too: https://www.youtube.com/watch?v=Wl4XiYadV_k&rel=0&controls=0

Here's a little preview of the 'Save Page' settings screen where you can configure forms to publish to pages.

Some 2.3 updates now present on the ProcessWire dev branch at GitHub: New session handling features ProcessWire now supports alternate session handlers and includes a new module that provides for managing them in the database, rather than the file system. To enable, you just install the SessionHandlerDB module, and that takes over as the session handler. The advantage of a database session handler is that it can potentially be more secure in some shared hosting situations. It also enables ProcessWire to report on active sessions in the admin, so the new handler also adds a "Sessions" option to your "Setup" menu that gives you a table showing everyone browsing your site and where they are. I plan to expand upon this a bit more though. The new session handling interface also makes it possible for you to add modules that would move session handling to something like memcache, Amazon Dynamo DB, or really anywhere. New password security updates ProcessWire now uses Blowfish hashing for passwords when you are on PHP 5.3 or newer. If your database were to ever be compromised, this provides better protection from someone attempting to reverse engineer passwords from the hashes. Beyond blowfish hashing, we still use double salting as before (with one salt on the file system, and other unique to each user in the database). For existing accounts, the blowfish hash doesn't actually take effect until you change your password, so it'll be a gradual transition for many of us. Though the admin does give you a reminder every now and then. However, once you go blowfish, you can't go back, so don't develop a site in PHP 5.3 and then launch it to a PHP 5.2 server, unless you don't mind changing your password(s). And more… Addition of the WireHttp class, which provides ability to perform POST requests from the API. ImageSizer now uses better image type detection rather than image extension detection (via @teppo) WireArray now supports ability to sort by multiple fields at once as well as implements 'limit' and 'start' in selectors (via @nik) Updated to latest jQuery and jQuery UI (via @mindplay-dk) Removal of some big bottlenecks from FieldtypeRepeater (via @nik) Transparent GIFs are now supported during resizes (via @mrx) Support for 'min' and 'max' with integer and float fields Support for HTML5 'number' type with integer and float fields Support for HTML5 'required' attribute with many fields The datepicker in the datetime fieldtype now supports ability to specify selectable year range Several other updates in the commit log.

I think this will just depend on how and where you are setting the language. You'll want to make sure you are setting $user->language somewhere before your search (and before any output).

ProcessWire should scale very nicely as things grow. You shouldn't see slowdowns from quantity of pages unless you've got a bottleneck in your code. By that I mean primarily: using selectors without appropriate limit statements. Repeaters should also be used carefully like Teppo mentioned. Though the dev branch resolves the major bottleneck there that Nik had found and helped to fix. I don't see any problem with repeating your site over multiple servers so long as you are designating one as the master where actual changes are made. Pete may be able to speak to this better than me, but apparently some web hosts scan scale your server virtually, to quite a large scale that [apparently] spans several servers while behaving as one. But this is something I've not experimented with yet. This is actually already in the dev branch. Session handling can now be done by plugin modules, and it comes with a database session handling module. But you can pretty easily implement other types of session handlers using the same interface.

@ChrisB: Also, here's an example using Form Builder with embed option C in a responsive layout powered by Zurb Foundation (similar to Twitter Bootstrap): http://www.villasofd...landing-test-1/ … just in case this is helpful

I think you are better off using the Form Builder inputs as-is rather than the Twitter Bootstrap ones. Twitter Bootstrap is a partial solution, whereas Form Builder is a full solution. Form Builder output is also responsive -- just put it in a container the size that you need it and it will adapt to the container whether mobile scale or desktop scale. What it won't do is switch from multi-column to single column when small width, so your use of column width should target mobile rather than desktop, when used in responsive output. In order to avoid conflicts with Twitter bootstrap styles, stick to embed option A or B, which use iframes. If that doesn't work for your case, you can use embed option C, but you'll likely have to do some CSS tweaks to make it look good. If you are going to be limiting yourself to just the basic input types, you can also change the wrapper markup from the module settings screen. From here you could introduce more bootstrap-specific wrapper elements, for instance. But once you start doing that, you'll lose some of the things that Form Builder is giving you like fieldsets, collapsible elements, variable width elements, and possibly more.

Nik is right about this. You probably want to change your selector to something like this: $field = $user->language->isDefault() ? "body" : "body.data" . $user->language; $matches = $pages->find("$field*=$q"); That will force it to not consider the default language in the matches at all. However, most of the time you should just do this, which already takes languages into account: $matches = $pages->find("body*=$q"); So whether the user searches for "Beer" or "Cerveza" they will still get to the right page. If you exclude the default language, then that fallback never happens.

What does it add the rel=0 to? The URL in the iframe tag I'm assuming, but thought I'd tried this... Anyway, if this works, we might want to support other options too. What other worthwhile GET variables can be specified to youtube?

Nelson, try using a fully qualified URL with http:// and domain at the beginning. That will make it use a normal URL filter (which allowed GET vars and hashes). It's more restrictive on URLs where you just specify a path.

There is actually a reason for every bit of markup that appears in ProcessWire's generated forms, whether from the admin, Form Builder or elsewhere (they are all using the same Inputfields system). Once you start removing things from it, you likewise remove some feature, capability or customizability from it. In some cases, you might even remove the possibility of supporting certain types of inputs. That may be difficult to appreciate if you only look at it from the markup side, because it might be different from your own markup when making your own forms. Most notably, we have more wrapper elements and class names present than you would usually need in a standard HTML form. But these are not standard HTML forms, and you should avoid looking at it as such. ProcessWire forms have to cover more terrain than a typical web form. The Form Builder has to provide the capability of accommodating any type of layout, theme, or input (known and unknown, whether regular HTML or JS-based) with a common markup. Once you really start pushing Form Builder or ProcessWire forms, I think you can start to appreciate what the markup brings. Creating a form is the primarily purpose of what a form builder is for. When you are creating your own form markup, then you are the form builder. So my advice is that when you want to use Form Builder, let it do what it is designed to do and it will perform beautifully for you. On the other hand, when outputting a specific markup is more important than the result, then don't use any kind of form builder. A form builder is by nature a markup generating tool aimed at giving you really powerful forms quickly. And ProcessWire Form Builder is an expert at what it does. But you have to trust it and let it do its job. I've been both developing and using Form Builder for several months now, and strongly feel it is 100%. That's why I've moved it from beta to stable this last week. It is the most comprehensive and complete module ever built for ProcessWire (at least of those that I've built), including the core modules. Like mentioned above, you do have to use it in the way it is designed to be used and in the way it recommends. If you come across any issues or bugs that lead you to think some part is not 100%, then just let me know what it is -- I fix things very quickly. But I am not aware of any issues at present. At least, it is 100% stable with all the forms I am using it on at present.

Arjen is right. See /site/config.php $config->uploadBadExtensions = 'php php3 phtml exe cfm shtml asp pl cgi sh vbs jsp';

It's best to let an entire form be rendered together as a group, when possible. Like if you call $form->render(), that should render all Inputfields within the form together. This is important because it also has to process [input] them as a group. So if there are pre-rendered Inputfields in a form, they won't get processed with the form. So it creates more things for you to keep track of if you don't have all your fields rendering and processing together as a group. It's true that it's also easier to hook and extend these things if they aren't already rendered into markup. The main exception is the InputfieldMarkup type. That's designed to hold rendered markup for things that can't necessarily be rendered together with the form, like a table or some other kind of markup unknown to Inputfields. The example Soma is talking about (I think) is the MarkupAdminDataTable in ProcessTemplate that gets rendered into an InputfieldMarkup. Longer term, maybe we could come up with a new "Renderable" interface (requiring a class to just have a render() method that returns markup) so that stuff like this could be rendered together with the form fields.

If I recall correctly, post_max_size includes not just file size, but other post data as well. So it should be at least equal to, but preferably higher than the upload_max_filesize.

I've been experimenting with this by including the "rel=0" in the oEmbed call, but apparently YouTube ignores it. It looks to me like they don't support specification of this option with oEmbed, though if anyone can figure out how to do it I'll be happy to integrate it.

I wish that TinyMCE had a more graceful fallback for when a language file wasn't present. It seems like they way they are doing it is not right. Glad that worked, thanks for letting me know.

I've updated renderList to include the pagerOptions here too in the dev branch. I've got to be honest and say that arrays in GET vars have always bothered me. They are so darn verbose and ugly. Why have a query string like this: var[]=1&var[]=2&var[]=3 When you can do this: var=1,2,3 All it takes is encoding your array like this: $input->whitelist('var', implode(',', $var)); and decoding it like this: $var = explode(',', $input->get->var); That's just my preference anyway, but not suggesting it should be anyone else's unless these things also keep you up at night.

That's my understanding after doing some research online. Though I've not ever pushed those upper limits so just repeating what I've read rather than speaking from personal experience.

Thanks Soma, I'm making the same change here.

This is updated in the dev branch now too.

No idea why it would make any difference between 2.2.2 and now. There haven't been any changes to the stuff in question. For instance, the last change made to LanguageFunctions.php (where the __ function lives) was related to our previous thread, 4 months ago: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/LanguageFunctions.php The only thing I can figure at this point is PHP 5.2.4, which is known to have bugs. If you want to try and troubleshoot it a little more, try taking a look at what exactly the __() function is sending to the translator. So add this line: if($text == "whatever your text is") echo "<p>Textdomain: $textdomain</p>"; right before this: return htmlspecialchars($language->translator()->getTranslation($textdomain, $text, $context), ENT_QUOTES, 'UTF-8');