Soma

I'm sure it works in your case for now, but is "wrong"... - There's already an API var $fields! http://cheatsheet.processwire.com/#fields , as I said in the previous post. Now you overwrite it, and it may cause problems later if you would want to use $fields somewhere else. It's like if you would overwrite $page or $pages... (Apart from that you're getting inputfields and not fields here), anyway. So I'm wondering why your $fields template var isn't exisiting! You may already have it overwritten before that code somewhere? - The red code you posted isn't necessary in this code. - But if you want to go with $page->getInputfields() you already get the inputfields!, so there would be no need to get it again. - Then also with $page->getInputfields() , there's no need to set the $f->attr("value",$page->account_type) again as the inputfield already has the value set from the page you're getting them. So this would be correct if you want to take this route: $inputfields = $page->getInputfields(); $f = $inputfields->get("account_type"); echo $f->render();

Strange for me theres such an error only in the dev version. The stable works fine..

Ah or with $child->child->id should also work. does it?

The error reveals that get() is called on a non existent object. In the example the $fields->get(), see? Means the $fields somehow doesn't exist... it can't call the member method get() on it. $fields is like $pages or $page available in all template files, if not, there something either wrong with your installation, or you're using $fields in a function or module. In the scope of a function you'd have to use the global function wire("fields")->get(). $page in the getInputField($page, null) is just a page and I think it can be any, PW requires it. The secon argument is for the context. Since fields can have template context settings, you could pass the template there I think. You can see the base classes wire/core/field.php and wire/core/inputfield.php or any wire/modules/Fieldtype/* and wire/modules/Inputfield/* module that extend those. But the more important part in the code is this: $f->attr("value",$page->somefield); Where you set the value of a page to the inputfield before rendering. This is a very broad, somewhat complex or versatile, advanced and individual topic, I always have a little hard time educate to someone with basic to none coding skills just through writing without knowing the whole scope of the project and context. Are those front end users, trusted or not. What data needs to be edited or created... uploads, datepickers or just simple selects and so on. I spent already sooo many hours coming up with examples and explanations that I hardly feel motivated to do it over and over again. No offense to you or anyone personally of course! Peace The thing is, it is an somewhat advanced topic and it also took me some time to find all out and learn by trying and reading source code in core, understand how it works and what are the limits. It's also good to know that the inputfields and fields used in the backend primary are built to be used in the admin context and not originally intended for front-end usage. But it's built so well by Ryan that it's possible to use them out of the admin context to some extend. It's just that some fields other than simple text, select, radio or checkboxes ... like files, images,ASM select, dates with datepicker, they require some more assets to also be included in your front-end namely js and css files. So you'd have to include them aswell. The admin theme templates uses the $config->scripts and $config->styles file arrays to render the styles and scripts loaded by a inputfield module. I also recommend: - Read that thread I linked to completely. Have a look at some examples (my gists with forms) to get a feeling. They're by no mean complete or the only way. It gives you enough flexiblity even with styling and markup. You can set the markup of InputfieldWrappers. ie. $form->setMarkup($options) you'll see in wire/core/InptfieldWrapper.php - Study the FormTemplateProcessor module by Ryan. http://modules.processwire.com/modules/form-template-processor/ As Matthew said, you can also just build your very own markup and forms, as you would normally and use the API to add values, validate and save values to pages. It's not that much of a magic. And maybe keep trying to make simple forms using the API first to get into it... you know start small, grow big. Try to learn from mistakes and experiments asking in the forums.

Doesn't matter in the main.js or inputfields.js inside the document ready. Speaking of the /site/templates-admin/scripts/main.js Depends if you have a custom admin theme installed already or not. If not and you use default admin theme, you can copy the /wire/templates-admin/ folder to your sites folder and edit away.

Ah now that's the numChildren problem. In that it isn't published or access aware. Means even if all children are unpublished it will return true. There's now a attribute to make it recognize that Not sure what version it was added exactly but maybe this works for you: change all $child->numChildren to $child->numChildren(true) Or if you use older version you can instead replace it with this: count($child->children)

Huh? I didn't say anything? I'm just not sure what Peter is up to with and how he's approach to create front-end forms and for what task really are... as he says he don't wants to use form API. But it really depends what forms are they? There's nothing wrong with using form API PW uses itself in the backend and I'm the one that brought extensive and various form examples (with upload and page editing) in multiple threads about this subject. I've been using it since there's required field options and error messages. http://processwire.com/talk/topic/2089-create-simple-forms-using-api/ and my gist are full of it https://gist.github.com/somatonic

My guess it's that he has a local /site-default/ folder and tries to upload or edit it through it... but it doesn't exist on the server of course.

Yeah it's this LanguageSupportPageNames and is in dev with 0.0.6. Seems to exists in stable as with 0.0.3.

You don't need another type or class just for different validations of a text field, you can hook into the processInput of the inputfield and add your own validation and add error if needed. Rare cases where I need this but it's great and flexible way. There's also filter regex you can add in the field settings for validation but maybe little limited. Maybe some sort of module with common validations methods that can be added or configured along with multilanguage (of course!) error messages would be a nice addition. This could then be added to a field or through a hook.

I included the unframework Flourish once to validate forms and send emails. Since PW now has validation and required options for inputfields I don't need it anymore. I used codeigniter for some years long before PW but haven't since used it or any other framework as I'm very happy with PW.

Ok think I got a way to change the axis on sortable. Problem was that PW only inits the sortable for list greater than 1. So I got an error with the script that it can't set the "option" prior to initialisation. I made it work with: $sortableLists = $(".InputfieldFileList"); $sortableLists.each(function(){ if($(this).children('li').size() > 1) { $(this).sortable( "option", "axis", "none"); } });

If you installed PW, there's no /site-default/ it is only before the install and it will change to /site/.

I just found why grid sorting doesn't work. It's because Ryan added a axis: 'y' to the sortable init to restrict it to vertical sorting.... If I remove that it works with the sorting. This is what I have added to the inputfields.css of the admin theme. ul.InputfieldFileList{ overflow: hidden; } ul.InputfieldFileList li{ width: 32%; margin-right: 1%!important; float: left;} And this added to the inputfields.js of the admin theme $( ".InputfieldFileList" ).sortable( "option", "axis", "" ); So it does work again. Edit: Ok it does not work to set the option afterwards. I had removed the option in the core so it worked and forgot. Looks like it would have to changed in the InputfieldFile.js in the core to remove the axis: 'y'; Just to note that this might look nice, but since the height of a box isn't fix, once you have a image that has a long title the box will get taller and the floating will get screwed. So you would have to give the li a fixed height. Edit: or to avoid long image names to break one could add this ul.InputfieldFileList li .InputfieldFileName{ width: 150px; display: block; overflow: hidden; white-space: nowrap; float: left; margin-right: 1em;}

The width settings is for the field itself and not for things inside a field. Of course it's possible to overwrite the CSS for image field, you can try it using inspector in chrome for example on the fly. Depends how fit you are with CSS, but this would give an idea what to change (container, li's etc). I tried to float them and add a width, but also you'd need to clear float on the wrapper since PW doesn't have any. But the problem then is that the jquery sortable doesn't work nice with such a floated list. You could add a new css file directly to the admin theme (default.php) or inputfields.css, or through a module to autoload and add your css file.

Name is a special property not a field same as other fields, so you need to tell it what language you want. echo $page->localName($user->language); or echo $page->get("name$user->language");

Without further consideration on if what you do is really a good way to go building forms... Every inputfield has a render method to render the field specific markup then added to field wrappers and the form wrapper as used in the admin. It's possible to get the inputfield markup used my PW: $f = $fields->get("somefield")->getInputField($page, null); $f->attr("value",$page->somefield); echo $f->render();

I already edited the title. But found the 1.9 funny so have kept it. Heh

No you dont have to upgrade anything just deinstall and install the other. Remove what you dont need like the published page field if you used that. Then you configure lang segment on home root page settings. And of course you have to enter all page names for the alternative languages. So if your site is already live you might want to copy the titles to the name fields which could be done with a simple script sitewide. And of course you have to adapt your language switch. Youll find more infos in the module thread.

Just to defend again ImageManager... you can select and insert images in wysiwyg as usual.. just browse the pages and select the image. It's mentioned in the description. Also I don't think it's hard or complicated to copy a tag into the body.. and after saving you'll see the image and can threat it as with all image s in tinymce.. for example change the image or resize it in the editor. But I think people are too scared to even try it so it's a little hard without people testing and giving feedback to further develop it.

Images here is a WireArray and not an regular array.

Yeah it says what it does.

You misunderstood what I meant with max width. I meant the width of the larger viewport side. So maybe what you have in mind already. It was just a little confusion what the desired result is with all those screenhots . I'm just curious what you plan to do if ratio/orientation changes or if images have extreme ratios? Meaning to calculate the space of the area and resize the images according to that may result in having a image larger than viewport... Well I once I had such a calculation (can't remember exactly) It should be pretty easy to get a max width or height depending on orientation ratio. $vw = 600; $vh = 600; $spacing = 50; $images = array( array(3000,1800), array(2300,2300), array(1500,2000) ); $ratio = $vw/$vh; if($ratio < 1) { // portrait $max = $vw - $spacing; } elseif($ratio > 1){ // landscape $max = $vh - $spacing; } else { // square $max = $vh - $spacing; } foreach($images as $im) { if($im[0] > $im[1]) { // landscape image echo "w: ". $max . " h: " . round($max/$im[0] * $im[1]) . "<br/>"; } elseif($im[0] < $im[1]) {// portrait echo "w: ". round($max/$im[1] * $im[0]) . " h: " . $max . "<br/>"; } else { // square echo "w: ". $max . " h: " . $max . "<br/>"; } } And this would be a area square calculation and you'll quickly see what I mean. $vw = 800; $vh = 600; $images = array( array(3000,1500), array(2300,2300), array(1500,2000) ); $area = $vw*$vh; echo "area: " . $area . "<br/>"; foreach($images as $im) { $r = sqrt($area/($im[0] * $im[1])); $w = floor($im[0] * $r); $h = floor($im[1] * $r); echo "w: ". $w . " h: " . $h . " (area = " . ($w * $h) . ")<br/>"; }

Well the class you hook on is a little special in that it's extending CommentForm, but since it works for all of us except for you. What PW version do you use and PHP version? Can you try hooking page render? $this->addHookAfter("Page::render", $this, 'copyAverageRating'); Works?

Have you at some point added the autoload true when the module was already installed? There's no bug as far as I know as PW wouldn't work at all with all those hooks used in core.