Leaderboard

Whether or not one would benefit a lot of Composer depends a lot on the type of work they do (like @szabesz already pointed out), the workflow they prefer, and a few other factors. I for one haven't seen any reason to really get into using Composer. It's not that I don't like it, mind you – I really do, and I actually wish I had more use for it, but I just don't. I do most of my work with ProcessWire, and most of the time I work on web sites: public-facing sites, intranets, extranets, directories of data, etc. I do custom development for those sites, applications if you will, and in many cases there's some server-side automation / integration involved. ProcessWire does out-of-the-box most of what I need to get that stuff done, I use some third party modules here and there, and PHP itself is a framework with a vast collection tools and extensions built-in. That being said, when I browse the list of the most popular packages on Packagist, I see some projects I've used in the past (using a basic download / git clone + require one file approach) and some that I probably could've used but usually have worked around with a few lines of my own code. Either way, these projects could've saved me a few minutes (or even hours) here and there, had I already been well versed in the Composer workflow. Now that ProcessWire supports Composer, I'm probably going to give it a try and see how it feels, but for the time being my opinion still stands: Composer is by no means something you "have to" use, even if you do so-called "serious development". It's one tool among others, and while some no doubt benefit from it greatly, for some it's of very little help (or potentially even harmful as it can tempt you to rely on a dependency for everything – left-pad, anyone?)

Module: http://modules.processwire.com/modules/ajax-intercooler-js/ Repo: https://bitbucket.org/pwFoo/ajaxintercoolerjs AjaxIntercoolerJS module features integrates IntercoolerJS async CCS ("loadCSS") and JavaScript load / update optional disable async css / js handling for blocks, sidebar, ... Intercooler X-IC response header support support / hook $session->redirect multiple X-IC-Trigger handling multiple X-IC-Script handling Usage Basics It's a autoload module, but you need to enable it inside of your templates, because scripts and dependencies ("JqueryCore") have to be loaded too. You can enable / load it global inside of the TemplateFileHelper controller "_layout.php" $ic->enable(); Some changes are needed to your main template "_layout.tpl". <!-- IntercoolerJS needs a target with ID "pageContent" for (async) page content --> <div id="pageContent"><?=$pageContent?></div> And your navigation links need some IntercoolerJS attributes like that. <a href="..." ic-get-from='/url-to-load' ic-target='#sidebar'>...</a> Your just use and hook MarkupSimpleNavigation. $nav = $modules->get('MarkupSimpleNavigation'); $opts = array( 'show_root' => true, 'item_tpl' => "<a href='{url}' ic-get-from='{url}' ic-target='#pageContent' ic-push-url=true>{title}</a>", 'item_current_tpl' => "<a href='{url}' ic-get-from='{url}' ic-target='#pageContent' ic-push-url=true>{title}</a>", ); // optional modify a specific link to use another target. For example "#sidebar" $nav->addHookAfter('getTagsString', null, function($event) { $link = $event->arguments[1]; if ($link->title == 'sidebar') { $event->return = "<a href='{$link->url}' ic-get-from='{$link->url}' ic-target='#sidebar'>{$link->title} (sidebar)</a>"; } }); // render and set as _layout.tpl template var $layout->set('navigation', $nav->render($opts)); Disable CSS refresh (remove "current" styles and load the new one) The current loaded page css shouldn't removed if the sidebar is updated. So it's possible to disable the asyncHandler inside of the "sidebar" template. $ic->asyncHandler(false); Quick and dirty FrontendUser integration You just need a PW template file like that. $fu = $modules->get('FrontendUser'); $fu->login(); $button = $fu->form->fhSubmitBtn; $button->attr('ic-post-to', $page->url); $button->attr('ic-target', '#pageContent'); if (!empty($_GET['logout'])) { $fu->logout($page->url); } // Workaround until IntercoolerJS 1.0.1 release if ($input->post['ic-trigger-name']) { $input->post[$fu->form->fhSubmitBtn->name] = $input->post['ic-trigger-name']; } $processed = $fu->process($page->url); if ($processed && !$user->isGuest()) { // $processed == false if login failed (not submitted / login successful == true) echo "Hello $user->name!"; echo "<a href='$page->url?logout=1'>Logout</a>"; } else { echo $fu->render(); } X-IC Response Headers /** * Set x-ic-trigger response header * @param array $array One or more events with related data arrays */ public function trigger($array) { $json = json_encode($array); header('x-ic-trigger: ' . $json); } /** * Set x-ic-script response header * @param string $js Valid javaScript code */ public function script($js) { header('X-IC-Script: ' . $js); } /** * Stop current / parent element Intercooler polling */ public function cancelPolling() { header ('x-ic-cancelPolling: true'); } /** * Resume current / parent element Intercooler polling */ public function resumePolling() { header ('x-ic-resumePolling: true'); } /** * Set current / parent element Intercooler polling interval * @param string $interval */ public function setPollInterval($interval) { header ('x-ic-setPollInterval: ' . $interval); } /** * Set x-ic-refresh response header * @param string $pathCsv Comma separated paths to refresh. */ public function refresh($pathCsv) { header('x-ic-refresh: ' . $pathCsv); } /** * Set x-ic-open response header * @param string $url New window / tab address */ public function open($url) { header('x-ic-open: ' . $url); } /** * Set x-ic-redirect response header * @param string $url Redirect destination address */ public function redirect($url) { header('x-ic-redirect: ' .$url); } Wrapper for X-IC-Trigger Add a event trigger with event name ($event) and parameters array ($array). "addTrigger()" method is a wrapper for usage with multiple event triggers. Native method for a single execution is method "trigger()" $ic->addTrigger($event, $array); Wrapper for X-IC-Script String of javascript code for client side execution. "addScript()" method is a wrapper for multiple usage of "script()" method. $ic->addScript($javascript); $session->redirect is hooked! The module hooks $session->redirect() method for ajax calls. It's needed to execute redirects by IntercoolerJS X-IC-Redirect for ajax calls. Used for the FrontendUser integration.

