Leaderboard

I've done both so far. Since we use PW for our corporate intranet, there are a number of additional databases we pull data from, which is quite straight forward (just an include that instantiates a new WireDatabasePDO and wire()s it). We have a search interface to our test report database where all the data for on-site test runs of our machines are stored, pull in infos about the processing state of lab samples and display an ajax loading tree of standard parts lists for the project engineers from the ERP. Other DBs have been converted to PW pages, like e.g. the archive for the old support ticket system. We even have a mix at some places. For our sales department, we pull the contact information for our worldwide offices from the ERP, create pages if they don't exist yet, and the department augments these pages with additional infos like contractual details that the ERP can't store without climbing through major hoops. We have a semi-live attendance list (the most visitied page by far) filled with data combined from PW's user list (synchronized from Active Directory), attendance status from the time accounting software and person info like the building/room number from the ERP, with the HTML output being generated every five minutes by a background job to ease server load a bit. We have some additional, non-PW tables in the PW database for speeding up things, like caching the listings of large directories with parts drawings, and even wrote our own CKEditor plugins to easily embed links or image tags for these files. You could say PW runs as a big "spider web" that connects all the apps in our company, with data being pulled in wherever necessary. There are a few apps where we thought about storing the content in PW but decided against it due to the sheer amount of data and the performance impact PW's normalization would bring. Right now we're at around 25k pages and a little over 100 fields in 50 templates. We use the UserGroups module and template settings to limit backend access to individual templates and keep the list of available templates short for our editors (~60 editors who never see more than 6 templates in their selection list). Our intranet was built on a different CMS in 2006 and migrated to PW a few years ago, and the possibilities we gained were simply astonishing. It's always fun to have a sales rep for one of the intranet platform solutions on site and, after listing to their spiel about the great features they offer, show them what we have and ask innocently, "How much work would it be to implement all of this?" ?

@Tom. I have downloaded all four images and what you are saying, at least how I do understand it, seems not to be completly valid. What exactly was the source for what variation, as you said without resizing? (The original is larger than the others) I found these images: The original image is 4x larger (in pixel) than the compared variations. And it only has 157k, whereas the other have 300k. The original image is from a source of 1920x1080 resized in Photoshop CC2017 to 1500x1074 px and is very strong compressed. That is NOT a useful choice for a master image! Masterimages should be saved in 100% quality, (or quality 12 in Photoshop), in every single item of a workflow chain. Once you saved with lesser quality, you damaged the image, regardless if you later on save it with higher quality. When I save your original image in Photoshop with quality 12, I get a 427k image file, not 157k. Another ProTip is: work with images in 16bit colordepth all the time, best in a larger color spectrum like AdobeRGB, not sRGB, use PSD or TIFF as your local master image, and only transform from this local master image to every desired target format according these steps, respecting the chronology: - 1) resize to target dimensions - 2) transform into target color space, (AdobeRGB into sRGB, or AdobeRGB into CMYK, etc) - 3) reduce the color depth from 16 bit to 8 bit, (the last step always!) - 4) save into your target file format, for ProcessWire (online) master images, with the max quality in JPEG. From these (online) master images you can create very good results with the GD-Lib and with the IMagick-Lib. If you do not resize the original or only resize a very small value, you may set the sharpening property to "none". Also when using the GD-Lib, you may set the "defaultGamma" to -1. Experimenting with this two properties should be enough to render good results for all possible use cases. At least this are my experiences. Can you tell me why the original is compressed so strong? And do you have an uncompressed version too? (uncompressed means: never ever compressed in its total live workflow chain!) ------------ There definitely is a difference when using the same sharpening values with GD-Lib and IMagick. This is due to the fact that IMagick internally already uses a sharpening algorithm when resizing images, and GD-Lib completely lacks about this feature. Looking at PWs image resizing history, there first only was GD-Lib without sharpening, resulting in blurry images. Than we introduced a sharpening algorithm with four available values: none | soft | medium | strong, (defaults to soft) A long time later, we introduced the ImageMagick-Lib with all the same params available as for the GD-Lib. At this time my thinking was, when switching from GD to IMagick, one may switch from medium to soft, or from soft to none in the site/config.php file, as it is a global decision what image library to use. But a review / rework of the used algorithm values in the core libs is possible, so that we maybe will have nearly no differences between IMagick none and soft, but keep the currently used differences within the GD-Lib.

