ryan

That's correct that the 1% is taken out and substituted as left margins instead. This is for all columns except for the first in a row. I've actually been planning to switch to width classes rather than the inline styles that are used now. The primary reason is just to be able to support breakpoints with responsive layouts. For instance, if you've got a screen width under 600 px or something like that, you might want to cancel the floating behavior of all widths less than 100%, and instead just make them take up a full row. We can do that if we're using classes, but not if we're using inline styles. @interrobang: Check the markup settings in the Form Builder module settings. This may let you add the extra wrappers you want. Also want to mention that just because Zurb Foundation or Bootstrap (or another) provide some form features and grids doesn't mean that you have to use them with Form Builder. I personally think you are a lot better off with Form Builder's defaults than you are with those of Foundation or Bootstrap. Those frameworks are just trying to cover common form needs for the masses, but Form Builder goes well beyond this. As soon as you start letting a general purpose CSS framework take over your form styling needs, you are then limiting Form Builder's output capabilities to those of your framework. Though if you are dealing with fairly basic forms (primarily text fields) and simple needs, then there's also no harm in using a CSS framework for form styling either. But I think you will be happier if you give this control to Form Builder rather than [insert CSS framework here].

Digitex, I think I found the issue. Please try the latest update and it should work now.

$user = $users->get('antti'); $users->setCurrentUser($user); If you want to make the user persistent for the session (without having to do the above on every request), then do this: $session->_user_id = $user->id;

There's not a great reason. Basically, if it's a local URL (just as path) then it gets validated consistent with ProcessWire page path rules. If it's a full URL with schema and domain, then it gets validated by PHP's filter_var rules. So it's just a matter of what validates it. Probably what I should do is change the path validation.

I've been away from this for a bit, but I don't recall there being reference to multiple feeds outside of what you send to the $cal->load(...) call. But of course, you can create as many instances of the module, and load as many feeds as you want, using that method.

Yep. Form Builder 0.1.4 supports the Password Inputfield (which always uses double inputs).

When you are using Form Builder, all of ProcessWire's single-and-multiple selection Inputfields provide a very similar means of defining the options. But this applies only to forms in Form Builder.

I think in your case the best bet probably is to use the 'hidden' status, or to add your own checkbox field specific to this need. Ultimately we don't allow unpublished pages in page references because: unless you are superuser, you aren't going to see unpublished pages that you don't have access to edit. So it would violate the security model a bit if users could see or add unpublished pages. If only superusers could do it, then another editor (non-superuser) could potentially break the selection simply by saving the page. While I think there are some potential nice things about being able to add unpublished pages to page references, in the big picture, I think we're better off avoiding it.

Diogo, that's a good one to know about, thanks. That one should work too as it's not detecting specific options but rather pulling the entire query string out of the URL and then packaging it back up into the iframe embed code that youtube provides. Once I saw all the options on the page you linked, I figured that was the only way to go.

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';