Leaderboard

ProcessWire 3.0.163 adds a few new $pages hooks (see PW Weekly #323 for details), adds configurable module upload/install options (ProcessModule), and contains many other minor updates, code refactoring and optimizations. But by far, the majority of updates and commits are related to resolving more than a dozen recent issue reports. That will be the focus next week too, as the goal is to have the next master version out by the end of the month, or the first week of August. Priority focus is on any issues that might be bugs introduced between 3.0.148 (previous master) and 3.0.163, as we want to make sure at minimum we aren’t adding any new bugs from one master version to another. Regarding the new configurable module upload options, the intention here is to add additional safety by having the option of locking down the ability to install modules from the admin. As convenient as it is to be able to install and upgrade modules (during development) directly by URL, file upload or directory; the reality is that—depending on the case—it’s also not the safest thing to have on a client’s production site once development is finished. I think it’s best if module installation and upgrades are left to web developers, who are better equipped to resolve any technical issues that might arise during the process. Though it also depends on the installation, which is why I thought it should be configurable. So now you can specify which install options are available, and they can also depend on whether the site is in debug mode or not: $config->moduleInstall = [ // allow install from ProcessWire modules directory? 'directory' => true, // allow install by module file upload? 'upload' => 'debug', // allow install by download from URL? 'download' => 'debug', ]; Above are the current defaults, which can be changed by specifying your own preferred options in /site/config.php. Boolean true means always allowed, boolean false means never allowed, and string “debug” means: allowed if the site is in debug mode. (I’m currently debating on whether the ‘directory’ option should also be ‘debug’ as well.) In addition to these configuration options, the ProcessModule “New” tab now also provides instructions for manual installation of modules. None of us need it I know, but someone new to ProcessWire might see the prior “New” tab and not realize there’s a really simple and safe way to install modules from the file system. So the instructions just seemed to make sense there for consistency. ProCache 4.0 β released Last week I mentioned a new version of ProCache would be coming out this week and version 4.0 of ProCache was released on Wednesday in beta form. It’s available for download now in the ProCache board download thread. This is one of the biggest upgrades for ProCache yet. If you are upgrading from a previous version, read the upgrade instructions in the README.txt file included with it, as it will guide you through some of the new features, and may save you from having to make an update to your .htaccess file. I mentioned much of this in last week's post, but here’s a summary of what’s new in this version of ProCache relative to the previous version: Major refactor of entire module. Now native to ProcessWire 3.x (ProcessWire 3.0.148+ recommended). New .htaccess rules for static cache. New ability to select .htaccess version (v1 or v2, Tweaks tab). New option to specify how trailing slashes are handled (Tweaks tab). Upgrade SCSS compiler from version 0.7.8 to 1.1.1. Add Wikimedia LESS as additional option to Leafo LESS (select which you want on Tweaks tab). Improved per-template lifespan settings. Improved default and per-template behavior settings. New cache clear behavior: Family (parent, siblings, children). New cache clear behavior: References (page that reference saved page). New cache clear override: No-self (skip clearing page that was saved). Per-template behaviors now supports clearing specific pages by ID or selector. Numerous minor fixes and optimizations throughout. Removed direct .htaccess writing ability, replaced with live example file. Lots of new hookable methods for special cases. New “Tests” tab with the following built-in tests: cache function and performance; cache clear behaviors tests; test http response headers; test for GZIP, LZW, zlib/deflate or Brotli compression; Test for keep-alive connection. Thanks for reading and have a great weekend!

2021 update These things change and get tweaked over time, as stuff always does. We can make the size declaration a little more relevant. Declare a selection of sizes for your svg to "encourage" chromium-based browsers to use it instead of the larger bitmapped 192x192 and other assorted icons. We also need to thread the needle to ensure app start icons don't get confused and end up with an icon that is smaller than desired. Declare it last, after your png fallbacks - last one that is suitable size *must* get the nod. Counter-intuitively, declare that your svg is 150x150. (adjusted for 2021) ? "sizes": "48x48 72x72 96x96 128x128 150x150 256x256 512x512 1024x1024", { "name": "Alfresco bar + bistro, Eumundi", "short_name": "Alfresco", "description": "Relaxed outdoor dining on our spacious deck in Eumundi", "start_url": "/", "display": "standalone", "background_color": "#acbd72", "theme_color": "#acbd72", "icons": [ { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon-48x48.png", "sizes": "48x48", "type": "image/png", "purpose": "any" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon-192x192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/maskable-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }, { "src": "https://www.alfresco-bar-bistro.com.au/site/assets/files/favicons/favicon.svg", "sizes": "48x48 72x72 96x96 128x128 150x150 256x256 512x512 1024x1024", "type": "image/svg+xml", "purpose": "any" } ] } Cross-Origin-Resource-Policy (CORP) manifest/icon bug A slightly-related testing note, if you are incorporating Cross-Origin-Resource-Policy (CORP) to enhance site security. Please note there is a chromium bug which affects chromium dev tools ability to properly display your manifest icons: Chromium DevTools bug: Cross-Origin-Resource-Policy prevents manifest icons from loading This long-term bug doesn't seem to affect the way the manifest itself works or the icons, just their display in Dev tools > Application > Manifest in Chrome, Edge, Brave, Opera... sheesh. Firefox Dev tools continues to happily display them without a problem. ------------------------------------------------------------------------------------ Quick tip for 2020 web manifests, which I couldn't find anywhere else. Wanted web manifest on Chrome/Edge to download the tiny favicon svg, instead of the larger 192x192 png it wanted to by default. Not a big deal, but mildly annoying: 15kb (non-scalable) png vs 1.5kb (infinitely scalable) svg. After a little head-scratching and fiddling around, came up with a solution that seems to do the trick. Declare it last, after your png fallbacks - last one that is suitable size *must* get the nod. Counter-intuitively, declare that your svg is 150x150. (adjusted for 2021) Mine isn't. Never has been, it's a scalable vector graphic. Simply declaring it is 150x150 in the manifest is enough to get the job done. Suspect the Chrome/Edge engine declares that any non-specified svgs are given that 150x150 size and anything else returns as a "fail". Without declaring a size on it, or declaring it as anything other than 150x150, it just wouldn't load. Weird, but works, so I'm happy ? { "name": "Longer App/Business Name", "short_name": "Short Name", "description": "Description of App/Business", "start_url": "/", "display": "standalone", "background_color": "#880000", "theme_color": "#880000", "icons": [ { "src": "favicon-192x192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" }, { "src": "favicon-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" }, { "src": "maskable-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }, { "src": "favicon.svg", "sizes": "150x150", "type": "image/svg+xml", "purpose": "any" } ] }

Hello, I would like to report a tiny bug in the latest dev branch of PW. I downloaded the dev zip file from here : and tried to install. Everything went fine but hit the error message as in the screenshot. So its says there is an unexpected * in the site/config.php file. I checked the file and found that it supposed to be a comment actually but somehow, the position of '/' is wrong to make the comment '/* ' . Hence I manually edited the file and went to installation but the error repeated in different line once I passed the admin password setup page. So the PW installer is writing the site/config.php file with newly updated DBinfo. So I manually edited the site/config.php file before click the DB configuration section, next time. It passed and installation finished. But I think this is somehow a bug ? I dont know, just notifying it here. another thing I noticed that - the button says the version 3.0.162 but the downloaded zip installed admin shows ProcessWire 3.0.163 dev © 2020

Good news! We are live now! AppApi has been approved and now appears in the modules directory: https://modules.processwire.com/modules/app-api/ Thank you for your many reactions to the release - I hope it helps you build the best apis you can imagine!

I'm currently building a Fieldtype/Inputfield for selecting date and time ranges (eg for events). There was quite some interest in this thread, so I thought I start a dedicated discussion... Background: I guess everybody of us knows the problem: You want to present events on your website and you start with a new template and a title and body field... For events you'll also need a date, so you add a datetime field called "eventdate". Maybe the event does not take place on a specific day but on multiple days, so you need a second field... Ok, you rename the first field to "date_from" and add a second field called "date_to". So far, so good. Then you want to list your events on the frontend. Simple thanks to the pw API, you might think. But you realize that it's not THAT simple... Which events take place on a specific day? What would the selector be? Yeah, it's not that complicated... it would be something like: $from = strtotime("2020-01-01"); $to = strtotime("2020-02-01"); $events = $pages->find("template=event, date_from<$to, date_to>$from"); Why? See this example, where the first vertical line represents the $to variable and the second is $from: The start of the event must be left of $to and the end must be right of $from ? Ok, not that complicated... but wait... what if the date range of the event (or whatever) was not from 2020-01-18 to 2020-02-25 but from 18 TO 25 (backwards)? The selector would be wrong in that case. And did you realize the wrong operator in the selector? We used date_to>$from, which would mean that an event starting on 2020-01-01 would NOT be found! The correct selector would be >=$from. That's just an example of how many little problems can arise in those szenarios and you quickly realize that the more you get into it, the more complicated it gets... Next, you might want to have full day events. What to do? Adding a checkbox for that could be a solution, but at the latest now the problems really begin: If the checkbox is checked, the user should not input times, but only dates! That's not possible with the internal datetime field - or at least you would have to do quite some javascript coding. So you add 2 other fields: time_from and time_to. You configure your date fields to only hold the date portion of the timestamp and show the time inputfields only if the "fullday" checkbox is not checked. We now have 5 fields to handle a seemingly simple task of storing an event date. That's not only taking up a lot of space in the page editor, you'll also have to refactor all your selectors that you might already have had in place until now! Idea So the idea of this module is to make all that tedious task of adding fields, thinking about the correct selectors etc. obsolete and have one single field that takes care of it and makes it easy to query for events in a given timeframe. The GUI is Google-Calendar inspired (I'm acutally right now liking the detail that the second time input comes in front of the date input). I went ahead and just adopted that: Next steps I'm now starting to build the FINDING part of the module and I'm not sure what is the best way yet. Options I'm thinking of are: // timestamps $from = strtotime("2020-01-01"); $to = strtotime("2020-02-01")+1; // last second of january // option 1 $pages->find("template=event, eventdate.isInRange=$from|$to"); $pages->find("template=event, eventdate.isOnDay=$from"); $pages->find("template=event, eventdate.isInMonth=$from"); $pages->find("template=event, eventdate.isInYear=$from"); // option 2 $finder = $modules->get("RockDaterangeFinder"); $finder->findInRange("eventdate", $from, $to, "template=event"); $finder->findOnDay("eventdate", $from, "template=event"); ... I think option 1 is cleaner and easier to use and develop, so I'll continue with this option ? Future As @gebeer already asked here I'm of course already thinking of how this could be extended to support recurring events (date ranges) in the future... I'm not sure how to do that yet, but I think it could make a lot of sense to build this feature into this module. I'm not sure if/how/when I can realease this module. I'm building it now for one project and want to see how it works first. Nevertheless I wanted to share the status with you to get some feedback and maybe also get your experiences in working with dates and times or maybe working with recurring events (or the abandoned recurme field). For recurring events the finding process would be a lot more complicated though, so there it might be better to use an approach similar to option 2 in the example above.

Page Reference Default Value Most ProcessWire core inputfield types that can be used with a Page Reference field support a "Default value" setting. This module extends support for default values to the following core inputfield types: Page List Select Page List Select Multiple Page Autocomplete (single and multiple) Seeing as these inputfield types only support the selection of pages a Page List Select / Page List Select Multiple is used for defining the default value instead of the Text / Textarea field used by the core for other inputfield types. This makes defining a default value a bit more user-friendly. Note that as per the core "Default value" setting, the Page Reference field must be set to "required" in order for the default value to be used. Screenshot https://github.com/Toutouwai/PageReferenceDefaultValue https://modules.processwire.com/modules/page-reference-default-value/

Just happend on PW 3.0.163. Fixed by rebuildAll method available since 3.0.156 $pages->parents()->rebuildAll();

This one is designed to work in the admin, so all of the settings, and how the javascript works is only going to work in the admin. But it's such a simple plugin, you could easily roll it into a formbuilder form.

I didn't know the configurable module upload functionality was coming and this was an awesome way to end the week. Can't wait to play with it!

In this post (https://processwire.com/docs/start/api-access/) Ryan says So, this has made me thinking it should be. Also I tried setting it on the fly to false before creating the second instance. But I had not verified that it was definetly disabled. Now after writing it into all site/config.php files, the error is gone and I get multiple instances. But I encountered a new weird thing: I loaded three instances with the PW versions 3.162 + 3.0.160 + 3.0.155. But when executing this code, every instance shows me the 162 !! ?? ? // bootstrap ProcessWire master instance require_once(PW_MASTER_PATH . 'index.php'); mvd($wire->getInstanceNum() .' # '. $wire->config->version); // echo instance and version of the master (expected: 3.0.162) $wire = new \ProcessWire\ProcessWire(PW_MASTER_PATH); mvd($wire->getInstanceNum() .' # '. $wire->config->version); // echo instance and version of the new created instance from master (expected: 3.0.162) $site2 = new ProcessWire(PW_SITE2_PATH, PW_SITE2_HTTPURL); mvd($site2->getInstanceNum() .' # '. $site2->config->version); // echo instance and version of site2 (expected: 3.0.160) $site3 = new ProcessWire(PW_SITE3_PATH, PW_SITE3_HTTPURL); mvd($site3->getInstanceNum() .' # '. $site3->config->version); // echo instance and version of site3 (expected: 3.0.155) die('RIP');

I had not. It works fine now, thank you.

Are you sure that it outputs plain text? Maybe it is html entity encoded by a defined Text Formatter in your field. You can check this under Fields > NameOfYourField > Details the first point is "Text Formatter". If there is something selected like HTML entity encoder, htmlspecialchars, then remove it and try again, (after a browser cache flush).

Here's a little text formatter module that redirects all external links found in a textarea (e.g. for hit counting) to a given URL. TextformatterExternalRedirect GitHub repo As TextFormatters do, this module modifies the contents of the textarea (HTML) at rendering time. It prepends the given URL to the link address for external links (http and https), optionally makes sure that the link is opened in a new window and allows you to add css classes to such links. All options can be configured in the module's configuration settings. Usage: Download the zip archive and extract it to site/modules, the rename the top folder to TextformatterExternalRedirect Go to the backend and select "Modules" -> "Refresh", then click "Install" for "External Link Redirect" Click "Settings" and configure the module Go into the field configuration for the field(s) you want this formatter to apply to and add it from the dropdown Done, now any external links in the configured fields will have the configured settings applied Feel free to leave feedback and post and questions you have here.

Adds a class="external" and a rel="nofollow" to every external link by default. Optionally adds a rel="noopener", a rel="noreferrer" and a target="_blank". Note: This module is based on TextformatterMarkExternalLinks and some improvements of @teppo that were never implemented due to module's author inactivity. Download TextformatterOptimizeExternalLinks Requirements ProcessWire 3.x Changelog 1.0.0 (3 April 2018) Initial release