Leaderboard

Hi guys, so since I moved to Processwire, it has been my default go-to CMF/CMS for my website and client applications, apparently my previous job took a toll on me, and made me have less time, but now finally had the chance to change my website to something I always had in mind. I decided to go with something minimal, as I tend to enjoy writing, so wanted a website to have more text than graphics and I think I whipped up something clean. Currently I still have more to do, but this is my current website, the main purpose to have a content driven website where I will be writing tutorials , articles more and hopefully technical notes. Please let me know your honest opinion. PS: I am more of a coder than a designer but i think this old dog still pulled it off https://okeowoaderemi.com/

This latest version on the dev branch includes a few additions, optimizations and fixes. I'm only in the office for a brief time today, so I'll plan to cover these in more detail hopefully in next week's blog post (along with next week's updates), but here's a preview. There's a lot of improvements to the "Overrides" tab that you see when editing a field (Setup > Fields > Edit). These are the field settings in the contexts of different templates. In 3.0.144, you now get a list of all field settings that you want to allow to be customized per-template. In previous versions, you only saw this option if you were in $config->advanced mode. It's still a YMMV setting, so appropriate disclaimers have been added to the field. But since it's been there for more than a year and there have not been any reports of issues (that I'm aware of yet), I thought it didn't need to be limited to advanced mode anymore. The table that shows you what overrides are in place is now improved as well. You can now click any override setting to open a modal window to see/edit them as needed (previously they were just non-clickable text labels). This is the same window that you get when clicking a field in the Template editor. Though unlike the Template editor, it takes you directly to the setting you clicked on and highlights it. After saving or closing the window, it updates the table for any changes you made. In addition to this, the overrides table now shows a Diff rather than separate Old and New values for modified settings, which better clarifies what was changed. (That Diff comes by way of a new method added in the WireTextTools class). Version 3.0.144 also adds a new Inputfields Javascript API. More methods are likely to be added to it, but you can see what's available in this first version in the comments for this file (inputfields.js). The purpose of this Inputfields JS API is to make it simpler to manipulate Inputfields from the JS side, as well as solve some needs that I've had in the core and modules; which presumably some other developers may have had as well. It takes a lot of stuff that previously required knowing which classes and attributes to manipulate and simplifies them to simpler methods calls from the new Inputfields JS API variable. It also abstracts away some admin-theme specific stuff so that you can use the same API to perform certain manipulations regardless of admin theme. I'm still working out some details and likely have some issues to fix and additional functions to add, so I'll save examples and more description for next week. Though the updates mentioned for the "Overrides" tab do use a little bit from this API. This version also contains a couple of fixes per GitHub issue reports, and that'll continue into next week's version as well. More updates next week. Until then, thanks for reading and have a great weekend!

Thanks @dragan will give it a try. Another idea I had was to use FormBuilder for the login form - again hackish. Really wish PW had a solid Login/Register module...

A couple of hooks that I have found useful in some situations... In the admin menus the icon associated with each page is normally determined by the "icon" item in the Process module config (e.g. as set in the getModuleInfo() method). But sometimes you might want to change that icon. For example, the Lister Pro module uses the "search-plus" icon, but this is not so good when you have multiple Lister Pro instances because it makes each instance less distinct. With the hook below I can use a custom icon for the extra Lister Pro instances I have added: // Add custom icons to Lister Pro menu items $wire->addHookAfter('Page::getUnknown(page_icon)', function(HookEvent $event) { $page = $event->object; if($page->process == 'ProcessPageListerPro') { if($page->title === 'Flora species') { $event->return = 'leaf'; } elseif($page->title === 'Flora images') { $event->return = 'picture-o'; } } }); If you change an icon in the admin menus like this you can do a Modules > Refresh to clear the menu cache and see the updated icon. And for Page List you probably know that you can assign an icon to all pages that use a template in the template's "Advanced" tab. But with the hook below you can assign icons to pages more dynamically based on any properties of the page. So, for example, you could assign a warning icon to a page to alert site editors if some important field was left empty. // Add warning icon to news items without a date $wire->addHookAfter('Page::getIcon', function(HookEvent $event) { $page = $event->object; if($page->template == 'news_item' && !$page->date_1) { $event->return = 'exclamation-triangle'; } });

Yeah, the navigation is not ideal. I have to scroll 3-4 times down to see the next content below, which is counter-intuitive. There are also JS/Vue errors in projects. I can't get past the 2nd one and get [Vue warn]: Error in render: "TypeError: Cannot read property 'title' of undefined"

This is a very hackish solution, but then again it's Saturday, I have never used the LR module before, and I could do with more coffee :) Basically: Create an iFrame. May not be elegant, but it seems to work. You'd have to add a logic for the registration confirmation page, so that this doesn't load in the iframe, but in its own page. btw, the very first line above was me trying out another idea: create several pages with the LR-template and then tinker around with form targets or hidden input fields.

Thanks Psy , I will work on that

Nice ? home page nav was a bit confusing for me, eg when clicking on 'About', it scrolled to your About section but the menu disappeared. There was no obvious way to get back to the top of the page. When I scrolled up, the menu had disappeared. Using iMAC with wide screen. Going into phone mode in Chrome dev tools made it a bit easier... Otherwise, well done you!

On a loosely related note: in case you already serve your content via HTTP/2, combining files is often less important. In some cases it may even be the opposite: technically the optimal use case would involve combining JS files into separate, smaller bundles that contain related features. "One big blob of JS" is very close to an antipattern these days. Just my five cents. Overall what I'm trying to say here is that if you're using HTTP/2 (which you should – and if not, that's something to focus first anyway) I wouldn't worry too much about bundling files, unless you've got loads of them ?

Not sure why you would be seeing that. I tested here and couldn't reproduce - that kind of selector works fine for me regardless of limit.

Many thanks for this, @Mats var request = new Request(url, { headers: new Headers({ 'X-Requested-With': 'XMLHttpRequest' }) }); fetch(request) .then(response => response.text()) .then(data => { console.log(data); });

Hey @ryan! I'm not sure if you did something special last week to get the Packagist dev-dev branch updated, but either way it is now serving 3.0.143. The problem is that this is the version right before the "Operator '&' is not supported" issue was fixed. I was hoping that releasing 3.0.144 would again update Packagist, but it didn't, which means that installing ProcessWire dev branch using Composer via Packagist currently results in a bugged version. If you did do something special last week in this regard, it'd be awesome if you could do it again – and if not, a manual "update" at https://packagist.org/packages/processwire/processwire might be in order, or at least that could force Packagist to fetch the latest version ?

This version on the dev branch contains 26 commits (relative to 3.0.142) and is focused primarily in resolving reported issues, and we managed to cover 18 of them in this version. Thanks for the reports and help in our GitHub issues repo. This version represents about 2 weeks of work, and ProcessWire Weekly #284 has good coverage of those that occurred last week. More details about this week's updates can be also be found in the dev branch commit log. There are also some other minor additions and improvements in 3.0.143 as well. My favorite are the improvements to our logs system. It now collapses identical log entries that occur near each other. That means a single recurring log entry (like an error message) won't repeat indefinitely in the log and take up a lot of space. Now it just adds a counter to one log entry and updates the timestamp, rather than duplicating the entire log entry... Much more efficient. When you view a log in Setup > Logs, it identifies these collapsed log entries for you. In addition, the output in the "errors" and "exceptions" logs now have improved readability, isolating error messages and filenames from stack traces. Lastly, the ajax navigation in Setup > Logs now shows logs in newest-to-oldest (modification date) rather than alphabetical, which I find a lot more useful. The log at the top of the list is always the one most recently updated. For core updates in coming weeks, I'm primarily focused on preparing the current dev branch to merge to the master branch, as it's been awhile since the last merge and the master branch is itching for a new version. Most of you reading this already run on the dev branch, but there are many out there that also stick to the master branch, and with all the new stuff on the dev branch, I'd like to get our master up-to-date with this as well. Thanks for reading, have a great weekend!

I haven't had the chance to see this in action yet, but looking at the code I'm wondering about one thing: at least in my case it's often important to know exactly when a particular issue first occurred, so that I can figure out what might've caused it – but if that initial occurrence is now removed, doesn't this make that process difficult, if not impossible? My initial thinking is that perhaps we should also store the timestamp for the first occurrence along with the counter data. That would, in my opinion, be an improvement over just logging the latest case along with a counter. While debugging a strange issue it's sometimes also helpful to know about the exact timestamps of all occurrences, but then we're basically back at not having this feature at all ? Overall I can see value in this, particularly from the UI point of view and for those cases where you're somehow spammed with a truckload of identical log entries, but I'm also a bit concerned that it could make debugging problems harder. As such, it might actually be a good idea to allow disabling this feature altogether; this way users could still opt-in for "full logging" instead if that works better for their workflow.

Hi, So today I will writing a small tutorial on developing templates in Processwire using Twig Template, Processwire is a highly flexible CMS which gives developers/designers/users options and allows easy extension of the platform. So here goes the tutorial What is Twig Template ? Simply put in my own words, Twig is a modern templating engine that compiles down to PHP code, unlike PHP, Twig is clean on the eyes , flexible and also quite *easy* to have dynamic layout site with ease ,without pulling your hair out. Twig is trusted by various platforms. It was created by the guys behind Symfony. Take this code as an example {% for user in users %} <h1>* {{ user }}</h1> {% endfor %} This will simply be the equivalent in PHP World <?php $userArray = ["Nigeria","Russia"]; foreach($userArray as $user): ?> <h1><?= $user ?></h1> <?php endforeach; The PHP code though looks simple enough however, you start to notice that you have to be concerned about the PHP tags by ensuring they are closed properly , most times projects gets bigger and comes complex and harder to read/grasp, and also in PHP you can explicitly create variables in the template making it very hard to read as it grows and prone to getting messy WordPress is a major culprit when it comes to that regard. Have you ever wanted to created separate layouts for different pages and break your sites into different parts e.g Sidebar, Comment Section, Header Section ? the regular approach would be to create individual pages for each section and simply add them as templates for the pages and with time, you can end up having tons of templates, however Twig allows you to easily inherit templates and also override the templates where you can inject content into the block easily. Don't worry if you don't understand the concept, the following parts will explain with an example of how to easily inherit layouts and templates. Layout <!DOCTYPE html> <html lang="en"> <head> {{include("layout/elements/header.twig")}} </head> <body> <div class="container-fluid" id="minimal"> <header id="pageIntro"> <div class="bio_panel"> <div class="bio_section col-md-6"> <h1>Okeowo Aderemi</h1> <h2>{{ page.body }}</h2> </div> </div> <div class="clearfix"></div> </header> <section id="page-body"> <div class="container"> <div id="intro" class="col-md-7 col-lg-7"> <h1>About me</h1> <h2> {{ page.summary }} </h2> </div> {block name="content"}{/block} <a style="font-size:1.799783em; font-style:italic;color:#d29c23" href="{{pages.get('/notes').url }}">Read more articles</a> </div> <div class="clearfix"></div> </div> </section> </div> <footer> <div class="header-container headroom headroom--not-top headroom--pinned" id="header-container"> {{include("layout/elements/footer.twig")}} </div> </footer> </body> </html> This is basically a layout where we specify blocks and include other templates for the page, don't panic if you don't understand what is going on, I will simply break down the weird part as follows: Include This basically is similar to native PHP 'include', as it's name suggests it simply includes the templates and injects the content into the layout , nothing out of the ordinary here if you are already familiar with php's include function. {{ output }} This simply evaluates the expression and prints the value, this evaluate expressions, functions that return contents , in my own short words it's basically the same as <?= output ?> except for the fact that it's cleaner to read. {% expression %} unlike the previous this executes statements such as for loops and other Twig statements. {% for characters in attack_on_titans %} <h1> {{characters}} </h1> {% endfor %} This executes a for loop and within the for loop, it creates a context to which variables in that context can be referenced and evaluated, unlike dealing with the opening and closing PHP tags, Twig simply blends in with markup and makes it really quick to read. I will simply post the contents of both the header and footer so you can see the content of what is included in the layout header.php <meta charset="utf-8"/> <meta content="IE=edge" http-equiv="X-UA-Compatible"/> <meta content="width=device-width, initial-scale=1" name="viewport"/> <title> {{ page.title }} </title> <link href=" {{config.urls.templates }}assets/css/bootstrap.min.css" rel="stylesheet"/> <link href="{{config.urls.templates }}assets/css/main.min.css" rel="stylesheet"/> <link rel='stylesheet' type='text/css' href='{{config.urls.FieldtypeComments}}comments.css' /> <link rel="stylesheet" href="{{config.urls.siteModules}}InputfieldCKEditor/plugins/codesnippet/lib/highlight/styles/vs.css"> <script type="text/javascript" src="{{config.urls.siteModules}}InputfieldCKEditor/plugins/codesnippet/lib/highlight/highlight.pack.js"></script> <script src="{{config.urls.templates }}assets/js/vendors/jquery-1.11.3.min.js"> </script> <script src="{{config.urls.templates }}assets/js/vendors/bootstrap.min.js"> </script> <script src="{{config.urls.FieldtypeComments}}comments.js"></script> <link rel="stylesheet" type='text/css' href="{{config.urls.templates}}js/jquery.fancybox.min.css"> <script src="{{config.urls.templates}}js/jquery.fancybox.min.js"></script> {block name="javascriptcodes"}{/block} footer.php <nav class="site-nav pull-right"> <div class="trigger"> <a class="page-link" href="{{pages.get('/about').url}}"> <span>{</span> About <span>}</span> </a> <a class="page-link" href="{{pages.get('/notes').url}}"> <span>{</span> Journals <span>}</span> </a> <a class="page-link" target="_blank" href="https://ng.linkedin.com/in/okeowo-aderemi-82b75730"> <span>{</span> Linkedin <span>}</span> </a> <a class="twitter page-link" target="_blank" href="https://twitter.com/qtguru"> <span>{</span> Twitter <span>}</span> </a> </div> </nav> There's nothing special here, other than twig simply injecting these fragments into the main layout , the next part is the most interesting and important concept and benefit that Twig has to offer {% block content %}{% endblock %} This tag simply creates a placeholder in which the content would be provided by the template inheriting this layout, in lay terms it simply means child templates will provide content for that block, the 'content' simply uses the name 'content' to refer to that specific block, so assuming we were to inherit this template it would simply look like this. Inheriting Template Layout {% extends 'layout/blog.twig' %} {% block content %} <div class="container blog-container"> <section class="blog"> <header class="blog-header"> <h1> {{page.title}} </h1> <h5 class="blog_date"> {{page.published|date("F d, Y")}} </h5> <br> </br> </header> <div class="blog_content"> <hr class="small" /> {{page.body}} <hr class="small" /> </div> </section> </div> {% endblock %} {% block nav %} <div class="col-md-4 col-xs-4 col-sm-4 prev-nav"> <a href="{{page.prev.url}}"> ← Prev </a> </div> <div class="col-md-4 col-xs-4 col-sm-4 home-nav"> <a href="{{homepage.url}}"> Home </a> </div> <div class="col-md-4 col-xs-4 col-sm-4 next-nav"> <a href="{{page.next.url}}"> Next → </a> </div> {% endblock %} In this snippet you can easily notice how each blocks previously created in the header and layout are simply referenced by their names, by now you will notice that twig doesn't care how you arrange the order of each block, all Twig does is to get the contents for each blocks in the child templates and inject them in the layout theme, this allows flexible templating and also extending other layouts with ease. Twig in Processwire Thanks to @Wanze we have a Twig Module for Processwire and it's currently what i use to build PW solutions to clients https://modules.processwire.com/modules/template-engine-twig/ The Modules makes it easy to not only use Twig in PW but also specify folders to which it reads the twig templates, and also injects Processwire objects into it, which is why i can easily make reference to the Pages object, another useful feature in this module is that you can use your existing template files to serve as the data provider which will supply the data to be used for twig template. take for example, assuming I wanted the homepage to display the top six blog posts on it, TemplateEngineTwig will simply load the home.php ( Depending on what you set as the template), it is also important that your twig file bears the same name as your template name e.g home.php will render into home.twig here is an example to further explain my point. home.php <?php //Get the Top 6 Blog Posts $found=$pages->find("limit=6,include=hidden,template=blog-post,sort=-blog_date"); $view->set("posts",$found); The $view variable is the TemplateEngine which in this case would be Twig, the set method simply creates a variables posts which holds the data of the blog posts, the method allows our template 'blog.twig' to simply reference the 'posts' variable in Twig Context. Here is the content of the 'blog.twig' template blog.tpl {% extends 'layout/blog.twig' %} {% block content %} <div class="block_articles col-md-5 col-lg-5"> {% for post in posts %} <div class="article_listing"> <span class="article_date"> {{post.published}}</span> <h2 class="article_title"> <a href="{{post.url}}">{{post.title}}</a> </h2> </div> {% endfor %} {% endblock %} So home.php sets the data to be used in home.tpl once Twig processes the templates and generates the output, twig takes the output from the block and injects it in the appriopriate block in the layout, this makes Processwire templating more flexible and fun to work with. The major advantage this has; is that you can easily inherit layouts and provide contents for them with ease, without the need of running into confusions when handling complex layout issues,an example could be providing an administrator dashboard for users on the template side without allowing users into the Processwire back-end. You can also come up with several layouts and reusable templates. Feel free to ask questions and any concerns in this approach or any errors I might have made or overlooked. Thanks