ryan

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

The session challenge cookie is a randomly generated hash with one copy in the session data (at the server) and another copy in a separate cookie. The two have to match in order for the session to be considered valid. The value is set at login time. It's basically just a secondary session ID for a little extra security. If someone finds out your session ID (via a URL or some other means) they would also have to have your session challenge key in order to intercept that session. There is also the session fingerprint which is kept only in the session data (at the server). This is a record of your IP and user agent. If either changes, the session is no longer valid. This is turned on by default (in config.php) but should probably be disabled for an online store, since you may be dealing with folks that have dynamic IP addresses. Though if you are using your own cookies for the cart, then it should be fine to leave the fingerprint check in place (where it would be more for admin users).

Lance I'm not sure specifically what a site title is, but guessing you just mean some common string of text that's repeated on every page? If so, I would probably add a text field to your homepage template and call it 'site_title' or whatever you want. Then have your main template (or head.inc) output that text wherever you want it to appear. For instance: <?php $site_title = $pages->get('/')->site_title; echo "<a id='logo' href='{$config->urls->root}'>$site_title</a>"; --- Edit: holy smokes, there were no replies when I started writing. I hit reply and now there's 3. You guys are fast.

$pa = $pages->find('template=' . implode('|', $templates->find('name^=basic-')));

I think what WillyC is saying here is that sessions come from cookies and are only a fallback if you use URL-based sessions, where a session ID is passed along in the URL. But that type of session is considered a security problem, and they are disabled in ProcessWire by default. My opinion is that people browsing without cookies probably don't want to be tracked. If they have cookies disabled, they probably aren't able to do much anywhere. I could be wrong, but I don't think there are many stores that will let you build a cart and complete a transaction without cookies (?). I guess that using HTML5 storage, Flash or even a browser's file/image cache could be alternative ways to maintain session data.

You are right, in this case the redirect would have to include the hash. In PW1 there was no redirect, so that wasn't a consideration. Still, that won't be a problem.

Here's how I was thinking it could work (also the way it worked in PW1). The WireTabs class would auto-select a tab when the URL had a # in it. For instance, /processwire/page/edit/?id=1#children would automatically select the 'children' tab when the page was loaded. Then, every time a tab was clicked, some JS would modify the <form> action attribute to change the # property in the URL. It's a simple concept, but makes sense with the purpose of the '#' properties in a URL to be what auto-selects a tab, much like it would jump to a place in another HTML document.

Great answers Slkwrm. Biotech, thanks for your interest in ProcessWire. I only have the skyscrapers profile for PW 2.0 available. I can send it to you, but so much has changed since then that I'm not sure it's the best example anymore. I do plan to update it, hopefully soon. Just need to get a couple free hours to do it.

This is great Soma. I've actually been meaning to have this capability built into WireTabs for quite awhile (it was in PW1 and just never made it over yet). Perhaps we could combine efforts and make this part of the core, as I think it's always better for it to return to the tab it was on when you click save.

Oliver, the module ID is already determined by the time your install() function is called. For instance, you could add this to your install function: $id = wire('modules')->getModuleID($this); However, when you do $page->process = $this; it is already doing the above for you behind the scenes.

Rob, the issue here is that your sleepValue has a 'url' field in each item of the $value (the one that was created from 'data' by your wakeupValue function). You'll want to have your sleepValue do the opposite of wakeupValue. So it should create a new array containing 'data' and 'text' for each record, rather than 'url' and 'text'. Then it should return that array. I would think that the way it's setup right now, there would be problems maintaining the url/data value on any page save, not just cloning. But luckily the fix here is simple.

