Leaderboard

This week we’ve got a couple of really useful API-side improvements to the core in 3.0.151, among other updates. First we’ll take a look at a new $config setting that lets you predefine image resize settings, enabling you to isolate them from code that outputs them, not unlike how you isolate CSS from HTML. Following that, we’ll introduce and show you how to use a handy addition to our static language translation functions. If you’ve ever come across the term “abandoned translation”, you’ll really like what this adds— https://processwire.com/blog/posts/pw-3.0.151/

I've dabbled a bit and adapted my cache module to work with Redis (working mostly on Windows, this was a bit of an adventure, but Windows Subsystem For Linux saved the day). CacheRedis - a simple Redis cache interface for ProcessWire There should be enough documentation to get started in the README. In short, it has the following methods: $redis->fetch($key[, $expire, $func]) $redis->store($key, $expire, $value) $redis->delete($key) $redis->flush() $redis->renderFile($file[, $expire[, $options]])

--- Module Directory: https://modules.processwire.com/modules/privacy-wire/ Github: https://github.com/blaueQuelle/privacywire/ Packagist:https://packagist.org/packages/blauequelle/privacywire Module Class Name: PrivacyWire Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md --- This module is (yet another) way for implementing a cookie management solution. Of course there are several other possibilities: - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/ - https://github.com/webmanufaktur/CookieManagementBanner - https://github.com/johannesdachsel/cookiemonster - https://www.oiljs.org/ - ... and so on ... In this module you can configure which kind of cookie categories you want to manage: You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience. Currently there are four possible cookie groups: - Necessary (always enabled) - Functional - Statistics - Marketing - External Media All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ... When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax: <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision. If you want to give the users the possibility to change their consent, you can use the following Textformatter: [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie. You can also add a custom link to output the banner again with a link / button with following class: <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> I would love to hear your feedback ? CHANGELOG You can find the always up-to-date changelog file here.

Modules Manager 2 provides an easy to use interface to download, update, install, uninstall and configure modules. It is meant to provide an optimized alternative to the core ProcessModule dashboard. Maybe @ryan agrees to merge it to the core at some point when it is finished and polished. Features: Seamlessly download, update, install, uninstall or delete modules Live-Search (aka find as you type) for module names Live-Search (aka find as you type) for categories Browse new and unkown modules from the modules directory on modules.processwire.com Choose your favorite layout (cards, reduced cards, table) Modern UIKit design (therefore only works with AdminThemeUikit) Caches the module list from modules.processwire.com directory locally. What is Modules Manager 2? Why a new module manager? Some people including myself think that the actual module installation in ProcessWire could be improved in some places. Make it easy for ProcessWire beginners and power users Offer better discoverbility to find the right module Make it easier and faster for powerusers to manage modules A manager that list all official modules is a feature, that many other frameworks/CMS's like ModX, WordPress or PrestaShop have by default. What are the disadvantages of the actual core module interface? Installation of a module is not very user-friendly: You have to be aware where to get new modules, search for a module, copy or remember the module name or URL, go back to your ProcessWire installation, paste the module name(URL, click on "get module info" and finally install the module It only displays installed modules, not the ones that are available in the modules directory Uninstalling a module requires you to go to the module detail page, click a checkbox and then submit the change. After that you have to go back to the module overview page. It only displays installed modules, not the ones that are available in the modules directory, so it makes discovering modules hard BETA software Use this module at your own risk. I am not responsible for any damage or unexpected behaviour. Some things might not work fully, please see the TODO list for details. I need your feedback and help This module is still in development and I am happy to discuss with you and get some feedback. What do you like? What is missing? What could make the process even easier? Ask, suggest or provide pull requests. You can download the module at https://modules.processwire.com/modules/modules-manager2/ or from Github: https://github.com/jmartsch/processwire-modules-manager2

@astock: I just checked the code. While the hasVoted method is called before renderPoll(), it doesn't get the current user. I have added a github branch with a fix if you want to give it a spin.

