Leaderboard

Hello! I use .env files on every ProcessWire project to manage environment-specific configurations and settings. I've built a ProcessWire specific utility that makes using .env files a breeze. This post isn't intended to debate .env vs. config.php, use what you're comfortable with and prefer. That said, here are a few benefits to using .env files that may make it worth considering: Native support on web servers, including Apache, they are not served via http request by default True environment based secrets and settings management A standard file widely used and accepted as the method for managing secrets and sensitive values Able to store any value whether sensitive or not and access them globally Building a dedicated solution came from a discussion here on the forums where I threw together a rough implementation that needed little polish for real world use. It makes use of phpdotenv. This utility delivers the following: Easy use of and access to .env variables Caching the parsed .env for performance. This is a significant part of this utility and addresses a known need Automatic .env change recognition and re-caching Utilities to make working with environment variables feel ProcessWire native and a few extra nifty things What it isn't: A module. It's not possible to make a module for this need because the information kept in a .env file needs to be available before ProcessWire boots. Adding this to a new or existing project is very easy. It's designed to implement quickly and use immediately in your projects. Full documentation is provided in the Github repository. Here are a few examples of using this tool: <?php namespace ProcessWire; use Env\Env; if(!defined("PROCESSWIRE")) die(); $env = Env::load(__DIR__ . '/../'); // Make env available throughout the application $config->env = $env; $config->dbName = $env->get('DB_NAME'); $config->dbUser = $env->get('DB_USER'); $config->dbPass = $env->get('DB_PASS'); // Env::get() takes a second argument that is the fallback value if for any reason DEBUG doesn't exist $config->debug = $env->get('DEBUG', false); // Conditional values. By default, if the condition is falsey, Env::if() returns null $config->adminEmail = $env->if('APP_ENV', 'production', 'you@youremail.com'); // A fourth argument will be returned if condition is false, truthy/falsey output can be env var names or specific values $config->adminEmail = $env->if('APP_ENV', 'production', 'ADMIN_EMAIL', 'you@youremail.com'); // Conversely, you can also check if a condition is not met. $config->adminEmail = $env->ifNot('APP_ENV', 'development', 'ADMIN_EMAIL'); // Use one env value to set multiple config properties $config->advanced = $env->if('APP_ENV', 'production', false, 'ENABLE_ADVANCED'); // Never in production, change locally in env as needed $config->adminEmail = $env->ifNot('APP_ENV', 'development', 'ADMIN_EMAIL'); // Never send an email in dev, always on staging/production These helper methods make is very straightforward to implement a dynamic config file. This can be useful for using secure .env values while retaining the ability to commit and upload some types of changes to your config.php file without needing to touch .env values on the server. You can also use Env::pushToConfig(). As long as you use the "screaming snake case" naming convention for your environment variable names, type and value recognition are handled automatically. <?php $env->pushToConfig($config, [ 'usePageClasses' => true, 'templateCompile' => 'TEMPLATE_COMPILE', 'debug' => ['DEBUG', false], // Fallback to false 'advanced' => $env->if('APP_ENV', 'production', false, 'ENABLE_ADVANCED'), 'adminEmail' => $env->ifNot('APP_ENV', 'development', 'ADMIN_EMAIL'), 'httpHosts' => [ 'something.com', 'staging.something.com', 'something.ddev.site' ], ]); Using Env in your application files and templates can be very useful. In the above example we assigned the Env object to $config->env. This lets you access your .env variables globally and use some helpful methods. <?php if ($config->env->eq('APP_ENV', 'development')): ?> <script src="/some/development/stuff.js"></script> <?php endif ?> <?php if (!$config->env->exists('GOOGLE_API_KEY')) { $wire->error('A Google API key could not be loaded from the environment file.'); } try { // Do something that could fail } catch (Exception $e) { $message = $config->env->if('APP_ENV', 'production', 'Oh no. Friendly message here', $e->getMessage()); } This utility also automatically casts 'true' and 'false' values in .env files to booleans, and casts numbers to integers. It also includes several configuration options. I have been using this tool in production and have been happy with it. Maybe you might find it helpful in your projects as well. If you like it, throw a star on the repo. If you run into any bugs, file an issue on Github. I may publish it as a composer package at some point. Env utility for ProcessWIre on Github.

Hey @bernhard! First of all: Enjoy the rest of your vacation! 😉 And thank your for your reply! Yes, I am! It's done with the "byhour" property, like this, which obviously is way nicer than any dirty workaround approach. new RRule({ freq: RRule.MINUTELY, dtstart: new Date(Date.UTC(2025, 2, 5, 10, 0, 0)), count: 30, interval: 75, byhour: [10, 11, 12, 13, 14, 15, 16, 17, 18] }) Let me know if I can help in any other way. I'm in Vienna in April. Coffee's on me. 😉

@zilli This is a complete coincidence and the only reason I can speak to anything on this topic is that was just tinkering with PagesVersionsPro a week or two ago on a site that I'm building. Some interesting timing! @sodesign Here are a few comparisons. I'm not familiar with Craft, but hopefully the info will help your comparison with that. Differences from WP Versions are manually performed, there currently isn't an autosave feature, however this may change in the future if/when PVP replaces or supplants ProDrafts (that's a Q for Ryan) WP's style is more of a timeline "snapshot" method whereas PVP works with true page versions that are completely separate instances related only to the live page or version you created it from. You can manage and switch between versions based on a name and content first approach. You can create versions and then pick any one of them to edit or restore at any time without the "restore and edit" process that WP requires, so no "version stacking" by replicating when you may not need/want it. Because versions are manual, all versions are always named which is helpful for picking out specific states of a page or intent of edits rather than by timestamp like in WP. Where WP shows you HTML/markup comparisons between versions, PWP's compare feature shows you changes for each field as fully rendered field values, including image fields, so that you can see the changes side by side which is a much better end user experience. PVP allows you to fully load a version of a page in the browser and see it as visitors would see it for a visual comparison. It's worth noting that while you can create versions from any version whether live or not, comparisons are always made between a given version and the live page. I personally think this is a better approach because end users pretty much only care about what a version looks like compared to the live version. Please feel free to correct me if I got anything wrong with WP's implementation, I've seldom found it useful (if not outright frustrating) and may not be up to speed with more recent features. Also, I believe PVP is still in beta. I don't have enough experience to know what that means for real world use. If you have access to PagesVersionsPro I recommend installing it and taking it for a spin. You'll get the gist quickly and be able to decide how it works out for your needs. I'm looking forward to spending more time with PVP. For my current project I had to stick with ProDrafts as it's a carryover feature from their last PW site and it's not compatible with PVP. There was a post somewhere by @ryan about the status of PVP and a potential new release at some point in the first half of 2025 but he would be able to better speak on the status and plans for the module. Hope that was helpful!

It looks as if you are still using the old function in the _main.php file (line 6). At least that's what it says in the error message site/templates/_main.php (6): RockFrontend->styles()