ryan

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.

I'm with Soma, explode('BAM' 'my head'); It's late here, I'm sampling Belgian beers while typing, and I'm tired, so I think that means I'm done for the day. Will revisit this thread tomorrow.

This is an excellent question (as always). I've given a lot of thought to this a couple months ago. My thought is that the opposite would be a much bigger problem. There isn't any way that a machine could make a judgment call about whether a change in a translation is significant or not (as of February 2012), short of some very complex and creepy AI. Even more so given the diversity of communication possibilities among languages. A machine can't tell the difference between a spelling correction and a life-or-death medical instruction. The only safe thing to do is to consider the translation abandoned as soon as the original changes. Given the possibility of something important being in translated text, it's far better to present the text in its original form than in incorrect translated form. We've taken the lead from GetText on this, and I think it's the right way to go. Also want to add that both GetText and PW's built-in language parser are for static text that's not likely to change often, not dynamic text. Use the rest of ProcessWire for your dynamic text.

I wanted to add that the idea behind the repeatable fields implementation came from Diogo and his post (below), as well as related posts from Apeisa, Adamkiss and Martinluff (and I may be missing others) sparked the direction used in the new repeatable fieldtype. While a little different than what he mentioned, Diogo's original post, and follow-up posts are what got the ideas and momentum towards this direction going for the current implementation: http://processwire.c...ndpost__p__4519 Initially I'm just trying to get a reasonably simple implementation of repeatable fields going, but down the road we'll expand to broaden the possibilities consistent with peoples' needs... perhaps with pagination and more. Though admittedly, terms like pagination within a field make me wonder if we're going too far. But I've started to revisit some code in the FieldtypeRepeater module based on some feedback here, working towards giving you more page management possibilities with it. But don't expect too much here, this will just be a beta test version 1 and it's not going to perform any miracles. And like with anything new, I'm sure there will be bugs to uncover as well. Repeatable fields like this do seem to open a lot of new possibilities. I think part of that is just that we've not had them quite like this before (at least in PW), and it seems like a whole new dimension to explore. But while you could apply repeatable fields like this to all kinds of uses, I don't necessarily think we should be doing that. They will be great for some things, but they will also be tempting to use in places where they really shouldn't (I've already had to restrain myself). These repeatable fields with all kinds of possibilities will blur the line on that and demand more discipline. I think that like every page is viewed at it's own URL, it should also be edited at it's own URL (in most situations). But for repetitive data that may use a page + template by convenience rather than by need--repeaters will be perfect. I just don't want to see people turn their sites into spreadsheets. I personally will be using them on only half of sites that I build (I estimate). But I can't wait to get this out for you all to try and see where it might help to simplify tasks and open new possibilities. I think I've only scratched the surface with my own testing here, so this fieldtype will continue to evolve as your needs do. Thanks for all the great ideas and interest in this.

Thanks this is good feedback. I have a feeling the new site design is going to make a big difference here. Adam has done a nice job with it.

Is this for a getModuleConfigInputfields function? I don't think I've ever tried fieldsets there, though I can't think of any reason why it wouldn't work. But if you don't mind going without fieldsets for a day or two, I can reproduce and fix it here.

Uninstalling should remove the page and process. Also there's no harm in manually removing the page either. But if you just want to add the CSV import process, then I would just edit the existing page that's already there and select 'ImportPagesCSV' and save, and that'll be the same as if it had installed it.

Slkwrm, it looks like the default 'maxlen' setting for InputfieldText is 255 (bytes), and clearly that's not long enough. I'm updating it to a default of 1024 characters or 3072 bytes to better accommode the UTF-8 possibilities. Btw, this only applies to English phrases less than 128 characters, as all other phrases use InputfieldTextarea with no length limits. But of course, a Russian translation of a 100 character string could easily go beyond 255 bytes in UTF-8, so that's poor planning on my part. I'll have the increased lengths committed to the source shortly. Sorry for the inconvenience, but I'm glad we tracked this one down.

Thanks Antti, I'm updating this in the default site profile too.

Assuming this is a mod_security thing, which it sounds like, I would ask the hosting company how to disable it. If they can't or won't, that web host probably doesn't meet the minimum requirements to run anything but a very basic CMS. It would be a good reason to switch. That code that WillyC posted should disable mod security from the htaccess (even on a shared host, if supported), but I think the exact method of doing it depends somewhat on the apache/mod_security version. It's possible that such a method may work, but the one he posted might not be the right one in your case... still worth investigating further, just in case. But probably best to check with the web host to see what method they recommend.

Thanks for all the great feedback! This module is ready now, but I feel like I need to give it a more thorough testing on this end so will probably aim to have it to you this weekend or early next week. I'm short on time today, but am hoping to catch up with all of the questions here tomorrow.

You can export profiles using the ProfileExport module, and then import them using the PW installer. I've been using it for site migrations lately and it works well. I think it's not a bad idea to have a profile like you mentioned. Though I think PW's appeal is really to the designer/developer audience that can appreciate what ProcessWire does (relative to something like WordPress). But I'm all for expanding the audience. If having such a profile broadens our appeal, seems like a good thing.

I don't think ProcessWire will care whether you are using a shared cert or your own. But if you are linking to/from an http vs https page, PW does assume they are running at the same hostname. So you'll have to adjust any links in your site to be consistent with the shared https hostname provided by your hosting service.