Leaderboard

As one of the earliest RockPageBuilder users (I think you can say so) I have to admit that this is my go-to module since day one. If you liked the RepeaterMatrix module for building pages you will absolutely love this one. In my opinion it is far superior and the frontend editing possibilities seem to be the "missing link" that developers & designers were always looking for. I made around 7 websites with this tool (small and medium in scale) and I definitely will showcase some of them as this module is finally released ?

I'm thrilled to announce the official release of RockPageBuilder, the game-changing tool that's set to transform your web development journey (at least ChatGPT says so ??)! With its brand new drag-and-drop interface RockPageBuilder is your secret weapon for creating outstanding ProcessWire-based websites. Get a taste of the future of web development by visiting the demo page at https://pagebuilder.baumrock.com/ and exploring the RockPageBuilder documentation at https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/ Don't miss out on this exciting opportunity to elevate your web development game. Get ready to rock with RockPageBuilder! ??️ Early Bird Sales until 30.11. https://www.baumrock.com/processwire/module/rockpagebuilder/ Here is a quick demo video: And here is how to install it from scratch in under 5 minutes: Some showcase projects are already in the pipeline ? So be sure to subscribe to https://processwire.rocks/ or to https://www.baumrock.com/rock-monthly/ Have a great weekend!

Generate image placeholders for smoother lazyloading. Currently supports ThumbHash, BlurHash, and average color placeholders. I've been using the wonderful ImageBlurhash module for this in the past, but unfortunately it's no longer in active development. This new module adds ThumbHash and Average Color placeholder algorithms, improves performance by caching generated placeholders, fixes an issue when replacing images, and allows regenerating and clearing placeholders via the admin interface. Try it out using the installation instructions below or check out the GitHub repo for details. Why use image placeholders? Low-Quality Image Placeholders (LQIP) are used to improve the perceived performance of sites by displaying a small, low-quality version of an image while the high-quality version is being loaded. The LQIP technique is often used in combination with progressive lazyloading. How it works This module will automatically generate a small blurry image placeholder for each image that is uploaded to fields configured to use them. In your frontend templates, you can access the image placeholder as a data URI string to display while the high-quality image is loading. See below for markup examples. Placeholder types The module supports generating various types of image placeholders. The recommended type is ThumbHash which encodes most detail and supports transparent images. ThumbHash is a newer image placeholder algorithm with improved color rendering and support for transparency. BlurHash is the original placeholder algorithm, developed at Wolt. It currently has no support for alpha channels and will render transparency in black. Average color calculates the average color of the image. Installation Install the module using composer from the root of your ProcessWire installation. composer require daun/processwire-image-placeholders Open the admin panel of your site and navigate to Modules → Site → ImagePlaceholders to finish installation. Configuration You'll need to configure your image fields to generate image placeholders. Setup → Fields → [images] → Details → Image placeholders There, you can choose the type of placeholder to generate. If you're installing the module on an existing site, you can also choose to batch-generate placeholders for any existing images. Usage Accessing an image's lqip property will return a data URI string of its placeholder. $page->image->lqip; // data:image/png;base64,R0lGODlhEAAQAMQAA Accessing it as a method allows setting a custom width and/or height of the placeholder. $page->image->lqip(300, 200); // 300x200px Markup Using a lazyloading library like lazysizes or vanilla-lazyload, you can show a placeholder image by using its data URI as src of the image. <!-- Using the placeholder as src while lazyloading the image --> <img src="<?= $page->image->lqip ?>" data-src="<?= $page->image->url ?>" data-lazyload /> Another technique is rendering the placeholder and the original image as separate images on top of each other. This allows smoother animations between the blurry unloaded and the final loaded state. <!-- Display placeholder and image on top of each other --> <div class="ratio-box"> <img src="<?= $page->image->lqip ?>" aria-hidden="true"> <img data-src="<?= $page->image->url ?>" data-lazyload> </div>

