Leaderboard

With the next SnipWire release I plan to support only V3 of the Snipcart engine. Supporting both versions would be too much effort. How do you think about this?

I found the solution with wireLangReplacements() function. /** * Replace "Missing required value" text ONLY on frontend * */ if($page->template->name != "admin") { wireLangReplacements([ 'Missing required value' => 'My replacement value', ]); }

Yeah, my module was approved and is now listed in the ProcessWire module catalog https://processwire.com/modules/no-cookie-without-consent/. Thanks to all and have fun.

This week we've been resolving a few more remaining issues, mostly those that take more time or discussion. So there's not many commits to the dev branch this week, but that also means we're very close to having the main/master version ready. I'm hopeful we'll be there by this time next week. If you have a chance to test the current dev branch please do, and let us know if you run into any issues. Thanks and have a great weekend!

Not sure if I'll post every issue here, but at least here's the first one ? --- Hey there, RockStar developers! ? What's new in the Rock Universe? ? baumrock/AdminStyleRock v1.3.0 Make your ProcessWire backend truly yours with the latest AdminStyleRock update! Version 1.3.0 brings a super cool feature that allows you to effortlessly set a custom logo in the ProcessWire backend. Your admin experience just got a whole lot snazzier! ? ? baumrock/RockFrontend v3.3.0 Get ready for greatness with RockFrontend v3.3.0! We've introduced exciting new features, including static site rendering and a nifty view-folder feature. The top bar's hidden style has been polished for that sleek look. While we're working on documenting these gems, be sure to explore and experiment with these additions! ? ? baumrock/RockShell v2.1.0 Our new db:download command streamlines database management even more. And here's a treat: an alias for your laptop lets you simply call "rockshell db:pull staging." Say goodbye to the lengthy commands and hello to efficiency! ?️ ?️ baumrock/RockMigrations v3.29.0 Prepare to be wowed by RockMigrations v3.29.0! This version brings a fresh approach to shipping your modules with custom page classes. Plus, our new path helper methods ensure your paths are on point, with normalized separators and no more pesky multiple slashes. Another really helpful feature was added to RockMigrations this month, but then removed because it's now part of TracyDebugger itself! Say hello to the "Redirect Info" section in the "Request Info" panel! Have you ever been redirected by something and didn't know why? That belongs to the past as you can now clearly see that the redirect was triggered by line 3 in /site/templates/home.php  ? Sneak Peek: Exciting Commercial Modules We've got some fantastic updates brewing for our commercial modules, slated for release soon. Brace yourselves for RockCommerce, the power behind the shop on baumrock.com, where you'll find our incredible modules up for grabs. And speaking of modules, RockPdf has been making monumental strides. It's now responsible for crafting the invoices that accompany every order. ?️ ? Stay Connected: As we rock and roll into the future of development, there's plenty more where this came from. Stay tuned for more exciting updates, innovative features, and game-changing modules that will take your projects to new heights. Thank you for being part of our developer community. Your passion and feedback keep us strumming along. Until next month, keep coding and keep rocking on! ?? Keep rocking, Bernhard

@gornycreative I've just added this feature to the latest release of RockMigrations! It will also show you the correct code to copy&paste:

Lots of great stuff in RockMigrations v3.29.0 Sorry for the ugly background but otherwise the links don't work!

Now I understand. Looks like an update should fix your issue:

Wow, what a great article. Communication - Ownership - Performance is always a model to go

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!

This is what I do, which is almost like (2). site/config.php: <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); // Other PW default config values... // ... $config->dbHost = 'localhost'; $config->dbName = 'example_site'; $config->dbUser = ''; $config->dbPass = ''; $config->dbPort = '3306'; $config->dbCharset = 'utf8mb4'; $config->dbEngine = 'InnoDB'; // Environment overwrite if (file_exists(__DIR__ . '/config.local.php')) { require_once(__DIR__ . '/config.local.php'); } config.local.php: <?php namespace ProcessWire; $config->dbUser = 'example_site_user'; $config->dbPass = 'example_user_pass_123456'; config.local.php is in .gitignore, so never committed, and separate config.local.php files exist on testing / live environments. (I use DeployHQ and this is added as a config file that gets deployed with the rest of the code). To me, the benefits of this approach means that the entire config can be changed depending on the environment, and used to turn things on or off, like debug or advanced mode.