@Robin S was just typing a reply to say I was thinking there might be quick css fixes, maybe more complicated js ones. I was hoping someone with a bit more knowledge of the theme code might know some quick ones, and lo and behold! This is good stuff thanks. Totally get Ryan doesn't monitor the forums but just wanted to see if anyone had any more knowledge of this before attempting to do so myself. Issue / requests definitely the most proactive way to move forward. @wbmnfktr its just little bits and pieces that I feel could be optimized. I am maybe noticing it right now because I am clicking around the admin a lot for a new site. Generally didnt want to bring this up as a major flaw or need for a rewrite, just hoping there might be ways to optimise this stuff. Beyond Robin's suggestions my hunch is there is also probably also some weird interplay between UIKit js and jqueryui going, but I need to dig in and have a look. Thanks all for the feedback, if anyone has any other fixes maybe PM me or post back here, at some point soon I'll put these into issues / requests.

What I've done so far, is a small implementation of webp-convert. Currently without a ProcessWire specific module or something, but that's planned. Just added a file called webp-on-demand.php in the ProcessWire root directory with following content: <?php // docs https://github.com/rosell-dk/webp-convert require 'webp/webp-on-demand-1.inc'; use WebPConvert\WebPConvert; $docRoot = rtrim($_SERVER["DOCUMENT_ROOT"], '/'); $requestUriNoQS = explode('?', $_SERVER['REQUEST_URI'])[0]; $source = $docRoot . urldecode($requestUriNoQS); $destination = $source . '.webp'; // Store the converted images besides the original images (other options are available!) $options = [ // Tell where to find the webp-convert-and-serve library, which will // be dynamically loaded, if need be. //'reconvert' => true, 'require-for-conversion' => 'webp/webp-on-demand-2.inc', 'quality' => 'auto', 'max-quality' => 75, 'fail' => 'serve-original' // see https://github.com/rosell-dk/webp-on-demand/blob/master/docs/api.md for more info ]; WebPConvert::convertAndServe($source, $destination, $options); Then in the folder webp the two on-demand files from here. After that I added following to the .htaccess: <IfModule mod_rewrite.c> RewriteEngine On # Redirect images to webp-on-demand.php (if browser supports webp) RewriteCond %{HTTP_ACCEPT} image/webp RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^(.*)\.(jpe?g|png)$ webp-on-demand.php [NC,L] </IfModule> AddType image/webp .webp And that's it. If the browser supports webp, all requests of .jpg and .png are redirectet to the webp-on-demand.php which desides if it needs to convert the image or serve the already converted one. A small caveat: the standard installation of Plesk has no webp support included, so on webservers with Plesk you either need to wait for their implementation or compile it yourself.

I wanted to create a HTML Sitemap with the same pages as the XML sitemap. Unfortunately the $pages->find() method doesn´t support the order of the page tree, so I could not use the provided function to get all pages from the XML-Sitemap in the same order as the page tree. $pages->find('seo.sitemap_include=1'); So I wrote a little recursive function to render all the pages except the ones which were not included in the XML sitemap. The pages have the same order as in the page tree. function renderSitemap($items, $depth = 0) { $separator = ''; for ($x = 0; $x <= $depth; $x++) { $separator .= '-'; } foreach ($items as $item) { if ($item->seo->sitemap->include == 1) { $subitems = $item->children(); if (count($subitems)>0) { echo '<b>'.$separator.$item->title . '</b><br />'; } else { echo $separator.$item->title . '<br />'; } $subitems = $item->children(); renderSitemap($subitems, $depth+1); } } } //OUTPUT INSIDE TEMPLATE FILE $items = $pages->get("/")->children(); echo '-'.$pages->get("/")->title.'<br />';//this is only for the homepage renderSitemap($items); This little function is not intended as a complete HTML sitemap markup generation solution. It only outputs the title of the pages (without links). It should only be a starting point for others to show you how to use SEOMaestro settings in combination with a frontend sitemap. Maybe if someone has a better solution it would be great if you post it here. Best regards This is what it looks like:

@Mikie, you will probably need to open separate issues for each concern in the Issues or Request repos in order for Ryan to notice - he doesn't tend to participate much in the general forums these days. In terms of which repo, I'd say that it belongs in the Issues repo if something is broken or not working as expected, and in the Request repo if it's about adding a new feature or improving something that already works. In each issue please describe exactly what the problem is and what a solution would look like. And if you are able to contribute code for a suggested fix that's great (but not essential). I have some possible fixes for some of the things you mentioned that you'd be welcome to include in any issue report if you want... The footer sits under whatever content makes up the page, so if new content is loaded into the page by AJAX or page elements change in height then it's expected that the footer will move. Are you suggesting that the footer should be sticky to the bottom of the viewport when the height of the page content is less than the viewport height? Personally I would prefer that, but it's perhaps a matter of opinion. Here is some CSS that could be used for a sticky footer: /* Sticky footer */ html { height:100%; } body:not(.modal) { display:flex; flex-direction:column; height:100%; } body:not(.modal) #main { flex:1 0 auto; width:100%; box-sizing:border-box; } body:not(.modal) footer { flex-shrink:0; } This FOUC with WireTabs was much worse with the older admin themes - I hardly notice it in AdminThemeUikit but it is there. A CSS fix: /* Prevent FOUC for WireTabs content */ .WireTabs + .Inputfields > .InputfieldWrapper { display:none; } The main FOUC relating to fields that bugs me is the delay in hiding inputfields with show-if conditions. I'd rather have show-if fields hidden by default and then shown when necessary. There's an open request about that, along with a roll-your-own fix for the meantime: https://github.com/processwire/processwire-requests/issues/179 I'm not sure what sort of change you want to see with regard to CKEditor fields or image fields. Some inputfields take a moment to initialise - I'd rather see the interface as soon as possible even if parts of it need to adjust slightly after loading than have the whole interface hidden until loading is complete (not sure if that's what you're suggesting). Generally speaking the behaviour of non-core modules is up to the author of those modules. But in the case of the Lister Pro button you mentioned this is due to the way the admin theme wraps and clones "head" buttons. A CSS fix: /* Hide Lister button links at bottom when results are empty */ #ProcessListerResults:empty + .InputfieldButtonLink { display:none; }