I can modify our $session to copy data, that would make sense. It just never came up before, but lt me see if I can add this. Though you may actually want to use a cookie rather than a session for cart data, just so that the cart data can live longer than the session (there isn't really any reason for it to expire as quickly as a session does). Also want to mention that PW uses PHP's $_SESSION as well (keeping it's data in an array inside of it), so it's not a problem to use $_SESSION rather than $session.

Great work Soma! I'm really liking this fieldtype. I wanted to mention one potential improvement that would be easy to make. Rather than having to use the technical sounding range.data and range.data_max in selectors, wouldn't it be nice if you could use range.min and range.max? If you want to do that, add this to your Fieldtype: public function getMatchQuery($query, $table, $subfield, $operator, $value) { if($subfield == 'min') $subfield = 'data'; if($subfield == 'max') $subfield = 'data_max'; return parent::getMatchQuery($query, $table, $subfield, $operator, $value); }

I don't know how you would go about testing SSL in MAMP. But if you can access any URL on your server from either http:// or https:// then you should be set. The next thing to do is just edit your PW templates and configure which ones should only allow https access.

Sounds like much has changed since I originally did DB research before building ProcessWire. Back then, MySQL MyISAM was the only fulltext game in town (short of using something like Lucene). This wasn't that long ago actually, but it's good to hear that this has changed. I'm sure there is lots to like about PostgreSQL and I like everything I've read. I would love to support it in a future version of ProcessWire. I'm sure that it has many great things relative to others, like you've stated. But I also think that most web developers' reality is not one where the use of one database over another matters very much. I've used MySQL every day for the last 12 years and have never had a concerning situation or ever lost data in any form. MySQL has been one of the most reliable tools I've dealt with, and is one of the things I've been able to depend on most among all the tools I use. So my point is that these factors may matter to someone that works a lot with databases on their own, but they may not weigh so heavily to the larger web developer audience. Still, I'm very interested and supportive of PostgreSQL support in ProcessWire. The only reason I didn't built in support in the beginning is due to the lack of fulltext index support at the time.

I never knew the name for it. It's good to hear that, "flashdata". This was mainly setup so that modules could queue messages that would only be seen on a follow-up page. Since many modules do a session->redirect() after a save, there needed to be a way to queue those messages to be seen on the following page load rather than the current (where they would never be seen). I don't think that you actually have to call $session->message(), as I think any notice sent through message() or error() gets queued. Though calling $session->message() is a good way to make that intention clear from the code side.

Seems like a good idea, and it will be easy to add. I'll plan to add this. Thanks for the idea.

It really depends on the fieldtype, but for text fieldtypes the idea is to be flexible. There is no bad data with trusted input, just bad output. If you don't want to allow HTML for instance, then you would select textformatters such as 'strip tags' and 'html entities'. But we avoid modifying what the user enters as we don't want to limit PW to one use over another. Specific validations are for specific fieldtypes. PW's basic fieldtypes are meant to be open-ended, as much as possible. For specific data needs, the intention is that you would use (or create) a specific fieldtype rather than expecting it from a general purpose one. Taking that zip code example, that's a pretty specific input -- if we are taking a zip code as input, we'd ideally use a zip code fieldtype so that it knows how to validate zip codes and doesn't take up any more storage space in the DB than what is needed for a zip code. However, I'm not at all against adding more validation capabilities to the basic fieldtypes, and like the examples in your approach. It certainly can't hurt anything so long as it's optional, so will plan to continue adding more validation possibilities to the basic fieldtypes.

Good question Oliver. The Fieldtypes do each require a DB table, and must have at minimum a 'data' column (regardless of whether it's text, integer, etc). I also recommend that you extend Fieldtype rather than FieldtypeMulti. If you don't need multiple items stored in the DB per page, then there's no reason to use FieldtypeMulti. Your wakeupValue will construct an array or WireArray or some other object, and it doesn't really matter where it gets the data from to do it. If your Fieldtype holds (but doesn't store) multiple items, I recommend using your 'data' column in the schema as an integer that just stores a count of how many items there are. That way it can still be used in selectors to find pages that have a populated value vs. pages that don't.

Some great ideas here. I just wanted to add that this really is how ProcessWire is supposed to be used, and it's not considered "abuse". It is perfectly fine (and encouraged) to use pages for lower level stuff.

I just committed FieldtypeRepeater to the core, so it's now there, though as a 'beta' module. Right now it's in a fairly simple form, as I still have some more options being worked on with it. But I wanted to get it posted for those that wanted to try it and help test it. Since I'm the only one that's used it so far (and on basic/small things) I don't suggest using it in production just yet, as there are bound to be issues uncovered as others test it. I appreciate any help testing this. To install, just make sure your core is up-to-date, go to Admin > Modules and click 'Check for new modules'. It should find FieldtypeRepeater. Click install. Then create a new field and select 'Repeater' when it asks for the type. Once you've added a repeater field to a page, you use the field from the API exactly as you would any other multi-page reference field (see the first post for an example). I also want to note that if you have 'debug' mode enabled in your PW, the Repeaters Fieldtype is quite chatty (which you may or may not like). If debug mode is off, the fieldtype will do its job quietly.