pwFoo

Two workarounds. Modify the template item_tpl: $opts = array( //'item_tpl' => "<a href='{url}' ic-get-from='{url}' ic-target='#pageContent' ic-push-url=true>{title}</a>", ); Or hook MarkupSimpleNavigation::getTagsString to replace the string public function hook_msn_item_tpl($event) { $link = $event->arguments[1]; $event->return = "<a href='{$link->url}' ic-get-from='{$link->url}' ic-target='#pageContent' ic-push-url=true>{$link->title}</a>"; } Modify item_tpl replace the default template and have to be done manually. The hook replaces the hole string and also user configuration too.

Hi @Soma, I searching for an easy way to hook your module and add additional html attributes to the link elements (like "data-*"). Any suggestion how just to insert a custom string? Hook would be great. As option (changed template) would be ok too, but hook would be prefered. Maybe you could add a customAttributes option to insert a custom string? <!-- see the placed variable --> <a href="#" class="dropdown-toggle" {$customAttributes}>' . $title . ' <b class="caret"></b></a> <!-- examples --> <a href="#" class="dropdown-toggle" data-toggle="dropdown">' . $title . ' <b class="caret"></b></a> <!-- or second one... --> <a href="#" class="dropdown-toggle" data-toggle="dropdown" data-mydata="another value">' . $title . ' <b class="caret"></b></a> *UPDATE* Same question as above, but another idea / goal *g* Also an ajax / intercooler example... String I need to inject to the link element. <a href="/test/" ic-get-from="/test/" ic-target="#pageContent" ic-push-url=true>Test</a> Custom string to insert: [...] ic-get-from="{$page->url}" ic-target="{$target}" ic-push-url=true [...]

Updated TemplateFileHelper Repo: https://bitbucket.org/pwFoo/templatefilehelper/src/ Created a first initial commit AjaxIntercoolerJS https://bitbucket.org/pwFoo/ajaxintercoolerjs/src Both dev / unstable!!!

Hi, try this. $person = $users->find('instrument=' . $instr); or $person = $users->find("instrument=$instr"); // or $person = $users->find("instrument={$instr}"); Variables inside single quote is just text / string. With double quotes php parses variables.

And it could be difficult to attach styles and scripts loaded by PW modules (like "JqueryCore") to global or current page scripts / styles... $config->scripts / $config->styles isn't hookable (FienameArray helper class) and I don't know how to detect the automatic loaded styles and scripts. Any suggestions how to detect automatic loaded styles and scripts? *UPDATE* I think I have a simple solution... Move $config->scripts to the right context... // Define as current page $config->scripts = $view->scripts; // Change to global before take care about the global layout $config->scripts = $layout->scripts; All Scripts / styles manually and automatically (PW modules like Inputfields, JqueryCore, ...) loaded are assigned to the needed context.

After some changes (removed "echo $view->render()" output from PW template file) it works like TemplateEngineFactory module from @Wanze. I think about abandon my TemplateFileHelper draft and switch to the existing (and maintained?) module. But I have to think about the script / style handling to be compatible to the planned IntercoolerJS module (global and custom page scripts / styles). TemplateFileHelper module would handle styles / scripts by TemplateFile instance ($layout ==> global, $view ==> current page ). So IntercooolerJS module is able to remove / replace "current page" scripts and styles to prevent side effects between ajax loaded pages. So I have to decide if TemplateFile calls like setFilename() and render() should be written to the PW template file (with my module draft) or handled by the module (hook Page::render, maybe switch to TemplateÉngineFactory). If pw template output is replaced by the rendered view maybe debugging could be difficult because output won't visible! It feels like more "control" if debugging output is visible and the controller includes the "echo $view->render()" call

I pushed an initial (testing) version of TemplateFileHelper to bitbucket. https://bitbucket.org/pwFoo/templatefilehelper/src/ The autoload module extends TemplateFile instances with API vars $layout and $view $layout -> global layout instance of TemplateFile to set layout placeholders ($layout->set(...) or global scripts / styles. $view -> current page instance of TemplateFile to set the current page placeholders and current page scripts / styles. load() method Load a template / view with additional controller (php) file as subTemplate. Returns a TemplateFile object to render / output Each sub-template controller have access to API Vars and $subTemplate (current TemplateFile instance, $subTemplate->set('placeholder', 'My value...')). Load site/templates/chunks/test1.php controller and site/templates/chunks/test1.tpl view: $part = $view->load('chunks/test1'); echo $part->render(); chunks/test1 example <?php // chunks/test1.php - controller $subTemplate->set('var1', "Subtemplate variable output..."); <!-- chunks/test1.tpl - view --> <div><?=$var1?></div> scripts / styles properties FilenameArray like $config->styles | scripts. It should help to organize scripts / styles with ajax in mind (global / current page only). // current page script $view->scripts->add('js-file.js'); // global / layout script $layout->scripts->add('js-file.js'); You have to handle the output yourself by two foreach loops inside your _layout.php / _layout.tpl files (non ajax calls scripts and styles should be in layout head section). foreach ($layout->scripts as $globalScript) { ... } foreach ($view->scripts as $currentPageScript) { ... } IntercoolerJS module will take care about async / ajax handling of (custom page) scripts and styles. hook Page::render hook after page render to load and add the global layout. The current page template (PW template file == controller) just handle the currents page code / view. Global layout / controller / view is moved to separate files (default: _layout.php controller and _layout.tpl view). Just use $layout->set(...) to fill the _layout.tpl placeholder variables inside the _layout.php controller file. configurable module Some settings are available... Global layout (view + controller) file name (default: "_layout") Current page content variable (used inside of the _layout.tpl view to output current page content, default: "currentPageContent") View file extension (default: ".tpl") Controller file extension (default: ".php") It will be a dependency of the planned IntercoolerJS module which adds ajax page calls, async scripts / styles handling (current page scripts and styles...) and need a defined template handling to work...

Also take a look at IntercoolerJS Response Headers. x-ic-redirect header('x-ic-redirect: http://www.google.de'); Redirect to url at client side. Also addHookBefore Session::redirect works fine! So a $session->redirect during ajax page call won't be ignored and executed at client side by IntercoolerJS x-ic-open header('x-ic-open: http://www.google.de'); Open a new window with given URL. x-ic-script header('x-ic-script: alert("Just a test..."); alert("and again...")'); Execute javascript code. x-ic-trigger $data = array('myEvent' => array('key1' => 'value1', 'key2' => array('key21' => 'value21'))); $json = json_encode($data); header("x-ic-trigger: $json"); Transfer json to client and trigger an event. $('body').on('myEvent', function (event, data) { alert(data['key1']); });

@hansv Thanks for feedback about the reason! I'm happy you solved the problem It just use the power of Processwire API and hooks

At the moment I write the needed javascript code to extract / execute the transfered json code and remove the temp. dom elem. The code take care about async script file load with browser caching enabled (jQuery ajax() method) style file (un-)load unload because of css side effects with different pages and css styles prevent css file to be loaded twice or multiple times browser caching enabled (default, nothing to do ;)) inject / replace inline styles code inject inline scripts code It works, but I don't know about existing side effects... $( document ).ready(function() { Intercooler.ready(function (elt) { var pwJsonTransfer = '#pwJsonTransfer' var ProcessWire = JSON.parse($(pwJsonTransfer, elt).text()); // get json information from response $(pwJsonTransfer).remove(); // remove temp json transport element from dom // load css files if not existing in the DOM $(ProcessWire.styles).each(function () { if ($('link[href="' + this + '"]').length < 1) { loadCSS(this); } }); // Remove "old" async loaded stylesheets because it could break the current page $('body').children('link').each(function () { if ($.inArray(this.href, ProcessWire.styles) == -1) { $(this).remove(); // remove unused stylesheet (not in the current css array) } }); // load js files if not existing in the DOM $(ProcessWire.scripts).each(function () { if ($('script[src="' + this + '"]').length < 1) { $.ajax({ url: this, dataType: 'script', cache: true // to prevent multiple file download }); } }); // inline custom styles of current page if (ProcessWire.inlineStyles === null) { $('.pwAsyncCustomCSS').remove(); // no custom css, remove element } else if ($('.pwAsyncCustomCSS').length > 0) { var inlineStyles = $('.asyncCSS'); // reuse existing element inlineStyles.innerHTML = ProcessWire.inlineStyles; } else { // element not exists, create a new one var inlineStyles = document.createElement('style'); $(inlineStyles).addClass('pwAsyncCustomCSS'); $('body').append(inlineStyles); inlineStyles.innerHTML = ProcessWire.inlineStyles; } // append inline scripts var inlineScripts = document.createElement('script'); inlineScripts.innerHTML = ProcessWire.inlineScripts; inlineScripts.type = 'text/javascript'; $('body').append(inlineScripts); }); }); I think I'll create and upload the two modules TemplateFileHelper and IntercoolerJS soon... but dev / unstable!!!

