ryan

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.

Thanks Slkwrm. I submitted an update earlier today that should fix any issues with the standard text field max length.

I think it's time for some upgrades to InputfieldInteger. I'm adding this to my list.

I don't know what WillyC was saying above, but his code suggestions are right on. I agree with everything he said (in the code at least). Also, Jim this is one awesome module you've put together. Nice work! Edit: WillyC please use English, if possible. People are reporting your post as spam (and I know it's not, your post was good). Admittedly, I never understand your drunken-refugee-Yoda English, but I think even fewer here understand your Klingon (?) or whatever that is. I do admit it looks very pretty though (as does your beard). But please use English where possible, or at least make us think you are... Ultimately if we can understand your code, that's all that's necessary, and you are doing well there.

I like your idea of a regex, that would be easy to implement and very powerful. I agree on the importance of input limits. Though the need for that level of specificity in limits is pretty rare in my own projects. And this is the first time it's come up here. As a result, it's not been at the top of the priority list, but it's something that Fieldtypes are built to support (and already do in many instances). Actually, I think the number fields are probably one of the few that don't yet have many options for setting boundaries. It's not that the boundaries aren't useful, it's that I'm very cautious about enforcing any rules that could put a page in a state where one couldn't save. If I have an integer field that I know has to be between 1 and 3, then I'm usually enforcing that in my template code, where the need for the boundary exists. Longer term, I still think it's better to have it in the admin. Now that it's come up (via your message) that builds momentum for doing it sooner rather than later. Beyond a min/max in the integer and float fields, are there any other fields you think specifically additional validations would be worthwhile? I do like the idea of adding the regex option to the single line text field, though I'm not sure how many will use it (beyond us).

Sorry about that, I think I've got it fixed now if you want to try it again.

That's great! Glad they got it resolved. It sounds like the company is a good one if they found a solution for you on this. But to answer your question about a good US host, stick with a VPS (or something like it) so that you don't have to play the shared host games like this. You want to have control over your hosting environment. I've found ProcessWire runs great on every shared host I've tried it with. But stepping outside just ProcessWire for the moment, if you need to handle real traffic or run something beyond static HTML files, shared hosts are painful. They work well enough to make you think it's a good deal, but if web development is your job, then using a shared host is like being a chef limited to a pocket knife. Everything takes longer and you regularly have to improvise. The only shared host I was ever really happy with was Pair Networks (http://pair.com), but that was years ago and I have no idea what they are like now. They don't do shared hosting, but ServInt (http://servint.net) is the only hosting company I would trust my clients to. And obviously, that's who hosts processwire.com too. If you can step up from shared hosting to go the VPS (or more) route, they are fantastic and their servers are well optimized for ProcessWire. There are other good ones too. I know Pete has also mentioned he's had a good experience with a company called StormOnDemand. I've also heard good things about KnownHost and PowerVPS in the past. If you need something dirt cheap, don't need to handle real traffic and don't mind all the throttling and crap, BlueHost and HostGator are not bad for the price (both use cPanel, which I like), but use them for stuff you don't care about too much.