Leaderboard

No, as written two posts above, we have different purpose images. There could be, for example, uncompressed master images that serves as source and should not be displayed on screen! Following I show some more image file purposes, but want to start with a brief introduction to image processing procedures. Within a web environments very limited support, our master source images have to be uncompressed JPGs with 8 bit color depth per channel. Far from optimal. In other environments TIFF or PSD in 16 or 32 bit color depth is used for that purpose. The destructive compression method of JPGs is responsible for most of the user errors that occur during the processing steps. Once you saved a JPG compressed within a workflow, as source or intermediate, you damaged it unrecoverable! And one also cannot detect this programmatic within a common web environment! This is one reason why we keep the master source, the original image untouched, "as is" in PW! (besides other aspects) So, for our use cases, the JPG format can have different purposes: uncompressed master source images, uncompressed intermediate variations, final optimized and compressed variations for screen output. Also, if one has a use case for it, one can optimize and finalize JPGs only for the purpose of printing in PW. Or for embedding them into PDFs, or for serving them as single files or as zipped archives for different purposes per downloads. So, it's not: "all get displayed on screen". Some never should be displayed on screen. (I maintain sites for photographers who keeps 60k+ images as original (pw master source) images in the site. They only publicly show watermarked images within limited dimensions. The original images are protected against web access. And they are used for all the different above listed output purposes.) Luckily with the WebP format it behaves different. Due to its intended purpose, (that is, highly compressed and optimized for screen output), it is unusable for all other purposes! Sure, if you want to or don't care about anything, you can use everything wrong, but it is not that subtle like with JPGs. In German we have a saying: "gefährliches Halbwissen" ("dangerous half-knowledge"). No idea whether one can translate the sense connected with it by DeepL? But it means something like: If you already know a good part, you quickly run the risk of drawing (wrong) conclusions about the unknown parts. Personally, I am always happy when I get explanations, help or advice from people who have more specialist knowledge. After all, I can't know everything myself, right? ? One of my most important life experiences & wisdoms to fight against my "gefährliches Halbwissen": "If there are many people who study and learn for years to get a vocational qualification before they can "really" get into the subject, then I know that a huge part of it is invisible to me, even if I think I already understand a lot of it.".

Because it is not a "normal" image format by its intended purpose! As far as I understood, you upload already compressed images that you don't want to proceed further? Note: 1) Already (not lossless) compressed images should not be used for any transformation, because the images are lacking lots of information due to the compression. (like the webp format!) 2) If you do not want to use the resize functionality, you have to provide the final webp by yourself too. PW only provides webp support for PW created variations for final output. This is due to the file formats nature or its intended purpose. Maybe you don't want or need a webp variation for admin thumbs. Maybe other users don't care. Maybe some users really like it when opening a editor page with 300 images displayed as admin thumbs. I cannot answer this other then: It may depend on a lot of different things? I really would like to discuss the general webp support first, and the less common use cases like this later on, in a following fine tuning phase. ----------- AFAIK the most common case is to use the pageimage system with uploaded uncompressed images that serves as master images. Those master images are never get served to the outside "as is". They every time get transformed into a variation file that is optimized and finalized for a specific purpose! At least this is the only correct way for an error-free workflow with maximum possible quality combined with smallest possible file size! Whether people understand this or not, my almost 30 years of expertise in the photographic industry has never shown me anything else. And all my work within the PW images system is (and only can be) based on this. ----------- I know that there also is a minor usage of the pageimage fields for simply displaying the original files to the frontend, but my best bet is that this is much lower then 10%. In my opinion this is not the intended use case for pageimages. The use of a file field would suffice, if it also could display an admin thumbnail in the backend. But because this functionality is missing in a file field, pageimage fields are used as "compromise solution" for this purpose.

Great find buddy! Thanks. Wow! This is massive!

? Heya, success! This seems to be a reliable and resource-saving method to bring webp support to (existing) PW sites: .htaccess only 2.0 ? (subtitle: learning more about htaccess directives) When only calling webpUrl | webpSrc for all image sources, without any conditional markup, the whole site / page tries to get all images as webp files. $options = ["webpAdd" => true]; $img = $page->images->first()->size(120, 120, $options); echo "<img src='{$img->webpUrl}' alt='{$img->description}' />"; The new htaccess directives will check if the browser supports webp. If not, it redirects the webp requests to the jpeg or png variations. Also if the browser supports webp, but a webp file is not available (for what ever reason), the htaccess redirects to an existing jpeg or png file. So, it redirects, it does not only rewrite the URL. Look at this screenshot, the redirected request has the correct file extension: The new .htaccess directives: To support png too, we need to copy the block and change .jpg to .png, or there is a way to implement both types into one block. We will see. ?

