ryan

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

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.