This week I've been working on various ProcessWire related projects, but haven't pushed much to the core. There was a core feature I've been working on which I decided to instead put in a module. It's one of those things that should be be really beneficial for some people, but not necessarily needed by everyone, so it makes more sense as a module. This particular module expands upon the page-lock option and permission in ProcessWire. The page-lock option (which you'll see as the "Lock" status in the Settings tab of the page editor) provides the ability to lock a page for edits. This can be really useful if you want to prevent a particular page from being modified for whatever reason. For instance, maybe you are doing a $pages->get('/some/page/'); on the API side and if the path /some/page/ got changed, it would break something in the site. So to prevent clients from breaking the site, you lock the page to prevent them from screwing it up and breaking something on the site. This is quite useful, and often a life saver. But I don't use it as much as I'd like because of one downside. That downside is that it locks the entire page so that nothing on it can be edited. So it's just too heavy of a lock. What if you just wanted to lock the page so that the name, title and parent couldn't be edited, but everything else could be? That's what this new module enables. To lock a field in the page editor, you click its header and hold until a dialog pops up asking if you want to lock it. To unlock, you do the same thing. Once a field is locked, it remains locked (non-editable) until unlocked. Only users with page-lock permission on the page can lock or unlock fields. Locks can also be managed with checkboxes in the page editor Settings tab as well, just in case that is more convenient in some contexts. While these are editor locks rather than API locks, the locks do affect contexts outside the page editor too, such as actions in the page list. For instance, if you locked "parent" then you wouldn't be able to bypass it dragging a page in the Page List. I finished developing the module today, but I've not yet written documentation for it or uploaded to GitHub, etc., so I'm going to give it another day of work and testing before releasing it next week, and will cover more details in next week's post. Thanks and have a great weekend!

Could you please create a new topic if you need further help, thx ?

Thx @Jon just pushed release v4.7.1 with the fix ready for everybody to download ? Hm. Maybe a permission issue? Check if your user has the rockfrontend-alfred permission on the home template

Fixed the issue perfectly thank you The only other issue I have is Alfred not loading on the homepage of an existing site I've adding RockBuilder to, loads and works on all other pages just not the home page. Tested on a fresh install which worked as expected. So something within my site

Hey @Jon sorry for the issue - didn't think of subfolder installations! Can you try to change this in InputfieldRockPageBuilder.js:351 // from this $.get("/rpb-create-block/?field=" + field + "&name=" + name) // to that $.get(RockFrontend.rootUrl + "rpb-create-block/?field=" + field + "&name=" + name)

Hi, depends on your needs. Do the Pdf docs contain sensible data, are the docs restricted to users or groups? Can the docs easily guessed and accessed by changing a simple URL parameter like doc_001.pdf, doc_002.pdf etc? Depending on your needs, there are several options to implement it like simple .htaccess with Index listing, a restricted page with non guessable links … So some more infos would be useful here.

@da² the PageReference field needs a pagearray. Try this $classPageIds = PageArray([16988]); $page->carClasses = $classPageIds; echo $page->carClasses; // should output 16988 Be aware that this change will not be saved!

Hi, it seem a server issue, but for now we cant see what is the root source of the disk being filled. Do get an access to ssh again, which is the most important thing for now, you could use à logged user, and then in the admin, delete all logs file, then SSH asap. Once in the server, check /var/log and remove some old *.gz or the bigger to get more space, then investigate. Try to make a backup or an image of the server if you can before doing root cmd.

There are a couple of things you could try in the PW admin area. The first option would be to find a template that has the 'Clear cache for entire site' setting (or enable it). Find a page that uses it, and Save it. The next option, if that doesn't work, is to find a page (or pages) with large files added to them. Download a copy of the original files, and then delete them from the page. (You can re-add them later once the issue is resolved). This might give you enough free space to gain access via SSH to clear the cache, or to install the ProcessCacheControl module which lets you clear it from within PW. Whatever you do, though, try to be quick, to avoid it filling back up again before you have time to intervene.

Native AVIF support would be great for creating performant sites. When WEBP support was added to the core, it was done as a one-off addition. AVIF could be added in the same way by accessing an $image->avif property on the image object. However — I think @BrendonKoz touched on this above — adding more alternative output formats will probably require some rethinking to keep this part of the core modular. We'll definitely see more image formats being developed in the future, and it'd be great to access them from a single property or as a single parameter with formats and fallbacks, e.g. $image->url(300, ['format' => 'webp,png']).

I'm a little late to the game on this but wanted to throw out what we use on our PW sites. We keep all credentials in .env files in the root directory and then loaded using a package called phpdotenv. The .env file is loaded and then the credentials can be accessed at runtime via the $_ENV global. Some further details on this setup: .env files are automatically protected system files in Apache and will not be served (unless someone actively overrides this, but that would be bad). These files are not added to the Git repository and never stored. We have .env files for local, staging, and production. The contents of each file are stored in whole as a secure note in our password manager. The dotenv library is loaded once in config.php and the values are available globally. We also store credentials for external APIs and services. This allows us to store not only credentials, but any values that differ between local/staging/production. We store all of our config.php variable values in .env so that the config.php file is environment agnostic and we can always be sure that the .env is the single source of truth for the entire CMS configuration. We use Git to deploy to staging/production servers so using .env files allows us to push all of our code while knowing that sensitive information and data that changes between environments never gets mixed up. Also makes it very clear to anyone looking at the code that these values are stored in a dedicated system dot file. Here's the package, can be installed with composer https://github.com/vlucas/phpdotenv This is what a config.php file looks like with it in use: <?php namespace ProcessWire; // Load env variables from .env in root directory $dotenv = \Dotenv\Dotenv::createImmutable(__DIR__ . '/../'); $dotenv->load(); $config->debug = filter_var($_ENV['CMS_DEBUG'], FILTER_VALIDATE_BOOLEAN); $config->usePageClasses = filter_var($_ENV['CMS_USE_PAGE_CLASSES'], FILTER_VALIDATE_BOOLEAN); $config->useFunctionsAPI = filter_var($_ENV['CMS_USE_FUNCTIONS_API'], FILTER_VALIDATE_BOOLEAN); /** * Database Configuration */ $config->dbHost = $_ENV['CMS_DB_HOST']; $config->dbName = $_ENV['CMS_DB_NAME']; $config->dbUser = $_ENV['CMS_DB_USER']; $config->dbPass = $_ENV['CMS_DB_PASS']; $config->dbPort = $_ENV['CMS_DB_PORT']; $config->dbEngine = $_ENV['CMS_DB_ENGINE']; // Etc... Hope this might be useful to someone!

https://jakearchibald.com/2020/avif-has-landed/

Hi folks, I published "Simple file downloads with ProcessWire tutorial" today which explains how to make a simple download function with ProcessWire (tested with version 3.0+). Basically this is based on my post here in the forums