@MarkE - The events just have a page field multiple where you select the works being performed. Some events come in through Boosey and those have a reference ID we store so those are auto assigned. Works pages just have a section that searches for upcoming events and outputs them. But there are a ton of other ways that works are connected to each other, using versions, members and custom taxonomies that focus the relationships that are specified...

Maybe a directory traversal attack (to install backdoors or whatnot). I would immediately contact the hosting company, and also check for suspicious files. Lock down your forms, or any other potential areas that allow user-input.

One of the reason could be that "News" (as a string) is hardcoded inside some selector. Just a quick guess.

Yeah, I also had this problem. I managed to style the icon using inline styles (doing that manually first), eg <path fill=red ... > but I couldn't find a way to control the size of the icon. I tried several approches. I even used the SVG as <img src=...> but then the coloring part didn't work any more. TTF now works find for both situations except for duotone icons (which would be nice but not necessary). Please follow the new readme exactly, I'm using the font https://www.fontsquirrel.com/fonts/rock-salt successfully in my PDF: This is my setup for this font + fontawesome pro: /** @var RockPdf $pdf */ $pdf = $this->modules->get('RockPdf'); $pdf->settings([ 'mode' => 'utf-8', 'format' => 'A3-L', 'dpi' => 300, 'img_dpi' => 300, // fonts 'fontdata' => (new \Mpdf\Config\FontVariables())->getDefaults()['fontdata'] + [ 'fancy' => [ 'R' => 'RockSalt.ttf', 'I' => 'RockSalt.ttf', ], "fab" => [ 'R' => "fa-brands-400.ttf", 'I' => "fa-brands-400.ttf", ], "fad" => [ 'R' => "fa-duotone-900.ttf", 'I' => "fa-duotone-900.ttf", ], "fal" => [ 'R' => "fa-light-300.ttf", 'I' => "fa-light-300.ttf", ], "far" => [ 'R' => "fa-regular-400.ttf", 'I' => "fa-regular-400.ttf", ], "fas" => [ 'R' => "fa-solid-900.ttf", 'I' => "fa-solid-900.ttf", ], ], ]); ... Then I can just add the "fancy" class to get the RockSalt font. Don't forget to define the font in CSS: .fancy { font-family: fancy; } Does that help?

I've kept hearing that one for the last twenty years, yet here we are. I think that's enough said ?

