Soma

Yes that's correct 'collapsed' does collapse all to the top level, except for those you'r on or in. It's only opening branches you're on. 'max_levels' does limit the levels rendered from the top level. So you example kinda illustrates this correct. Company - Products -- product A -- product B (= active) -- product C - Downloads / Manuals - News Also this Company - Products (= active) -- product A -- product B -- product C - Downloads / Manuals - News Or like this Company - Products -- product A -- product B -- product C (= active) -- product C1 -- product C2 - Downloads / Manuals - News I don't know why it's not working for you, but I use it all the time, and I think quite a lot of others too.

I would try to work as much with what PW gives you and adapt the CSS, I think there's even an responsive theme in Formbuilder... but could be wrong. If you really need to adapt the HTML markup and CSS classes used by the InputfieldWrapper you can. As in this thread already mentioned: from the InputfieldWrapper.php core class /** * Markup used during the render() method - customize with InputfieldWrapper::setMarkup($array) * */ static protected $defaultMarkup = array( 'list' => "\n<ul {attrs}>\n{out}\n</ul>\n", 'item' => "\n\t<li {attrs}>\n{out}\n\t</li>", 'item_label' => "\n\t\t<label class='ui-widget-header' for='{for}'>{out}</label>", 'item_content' => "\n\t\t<div class='ui-widget-content'>\n{out}\n\t\t</div>", 'item_error' => "\n<p><span class='ui-state-error'>{out}</span></p>", 'item_description' => "\n<p class='description'>{out}</p>", 'item_head' => "\n<h2>{out}</h2>", 'item_notes' => "\n<p class='notes'>{out}</p>", ); Using the form inputfield object you could simply $form->setMarkup(array('list' => "<div {attrs}>{out}</div>")); The same exists for the classes used. But at the end I don't know if messing with it helps. Rendering form fields: As I said earlier, it's always possible to render a certain field explicit. echo $form->get("name")->render(); You could even use the form building method in this thread starting post and render fields where you like. There'll be still markup being outputed depending on the inputfieldtype, but maybe allows for more flexibility. $showform = true; $form = $modules->get("InputfieldForm"); $field = $modules->get("InputfieldEmail"); $field->attr("name", "email"); $field->label = "Email"; $form->append($field); if($input->post->submit) $form->processInput($input->post); if($form->getErrors()) { $showform = true; } else { $showform = false; // form valid, do something } if($showform) { echo "<form action='#' method='post'>"; echo "<div class='row'>" . $form->get('email')->render() . "<div>"; ... } Anything is possible, just use what you need. Think it's almost same as you would work with fields or pages.

Read my previous post onjegolders.

Only with the default options it will render all levels. max_levels is there to limit this to as many levels as you like/need.

This error would indicate there's a syntax error missing closures or something. But since there's no such fault in PW and in ProcessPageSearch module, looks a bit like you're files weren't uploaded completely or something got corrupt.

Setting the password or any value directly through API won't give you any validations. This is a functionality the inputfield is usually doing and processed in a certain way (input). If used on non interactive level the API doesn't restrict you from doing things you can't do or aren't allowed in the admin. So you ultimately you have to take care of those thing when using the API directly. So while this works: $u = new User(); $u->name = "test"; $u->of(false); $u->pass = "1234"; $u->save(); "1234" isn't a valid password if PW's password inputfield would validate it, but it's correctly saved and works. Just not recommended to code public sign up form like this. So you have to take care and add some checks to make sure its min-max length is ok and also that there's some at least 1 number and letter. If you're doing it manually and want to use the validation of the password field in PW you could use InputfieldPassword. // "_pass" = the confirm password / actually two inputs $p = new WireInputData(array("pass" => "1234", "_pass" => "1234")); $inputfield_pass = $modules->get("InputfieldPassword"); // load the inputfield module $inputfield_pass->attr("name","pass"); // set the name $inputfield_pass->processInput($p); // process and validate the field // if any errors found if($inputfield_pass->getErrors()){ print_r($inputfield_pass->getErrors(true)); } // or if coming from a form (POST) with the field names already "pass" and "_pass" $inputfield_pass = $modules->get("InputfieldPassword"); $inputfield_pass->attr("name","pass"); $inputfield_pass->processInput($input->post); // process and validate the field // if any errors found if($inputfield_pass->getErrors()){ ... } After all if you're setting a Password directly manually with the API you don't need validation, you are directly responsible to make the password strong.

Not sure I can follow. But yesno, if you use form inputfield then thats what you usually want to use as a whole. On the other hand you can render any inputfield individually but you have to do a lot more work and maybe manually creating the form would be also a good alternative. Just saying. So why?

should be // create a text input $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr('id+name','name'); $field->required = 1; $field->attr("class" , $field->attr("class") . " myclass"); $form->append($field); // append the field to the form required also adds a class... Happy experimenting.

This will overwrite also existing classes. If you want them to stay $field->attr("class" , $field->attr("class") . "myclass");

$field->attr("class" , "myclass");

Try clearing the sessions and caches in assets folder. If theres no sessions folder, create one. Enable debug mode in config.php. Create new password like martijn explains.

The full page gets displayed for this kind of hook cause it's not that you hook into page view or render.. so it was working all the time. I wouldnt know why not. Anyway now you know for the next time

You can check if a page is selected with $page->pagefieldmultiple->has($somepage)

Possible that you need to set both, also the repeaterFields. But have no idea.

I'm not sure about repeaters API to create a new fields and repeater. repeaterFields doesn't seem really the way to add fields. This is only used on the field config UI to add and remove fields. So it exists but it's processed through a POST. Repeaters use a template/fieldgroup where the fields are added. So a way to add fields I found by trying is after saving the repeater you get the template used by this repeater with the prefix "repeater" and the fieldname $t = $fieldgroups->get("repeater_quotes"); $t->add("title"); $t->save();

What is this? $f->repeaterFields = $repeaterFields; Where does $repeaterFields come from? Also shouldn't it be something like: $f->repeaterFields->add($field);

You don't need to sanitize a password at all, never. Not even with $sanitizer->text(). And a password 1234 isn't valid.

Hello Ovi Thanks for the info. I could connect and checked it out. I haven't done anything and it works. I only clicked "Check for new modules" once. The hook is getting executed and the output is shown in the review box after I submit the comment. Not sure what's about it, maybe you didn't look close enough but it's working as it should. I tested on this product /adaptasun-sea-and-tropics-spf-30/. Now I first looked also at what modules are installed, and the only strange thing is that you have 2 FieldtypeComments module, the one in core and one by Apeisa in site/modules ... ? Can they coexist like this? Well if it works, but I'm not sure if it would cause troubles or isn't needed. At least the core one can be deinstalled? Well so far, happy hacking.

As Ryan said, Page fields either can be multiple or single. multiple = PageArray (array) single = Page (value) It doesn't matter how many values are stored. PageArray will always be PageArray even if it has only 1 entry. multiple = [page1,page2,page3] multiple = [page3] single = page4 So checking for count(PageArray) > 1 will not produce expected results. Possible solutions I gave you in your other thread here http://processwire.com/talk/topic/3915-api-syntax-to-edit-field-value-in-form-with-pw-settings-and-attributes/?p=38943

You hook after render. So the inputfield is already rendered. You would need to add also a hook before render to modify it.

Simplest is to move a copy of TinyMCE to your site modules folder and rename to something else MyTinyMCE on all code. Then you can leave out the pwimage plugin.

No problem. I fixed the callback issue now with: $('.section:not("#index") h3').bind('click', function(){ parent = $(this).parent('.cat'); if( parent.find('.descr:visible').length > 0 ) { parent.find('.descr').slideUp(animated ? speed : 0).promise().done(function(){ $container.isotope('reLayout'); }); } else { parent.find('.descr').slideDown(animated ? speed : 0).promise().done(function(){ $container.isotope('reLayout'); }); } });

Ok I see now the problem is that for every description slideUp there's a callback call to relayout. When it's enough to call it once after all have completed. I'll fix this. Thanks for finding it.

Sorry I missed that somehow. But it doesn't work, it messes up the layout even more! As I said it's there for a reason to relayout ispotope after the animation is done. It doesn't happend when animation is disabled but when it's on. So there would have to be a separate if to only do it that way when animated is enabled.