VSCode introduces Remote Development in the new Insiders Release! https://code.visualstudio.com/docs/remote/remote-overview Seems like they were watching our thread here closely ?

A module for managing files and folders. Supports creating, opening (e.g. viewing, playing, editing), renaming, moving, copying, deleting and searching for files. You can also view and change (not supported on Windows) file and directory permissions. https://github.com/matjazpotocnik/ProcessFileManager The author of FileManager component is (c) 2006 - 2018 Gerd Tentler, http://www.gerd-tentler.de/tools/filemanager/. I modified it to work with ProcessWire as a module. Please see license files on usage in commercial projects!

Maybe the most reliable way is: $webpsupport = (strpos($_SERVER['HTTP_ACCEPT'], 'image/webp') !== false); if($webpsupport) { //serve webp } else { //serve jpg or png or whatever } Of course, .htaccess is a viable solution...

Yes, there are [OR] conditions in htaccess.txt, but they are all [OR], not a mixture of [OR] and [AND]. I understand that, but how would .htacces know if image.webp is "made" from image.png or image.jpg? How would you decide which one is first? Also, when I upload image.webp I get "Pageimage: castle.0x260.webp - not a supported image type"

@matjazp If sending webp first is not possible to you, you may use the initial htaccess solution, what already worked for you, but with the redirect in the rewrite rule (R=301): AddType image/webp .webp <IfModule mod_rewrite.c> RewriteEngine On AddDefaultCharset UTF-8 ### Redirect regular PW JPEGs and PNGs to their WEBP image copies, ### if available and if the Browser supports WEBP: ## Does Browser accept WEBP images? RewriteCond %{HTTP_ACCEPT} image/webp ## Is it an existing file? RewriteCond %{REQUEST_FILENAME} -f ## Does a WEBP copy exist for it? RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.webp -f ## With an added GET var or GET value of skiprewrite we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch '*skiprewrite*'" ## With an added GET var or GET value from the PW Page Editor, we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch 'nc=*'" ## Is it a regular PW JPEG or PNG image, stored under site/assets/files? RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.(jpe?g|png)(.*)$ /$1$2$3/$4.webp [R=301,L] </IfModule>

This is old schooled from before PW 2.4, but it works fine for me. I use it until today, not only for modules that need backwards compatibility: /** * Default settings used by this module * * @return array */ static public function getDefaultData() { return array( 'myKey' => 'myValue', 'anotherKey' => 'anotherValue' ); } /** * Populate final merged data from default and DB * (use init or ready method for this, depending on your needs or preferences) */ public function ready() { $data = $this->wire('modules')->getConfig($this->className); // fetch the config data from DB for this module $data = array_merge(self::getDefaultData(), $data); // merge with default data foreach($data as $key => $value) $this->$key = $value; // populate final data to class properties } /** * the config screen: */ static public function getModuleConfigInputfields(array $data) { $data = array_merge(self::getDefaultData(), $data); // merge stored data from DB with default data // ... }

Seems like Microsoft was watching this thread closely ? Let's continue the discussion regarding VSCode in the dedicated VSCode Thread!

There‘s the $classLoader class in the core if you need to setup autoloading.

@BitPoet - enjoy the PCT - I have only done Tuolumne to Sonora Pass, but it was incredible. I am sure the entire thing will be an amazing experience!

News Update - 3 May 2019 - Part One The little speckled fella has been very busy on the trail. Despite being the smallest of its kind, she has lofty dreams. We've been working on the API and the Products GUI. In the next post, I'll tell you more about the API. Products Features and GUI Though there are a few issues still pending (aren't there always? sigh), I am relatively pleased with the results. Of course, during beta testing we'll received and incorporate feedback as best as we can. Only UI-Kit theme will be officially supported. Multilingual fields if site is multilingual Ajax powered inputs for fast and convenient editing Four types of products Physical product requiring shipping Physical product not requiring shipping (for collection) Digital product Service/Event (etc) products - e.g. Swimming lessons, Consultancy services, Hotel booking, etc Product Classification (ajax powered) by: Type: e.g. Belt, trousers, etc Brand: Puma, Sanyo, whatever (editors can type in or import brand names + planning to support logos) Categories (aka Collections): Multiple categories, e.g. Men, Girls, Hospitality Tags: Multiple tags can be entered, e.g. sale, amazing, etc Product Variants (consists of an Option (e.g. Colour) and an Option Value (e.g. Red) Add zero or n variants as you wish Live preview as you build variants Each created product variant can be enabled/disabled. Devs can then decide to either show that variant as unavailable or not show them at all. That's up to you :-). Apart from classifications, shipping class, inventory policy, weight and dimensions units, title and description (and this latter one may change), almost all product properties will vary by variant if variants are used Product properties include: Images Colour (more on this below) Downloads (centralised and reusable) Price and Compare Price (aka former price) Inventory policy (whether to track or not) Charge taxes SKU (stock keeping unit) Inventory (quantity) Allow back orders (aka overselling) - @note: this can be set per variant. This is useful if one variant can be restocked faster than others Weight Length Width Height Weight Unit (mg, g, kg, oz, lb, t) Dimensions Unit (mm, cm, m, in, ft ) Shipping Class - can be used for product-based shipping if needed (e.g. bulky goods, light, fragile, small items, perishable, etc) Images (more on this below) Downloads (more on this below) Images Multiple images can be added to both a product and its variants (in case its has some). Images add to the product itself can be used with all variants Images added to a variant are tracked/tagged as belonging to only that variant In some cases, it may not make much sense to add different images for similar variants. For instance, a small red hat and a large red hat could probably share the same images. Although we do not currently support specifying an already uploaded image as belonging to a group of variants, this may change in the future Colour Similar to images, can be set at both product and its variants level Colour saved in RGBA format Downloads Also similar to images, can be populated for both both product and/or its variants Multiple files can be added to a product A file designated for 'whole' product will be available to download irrespective which variant of the product was purchased Conversely, a file or files saved for a variant will only be available to the buyer if they buy that variant of the product The above is useful if you want buyers to be able to download different files of the same product. For instance, recently someone needed to sell two versions of a font as part of one product. This is a solution for such cases. TODO List Lots! e.g. default settings for some properties, e.g. weight unit, shop currency, etc. For the frontend, we are creating a rich language-aware API that you can use to build your shop however you want. There will be no rendering of markup (but see first post in this thread about a separate fully functional frontend shop). In the next post, we talk a bit about the API. Before that, here are some screenshots and a video demo (if you can spare some 20 minutes away from watching, er..., cat videos? ?) Screenshots Video Demo Thanks ?

Thanks for sharing this, a wonderful and funny read that also brings up some sentimental points. And, coincidentally, I also read his article about quitting at YouTube which ends with My request to take six months off next year to go backpacking (thru-hiking) on the Pacific Crest Trail was approved a week ago. Didn't think it might be this valuable in my CV?

I was reading a thread about Structured Data, is it possible to use this module to generate the AggregateRating? See MarcoPLY example. Thank you.

Yeah, I also had a good experience with it on the short tests I did so far. For me it would just be too much hassle to change php/db versions, create ssl certs, create vhosts or have a mailcatcher without such a tool...

Confession bear meme on tests: I'm a virgin. Never implemented any of them, mostly because I work alone for many years now. But found this cool project today, called Cypress. This is the easiest way to test a website or app I've found. Check their intro video out: https://docs.cypress.io/guides/getting-started/writing-your-first-test.html Note: I recommend this Chrome extension to speed up videos: https://github.com/igrigorik/videospeed as the narration of this video is kinda slow. ?

@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; }

Testing against the template object with the == "equal" operator is okay because it means "equal to after type juggling". So the template object is converted to a string for the comparison, and thanks to Template::__toString() the the string value of a template object is its name. When a page is first created (via admin) the only populated fields are Title and Name. So Page Reference fields are no different to any other field - they are empty until they are populated and saved in Page Edit. Maybe you want to hook Pages::published instead?

Not a completly serious tip for listening during developing, but maybe a good one for listening before starting. ? or

Not exactly the same, but check out Cobalt2 theme.

So, how's everyone? Version Control I finally started using VSC inbuilt version control, yipee! Thanks to @bernhard for the nudge. I got here after struggling to get a decent SourceTree replacement for Linux. Side Bar I've been wanting to move the side bar to the right but never got round to it. Today, I finally did it...and I like it! Any right side bar people here ??

Or just put that in the settings: { "files.associations": { "*.module": "php" } }

If you are developing modules I'd recommend changing .module to .module.php so every ide from every user will recognize it ?

Without a backslash class names resolve to current namespace (ProcessWire), and since DateTime class is in global namespace, you should put \ before DateTime. $today = new \DateTime(); Also, I've realized that I am getting the same error, but $pages->find() is still returning a result (because when DateTime object is converted to string it turns into an empty string '', and the selector becomes "published>'' ", which returns all pages). You can fix the error using: $today = new \DateTime(); // use UNIX timestamps $aFewDaysAgo = $today->modify('-2 days')->getTimestamp(); $lastYear = $today->modify('-1 year')->getTimestamp(); // or convert to ISO format // $aFewDaysAgo = $today->modify('-2 days')->format('c'); // $lastYear = $today->modify('-1 year')->format('c'); $latestPages = $pages->find("published>=$aFewDaysAgo"); $pagesSinceLastYear = $pages->find("published>=$lastYear");