Leaderboard

Well, I use personally use UIkit 3 + TailwindCSS. Tailwind you are going to hear a whole lot more about in the upcoming months. I know you are talking about file size and this is exactly why UIkit + Tailwind is great! I don't really use UIkit's CSS at all. I just use the JavaScript because the amount of utilities they have manage to pack into 130kb (less than most images) is amazing. I'm talking Parallax, Sliders, Lazy Loading Images, Srcset utilities, placeholder generators, scrollspy, sticky. Most of which can be and usually is utilised in any project. I challenge you to get all of that under 130kb. Also it doesn't have any dependencies. Tailwind you can get down to about 3KB per website using Purge and Gulp/Webpack. It truly is amazing and Utility first CSS is such a refreshing way to work with CSS. I know all the arguments, and I'm a minimalist. I don't like all the classes too. But Tailwind's benifits out weigh the cost. 1. You don't have to struggle with inherited styles, or coming up with class names to define each section, some of which may look the same but be very different in content. 2. Consistency, it puts pressure on you to keep things consistent. So you hardly stray to loads of different type sizes and colours. 3. With Purge, you can have an entire website styles in ~3kb. I believe Ryan chose UIkit 3 because he has learnt the classes and is confident with the framework, and is impressed with the JavaScript utilities. And because you can build website much quicker using it. I see it as a hybrid between utility and a standard framework. It offers many utility classes. You could also Purge UIkit's CSS and get it around 160KB. I don't believe that this isn't a good fit for ProcessWire as you have previously mentioned. Many who use ProcessWire love UIkit. It follows the same philosophy: A powerful framework, that is easy to understand and learn to get things done quicker. Just like ProcessWire gives developers confidence in that they can do challenging bits of functionality easily with the power of ProcessWire's amazing API (like seriously, I built a real estate system using ProcessWire, something I wouldn't have dreamed of doing on any other platform). Well UIkit also gives that confidence to the front-end. But if I was to choose for myself, I much prefer pairing Tailwind for the CSS and UIkit for the JavaScript. That ~140KB (Tailwind + UIkit) covers me for most websites I build.

https://processwire.com/api/ref/session/force-login/

Very nice writeup. Thank you for sharing! There are so many different approaches to handling responsive images and it is great to see how others do it. Would love to see more approaches from others here, too. To get the concept of responsive images, I read the anatomy of responsive images which explains them very well. Then I used to implement a quite similar approach to @MoritzLost for some time utilizing the MarkupSrcset module and also my own functions. Until I stumbled upon an article about creating responsive images which shows an approach that I now prefer. In this approach you go through all your different images in the finished layout and determine their exact respective size at your breakpoints. Then you build srcset and sizes attributes for those exact values. So there is no more approximation using scaling factors. You get exactly the amount of images at the sizes you need them. I pass an array with the breakpoints and the required sizes for that breakpoint and build srcset and sizes from that array. Here's the code: /** * Builds responsive img tag with srcset and sizes attributes * @param \Processwire\Pageimage $img * @param array $breakpointsizes array of associative arrays that describe media min breakpoints and width/height of images from the respective * breakpoint to the next * Example: * $breakpointSizes = [ * ['bp' => 320, 'sz' => [500, 0]], * ['bp' => 576, 'sz' => [992, 0]], * ['bp' => 992, 'sz' => [690, 0]] * ['bp' => 1200, 'sz' => [835, 0]] * ]; * @return string */ function renderImageResponsive($img, $breakpointSizes) { $imgSrc = $img->url; // use original image as fallback src $alt = ($img->description) ? $img->description : $img->page->title; // if no description use page title // construct sizes attribute $sizes = array(); foreach(array_reverse($breakpointSizes) as $bs) { $sizes[] = "(min-width:{$bs['bp']}px) {$bs['sz'][0]}px"; } $sizes = implode(', ', $sizes) . ', 100vw'; // construct srcset attribute $srcSet = array(); foreach($breakpointSizes as $bs) { $srcSet[] = $img->size($bs['sz'][0], $bs['sz'][1])->url . " {$bs['sz'][0]}w"; } $srcSet = implode(', ', $srcSet); return "<img class='img-fluid' src='{$imgSrc}' srcset='{$srcSet}' sizes='{$sizes}' alt='{$alt}'>"; } Obviously it does not account for Retina which needs to be added. I will also extend my function to add support for other attributes like you showed it. That is a great idea.

Excited about the new processwire.com! I agree that the search could be better - especially if processwire.com is to be advertised as powered by ProcessWire. I get why the forum search might be poor because that is not powered by PW, but it has long puzzled me why the Modules Directory search is so poor seeing as that is PW-powered. An example: right now in the "Latest Additions" section we can see a module from netcarver titled "Street Address". So how come when I enter the exact words "Street Address" in the search box that module doesn't appear as the first result, and even doesn't appear on the first page? https://modules.processwire.com/search/?q=Street+Address

This post contains an introduction to our plans for rebuilding the ProcessWire.com website. In part one, we take a look at the initial strategy, framework, and concept for the new site, primarily from the development side: https://processwire.com/blog/posts/rebuilding-the-processwire.com-website--part-1-/

Happy to hear that the website will be finally rebuild. I hope a modern design will attract more potential users. With UIkit you have made an excellent choice for a framework. I would wish for a better search function, maybe powered by a service like Algolia. ? Having worked with UIkit for two years now, I am obviously biased, but in my opinion it is the best framework at the moment. It is far more complete as Bootstrap with more components and more active development. Gridlex is a grid system, not a framework. The grid component in the UIkit framework is maybe 5% of the whole framework. So the UIkit framework can do 95% more than Gridlex. ?

@pwired I don't wanted to start a discussion about frameworks here. I just wanted to point out that UIkit is a good choice for a framework to rebuild the new ProcessWire website and comparing it to a grid system are two different things. The UIkit framework is (as most frameworks are) modular. So if you want to use only the grid system, you can include only the grid system in your stylesheets and it should have around the same size. I don't know how much exactly because I have never just compiled the grid system and I don't count bytes, because in my opinion the size of your stylesheets are the least thing to worry about. No, I think most of the people don't use the whole 100% of a framework. Personally I use probably around 40% and include the whole framework anyway, because I like to have a good set of components available. It lets me focus more on the content and design while developing a website and I don't have to reinvent everything (grid, utility classes, slideshow etc.) from scratch. But as mentioned, if you only want to use a part of a framework, you can simply don't include the rest. ? That is the same approach as using a framework. Except when using different libs from different developers with different support and compatibility, you use components from one developer that are always compatible with each other. Before using framework I also used one lib for a slideshow, one for filterable grid, one for lazy loading images etc. With UIkit I only need one framework or if some lib does something better, I use this lib instead. That is true under the assumption when leaving the framework untouched and using it plain. The part of a good designer/web developer is to build styles on top of a framework and make it look different. In my opinion a framework should not be used plain and is just a foundation for an individual design. Of course everything I say is my opinion only and everyone is free to choose whatever suits your projects the best. Using a framework is not always the best choice and for designs that are different, I also don't use a framework. But for a large project like rebuilding the ProcessWire website it can help a lot to have a good foundation and the UIkit framework is this. If you want't to discuss further @pwired, you can create a topic, invite me to an existing one or send me a PM. ? Yes, the current search function is not really good, especially when you have build better search functions with ProcessWire. ? In my opinion it should be able to search the whole website (blog posts, modules, docs, API, etc.) and have autocomplete suggestions. A service like Algolia may be not necessary and this could be probably achieved by ProcessWire alone, but I had to work with a similar CMS for a while which uses Algolia on its website and it was a breeze to have a good search function for learning a new CMS. Of course the CMS is not as powerful as ProcessWire and you can remove the link if this is advertising. Regards, Andreas

News Update - 10 October 2018 I know many of you are eagerly awaiting the next version of Padloper. I thought I'd give you a couple of updates regarding progress. First, I'd like to thank you for the feature requests and your support. As previously stated, it will not be possible to accommodate all requests and those that may be accommodated may have to wait till other releases. OK, to the update. The following have so far been achieved. FieldtypeProducts A new Fieldtype for storing products including their variants, if any. This allows for easy retrieval and storage of data and and API that makes it easy to filter, search, manipulate, update, etc product details. So..: $foo = $products->find("colour=red,quantity<10"); $bar = $product->first(); echo $bar->size; echo $bar->price; // etc Discounts We have a new discounts class that allows for 4 types of discounts each with generic and specific requirements. Percentage discount Fixed amount discount Free shipping discount Buy X Get Y discount In turn, as applicable, the discounts are subject to generic conditions including customer country,named customers, customers subscribing to your newsletter, global usage, customer usage limits, customers who abandoned carts, start/expiration dates, etc. There are also discount-specific conditions including whether to apply discount to entire order, specific products or specific categories/collections, minimum requirements (purchase amount or quantity of eligible products in cart), etc. Import/Export Products This class allows for importing products into your shop as CSV, JSON or arrays. It is 98% done. It will also allow for exporting products as CSV (and maybe in future, as JSON, if there is demand). MarkupPadloper This is WIP to eventually replace PadRender. This allows for retrieving products, product tags, product categories, etc, either as ready-to-render (i.e. includes the markup) vs retrieving the raw product details so one can use their own markup, anywhere, anyhow, to output products. Other A bit of work on customer notifications (including email templates) and FieldtypeOrders for orders plus some other stuff. I got a lot to do, so I better get cracking! ? Thanks for reading.

Hello there, I've started using ProcessWire at work a while ago and I have been really enjoying building modular, clean and fast sites based on the CMS (at work, I usually post as @schwarzdesign). While building my first couple of websites with ProcessWire, I have written some useful helper functions for repetitive tasks. In this post I want to showcase and explain a particular function that generates a responsive image tag based on an image field, in the hope that some of you will find it useful :) I'll give a short explanation of responsive images and then walk through the different steps involved in generating the necessary markup & image variations. I want to keep this beginner-friendly, so most of you can probably skip over some parts. What are responsive images I want to keep this part short, there's a really good in-depth article about responsive images on MDN if you are interested in the details. The short version is that a responsive image tag is simply an <img>-tag that includes a couple of alternative image sources with different resolutions for the browser to choose from. This way, smaller screens can download the small image variant and save data, whereas high-resolution retina displays can download the extra-large variants for a crisp display experience. This information is contained in two special attributes: srcset - This attribute contains a list of source URLs for this image. For each source, the width of the image in pixels is specified. sizes - This attribute tells the browser how wide a space is available for the image, based on media queries (usually the width of the viewport). This is what a complete responsive image tag may look like: <img srcset="/site/assets/files/1015/happy_sheep_07.300x0.jpg 300w, /site/assets/files/1015/happy_sheep_07.600x0.jpg 600w, /site/assets/files/1015/happy_sheep_07.900x0.jpg 900w, /site/assets/files/1015/happy_sheep_07.1200x0.jpg 1200w, /site/assets/files/1015/happy_sheep_07.1800x0.jpg 1800w, /site/assets/files/1015/happy_sheep_07.2400x0.jpg 2400w" sizes="(min-width: 1140px) 350px, (min-width: 992px) 480px, (min-width: 576px) 540px, 100vw" src="/site/assets/files/1015/happy_sheep_07.1200x0.jpg" alt="One sheep"> This tells the browser that there are six different sources for this image available, ranging from 300px to 2400px wide variants (those are all the same image, just in different resolutions). It also tells the browser how wide the space for the image will be: 350px for viewports >= 1140px 480px for viewports >= 992px 540px for viewports >= 576px 100vw (full viewport width) for smaller viewports The sizes queries are checked in order of appearance and the browser uses the first one that matches. So now, the browser can calculate how large the image needs to be and then select the best fit from the srcset list to download. For browsers that don't support responsive images, a medium-sized variant is included as the normal src-Attribute. This is quite a lot of markup which I don't want to write by hand every time I want to place an image in a ProcessWire template. The helper function will need to generate both the markup and the variations of the original image. Building a reusable responsive image function Let's start with a function that takes two parameters: a Pageimage object and a standard width. Every time you access an image field through the API in a template (e.g. $page->my_image_field), you get a Pageimage object. Let's start with a skeleton for our function: function buildResponsiveImage( Pageimage $img, int $standard_width ): string { $default_img = $img->maxWidth($standard_width); return '<img src="' . $default_img->url() . '" alt="' . $img->description() . '">'; } // usage example echo buildResponsiveImage($page->my_image_field, 1200); This is already enough for a normal img tag (and it will serve as a fallback for older browsers). Now let's start adding to this, trying to keep the function as flexible and reusable as possible. Generating alternate resolutions We want to add a parameter that will allow the caller to specify in what sizes the alternatives should be generated. We could just accept an array parameter that contains the desired sizes as integers. But that is not very extendible, as we'll need to specify those sizes in each function call and change them all if the normal size of the image in the layout changes. Instead, we can use an array of factors; that will allow us to set a reasonable default, and still enable us to manually overwrite it. In the following, the function gets an optional parameter $variant_factor. // get the original image in full size $original_img = $img->getOriginal() ?? $img; // the default image for the src attribute, it wont be upscaled $default_image = $original_img->width($standard_width, ['upscaling' => false]); // the maximum size for our generated images $full_image_width = $original_img->width(); // fill the variant factors with defaults if not set if (empty($variant_factors)) { $variant_factors = [0.25, 0.5, 0.75, 1, 1.5, 2]; } // build the srcset attribute string, and generate the corresponding widths $srcset = []; foreach ($variant_factors as $factor) { // round up, srcset doesn't allow fractions $width = ceil($standard_width * $factor); // we won't upscale images if ($width <= $full_image_width) { $srcset[] = $original_img->width($width)->url() . " {$width}w"; } } $srcset = implode(', ', $srcset); // example usage echo buildResponsiveImage($page->my_image_field, 1200, [0.4, 0.5, 0.6, 0.8, 1, 1.25, 1.5, 2]); Note that for resizing purposes, we want to get the original image through the API first, as we will generate some larger alternatives of the images for retina displays. We also don't want to generate upscaled versions of the image if the original image isn't wide enough, so I added a constraint for that. The great thing about the foreach-loop is that it generates the markup and the images on the server at the same time. When we call $original_img->width($width), ProcessWire automatically generates a variant of the image in that size if it doesn't exist already. So we need to do little work in terms of image manipulation. Generating the sizes attribute markup For this, we could build elaborate abstractions of the normal media queries, but for now, I've kept it very simple. The sizes attribute is defined through another array parameter that contains the media queries as strings in order of appearance. $sizes_attribute = implode(', ', $sizes_queries); The media queries are always separated by commas followed by a space character, so that part can be handled by the function. We'll still need to manually write the media queries when calling the function though, so that is something that can be improved upon. Finetuning & improvements This is what the function looks like now: function buildResponsiveImage( Pageimage $img, int $standard_width, array $sizes_queries, ?array $variant_factors = [] ): string { // get the original image in full size $original_img = $img->getOriginal() ?? $img; // the default image for the src attribute, it wont be upscaled $default_image = $original_img->width($standard_width, ['upscaling' => false]); // the maximum size for our generated images $full_image_width = $original_img->width(); // fill the variant factors with defaults if not set if (empty($variant_factors)) { $variant_factors = [0.25, 0.5, 0.75, 1, 1.5, 2]; } // build the srcset attribute string, and generate the corresponding widths $srcset = []; foreach ($variant_factors as $factor) { // round up, srcset doesn't allow fractions $width = ceil($standard_width * $factor); // we won't upscale images if ($width <= $full_image_width) { $srcset[] = $original_img->width($width)->url() . " {$width}w"; } } $srcset = implode(', ', $srcset); return '<img src="' . $default_img->url() . '" alt="' . $img->description() . '" sizes="' . $sizes_attribute . '" srcset="' . $srcset . '">'; } It contains all the part we need, but there are some optimizations to make. First, we can make the $sizes_queries parameters optional. The sizes attribute default to 100vw (so the browser will always download an image large enough to fill the entire viewport width). This isn't optimal as it wastes bandwidth if the image doesn't fill the viewport, but it's good enough as a fallback. We can also make the width optional. When I have used this function in a project, the image I passed in was oftentimes already resized to the correct size. So we can make $standard_width an optional parameter that defaults to the width of the passed image. if (empty($standard_width)) { $standard_width = $img->width(); } Finally, we want to be able to pass in arbitrary attributes that will be added to the element. For now, we can just add a parameter $attributes that will be an associative array of attribute => value pairs. Then we need to collapse those into html markup. $attr_string = implode( ' ', array_map( function($attr, $value) { return $attr . '="' . $value . '"'; }, array_keys($attributes), $attributes ) ); This will also allow for some cleanup in the way the other attributes are generated, as we can simply add those to the $attributes array along the way. Here's the final version of this function with typehints and PHPDoc. Feel free to use this is your own projects. /** * Builds a responsive image element including different resolutions * of the passed image and optionally a sizes attribute build from * the passed queries. * * @param \Processwire\Pageimage $img The base image. * @param int|null $standard_width The standard width for this image. Use 0 or NULL to use the inherent size of the passed image. * @param array|null $attributes Optional array of html attributes. * @param array|null $sizes_queries The full queries and sizes for the sizes attribute. * @param array|null $variant_factors The multiplication factors for the alternate resolutions. * @return string */ function buildResponsiveImage( \Processwire\Pageimage $img, ?int $standard_width = 0, ?array $attributes = [], ?array $sizes_queries = [], ?array $variant_factors = [] ): string { // if $attributes is null, default to an empty array $attributes = $attributes ?? []; // if the standard width is empty, use the inherent width of the image if (empty($standard_width)) { $standard_width = $img->width(); } // get the original image in full size $original_img = $img->getOriginal() ?? $img; // the default image for the src attribute, it wont be // upscaled if the desired width is larger than the original $default_image = $original_img->width($standard_width, ['upscaling' => false]); // we won't create images larger than the original $full_image_width = $original_img->width(); // fill the variant factors with defaults if (empty($variant_factors)) { $variant_factors = [0.25, 0.5, 0.75, 1, 1.5, 2]; } // build the srcset attribute string, and generate the corresponding widths $srcset = []; foreach ($variant_factors as $factor) { // round up, srcset doesn't allow fractions $width = ceil($standard_width * $factor); // we won't upscale images if ($width <= $full_image_width) { $srcset[] = $original_img->width($width)->url() . " {$width}w"; } } $attributes['srcset'] = implode(', ', $srcset); // build the sizes attribute string if ($sizes_queries) { $attributes['sizes'] = implode(', ', $sizes_queries); } // add src fallback and alt attribute $attributes['src'] = $default_image->url(); if ($img->description()) { $attriutes['alt'] = $img->description(); } // implode the attributes array to html markup $attr_string = implode(' ', array_map(function($attr, $value) { return $attr . '="' . $value . '"'; }, array_keys($attributes), $attributes)); return "<img ${attr_string}>"; } Example usage with all arguments: echo buildResponsiveImage( $page->testimage, 1200, ['class' => 'img-fluid', 'id' => 'photo'], [ '(min-width: 1140px) 350px', '(min-width: 992px) 480px', '(min-width: 576px) 540px', '100vw' ], [0.4, 0.5, 0.6, 0.8, 1, 1.25, 1.5, 2] ); Result: <img class="img-fluid" id="photo" srcset="/site/assets/files/1/sean-pierce-1053024-unsplash.480x0.jpg 480w, /site/assets/files/1/sean-pierce-1053024-unsplash.600x0.jpg 600w, /site/assets/files/1/sean-pierce-1053024-unsplash.720x0.jpg 720w, /site/assets/files/1/sean-pierce-1053024-unsplash.960x0.jpg 960w, /site/assets/files/1/sean-pierce-1053024-unsplash.1200x0.jpg 1200w, /site/assets/files/1/sean-pierce-1053024-unsplash.1500x0.jpg 1500w, /site/assets/files/1/sean-pierce-1053024-unsplash.1800x0.jpg 1800w, /site/assets/files/1/sean-pierce-1053024-unsplash.2400x0.jpg 2400w" sizes="(min-width: 1140px) 350px, (min-width: 992px) 480px, (min-width: 576px) 540px, 100vw" src="/site/assets/files/1/sean-pierce-1053024-unsplash.1200x0.jpg" alt="by Sean Pierce"> Now this is actually too much functionality for one function; also, some of the code will be exactly the same for other, similar helper functions. If some of you are interested, I'll write a second part on how to split this into multiple smaller helper functions with some ideas on how to build upon it. But this has gotten long enough, so yeah, I hope this will be helpful or interesting to some of you :) Also, if you recognized any problems with this approach, or can point out some possible improvements, let me know. Thanks for reading!

Hi Tom, Thanks for picking up my question and answering it first in the light of Processwire, and not Uikit3. This was exactly what I was hoping for someone would be able to do. Very good example of bringing things together in a much more efficient way. Exactly my point and also, such an architecture has the same spirit to pair with Processwire. Thanks for sharing all this.

ouch, this one I missed, thanks Adrian

Hi @kongondo, sorry for any confusion. I am purely talking about a frontend account area for customers where they can review orders, manage account info etc whilst staying on brand to the look and feel of the shop. When I mention authentication I meant incorporating a login / registration flow similar to Ryan's Login/Register module. See some screenshots from WooCommerce Storefront theme below. The code for this is here, but I can spin up a demo for you if you want.

Yes I know that Gridlex is not a framework, and that the Uikit framework can do 95% more than Gridlex also means that you are talking about uikit.min.css = 243 kB and uikit.min.js = 128 kB with gridlex.min.css only 35 kB. Do you really need that 95% more for every new project, or simply leave it untouched ? Unless of course you are going to recompile Uikit for every new project. How many people are really going to do that and figure out what can be left out and tweak compile Uikit for the next project ? The other way around is much more effective: use only libs needed for your project the same way you use your own snippets. Besides that, I noticed that every new project you do with Uikit (bootstrap and the others the same) starts to look the same like your other projects you did before. Problem is you are using same styles as so many other web sites out there made with Uikit. Not a good thing for brand awareness. Maybe I can make my point more clear with this article: https://dev.to/bitersen/case-against-premade-css-frameworks--3jn

Great post Ryan! I am really interested in your "inside out" approach. Would you mind keep sharing some details about your process in the next posts? I'm positive you keep an eye on the quality of the new website.

UIkit3 is a bit more of a utility class oriented CSS framework. The benefits of utility based CSS are excellently summarized in this article, which I side with given my own evolution with CSS: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ Gridlex is just a grid system from what I can tell. If you need all the usual components (accordions, tabs, etc.), UIkit3 has it covered extremely well, especially compared to the other big CSS frameworks. Many great options. I rarely pull in other libraries since UIkit has it covered, and since it's all under one roof, it's very consistent and doesn't lead to conflicts.

It is scattered all around the forum, for example: It just needs to be compiled I guess.

Hi, AndZyk Thanks for sharing your post and perspective No it's ok. My post was not about Uikit3 it self, but more about why Uikit is going to be used in the new Processwire website. I always loved to experience Processwire as a system that stays as close as possible to the core of things. Take a look at this thread that is going on about designing responsive: Edit: replaced wrong link with the correct one: (sorry Horst) https://processwire.com/talk/topic/19964-building-a-reusable-function-to-generate-responsive-images/ That is much more in the spirit of Processwire instead of using things like Uikit.