Martijn Geerts

You've read my mind Adrian, wanted to do the same for a long time...

You can see from the design that it is build by you. I love the consistency of your 'personal' style.

@skaplan, yeah sure ! Looks like a fun project!

A lot of people think they can code all day long, but do they realise they're debugging most of the time. Welcome to the club...

You need to have the Javascript, thats posted on that page to !

Aenean lacinia bibendum nulla sed consectetur. Nullam quis risus eget urna mollis ornare vel eu leo. Cras justo odio, dapibus ac facilisis in, egestas eget quam. {video} Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. $search = '{video}'; $replace = "<iframe width='560' height='315' src='$page->your_field' frameborder='0' allowfullscreen></iframe>"; str_replace($search, $replace, $page->body);

It is possible to swap the template file on runtime so that a page can have multiple template files. Maybe this is sufficient for you. This is possible with the Module FieldtypeSelectFile. You have to check the checkbox "Change Page Template" in the module settings and select the file to render in a page.

Using form when not needed feels so 1999 . The whole thing is quite weird when you know InputfieldForm extends wrapper. I did make a note on GitHub, maybe Ryan or Soma does know how. And about security, I follow kongondo's lead. No problem, definitely not in this case. Thanks guys for the followup.

Actually it didn't, but help is always appreciated

This solves it for now #content .WireTabs a { max-height: 37px; } #content .WireTabs { margin-top: -38px; top: 0; margin-bottom: 0; }

@Kongondo, I do think it has something to do with not getting the height properly for .WireTabs.nav or white-space injection on the javascript side. (What Javascript does when manipulation the dom) I have found a solution (not good) .with CSS for now. Doesn't work for pill tabs // CSS .WireTabs.nav { height: 2.4em; } #content .WireTabs a { height: 2.4em; } And thanks for your answer @LostKobrakai

If I render it with forms, legs sticking out. (post 5) Somehow I can't even correct it with CSS. I leave it for now because I want to continue... Thank you Kongondo for your help !

Always hard continuing scripting when something annoys you...

This way it should be See the the vertical borders of tab Two: (using form) Tabs need additional javascript to render. $(document).ready(function() { $('#content .container').WireTabs({ items: $(".Inputfields li.WireTab"), rememberTabs: true }); });

When I add it to a from, then the tab is overlapping the wrapper. ps: I have used a wrapper because I do not need a form. public function ___execute() { $form = $this->modules->get('InputfieldForm'); $this->modules->get('JqueryWireTabs'); foreach(array('One', 'Two', 'Three') as $number) { $tab = new InputfieldWrapper(); $tab->attr('id', 'tab_' . $number); $tab->attr('title', $number); $tab->attr('class', 'WireTab'); $markup = $this->modules->get('InputfieldMarkup'); $markup->label = $this->_('Label ') . ' ' . $number; $markup->value = "<h2>$number</h2>"; $tab->append($markup); $form->append($tab); } return $form->render(); }

I have rendering issues with JqueryWireTabs. Between the tabs and the wrapper there's 1px of margin or something. Can't figure out what it is. (see image) // js part $(document).ready(function() { $('#content .container').WireTabs({ items: $(".Inputfields li.WireTab"), rememberTabs: true }); }); public function ___execute() { $wrapper = new InputfieldWrapper(); $this->modules->get('JqueryWireTabs'); foreach(array('One', 'Two', 'Three') as $number) { $tab = new InputfieldWrapper(); $tab->attr('id', 'tab_' . $number); $tab->attr('title', $number); $tab->attr('class', 'WireTab'); $markup = $this->modules->get('InputfieldMarkup'); $markup->label = $this->_('Label ') . ' ' . $number; $markup->value = "<h2>$number</h2>"; $tab->append($markup); $wrapper->append($tab); } return $wrapper->render(); } I'm fighting this rendering issue now for quite a while. Could someone point me out what I do wrong.

There must be recent changes I guess, but this one works: oops this one is for delete tab <?php class AdminHelperHooks extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'My Admin Helper Hooks', 'version' => 1, 'singular' => true, 'autoload' => true ); } public function init() { // add hook to the page edit module and the method that creates the wanted fieldset $this->addHookAfter('ProcessPageEdit::buildFormDelete', $this, "removeDelete"); } function removeDelete(HookEvent $event){ // $event->return being the inputfield wrapper $wrapper = $event->return; // set the inputfield wrapper to hidden $wrapper->collapsed = Inputfield::collapsedHidden; // Get the active Object (ProcessPageEdit) $process = $event->object; // Remove the Settings tab with the ID $process->removeTab('ProcessPageEditDelete'); // we're done } } For settings tab <?php class AdminHelperHooks extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'My Admin Helper Hooks', 'version' => 1, 'singular' => true, 'autoload' => true ); } public function init() { // add hook to the page edit module and the method that creates the wanted fieldset $this->addHookAfter('ProcessPageEdit::buildFormSettings', $this, "removeSettings"); } function removeSettings(HookEvent $event){ // $event->return being the inputfield wrapper $wrapper = $event->return; // set the inputfield wrapper to hidden $wrapper->collapsed = Inputfield::collapsedHidden; // Get the active Object (ProcessPageEdit) $process = $event->object; // Remove the Settings tab with the ID $process->removeTab('ProcessPageEditSettings'); // we're done } }

I never liked programs/software translated to Dutch. So personally I wouldn't use the translated ProcessWire. On the other hand, I do think it's good for the ProcessWire project. Could you phone me so we can work something out?

@arjen, does this mean the company you work will 'support' it with time?

Call me old fashioned, but for minor sacrifices as writing a few more Characters I would not give up compatibility.

These are called bugs....

Thats exactly what i said

I have never liked the principle of using ID's that way. And I will never use it this way unless i'm absolute sure that the page can't be deleted or the ID is fixed in the core (homepage / trash / admin etc.). The problem with ID's is that when you delete the page, your ID is gone and your script will break. And a minor thing with ID's is that the ID wil not tell you anything about the page, so you need to comment it. I think it's almost always better to get a page from it context. Context of a page can be the template, the position of the page relative to an other, the amount of parents or kind of children. Or maybe even a combination of those factors. When you program with 'context' your client wil never be able to break your site.

It's not often I have to deal with “external” customers, but my experience is that text is a big bottleneck that is both approval and delivery. ProcessWire is the perfect CONTENT MANAGEMENT system, so I provide them all the tools to edit their content. While developing I use lorem ipsum and for images I use http://lorempixel.com/400/300/. (for example) Waiting for the customer is frustrating for you as developer and customers will blame you when their product take long to develop. I would rather finish their website quick then upload it to a 'private' place. Then the customer can content manage their own website. They are the ones who know best their product.

Officially it isn't allowed to use <nav> as list-item container. Only <ul>, <ol> or <menu> element as parents are allowed for li elements. The last one <menu> I've never seen used in the wild before. The <nav> element I find rather confusing to. I use the nav element mainly as a wrapper element for navigation elements or leave them out if I do not need them for styling. So mainly I use it for wrapping main navigation elements and that is search form input(s) included.