I think short-term mostly the module development will benefit from the composer addition. No need to pull in symfony/console for multiple modules with cli interface, when once would be enough. The new jumplinks module will be built by using the popular nikic/fast-route package. There are lot's of popular packages to support filetypes like excel or pdf (Pages2PDF uses mpdf), which can simply be pulled in by using composer. Version constrains allow each of those dependencies to be independently updated (e.g. security fixes) without the module author necessarily being involved.

I see, however I'm farm from being a full time PHP developer but someone who builds PW and WP sites and not afraid to dive into coding I've already tinkered with Composer and also with frameworks that heavily rely on them but I do not use any of them. I keep an open eye on Composer though, that is why I started this discussion in the first place. My framework of choice is ProcessWire, so as @LostKobrakai pointed out: but let's see what the future holds...

Sorry Steve, that was lazy on my part. Should be all fixed now, but be sure to do a hard reload - there's a JS file update needed. I really should have added JS versioning. PS - In case anyone was wondering, the "Copy plain text" button is great for pasting into a "Spoiler" in this forum.

the wireRenderFile() function won't have access to your custom variables, you would need to do this: $viewBag = array( 'content' => $content, 'summary => '$summary, ); then echo wireRenderFile($page->template->name .'.inc', $viewBag);

This is a good reminder for me. There's not enough time in a week (since I got back in town) and there's plenty of little details I still have to attend to, which is why I thought calling it a soft launch was better. This will definitely be added though. You are completely right here of course. I have updated the blog post to add that as well. I agree with this. Composer is pretty awesome and all, but it's not every day that I have a use for it. The work I do rarely requires anything outside of what is already in the PW core. This is likely common among web developers that build sites in PW or some other system that already provides the majority of what you will need. Sephiroth's comment is true when you step outside of this context though, into the wider development world of PHP. With version 3.0 we're hoping to bring more of that world into PW's audience. So even though most of our current audience likely doesn't use/need Composer for many of the sites they develop, my hope is that will change as more people relying on Composer begin to use ProcessWire. Also depending on the site/app, the PW core/modules can't always accommodate every need, so I expect people will very likely increase their use of Composer when the needs for something more arise.

One idea: if both have the same name (which can happen) it can be clearer that 2 different operations are covered if non default language names are added? renamed basic-page news as news2 renamed basic-page news DE as news2 (maybe a different bg color for the language part)

One more addition: testing with multi-language page name support, I'm seeing that the rename operations affecting only non-default language are not being logged as renames at all. Currently I'm thinking that this should be logged as a separate rename operation, i.e. if you change the name in multiple languages for the same page at once, it would look in the log a bit like this: renamed basic-page what as what-2 renamed basic-page what-in-finnish as what-in-finnish-2 Probably will implement it like that unless someone has a strong opinion on thi

Thanks, guys! I'm just now taking a closer look at these, and there are a few things I'd like to understand first. Regarding undefined indexes: @adrian and @SteveB, it sounds like you were both able to reproduce the undefined index problem. How exactly did you get there? I've been testing this with a multi-language setup and a non-multi-language setup for a while now, and can't seem to figure out the steps to reproduce this. As far as I can tell, this would mean that a page has been renamed or trashed, but there's no information about what the name used to be. Logically thinking that must be something that shouldn't be logged in the first place, or the problem is in the way I'm fetching the previous page name. Do you have any pointers here, what am I missing? Regarding RuntimeMarkup: I'm familiar with RuntimeMarkup, but haven't really used it, so my initial thought is that this doesn't sound quite right. A field should not report itself changed every single page load unless it really changes each page load, in which case logging these changes is the only sensible thing to do. Either way, one definitely shouldn't have to check for specific field types like that. Anyway, I'll take a closer look and see if there's actually a sensible reason why this is happening. Regarding non-working filters: @SteveB: If I'm getting this right, selecting an operation on the Changelog page results in a numeric GET param, such as "operation=3", right? I'm not able to reproduce this either, as the values in the operations dropdown are actual operation names, not numbers. Any pointers for reproducing this one? Thanks again for reporting these issues, and sorry for not being able to reproduce them..