That sounds like a problem with your installation or missing module. $result would be (exactly) true if a new user is registered. /** * Save the temp User object * @param User $user Temp User object to save * @return boolean Sucessful (true) saved or not (false) */ protected function ___save($user) { if (empty($user->name) || empty($user->email) || $user->pass->hash == '') { return $this->_('Register process unexpected failed!'); } if ($user->save()) { return true; } return $this->_('User registration failed!'); } And the save() method will prevent duplicates. I don't think the loop is generated by the module. Should be template code like the prevent redirection loops example. Do you redirect to the current page or is there a htaccess rewrite? Redirect to login page? ... Anyone else have such problems with the module? Additional examples could be helping.

Hi, you should execute the login() method one time. In your code it's called twice. If the login was successful you will redirected by the process() method to the destination. It looks like your $fu->process(...) call is executed every time. Could you add some debugging output and break the execution of the template file with the php exit? So you should see your debugging information and debug your code.

I split it up into two modules. TemplateFileHelper Inspired by Template Engine Factory and Wire Render Pattern. A simple module which hooks Page::Render and adds a global controller / template around the current loaded page if it isn't an admin page or an ajax call. It also takes care about css / js (files, "inline" and "$config->js()") and adds the method "load" to the TemplateFile class (which loads an template with an additional controller file). IntercoolerJS Depends on TemplateFileHelper (page template is current page only, global layout, it defines how to use / handle PW template files to be compatible to my IntercoolerJS module) and loads jQuery and intercoolerjs. I try to implement async js / css load (current page scripts and styles added inside a DIV and moved by JS code). I try to get it work with FormHelper module, but don't know if it would work with the PW inputfields.

