ryan

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.

I may be able to add a 'check for translatable modules' option that basically goes through your entire PW structure and performs text searches on any files ending with '.php' or '.module' and looks for the translation function calls. It would be kind of a heavy operation, so would have to be initiated rather than done automatically. The way I currently locate translatable files is by typing this in at the unix command prompt: grep "_(" /wire/* As for downloading all the translation files in one shot, I agree about the convenience of it but think the only way we'll be able to do it is by zipping them up at the server side. Perhaps something we can do, but would require either exec()'ing to the shell and running 'zip' or using a PHP library that doesn't seem to be as widespread as I'd like. So for the short term, here's the best way to grab everything into one file: 1. Edit the language and note the ID in the address bar. We'll assume it's "1234" for this example. 2. Go into the directory (from shell or FTP) /site/assets/files/1234/ 3. Copy all the .json files to a place where you can zip them up. If you are in the unix shell, you can do this: cd /site/assets/files/1234/ zip language.zip *.json If you aren't in the unix shell, then you'll have to SCP/FTP them to your computer and zip them up there.

It sounds like we're using the exact same localhost testing environment. This module creates a page: Admin > Setup > Import pages from CSV Looking at the install function, it won't assign the process if there is already a page there named 'import-pages-csv'. If you've already got a page there with the same name, you'll have to edit it and select 'ImportPagesCSV' for the 'process' field and then hit save. However, assuming you don't have a page there named 'import-pages-csv', then it should take care of it all for you and be ready to use right after you've installed.

Check to make sure that your custom Fieldtype isn't maintaining it's own $page state. Fieldtypes are a sort of module where only one copy is held in memory and different fields and pages are passed into its methods. So if your Fieldtype is keeping a copy of $page or $field somewhere beyond the scope of a function's execution, then it's taken on a state that fieldtypes aren't meant to. That could create a problem with cloning. I'm also curious about the 'url' column you mentioned. What does your Fieldtype::getDatabaseSchema function look like? If possible, post your whole fieldtype module (or email it to me) as it's probably not possible to do anything other than suggest things to look at, without seeing the actual code.

Good ideas, we'll definitely have to look into these for future updates in the comments module. However, I also want to note that we already do have an alternative built in, that I've found to be just as effective as a captcha (if not more so) on the sites where I use it. Look at the 'requireSecurityField' option in /wire/modules/Fieldtype/FieldtypeComments/CommentForm.php. This option can be enabled in the options to the form: echo $page->comments->renderForm(array('requireSecurityField' => 'security_field')); I typically hide my comment form with CSS to prevent the possibility of false positives: #CommentForm { display: none; } Then use JS to show the comment form, and append a security field to it: $(document).ready(function() { var $input = "<input type='hidden' name='security_field' value='1' />"; $("#CommentForm form").append($input).parent().show(); } No more spam. The only downside is that your comment form now requires Javascript to use. But since you are hiding it with CSS and making it visible with JS, at least you won't be disappointing anyone.