Hi @MilenKo, It's still rough, but feel free to read my notes on the different techniques for flexible page layouts https://docs.google.com/document/d/1peY-FUpevKgy87cKOxIVz8jwcv2-3c61zbiJr3QKO6c/edit?usp=sharing

Hey just bringing up as a point for discussion. I find in various areas of the admin there is quite a lot of reflowing of content and flash of unstyled content (FOUC). Examples are: the pages listing animation pushes the footer down the page every time, and this can also be seen on various pages where content doesn't load immediately (footer will fly down the page) basic pages with no fields – sit there and refresh a basic page a few times, you will see a flash of all content before tabs are created pages with lots of fields – progressive loading and rendering of different fields and groups causes lots of reflow, particularly loading wysiwyg and image fields modules eg lister-pro – loads the add new button initially on the left then it jumps to the top right as the lister loads, then columns reflow and resize as content loads in and classes are applied Whilst pw is very fast to render admin page html, to me the above makes it feel quite jarring and heavy. Generally speaking you want to aim for no reflow or FOUC whatsoever for a good user experience. I know there is a lot going on here and it is not a simple thing to manage an admin like this, but does anyone notice the same thing and have any ideas about how this can be optimised? Below are some relevant links. Minimising animations is the best place to start, although before anyone suggests it just using AdminOnSteroids to disable animations doesn't fix a lot of what I am talking about. https://developers.google.com/speed/docs/insights/browser-reflow https://gist.github.com/paulirish/5d52fb081b3570c81e3a

Hi @horst, that's right, but the script looks, if there is already a webp-version of the image and if deliver this directly. So there is no big processing during normal frontend activities through website users, if the conversion was already done. Though you are definetely right, it's an extra PHP call (but cacheable)

Hello @Tom., do you use the core module IMagick Image Sizer and have you disabled sharpening in the module settings? I usually disable it. Maybe that could be the reason. ? Regards, Andreas

Thanks a lot @Robin S. Guess I have to do some essential reading... I never had to use derefAsPage until now... I tried your new code, but now I get a fatal error on the above line: Call to a member function of() on integer. Guess there's something else in my setup that is not quite kosher - will go back to the drawing board tomorrow with a fresh set of eyes...

Any news on WebP? There is a lot of convocation in the studio currently on image quality. The general thing is the built in resizing of images (Imagick) leaves images soft, however adding any sort of sharpening and it over sharpens around text leaving it with halos. Some people in the studio have been talking about changing CMS due to how ProcessWire manipulates images leaving them soft or over sharpened losing detail. It's a big discussion at the moment and generally we have found Statamic & CraftCMS much better at resizing images and keeping quality (Statamic uses Glide - https://glide.thephpleague.com/) But WebP will be massively important also.

I'm wondering if the "override core module / multiple copies of the same module" feature would break after this, i.e. will ProcessWire understand that a .module file in /site/modules/ is a replacement for a .module.php file in /wire/modules/? This might not be an issue (can't check right now), but in case it is, then this should only be considered as a part of a bigger update, as it's a breaking change.

?

I don't want to downplay anything here but... how often do you all see FOUC in PW admin? I just started to look closer while admin pages load/reload... but to be honest... I see only some minor reflow issues here and there but nothing that annoys me. Right now I'm working on three different systems... local (Laragon) Remote (webgo) Remote (Dreamhost) While Dreamhost is remote and kind of slow only reflow issues appear on bigger pages there once in a while. No FOUC or something similar to that. Laragon and webgo are fast and those reflow issues are gone even before I really notice them. I don't use AOS, Tracy, Lister Pro or similar modules that may cause those... FOUC issues. Nonetheless... count me in for optimizing the backend to make it even better. Tested on: PW version 3.0.123 and 3.0.130