Leaderboard

Hi @bernhard, in the docs-old folder of the module there is a nice section about prices. It says that we can switch to gross prices with a config setting. I was not so sure whether that still applies and how it works with the cart calculations. So I just wanted to share my custom implementation, so that editors can enter gross price and net price will be calculated. I added a field (type RockMoney) "price_gross" in addition to the "rockcommerce_net" field to my product template. And in my ProductPage class, I have a saveReady hook that calculates the net price from the gross price and the vat for that product. /** * Calculates the taxrate of the product * based on the taxrate field of the product * if no custom taxrate is set, the global taxrate is used * * @return float */ public function getTaxrate(): float { return (float) $this->rockcommerce_taxrate ? $this->rockcommerce_taxrate/100 : $this->taxrate(); } /** * Executes when the page is ready to be saved. * * Only executes if price_gross is given and field rockcommerce_net is present. * Calculates the net price and VAT based on the gross price * and tax rate, if a gross price is provided. * It saves the net price to rockcommerce_net. * * @return void */ public function onSaveReady(): void { // only execute if we have price_gross if ($this->price_gross && $this->template->hasField('rockcommerce_net')) { // take price_gross and calculate vat and net price from it using taxrate $taxrate = $this->getTaxrate(); $vat = rockmoney()->parse($this->price_gross)->times($taxrate / (1 + $taxrate)); /** @var \RockMoney\Money */ $priceNet = rockmoney()->parse($this->price_gross)->minus($vat); $this->rockcommerce_net = $priceNet->getFloat(); } } I also use a custom getTaxrate() method from my page class, in case a custom rate is set for that product. Page edit screen

Thank you so much for the quick reply @bernhard and for adding stuff to the docs so quickly! Now the docs are coming together very nicely. I really appreciate that. That is totally fine. If we know these limitations as developers, we can maybe implement custom solutions if the existing cart hooks are sufficient and allow us to do those calculations and display them in the cart. I have a rather simple shop atm with single tax rate. Just wanted to know how to handle things when tax rates are needed per product. My experence with other shops shows that this will eventually come up at some point in time :-)

Hi @gebeer thank you for your questions. This is at the moment not possible. RockCommerce by default can only handle a global taxrate per user (to be more precise per cart), not per product. Absolutely. Unfortunately I had to do quite a lot of refactoring before I launched and therefore some of the docs were outdated, so I decided to keep them as backup in the docs-old folder and move them over to the new folder as I find time to correct outdated informations. I have done that now for tax handling and things are clear now hopefully. Thx! That's added! That's already in the docs about the cart. I have added a note to the tax docs as well, thx. As you can see in the old docs I thought about adding that, but I decided against it. The goal was to make the experience of setting up a simple shop as simple as possible. Obviously that comes with some limitations. I think it would not be too hard to add support for different taxrates per product. But it would also not be trivial. Different taxrates per product means the VAT of the cart is not anymore a simple "net times taxrate" calculation. It moves that calculation to each product and then the cart needs to collect all taxes and then maybe even list them on the cart summary like so: items net: 120,00€ items vat: 21,00€ - 10% of 50€ = 5€ - 20% of 50€ = 10€ - 30% of 20€ = 6€ The goal is to keep RockCommerce as simple as possible by default. Similar to product variations that have to be enabled manually we could also add an option to allow taxes on a product level rather than on a cart level. If you have that need (or anybody else) let's get in touch via PM!

We’ve been building web site with ProcessWire since 2013. ProcessWire serves to us as a secure, reliable platform, and honestly, I don’t remember any significant issue after 11 years of daily use (for us, PW is also a CRM). The magic of ProcessWire is that it is always growing with our needs and serves any unimaginable demand that our platform has had. All these years, our business has grown around ProcessWire, and as it usually happens, popularity brings the other side of the coin. In our case, it was online fraud and scammers. Our first approach was to use existing fraud prevention systems, but as our business is not pure e-commerce and fraud was indirect, there was no solution that matched our needs, so we started developing our system from scratch. This is where I exactly understood how ProcessWire and the community really hooked me. (-: First of all, taking ProcessWire as an example, we decided not to heavily rely on frameworks. It was a hard decision, because new school engineers like to bring as many dependencies as possible, but I continuously pointed to ProcessWire, and as a result, we created a fraud prevention/user behaviour analytics platform with ~4 PHP dependencies. The second decision that we took, looking at ProcessWire, was even harder than the first. The fraud prevention market, in contrast with CRM, is not widely targeted for open source software, but taking ProcessWire as an example, we decided to open source our system after ~8,000 engineer-hours under the AGPL license. For sure, after being open-sourced for one week, it's premature to give any feedback, and it is highly possible that open sourcing was a mistake. However, it brings me to the understanding that the real measure of software is not downloads or stars, but its influence over other developers, and from them onto other developers, like ripples on the water. From this perspective, I am infinitely grateful to @ryan, @Ivan Gretsky, @Soma, and every person behind the ProcessWire community for all the inspiration through these years. I'm so grateful that 11 years ago I met this community and had the chance to work with some of you. As I'm more reader than writer, I would like to use this rare opportunity to wish the ProcessWire community and your families a Merry Christmas and all the best in the New Year! Best Alex P.S. While this post is not intended to be an advertisement, if someone from community is facing challenges related to online fraud, user spam, or security, please feel free to contact me directly.

@artfulrobot @ryan - I wonder if some of the new techniques described here would help?

This looks really useful, by the way! Accessibility: I was going to submit this as an issue but perhaps you'd prefer discussion here as a precursor? Browser-native selects have a cool feature: you can type the label to find an item. If you're able to use a mouse like I am then this is just an efficiency, but if you can only use keyboard navigation then this is really very valuable to usability (on a long list) and to efficiency (on a short list). e.g. consider a list of countries. ("Where have you been on holiday?"). having to scroll and click is going to be awkward and slow; being able to type Uni and jump to United Arab Emirates (and below it United Kingdom) makes it a breeze. This important accessibility function gets broken by the way the icons representing selected/not are inserted as text before the labels. Sadly, CSS cannot rescue this - if CSS were supported better for <selects> then we could do various things to improve UX for visual users without it being at the expense of less able users. What about instead of using visual characters for selected/not, using <optgroup label="Selected"> and <optgroup label="Unselected"> and grouping the selected items first?

I didn't play with multilanguage image fields, but if it's the same behavior than with other multilanguage fields (probably) you have nothing to do: if a multilanguage field defines a value for the current user language, then this value is used, otherwise the default language value is used. EDIT : hmm, looks like there's no multilanguage image field, so language alternate fields looks like the only solution, and then a hook like @ngrmm proposed sounds good.

I solved this by renaming the field instead of moving content. In this case this was the even better (as more performant) solution, but I'd still be interested if anyone knows another way of doing this!