Hmm, something in one of the recent minor revisions is messing up bootstrap styles of some buttons on a form page of mine - not sure which revision introduced it though. I'm on 3.2.8 now, but it happened with the previous version too. Inspecting in the browser shows tracy using a style... #tracy-debug input[type="submit"], .btn {...} ...which is stomping on bootstrap's own button style.

Module: http://modules.processwire.com/modules/template-file-helper/ Repo: https://bitbucket.org/pwFoo/templatefilehelper/overview TemplateFileHelper module features add global controller and template to current page by a Page::render hook Manage global ($layout) and current page ($view) styles and scripts with a $config->scripts / $config->styles context mapping. So $config->styles / $config->scripts works fine too load sub-templates with a controller file an array of data to fill template variables just an html template Ajax page load in mind Usage Global layout A global controller / template is added by a Page::render hook. /site/templates/_layout.php // controller /site/templates/_layout.tpl // view / html template Example _layout.tpl <!doctype html> <html lang="de"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>TemplateFileHelper Processwire</title> <?=$styles?> <?=$scripts?> </head> <body> <div id="nav"><?=$navigation?></div> <div id="pageContent"><?=$pageContent?></div> </body> </html> Example _layout.php // MarkupSimpleNavigation $nav = $modules->get('MarkupSimpleNavigation'); $layout->set('navigation', $nav->render($opts)); // Global and current page styles $styles = ''; foreach ($layout->styles as $style) { $styles .= "<link href='{$style}' rel='stylesheet' class='global'>"; } foreach ($view->styles as $style) { $styles .= "<link href='{$style}' rel='stylesheet' class='current'>"; } $layout->set('styles', $styles); // Global and current page scripts $scripts = ''; foreach ($layout->scripts as $script) { $scripts .= "<script src='{$script}' type='text/javascript' class='global'></script>"; } foreach ($view->scripts as $script) { $scripts .= "<script src='{$script}' type='text/javascript' class='current'></script>"; } $layout->set('scripts', $scripts); Current page The PW template of current page will rendered inside the global view by Page::render hook. /site/templates/basic-page.php // controller /site/templates/basic-page.tpl // view / html template Example basic-page.tpl <div><?=$contentHome?></div> Example basic-page.php $view->set('contentHome', 'Simple output...'); echo $view->render(); Output (for example to debug) is possible too. echo "My PW template file output..."; $view->set('contentHome', 'Simple output...'); echo $view->render(); Sub-templates It's possible to use sub-templates / chunks inside of a PW template / controller. Sub-template with controller / view files $part = $view->load('parts/test1', 'parts/test1'); // relative to /site/templates (view = .tpl, controller = .php $part = $view->load('parts/test1', true); // same as above. "True" instead of write identical path / file twice $part = $view->load('parts/test1', 'parts/test1_controller'); // view "parts/test1.tpl", controller "parts/test1_controller.php" Sub-template with array data $part = $view->load('chunks/test1', array('variable1' => "value1", 'variable2' => 'value2')); Sub-template just a html chunk $part = $view->load('chunks/test1'); // view file /site/templates/chunks/test1.tpl PW template file as view Because direct output inside a PW template file is possible it also works without a view. Example: PW template without viewTested with the FrontendUser module quick and dirty... $fu = $modules->get('FrontendUser'); $fu->login(); $button = $fu->form->fhSubmitBtn; if (!empty($_GET['logout'])) { $fu->logout($page->url); } $processed = $fu->process($page->url); if ($processed && !$user->isGuest()) { // $processed == false if login failed (not submitted / login successful == true) echo "Hello $user->name!"; echo "<a href='$page->url?logout=1'>Logout</a>"; } else { echo $fu->render(); } Scripts / Styles context The module itself takes care about the global (inside _layout.php) and "current" (inside PW template file). Just use PW $config to set styles and scripts. $config->scripts->add('...'); $config->styles->add('...'); You can also force the context by use the additional global api variables. $layout->scripts->add('...'); // global context $layout->styles->add('...'); // global context $view->scripts->add('...'); // current page context $view->styles->add('...'); // current page context

