ryan

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.

Pete, I think the simplest thing would be to add a hook before InputfieldPageAutocomplete::render, retrieve the 'value' attribute and add the default value you want when it's blank. Let me know if I can provide a more code-oriented description/example.

Looks great Adam, nice job!

Soma great module!! It should be no problem to make your Fieldtype support two integers. Take a look at the FieldtypeMapMarker module for an example of how to have multiple fields in the module. To start you are going to want to have a DB schema something like this: public function getDatabaseSchema(Field $field) { $schema = parent::getDatabaseSchema($field); $schema['data'] = 'int NOT NULL default 0'; // min $schema['data_max'] = 'int NOT NULL default 0'; // max $schema['keys']['data'] = 'KEY data(data, data_max)'; $schema['keys']['data_max'] = 'KEY data(data_max)'; return $schema; } Basically, use the required 'data' column for one of your pieces of data, and then you can add any other columns you want. I called it 'data_max' here, but you could call it whatever you want.