Leaderboard

I like this thread, so I'm back to bump. Everyone has stacks! MEAN, MERN, TALL, LAMP, MEVN, RSTY, VILT, FLIP, PILF, DUMB, HALP... stacks are neat! It's cool when you can make a word out of tools! It makes it easier to argue over! I made some of those up! I'm planning out my current project and it needs a stack, or I'm not a Real Web Developer™ What is that stack you (didn't) ask? PATH. I'm putting the finishing touches on a full stack application I built over the last month using the TALL stack (Tailwind, Alpine, Laravel, Livewire). I've been jumping back and forth between that and ProcessWire and may write a post about the experience (when I can finally get enough time to do it). I've seen talk in the forums about ProcessWire alongside other tools like Laravel and want to share some firsthand information as far as differences, similarities, comparing how each handles the same task, when to consider one over the other, and takeaways that are going to influence how I use ProcessWire on upcoming projects. Also worth mentioning is how much I, and I cannot stress this enough, hate Tailwind and why I'm still going to use it. Before you ask, it's not because I can't spell "PATH" without the "T". I start out every project with research before writing code and in this case it's been a deeper dive into htmx. Along the way I have been reading Hypermedia Systems, a book written by the authors of htmx. It's free to read online, and I recommend it to everyone here. The contents of the book take the web back to basics, understanding it's core technology, and the importance of extending it's functionality, rather than fight it the way that client-heavy tools like React have chosen to do. PHP and PHP developers have a lot to gain from this approach and embracing that mentality, even if you choose not to use htmx. While my "stack" comment was a little flippant, the fact is that you can build ProcessWire applications and sites with dynamic content that provides an SPA-like experience without the SPA which is better for users, much more efficient, and provides a far better developer experience. Towards the topic of this post, I can't help but notice the continual renewed interest in alternatives to JavaScript as a full stack solution and to an extent (as noted in the videos above) an uptick in consideration for PHP as something to consider. As also discussed above, how much JavaScript fatigue is turning into JavaScript burnout. Anyway, here's a hot take by Theo that looks cold in comparison to the heat people are bringing in the comments calling him out (worth the click-through to read). One of the things that Laravel and ProcessWire have in common are modularity and the number of powerful tools built into their APIs, something I think about when hearing conversations about other PHP frameworks. So, bump in relevance to this video. You can already tell this guy is going to miss the mark because he doesn't have a Lamborghini in his preview pic SMH.

Hi @Spinbox, Yes. What @alexmsaid. There is a fix already, thanks to @alexm proposals above. In summary: Both 'calculating tax on a unit item and multiplying by quantity' versus 'totaling quantities first then applying tax' are acceptable approaches. One approach gives the taxman a few more pennies and the other saves the customer a few more pennies in taxation. I might make this configurable in the future but for now, I have adopted the latter per @alexm's suggestion (using bcmath). The rounding error mainly occurs in cases where tax is included in the price. I run around 10 million tests and all passed. There's two bits remaining. I need to implement this approach in Padloper discounts and do final test before releasing. I hope to have this ready by tomorrow. Thanks.

@Spinbox I'm pretty certain @kongondo is working on a revision of the tax calculation from our discussions. I'll let him clarify that though when he's free.

Hey ProcessWire RockStars! ? Ever felt like your ProcessWire backend could use a bit more... pizzazz? Or functionality? Well, it's time to roll up your sleeves and dive into the world of RockAdminTweaks! ??️ Creating tweaks is as easy as smashing a power chord on your guitar! If you've got cool features from AOS you'd love to see, why not port them over? We even have a GUI for creating new Tweaks! Let's make the backend rock even harder! Github: https://github.com/baumrock/RockAdminTweaks Modules Directory: https://processwire.com/modules/rock-admin-tweaks/ Docs: https://www.baumrock.com/processwire/module/rockadmintweaks/

I'm having an issue where the total price with tax differs from the unit price with tax for a product. The store also has 'All taxes are included in stated prices' checked under tax settings and tax is set at 21%. Is there a fix planned for this or can I hotfix this for now?

Another very interesting approach by @netcarver and @FireWire:

@kongondo I hadn't even noticed the email customer option!! That's wicked ??

For a case like this you can use the hookable method to return any markup you like, including an image. It won't work for a UIkit tooltip though because that only supports text. Example: $wire->addHookAfter('PageFieldInfo::getPageInfo', function(HookEvent $event) { $page = $event->arguments(0); // The page $inputfield = $event->arguments(1); // InputfieldPage $field = $event->arguments(2); // The Page Reference field // Return custom markup if($field->name === 'colour') { $image = $page->get('image[0]'); if($image) $event->return = "<img src='$image->url' alt='$image->description' style='max-width:200px; max-height:200px; margin-top:10px;'>"; } });

Thanks man! Finally, I did a brief write-up about Customers and Customer Groups.

I've written a utility for working with .env files in ProcessWire and it makes use of the directory structure in the great post shared by @netcarver. I think this addresses the items brought up here about vendor directory placement and also provides a clean and simple method of implementation while providing some handy tools to boot. You can view and download the code for this .env implementation strategy from this repository. This reads and caches .env file variables and makes them easy to work with in the ProcessWire config.php file. The readme in that repository provides a full rundown of directory structure and setup. Here's an overview of how it's used once you've configured it in your project. <?php namespace ProcessWire; /** * Example usage in config.php **/ use App\Env\Env; if(!defined("PROCESSWIRE")) die(); $env = Env::load(); // You can now access any variable in the .env file located in your root directory with an accessor method $env->get('YOUR_ENV_VARIABLE'); // => returns whatever that value is in .env // You can optionally make env values accessible globally in ProcessWire by assigning $env to a property // Then you can use $config->env->get('NAME_OF_VARIABLE'); $config->env = $env; // Use to set up your config values $config->debug = $env->get('DEBUG'); // ... But hey, why stop there? You can also do this: <?php namespace ProcessWire; /** * Example config.php file */ use App\Env\Env; if(!defined("PROCESSWIRE")) die(); $env = Env::load(); $config = $env->pushToConfig($config, [ 'useFunctionsAPI' => 'USE_FUNCTIONS_API', 'usePageClasses' => 'USE_PAGE_CLASSES', 'useMarkupRegions' => 'USE_MARKUP_REGIONS', 'prependTemplateFile' => 'PREPEND_TEMPLATE_FILE', 'appendTemplateFile' => 'APPEND_TEMPLATE_FILE', 'templateCompile' => 'TEMPLATE_COMPILE', 'dbHost' => 'DB_HOST', 'dbName' => 'DB_NAME', 'dbUser' => 'DB_USER', 'dbPass' => 'DB_PASS', 'dbPort' => 'DB_PORT', 'dbEngine' => 'DB_ENGINE', 'userAuthSalt' => 'USER_AUTH_SALT', 'tableSalt' => 'TABLE_SALT', 'chmodDir' => 'CHMOD_DIR', 'chmodFile' => 'CHMOD_FILE', 'timezone' => 'TIMEZONE', 'defaultAdminTheme' => 'DEFAULT_ADMIN_THEME', 'installed' => 'INSTALLED', 'debug' => 'DEBUG', ]); // Arrays aren't for .env files... $config->httpHosts = ['yourdomain.com']; // You can also get all of the values at once with this method $env->toArray(); What this does behind the scenes: Parses the .env file Casts booleans and ints appropriately where detected Caches the .env values in a file located outside of the public directory (read why below) Provides utility methods to access the .env data Optionally loads values to the server $_ENV array Values provided by the Env object are immutable Because ProcessWire has pretty much all of it's out-of-the-box configurations located in config.php, by default this only loads the values and makes them accessible via the get() method available on the object returned by Env::load(), not via $_ENV. You can optionally make your values available in $_ENV by passing 'true' to the load() method. About caching... This uses phpdotenv to read the .env file and load it's contents. There is some overhead for this process and requires significantly more work than just turning the .env into a key/value array. This application uses phpdotenv to parse the file then stores that in a cache file called env.php as a native array which is then subsequently loaded using require_once, an operation that is trivial for PHP to handle. Additionally, the object returned by Env::load() memoizes all values so the cached file is only read once during application execution and all subsequent key/value access is pulled from memory. Cache can be cleared using a provided method. I like how this came out and hope others find it useful. Interested in everyone's thoughts. It would really be great if installation and directory configuration were automated in a bash script, but I don't have the time. Pull requests are wide open for that ?

Another update: More info() settings! Please check out v1.8

You make some very good points - conditional loading of js/css in the php file does make things much easier for sure (like your superuser only example) and it would be painful to handle this any other way, so maybe keeping things as is will be fine. Sorry about the PRs to main - I didn't check if you have a dev branch. Are you OK handling the current ones as is so long as I modify the upcoming ones? I think an additional notes parameter could be useful. Perhaps also a link parameter that could automatically populate those info icons you added to a couple of tweaks within the description. Maybe also an author parameters (maybe GH username) so it's easy to keep track of who needs to be contacted for support going forward? Of course, the other approach to this would be something like what I did with AdminActions - see Robin's addon action maintained in his own repo (https://processwire.com/modules/admin-actions-replace-home/). I like the idea of separate maintenance without the need for PRs, but it would also be a pain for others to find all the tweaks, so probably a bad idea in reality.

Hi @netcarver thx for clarifying. I wouldn't call such a collection "bloat". By bloat in AOS I meant that all features are not well organised. They are all put into the same files leading to large files with lots of hooks etc.; If one feature makes troubles it's hard to find all related lines of codes. Or if you want to remove it you risk to break something else. In RockAdminTweaks all tweaks are isolated and well organised, so that's not a problem at all. Also tweaks are only loaded if they are activated so it shouldn't be a problem to have many tweaks in the module performance wise. PS: I changed the place for tweaks from assets to templates, because multilang features don't work in assets!

Customers and Customer Groups are new features in Padloper 009. Customers You can add/remove this optional feature at any time via ‘/admin/shop/configure-padloper/’. This feature does not require the 'Customer Groups' feature. Please note that there is no direct relationship between a 'shop customer' and an 'order customer'. This decoupling allows for a better delineation between guest and non-guest checkouts. The field for storing order customers is separate from the field for storing shop customers. The former is a 'permanent' record of a transaction (an order) in your shop. There is no direct link between a shop customer and a ProcessWire user, until you link them. Padloper allows you to do this easily. You can add customers to your shop either via the API or the admin. Note: When creating a customer, you have the option to create a (ProcessWire) user account for them as well. You can also do this later when editing the customer. Padloper does not handle the customer registration for you. This is because some devs prefer to send customer a link to register whilst others prefer emailing a temporary password to the customer. Padloper allows you to handle the registration and pass the details back to it to email to the customer. Padloper passes the new customer details, new user details and the temporary password set to the new user to the partial template 'customer-registration-request-email-content-html.php'. Devs can then use that information to handle customer registration. When you add a customer, they get the role 'padloper-customer'. A customer linked to a ProcessWire user is a 'registered customer'. In this case, the $customer->userID equals $user->id and $customer->email is $user->email. Currently, in case you had existing users in your shop that were customers prior to Padloper 009, Padloper does not currently link those users to the customers. You can do this via the API. If you change a 'linked' user's email, the email of the corresponding customer will also be changed to keep them in sync. The same thing happens if you edit the email of a linked (registered) customer; the corresponding user's email will also be amended. If you delete a ProcessWire user linked to a Padloper customer, the customer will be delinked, i.e. will no longer be a registered customer and $customer->userID will be 0. If you delete a registered Padloper customer, the corresponding ProcessWire user will also be deleted. It is possible to email a customer directly from the admin. A customer can have multiple addresses. These can be of types: Primary Shipping Shipping Primary Billing Billing A customer can only have one Primary Shipping and one Primary Billing address. The 'customer view' page allows you to see the details of the last 10 orders of the customer and the total of all their orders to date. With the customers feature, you can pre-populate address details of logged-in customers for a better checkout experience. You can also use this feature to build customer dashboards, address books, etc. as @alexm points out here. Currently, there is no dedicated API to retrieve, amend, etc. a customer. This is planned. For now, you can get a customer as follows: <?php namespace ProcessWire; $email = "mario@blaze.br"; $customer = $padloper->get("template=customer, customer.email={$email}"); if(!$customer instanceof NullPage){ // CUSTOMER FOUND /** @var WireData $customerBasics */ $customerBasics = $customer->padloper_customer; /** @var WireArray $customerAddresses */ $customerAddresses = $customer->padloper_customer_addresses; bd($customer, __METHOD__ . ': $customer - at line #' . __LINE__); bd($customerBasics, __METHOD__ . ': $customerBasics - at line #' . __LINE__); bdb($customerAddresses, __METHOD__ . ': $customerAddresses - at line #' . __LINE__); } Customer Groups You can add/remove this optional feature at any time via ‘/admin/shop/configure-padloper/’. This feature requires the 'Customers' feature. The Customer Groups feature allows you to segment your customers using certain criteria. The segmentation allows you to target specific customers for various purposes including marketing, loyalty services, discounts, statistical analysis, bulk emailing, etc. You will need to implement such actions per your needs, e.g. via an addon, etc. A customer can belong to more than one Customer Group. You can create unlimited Customer Groups. Currently, you need to manually create Customer Groups and add them to Customers. However, in future, you will be able to: Use a GUI query builder to create a customer group then apply it to matching customers. For instance, a Customer Group named 'Europe High' with the criteria "order > 500, country = Italy|Switzerland" Automatically add a Customer to a Customer Group if they meet the criteria. E.g., if a customer places an order and the customer's order totals becomes greater than >= 500 and the customer country is Italy or Switzerland, Padloper will automatically add them to the above 'Europe High' Customer Group. Screenshots

It seems to be a permissions issue. When Rock Migrations is run the regular way, it makes the $user a superuser with a sudo() method. If you run your migrations from your own script you probably need to do the same there.