I also did some tests. Instead of the form button name you will get $input->post['ic-trigger-name']. Tested with FormHelper and this code snippet to get form process work. if ($input->post['ic-trigger-name']) { $input->post[$form->fhSubmitBtn->name] = $input->post['ic-trigger-name']; } Because FormHelper module checks form state by button name attribute.

Will you redirected back the (frontend) page after backend edit and save?

I had a similar problem in the past. Upload finished, but the image wasn't uploaded / saved. It was php-mbstring related, which I forgot to install... Your problem looks different (mbstring is listed as enabled), but maybe it's also php module (json, ...) related too? Did you check all the logs (apache / php and PW logs)?

Nice New plugins https://caddyserver.com/docs/minify https://caddyserver.com/docs/filemanager

Hi @bernhard That's dependent on the two options above. I planned to build a intercooler-js module, but it's so simple to use... No need to build a wrapper around it to implement it as PW module... At the moment the module is a PW TemplateFile helper with additional css / js handling simple TemplateFile load method it hooks Page::render to add the main layout / template if it isn't an ajax call (because it should work with intercooler ajax calls ...) So maybe I build just a pw template helper (PW TemplateFile class helper, handle js / css, ...) module instead of intercooler.

Intercooler have great features which are simple to use. Just some html attributes to prompt the user, initiate a ajax request, add / remove css class, ... I don't know if the features should be limited by a "wrapper module"... What do you think? Wrap features into a object like PW fields (example with some field attributes...) $icField = new icField(); $icField->method = "GET"; $icField->src = "/path/to/file.php"; $icField->pushUrl = true; $icField->content = "Initial content"; $icField->template = "<div>|</div>"; echo $icField->render(); Output... <div ic-get-from="/path/to/file.php" ic-push-url=true>Initial content...</div> User should read the Intercooler documentation and just write the attributes to the template as shown above <div ic-get-from="/path/to/file.php" ic-push-url=true>Initial content...</div>

Maybe hre are some ideas / opinions about how to handle the ic-* attributes inside a PW module... Should I wrap the attributes into module methods like that? $ic->post(url) $ic->delete(url) ... But you need to output it as html attribute... <a href="<?=$url?>" <?=$ic->post($url)?>>LINK</a> Methods could also combine some intercooler options. <a href="URL" <?=$ic->post($url, $target, $history_Support)?>>LINK</a> But it need to be outputed inside an HTML element... Alternative could be ic-* attributes inside the templates as plain text... Any hints or ideas?

@Soma I need to add custom html attributes. Is there a way to add custom attributes like data-* without replace the links template? P.S. I tested MSN with PW devns. Should be compatible. If there are no issues you could add support up to 3.0?

@LostKobrakai Thanks, I'll remove the exit. PW templates output just the page specific html and layout is added by hook Page:render if needed. So exit isn't needed anymore

@teppo Is it possible to use it inside my module too?

Thanks! The way I was searching for! Just used exit as bad alternative for my first test.

Example caddyfile :80 { # document root root /home/httpd/public_html # fastcgi / <PHP-HOST>:<PHP-PORT> php fastcgi / 127.0.0.1:9000 php # converted htaccess rewrites internal /forbidden rewrite { r /\. to /forbidden } rewrite { r /(COPYRIGHT|LICENSE|README|htaccess)\.txt to /forbidden } rewrite { r ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) to /forbidden } rewrite { r ^/site(-[^/]+)?/install to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php to /forbidden } rewrite { r ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) to /forbidden } # GLOBAL rewrite { to {path} {path}/ /index.php?it={path}&{query} } log logs/access.log { rotate { size 50 age 7 keep 5 } } errors { log logs/error.log { size 50 age 7 keep 5 } } } You need php-fpm installed to pass php requests to. Log file path is relative to workdir (/home/httpd/). Used with Caddy 0.8.3 and 0.9beta2 behind a caddy reverseproxy.