Leaderboard

Hey @Ivan Gretsky No reason whatsoever — probably just forgot. Submitted ?

Hi guys! I'm a bit anxious because this is the first module I present! (beta modulo) But I will finally be able to share something with the community too! :) This is a BETA version of the PayPal payment system called: PayPal Commerce Platform. It is an advanced system (Business Pro account is needed) that brings various benefits in terms of fees and above all integrates direct payment with credit/debit cards. The module integrates with Padloper 0.0.2, which is the current installation I'm using. This system integrates the classic PayPal buy button, the alternative or local payment method and the new payment system: credit/debit cards that doesn't go through the PayPal account. It is a Stripe-style payment, it connects directly with the bank and integrates 3D security validation. I say that it is a BETA because this module currently only works with Sandbox account, to put it live you need to change API url manually (manually for the moment). Because this module is not ready for live: I would like to have your opinion on how I built the module (is the first one I do). I don't want to share something that is not fish but I need a comparison with someone more experienced than me, for be sure that this is the best way to code the module. If you want to try this I created a git, you will find all the instructions for installation and correct operation. (Git has a MIT licensed) https://github.com/MarcooRo/processwire-PayPal-Commerce-Platform I hope I did something that you guys can like :) UPDATE I have been testing the form for several days and everything is working fine. Each order enters correctly, so I have updated the repo with the latest changes and I can confirm that this version is ready for live! I have updated the repo: Added error message + popup Fixed some bugs related to multilingual Updated the switch for checking the responses of the 3D security system

Good day, @teppo! Why isn't the module in the PW modules directory yet? Are there any reasons for it not to be there?

Check the classes that are rendered within the body tag, you should see useful classes there to override css per-role. If you mean tabs/fields within the edit pages screen, there is a lot that can be made through roles and field permissions. https://processwire.com/blog/posts/field-permissions-overrides-and-more-2.6.2/#granular-access-control-with-field-level-permissions This post is old but I bet (without guarantee) that it most likely remains the same or very similar. This Dashboard is super configurable and I bet you can simply wrap the configuration of the panels into some switch/if statements to deliver configurations per role/user.

I have a page with 5 different templates to choose from when adding a new page. I want to have individual default page names on every new pages that is added as child. I know the function "Name format children" but i only works if you have a single template file attached to the page. Or can i make a default name on each template instead? Hook? Please help!

Hi all, we're a public research institute and in the future we cannot have CMS clients anymore (there can be legal issues in the future). That's why we'd like to transfer our client to a Processwire developer. We could transfer you the whole virtual machine (linux, apache). The client is super nice and on the technical site it is like 5 minor issues (making a new form, place a button here and there). Facts: 1. Client based in Germany 2. Processwire is used (3.0.123) 3. One content manager takes care of all the texts, which she gets from the client. That's a couple of hours a week. 4. Certain users (there is no registration) have an account where they can download certain pdfs. So this is an "exclusive area". 5. Users can forget passwords and re-create it on their own. 6. Bootstrap is used If you have any questions, let me know. Best, Marcel

Well Rick and Chris - some amazingly good news at last!! Rick - Apache worked perfectly. Default page etc. after installation. I've loaded some programs with an associated 'index' file and these all worked perfectly, too. And I did load PW as suggested fixing every problem (bar the lack of zip) as it occurred. This was my frustration - PW indicated that it was 'up and good to go'. Except it clearly wasn't!! Then as suggested I 'fixed' the 000-default.conf file and this led to the error I indicated (and which Chris has kindly commented on). There was another issue with this - I was no longer able to call up the index file that showed my applications. So, I changed the config file setting to read DocumentRoot /var/www/html (removed the pwire directory) and same for <Directory /var/www/html/........ I also commented out the entire rewrite options in.htaccess And as if by magic, it all works!!! Using the 'vanilla' IP address of the server shows me my index file and associated applications. Adding /pwire to the URL takes me to the PW home page - and all the links work! Login to admin; site map; about - whoopee!! ? Now, as fantastic as this is it would have been nice if PW on installation, had 'warned' me that I might need to fix an Apache config file and not left me wondering why this "easy to use" CMS wasn't...... But there we are. Thanks a million to all the patient and very helpful contributors. Very much appreciated!

@dotnetic I picked it up after developing our API in Slim and looking at some best practices. It would be really great if this was the ProcessWire default.

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 a holiday week here in the US, at least for my kids (school break). With kids home I've been off work this week so don't have any ProcessWire updates to report, but I'm looking forward to getting back to work next week and will have more updates to report then. Yesterday was Thanksgiving here in the the US and that kind of marks the beginning of the holiday season here. So today the Christmas tree went up, the lights are coming out and the holiday music has taken over the radio (or Alexa or Google or whatever we call it). Cheers and Happy Holidays!

Confirming that the expressions of interest is now closed. I will collate the responses and get back to all who registered. I am working on a getting started frontend that will help with the testing. I am also working on a minimal API documentation to help you put it all together. Thanks to all who have responded and/or have an intention to support this work in the future ?.

This module allows you to select fields that get anonymized after a defined period of time. Anonymization refers to either replacing field values with a configurable fill word, or removing stored data altogether. The time period after which page content gets anonymized can be configured (default is 60 days), and anonymized fields can be selected manually via module config screen. Behind the scenes LazyCron is used to trigger the anonymization process, which makes the whole process completely automatic. The module was developed for a client that handles job applications. The software we developed required to anonymize personal identifiable data after a specific amount of time, if the applicant did not get the job, according to the law DSGVO. There might be other uses, where this module could come in handy. Thanks @teppo for mentioning it in ProcessWire Weekly #393. I hope you don't mind, that I copied the description from your site? You can find the module at https://github.com/jmartsch/AnonymizeFields and in the modules directory at https://processwire.com/modules/anonymize-fields