Soma

Aah, so you want to use them for templates in the admin? How about: $opener = new Field(); $opener->type = new FieldtypeFieldsetOpen(); $opener->name = "myfieldset"; $opener->label = "Open fieldset"; $opener->save(); $closer = new Field(); $closer->type = new FieldtypeFieldsetClose(); $closer->name = "myfieldset" . FieldtypeFieldsetOpen::fieldsetCloseIdentifier; $closer->label = "Close an open fieldset"; $closer->save(); $tpl = $templates->get("custom"); $tpl->fieldgroup->add($opener); $tpl->fieldgroup->add($fields->get("body")); $tpl->fieldgroup->add($fields->get("counter")); $tpl->fieldgroup->add($closer); $tpl->fieldgroup->save();

There's nothing special about it you just use InputfieldFieldset and append the inputfields you want in there. Then create a new fieldset and add the fields you want there. Then add the two fieldsets to the inputfieldwrapper.

ModulesManager doesn't have tabs. Well I guess you already know you use getModuleConfigInputfields(array $data){ ... } to add configuration inputfields (not fields!) And you need to add the ConfigurableModule to the implements list (implements Module, ConfigurableModule). Now you can create a new InputfieldWrapper and add Inputfields to it. static public function getModuleConfigInputfields(array $data) { // if you have a static $defaults array for defaults you can merge them with saved ones in $data $data = array_merge(self::$defaults, $data); $fields = new InputfieldWrapper(); ... return $fields; } From there it's pretty easy. You can use all inputfield modules for inputs. It's much like creating a front-end form using API. Know my famous thread? Those inputfields are not bound to the fieldtype, like when used in the admin on pages. So the InputfieldSelect is a simple select module you can fill in options as you like. They're also used in FormBuilder. Ryan has even adapted some a little to support pure interactive inputs better. When used on a page (fields) they're actually a mix of the fieldtype and the inputfield and they depend on each other. Fieldtypes are more used to sanitize and save to db, wakup or sleep values etc, while inputfields kinda serve as an plain interface seen by the user, thus having a render() method. Some special Inputfields are more bound to functionality of other modules like "process" modules, but only remember InputfieldPageListSelect. From there it's just generaly PW API coding. So this would look like this to add a multiple ASM select static public function getModuleConfigInputfields(array $data) { $data = array_merge(self::$defaults, $data); $fieldwrapper = new InputfieldWrapper(); $modules = wire("modules"); $field = $modules->get('InputfieldAsmSelect'); $field->attr('name', 'mymodules'); $field->attr('value', $data['mymodules']); $field->label = 'Select modules.'; foreach($modules as $m) { // loop all installed modules if(strpos("$m->name","Process") === 0) $field->addOption("$m", "$m->className"); } $fieldwrapper->append($field); return $fieldwrapper; }

Yeah it's possible.

It would be a BIG security issue if you could. Nothing strange here, as in all programming languages... But then I also dont see the benfit of doing this. You could with eval() though but not recommended. You could just echo the url there into the string in the first place and pass that after to template.

Ah took me half hour to see whats up. Yeah you cant put php in a string like that and give it to a template to render and think the php gets parsed.

Try adding curley bracket to the code in question. <?={....}?> If it's more than just a var.

The more simpler and direct way for a custom select would be: $sel = $modules->get("InputfieldSelect"); $sel->attr("name", "cms"); $sel->addOptions(array( 'pw' => 'ProcessWire', 'joomla' => 'Joomla!', 'wp' => 'Wordpress' )); // setting the value will select the option, here with coming either from post or the default $sel->attr("value", $input->post->cms ? $input->post->cms : 'pw'); echo $sel->render();

My bet would be that you changed the page field settings from multiple to single and vis versa... however this can give unexpected results as it doesn't remove values already saved values when switched from a multiple to a single. So be careful. As for when using a page field single select, you already have the page object and not a page array. So the selected page would be simply the field itself. echo $page->channel->title // title of selected page A method to check for select page seems redundant and not necessary, as with multiple (page array) you already have has(). I don't see any benefit to add isSelected().

Split the words and search separate with %.

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();