No problem at all I was never quite sure if that was the best approach to overriding that open/collapsed setting, but thought in general that once you have saved a page once, you'll probably want it open while you are still working on it and haven't navigated away. I am open to suggestions though. Glad the name change is working as expected - I really like that option (which is of course why I also built: http://modules.processwire.com/modules/page-rename-options/), especially during development - I think I would go crazy without it Btw, I just committed some updates to BCE - I recently changed the way CSV files are parsed and I just realized I introduced a bug when the field names were in the first row. Anyway, you should update when you get a chance.

You are right, I had ?s=1 in the url, didn't notice... And name change is working of course. Thank you and sorry for taking your time.

True you do have a point, Composer is just another means

At the moment I think about a rewrite and code cleanup, but have no time to do it. The return value of process() method could cause a strange behavior because it returns "true" also if the form wasn't submitted because of the "return $this" for chaining public function process($redirect) { if ($this->form->fhProcessForm()) { switch ($this->action) { case 'Login': $result = $this->auth($this->userObj); break; case 'Register': $result = $this->save($this->userObj); break; } if ($result === true) { $this->session->redirect($redirect, false); // User sucessfully registered } else { $this->form->fhSubmitBtn->error($result); // Save user failed? } } return $this; }

v069 was uploaded with a quick fix that caused js errors when hovering pagelist items if FieldAndTemplateEditLinks was enabled (thanks @gmclelland).

Done!

Could the modules list in the Versions List be in alphabetical order? It's hard to find a given module if it's not.

Yeah, let's do it - I'll look into it more later. For now, here is what the latest info looks like when pasted into Github: Thanks again @horst and @szabesz for your feedback and suggestions.

I set all my templates up initially as "no-file" templates, using the Create a new template without a file... option, then go to the Files tab and enter "main" as the Alternate Template Filename. This points all my "logical" templates to a single "physical" template at /site/templates/main.php. From there, you can include the actual template any number of ways, the simplest being something like this: echo wireRenderFile('./views/'.$page->template->name.'/'.$page->template->name.'.inc'); The main reason I do it this way is that I also use AllInOneMinify for asset management, and I have it set up to automatically include an associated javascript and/or LESS file for each template if present, so for the "home" template, instead of having home.php loose in the templates directory, I have: /site/templates/views/home/ ...which contains: home.inc home.js home.less

I'm not sure, but isn't this more what people might be looking for when creating a new project: composer create-project processwire/processwire Otherwise processwire will be pulled inside the vendor folder, where it's from questionable use besides for being bootstrapped into other applications.

A PageArray can only hold one instance of each page, so yeah it does, but it's not really explicit that way (and won't work as expected with my paginator)

Regarding the video tutorials, what I have completed so far is just a 50-video series of straight-up comparing WP to PW feature-by-feature, so I don't think you'd personally benefit from that since you're already a ProcessWire guru. I will release them however there's some further editing I need to do as well as making it part of an overall content marketing strategy. I haven't had time for that yet, but at least the really hard part of recording the videos is done. In regards to something like a full training series, the idea is still in my head (on paper too), however I don't have any plans yet to go full force on that as I'm focused on other ventures.

I have made a module for you (all). I have had allready a routine that iterates through all pages and clears all imagevariations. But this only can be safely used if you have not used images in RTE's from the same page. If you have done so, those cannot be identified and gets deleted too. So please double check that you do not use Pageimages in your RTE fields before running this module. To run it you have to install it, go to its configscreen and check the box to run it. Also there is a second box, always checked by default, that let the script run in testmode. In testmode it doesn't delete the variations but list all found pages and the images count. So, if you really want to delte all ImageVariations sitewide, tipp the box to run the script, untipp the box to run it in testmode and press the submit button. PageimageRemoveVariations.zip EDIT: better use this enhanced module version from @tpr, with configuration for excluding imagefields: enhanced version!

This is the way to create template and fields with API: // new fieldgroup $fg = new Fieldgroup(); $fg->name = 'new-template'; $fg->add($this->fields->get('title')); // needed title field $fg->save(); // new template using the fieldgroup $t = new Template(); $t->name = 'new-template'; $t->fieldgroup = $fg; // add the fieldgroup $t->noChildren = 1; $t->save(); // add one more field, attributes depending on fieldtype $f = new Field(); // create new field object $f->type = $this->modules->get("FieldtypeFloat"); // get a field type $f->name = 'price'; $f->precision = 2; $f->label = 'Price of the product'; $f->save(); // save the field $fg->add($f); // add field to fieldgroup $fg->save(); // save fieldgroup All pretty much standard OO one can figure out looking at core and PW modules. But not someone unexperienced would figure out by themself. I think at some point we need to cover these in a documentation.

Soma's suggestion is correct–thanks Soma! Another way to do the same thing: if($session->authenticate($user, $old_pass)) { $user->pass = $new_pass; }