Another update - RockPdf now supports FontAwesome 5 in mPDF library ?? This works using webfonts (after I've unsuccessfully tried with SVG) and it supports resizing and coloring icons via CSS or LESS (wich didn't work when using SVG). I've updated the readme: Using FontAwesome 5 with mPDF Download a copy of fontawesome (https://fontawesome.com/download, eg Free for Web) Copy the TTF file into your /site/assets/RockPdf/fonts/ folder Add your font to your settings and start using icons in your PDFs // tracy console $pdf = $modules->get('RockPdf'); $pdf->settings([ 'fontdata' => (new \Mpdf\Config\FontVariables())->getDefaults()['fontdata'] + [ "far" => [ 'R' => "fa-regular-400.ttf", 'I' => "fa-regular-400.ttf", ], ], ]); $icon = "<i style='font-family: far;'>&#xf118;</i> "; $pdf->write($icon.'Hello World ' . date('H:i:s')); d($pdf->save()); You'll notice that we used the unicode representation of the icon. You can find all the codes on the cheatsheet (https://fontawesome.com/cheatsheet) or on the details page of the icon: https://fontawesome.com/icons/smile?style=regular Be careful to use the correct style (regular, solid, etc) and unicode! Special thx to jamesfairhurst Using metadata to get the unicode Too complicated? RockPdf comes with a helper so that you do not need to take care of all this and just use the regular fontawesome classes that you might already be familiar with! To make that work, just copy the icons.json file that is shipped with fontawesome in the metadata folder into the RockPdf assets folder /site/assets/RockPdf/fonts. // tracy console $pdf = $modules->get('RockPdf'); $pdf->settings([ 'fontdata' => (new \Mpdf\Config\FontVariables())->getDefaults()['fontdata'] + [ "far" => [ 'R' => "fa-regular-400.ttf", 'I' => "fa-regular-400.ttf", ], ], ]); $pdf->write("<style>.far { font-family: far; color: blue; }</style>"); $icon = $pdf->icon('far fa-smile'); $pdf->write($icon.'Hello World ' . date('H:i:s')); d($pdf->html()); // print content to console $pdf->save(); // save file to file system Using this technique you can easily style your icons using CSS or even LESS (when using RockLESS). Another example Unfortunately duotone icons do not work (if you know how to make them work please drop me a line!). Also styling the icons is sometimes a bit tricky - some CSS selectors work while others don't. Using classes directly on the icon worked best for me: $icons = $pdf->icon('fas fa-guitar red-2x') .$pdf->icon('far fa-guitar red-2x') .$pdf->icon('fal fa-guitar red-2x') .$pdf->icon('fad fa-guitar red-2x'); .fab { font-family: fab; } .fad { font-family: fad; } .fal { font-family: fal; } .far { font-family: far; } .fas { font-family: fas; } .red-2x { font-size: 10mm; color: red; } v2.0.1

What I know has been pieced together from official docs and discovered through trial and error, so I can't provide a good link there. However, I've pushed a few pieces into a small module based on Memache that can be a (partial) stand in for WireCache as an example. You can find it on github as PwMemcache. It has just a few methods to set/get/delete cache entries and doesn't allow saving and restoring of full pages like WireCache does, but it does have a renderFile method similar to WireCache. Maybe that could be a starting point. Most of the magic in using memory caches is using well thought out cache keys to avoid conflicting names (you're likely to use them more intensively than database caching) using reasonable expiry values (same as with database caches) preventing outdated data (e.g. by deleting entries when pages are changed, there's little 'automatic magic' there) taking care of special considerations when data is serialized and later unserialized, since behavior differs between solutions How exactly that best goes depends on the features of the caching solution. Unlike WireCache, many in-memory solutions have no wildcard deletion operators, so you sometimes have to build workarounds. My module for example does this when you pass PwMemcache::expireSave to the renderFile method. The cache contains an extra array where all the entries are stored that have to be cleared when a page is saved. In a Pages::saved hook, this entry is read, all cache entries listed in the array are deleted and the entry is emptied.

Hi guys, I was very excited for this module, but my life took a huge direction change and I no longer have the time to invest in module development. I am gonna leave the files here. You guys can take it and run. Maybe there might be something useful here. Maybe not. I still think it's a good idea to do drag and drop modal building in PW. So hopefully one day something like that can come to light. I love this community and I love ProcessWire. Live long and prosper. - Joshua Designme 2.zip

Right now only the default values can be overwritten via language translation files. But good hint - I'll add multi-language support for the config fields as well.

Perhaps you have auto-prepended and/or auto-appended template files in your /site/config.php, in which case you would want to use the $options array to override those when rendering the page, e.g. foreach ($pages->find("template=article") as $article) { $content .= $article->render('teaser.php', ['appendFile' => null]); }

Welcome to the PW forums @Anders! There are many different ways you could do this and at the end of the day it comes down to personal preference. Myself, if this was a one-off listing of teasers that wasn't to be used on other templates I would tend to build the markup directly in the template file and not render any other files. And if it was a listing that was to be used in several template files I would tend to render a file that looped over multiple pages and I would pass those pages to the rendered file. I prefer to output markup directly and make use of the Markup Regions feature, but to keep with your case of populating a $content variable it would be something like this: $content .= $files->render('teasers', ['items' => $pages->find("template=article")]); BTW, the wireRenderFile() function is sort of obsolete as far as I can see because it is just an alias for $files->render(). But if you wanted to render a page with something similar to your example... ...then you could look at the (largely undocumented) $page->render() method. The best resource that I know of for this method is Ryan's post here: Also you can read the comments for PageRender::renderPage() in /wire/modules/PageRender.module (which is what $page->render() calls behind the scenes). So you could do something like: foreach ($pages->find("template=article") as $article) { $content .= $article->render('teaser.php'); }