ryan

Thanks. I agree this does have potential to reduce the number of fields you might need, or at least, allow you to be more specific and contextual with the information you present with the fields. Ultimately it should lead to a better experience either way.

Thanks Hani, I have updated the module to add a new 'recurring' option which is set to true by default (and translates to singleevents=true' in the URL).

Alchime, I actually have not tried out that tutorial yet, so need to take a closer look at that. However, attached is a template file (basic-form.php) that is ready to use as a basic contact form with the default site profile. Let me know if this is helpful? basic-form.php.txt Note that you'll have to rename this to basic-form.php, place in /site/templates/. If you want it to email to a specific address (rather than the superuser) than edit the file and enter your email address in at the top where it says to.

That applies to PHP4 which did actually have OO bolted on. But PHP5 is a different beast that's been built around OO. PHP4 and PHP5 are like two different languages when it comes to OO. I can't say as though I agree of being jealous of Python (or Ruby) syntax. Nice languages, but we just didn't make a connection despite a lot of effort. Ruby especially left me tired... felt like working in a cubicle. This is my experience, but I know everyone is different. PHP is such a workhorse and seems to be the language of people who get stuff done, more than any other. Something about PHP also seems to drive creativity that the others don't. Still, it's not for everyone and thankfully there's much to choose from.

I agree, responsive sounds great. As far as I know, Kickstart is not responsive (or at least not built in)? Outside of that desire, it seems pretty fantastic... I'm going to be experimenting with it here on another project.

Welcome to the forum! I'm on a mobile phone, so have to keep it short--Those 'defaults' settings are really only good for when the field is first created. Your best bet is to edit the settings of the field using tinymce instead. You'll find this by editing the textarea field, clicking to details, then editing the tinymce advanced options'.

I agree, it would be very handy and I've been wishing for this on many occasions too. Most likely we'd just add it to InputfieldPage, which is the container Inputfield for all Page selection inputs. I will put some more thought to this to see how we might implement it.

In earlier versions of PW it was possible for usernames to be email addresses, but when users were switched to being pages, the usernames had to be compatible with page names. That pageName function you mentioned is the way to go, and username() should probably be deprecated or redirected to the pageName function, like you mentioned (something I need to do).

Soma, Diogo: you'll be glad to know I've taken a close look at field template context and how we might support it in the core. It'll be simpler than I thought, so there's a good chance I can get this in version 2.2, relatively soon. Now that I understand how we'll do it, I think we'll be able to provide template context of almost any field setting (custom and internal). So it will likely go beyond just title, description, collapsed, width, etc. To change the context of a field within a template, you will edit a template, then click on a field name or edit icon (in the asmSelect). It'll open a modal window with all the field's configurable settings, all within the context of the template. I think this will be pretty cool.

Stephen, I haven't fully developed the API for this field just yet. But here's how you'd do it at present (and it will get a lot simpler than this). I've written this in the browser so there might be mistakes here, and I can try to test this out later. // create the new repeater field $repeater = new Field(); $repeater->type = wire('modules')->get('FieldtypeRepeater'); $repeater->attr('name', 'my_repeater'); $repeater->label = 'Your Field Label'; $repeater->save(); // forces a self-setup + configuration (this is an odd step, I know, will improve) $repeater->type->getConfigInputfields($field); $repeater->save(); // add some other fields to the repeater $repeaterTemplate = wire('templates')->get($repeater->template_id); // get the template used by the repeater $repeaterTemplate->fields->add(wire('fields')->get('title')); // add title field $repeaterTemplate->fields->add(wire('fields')->get('summary')); // add summary field $repeaterTemplate->fields->save(); // add the new 'my_repeater' field to your the 'basic-page' template, as an example $template = wire('templates')->get('basic-page'); $template->fields->add($field); $template->fields->save(); Now to jump to another example. Lets say you already have a repeaters field called $page->my_repeater and you want to add a new repeater item to it: $repeater = wire('fields')->get('my_repeater'); $item = $repeater->type->getBlankRepeaterPage($page, $repeater); $item->title = 'Test item'; $item->summary = 'This is just a test item'; $page->my_repeater->add($item); $page->save(); This is all a little complex from the API side in my opinion, so I'll be making this a lot simpler... but just wanted to at least reply with a useful example.

I tested it out with PageEditSoftLock and found the problem. The reason it tells you that another instance of you is editing the page is because of this statement in the checkpagestatus function: $user = $this->users->get($user_id); if($user === $this->user){ When a new repeater page is added, it goes through a $pages->save(). After $pages->save() finishes, it clears the in-memory page cache to ensure any future $pages->get/find operations in the same request aren't returning old versions (it has always done this). Users are pages. As a result, your $this->users->get($user_id) is returning a new instance of the current user than what is in $this->user, so a '===' comparison won't work, since it checks to see that two objects are the same instance. But the fix is easy, just change the above code segment to this: if($user_id == $this->user->id) { This is also more efficient, as there's no need to retrieve the user from $this->users->get() when all you need is the user ID, and you already have it. --- Edit: fixed issue with the repeater labels note honoring the language setting. They should work properly now.

Antti, I've been sacrificing forum time for PW development time, and just wanted to apologize I've not been able to actively participate in this more. But I wanted to let you know how impressed and interested I am in this. I already have all kinds of plans for using this and getting more involved, and am thinking it will be perfect to use for the DI bookstore. This is the coolest and biggest PW project to come along, and I just wanted to explain my lack of posts in here. The reason is that I'm about to jump into a work schedule (this week) where I'm not going to be able to do anything major with PW for 6 weeks, other than fix bugs and make 2.2 official. Though I'll be developing [a site] in it, rather than developing for it, so I guess that still counts as ProcessWire time. But I've been redirecting my forum time to put out a couple new PW features ahead of schedule (primarily repeatable fields), to hopefully buy some patience for the weeks ahead where I have to focus mostly on another project. But once that is done, I am looking forward to building a store and participating in the project.

Testing out here, I agree this is really nice. Perhaps we should just implement it at the session level in the core rather than in the URL. I'm still not totally sure I like deleting a page, and then getting put into the delete tab of the next page I edit (for example) but most of the time the change in behavior is welcome.

Looking great. What do you guys think of the profile supporting mobile devices? Perhaps responsively. Also wondering if there might be value in building the profile from a framework like HTML Kickstart?

Good idea, I will plan to do that.

Definitely still on the agenda. But if you need something today, I would just use $_POST. The version that PW has ($input->post) is only normalized for PHP's magic_quotes setting, not sanitized for anything in particular. So if you are dealing with something where slashes would not be an issue (like numbers) it really doesn't matter whether you use $_POST or $input->post. My opinion is that it's never bad to keep close to the tools that PHP provides for you and that's reflected in ProcessWire. I know there are those out there that think there should be abstracted layers on top of abstracted layers on top of things like $_POST, but I am definitely not one of them. I don't believe in trying to redo or layer on top of something PHP already does well unless I need it to do something different. The closer we stick to PHP, the closer we are to the faster C++ code behind it and more familiar code is to other folks. Then again, I love PHP. But I know there are also those that would like to abstract away most of PHP, and I think that's silly. You'll occasionally see me use $_POST and $input->post interchangeably, depending on whether I'm dealing with input that may have escaped quotes.

Beewee, I think the other guys said it here best. But I just wanted to add that the number of things you have to learn is probably less than what you would have to with a typical tag-based system like ExpressionEngine. PHP combined with a logical API is in my opinion a lot cleaner and simpler than most of the tag systems. Not to mention, far less overhead, and much more powerful (when/if you want it to be). And the bits of PHP that you pick up will benefit you far beyond ProcessWire. We're here to help anytime you need it.

When you edit a field, there is a tab called 'input' and that's where you define the settings related to the input field presented to you in the admin. When you edit a template, you are there to edit the settings related to the template, not the individual fields. Maybe you don't agree with this architecture, but that's the way the system was designed from the beginning and I don't want to cross those concept boundaries until they fit the bigger picture of the system. That bigger picture is called template field context, and that's a feature that's already planned for and something we've been talking about for a long time. But also something that's going to take some real time resources to do well, and it can't be done now. But when we go there in a future version, you'll be able to modify some field settings within the context of the template. Things like title, description and now likely width. But I'm not interested in blurring this line until we have full support for field contexts within templates. As you know, ProcessWire does not currently support those different contexts for a field on a per-template basis. If you are creating multiple fields just to get different widths, stop doing that. You should not be using field widths in that case--leave it as a normal PW 100% width field like you've always used. These width settings are for when you have a specific need, like a pricing table or something like that. They are not something you should use on every field and not something you should use on fields where you need all kinds of different contexts. Because PW has always had 100% width fields before yesterday, not every field is going to be a good candidate for reduced width -- Soma the file field probably shouldn't be used at anything less than 50% at present. I would expect there will be other fields that won't be happy at reduced width, though I've not found any yet.

Soma I think there's multiple ways to look at it, but I'm not too enthusiastic about getting the templates involved in individual field settings. That seems like blurring the line about where things are defined, leaving one to guess where they would define one thing or another. This is when software gets complicated. Would you really want to define the width of the field in the template and then the type, size and maxlength with the field? These things are all related and shouldn't be separated in my mind. Templates aren't supposed to know anything about fields other than which ones they have. I do think about this stuff a lot before coding it. I also appreciate exploring this from all angles, and that's why I'm very glad to have you involved in this project. Your viewpoint is always valuable and well thought out. Consider how we work with markup. When you define floats, the container doesn't decide the proportional width of the floats--the floats do. When we define the type, size and maxlength of a field, we define it with the field, not the container. If a field is suitable for use in a narrow column, that's got to do with the type of field that it is and how you've configured it. This is the field's data. Reusability is far from black and white here. If you've setup a field for reduced-width use, shouldn't that remain consistent regardless of whether you are using it for columns or not? There's more than one reason to set the width of a field. Another consideration is that if we start defining field widths with the template right alongside the fields, people will think this is something rather important. I don't want people to think they have to use this. It's a nice optimization, and far from a requirement. If this were particularly important we would have had it a long time ago. Where I like your idea is as an add-on or override at the template level for the power-user. The field still defines its width, but you have the opportunity to override it in the template. That way the field still owns the data it should, but the template can see that and choose to override it. If you only wanted to define it at the template level, then you could. I want to hide the details of that by default so as to avoid confusing what is template data and what is field data, but give the option to the power-user. So I'm thinking an optional module or setting one can turn on if they want to define it at that level (and sliders would be particularly fun here).

Soma thanks for all your testing. I hope to test, reproduce and resolve the issues you've mentioned tomorrow morning, and then post a new update. Thanks also to Statestreet, Diogo, Seddass and Biotech for the testing and feedback. Compliments on this diagram, quite cool. While I need to retain the ability to have columns of different lengths, I do think this would be perfect if we were sticking to columns of the same width. I should be able to figure it out when I test tomorrow. Showing the title in the bar is something I'd like to do, it will be coming. But will just require that the repeater has a title field (title fields aren't required for repeaters). It's just not yet language aware in that regard. I'll add that in on the next update though. Beautiful!

Thanks for testing it out Soma and Statestreet. Are you talking about the Thumbnails module by Antti? I haven't tried it out with the repeater yet. In order to work in a repeatable, a module would have to be okay with having multiple instances of itself on the page (whether in a repeatable or just used by more than one field). All the core field types are good in this area, as far as I know. One way to test it is to just create two separate fields that use the Thumbnails module, assign them both to the same template, and then attempt to edit a page with that template. If you get the same issue, then very likely there is some hard-coded ID attribute in one of the elements or something. TinyMCE didn't take kindly to being in a jQuery sortable, so I had to make some adjustments for it. If you drag a repeater with a TinyMCE in it, you'll see I had to turn off TinyMCE for the field during the duration of the drag. But other than that, I've not run into problems with any other fieldtypes. If the Thumbnails module doesn't work now, I'm sure we'll be able to find a way to make it work. I don't understand. What's an RT? (retweet?) Just confirmed -- this is a bug. If you only populate an image field (and not any other fields on the item) the page and image gets saved with ajax. The repeater doesn't get the opportunity to see a change was made. But I think this'll be an easy fix. Can you clarify? Are you talking about the column width percent? You shouldn't have to reinstall anything. But make sure you are using the default admin theme, and hit reload once or twice to make sure you don't have JS or CSS files from an old version. The repeater is basically rendering the Inputfields for multiple pages, so chances are that the soft lock is hooked into something that is getting called several times rather than just once. We can take a closer look at interactions with other modules, though I'm thinking I should work out any bugs with the Repeater module first. Browser cache is always a possibility too. I think that's a good idea, but I also don't want to make too many assumptions here. If someone wants 10 columns of integer fields, they should be able to do it. But I don't want to limit the increment to 10s, because than would mess up someone doing a 4 column of 25%. Likewise, don't want to limit the increment to 5s because that would screw up the person trying to do 3 equal columns. Ultimately it doesn't seem like I can impose pre-defined increments here without excluding a lot of useful possibilities.

Seddass, thanks for your feedback. While I've now had a lot of experience developing them, I've not yet had much experience using them. So I don't feel all that qualified to outline the cases where one should or shouldn't use them. However, my feeling is that repeaters are ideal for reasonably small collections of data that don't need their own page URL. For instance, an office locations list or employee directory or something of that sort. Instances where you are going to be outputting the data in some table or list together, much like you edit them together. But I think the potential uses are much more broad than what I can think of right now, so this might be a better question for someone that's used matrix fields in EE or ACF in Wordpress, or a question for me to answer a couple months from now. By default, the repeater pages are created somewhere outside of your site tree (actually in /processwire/repeaters/). Because they are hidden off below the admin, they aren't searchable as pages themselves, except by those with admin access. That's intentional. We don't want selectors matching these pages since they aren't being used in the context of pages (at least not by default). I will be adding an option to make them "detached" so you can place them wherever you want and actually use them as pages in your site should you want to. But that will be an option, not the default behavior. Because they aren't searchable on their own by default, they have to be searched within the context of the page where they are used. So if you wanted to match all pages that had a 'buildings' having 40+ floors and a height field 800 or fewer feet, you'd do this: $pages->find('buildings.floors>=40, buildings.height<=800'); If you just wanted to match pages that had one or more buildings: $pages->find('buildings.count>0'); $pages->find('buildings>0'); // this also works This doesn't matter unless you actually implement a template file for your repeater field. So you should be fine to clear the current page only, unless you prefer to clear the site for another reason. If you want to implement a template file for your repeater, you create a file in your /site/templates/ named "repeater_[field name].php", i.e. in the case of the buildings field, it would be "repeater_buildings.php". That template file will receive a $page variable that is represents one 'buildings' record. So you could do something like this: /site/templates/repeater_buildings.php <?php echo "<h2>{$page->building_name}</h2>"; echo "<p>{$page->floors} floors, {$page->height} feet</p>"; The template used by your page with a 'buildings' field could then do this: /site/template/basic-page.php foreach($page->buildings as $building) { echo $building->render(); } However, for a relatively simple case like this, I would probably not bother with creating a repeater_buildings.php template file, and instead just put it all in the basic-page.php template. But if you do use the approach of rendering repeater elements with their own template, then you would want to consider the cache. Rather, you'd probably want to avoid using the cache for your repeater_buildings template and instead just rely on the cache used by your basic-page template.

This option has been added in the latest commit. You'll see it when editing any field from the 'input' tab. From the API, it's Inputfield::collapsedPopulated

Has anybody had the chance to try out these repeatable fields yet? I have one more update that I put in the latest commit, though this applies to all fields, not just repeatable fields. This update enables you to create columns rather than just rows. You can now specify a width percent in any field's input settings (or use the columnWidth property on an inputfield from the API). Here's a screenshot of the new setting: And here's the result (combined with a repeatable field). In the screenshot below, I've set building_name to have a width of 50%, floors to have a width of 25% and height to have a width of 25%: Note that because this involves some stylesheet tweaks, this may not work on 3rd party admin themes right away. But I'll be happy to assist admin theme developers to add the necessary stylesheet tweaks to make this work.

Comma can't be used to separate the template names because comma is used to separate individual components of a selector. However, the default output of WireArray::__toString isn't really that useful at present, so I've modified it to return a selector compatible string instead (like PageArray does). So if you've got the latest commit, you can do this (copied from your example): $pa = $pages->find('template=' . $templates->find('name^=basic-'));