kongondo

Hi @csaggo.com, Work on price fields to accommodate international currencies is now complete. Decimal styles are now handled correctly. In addition, thousands are also separated correctly (automatically). To help with this, we now have a new setting in Shop / General Settings -> Standards Tab -> Currency Format (please see screenshots below). Price fields will be formatted based on this new setting. Price fields also display the currency symbol if one exists or the currency's abbreviated name. Currently, this is not configurable but I can add this in future if there is demand for it. This also works for variants price fields. Update summary: Automatic formatting of price fields based on the General Settings 'Currency Format' (currency locale). This means, e.g. Canada French versus Canada English is possible; France - thousand separator is space; Germany - thousand separator is period and comma is decimal character, etc. Thousands are automatically formatted as you type. Thousands separator is based on the 'Currency Format'. Decimal style is based on the 'Currency Format'. Currency value validation is also enforced client-side. For instance, if 'Currency Format' is 'de-DE', one cannot use a period as a decimal. Other invalid entries are also prevented, e.g. cannot enter text in this field. Automatic currency symbol placement. Currently, there are no in/decrement elements on the price field. Works with both products and variants (include variant creation modal). Not yet implemented in manual order editing (e.g. fixed discount amount, etc). Download Please use your download link to get the updated Padloper. If you don't have this in your email, please send me an email to resend it to you. Once downloaded, use the files to overwrite the ones in your present install. You might need to refresh your browser cache to clear the older JavaScript files. Version The Padloper version stays the same until #8 is resolved. Screenshots Currency Format (locale) Example: Canada currency formats Example: Germany currency format Edit Product (German Euro is currency) Edit Product Variant (German Euro is currency) Create Product Variant (German Euro is currency) Please test and let me know how it goes. Thanks.

Just adding that I am working on an API for adding products, variants, categories, etc. This will be available via the global $padloper.

Hi @alexm, This is a multi page reference field (padloper_product_attributes_options) so you would add using any of the ways shown here in ProcessWire docs using PageArray::add() syntax. https://processwire.com/api/ref/page-array/add/ Here are some Padloper product variant examples Please note that example 2 assumes the (parent) product page has the attributes Colour and Size in its field padloper_product_attributes as the respective parents of the attribute options Red and Medium. <?php namespace ProcessWire; // the variant product page $variantPage->of(false); // Example 1: get and add one attribute option $attributeOption = $pages->get(1234);// e.g. /colour/red/ // Add one page (attribute option) $variantPage->padloper_product_attributes_options->add($attributeOption); // Example 2: Add multiple pages (attribute options) // $selector: full selector $selector1 = "template=padloper-attribute-option,title=Red|Medium,check_access=0"; $variantPage->padloper_product_attributes_options->add($pages->find($selector1)); // OR // $selector2: Padloper short syntax selector $selector2 = "template=option,title=Red|Medium"; $variantPage->padloper_product_attributes_options->add($padloper->find($selector2)); // Example 3: Add one page by ID (attribute option) $variantPage->padloper_product_attributes_options->add(1669);// e.g. /size/medium/ // save the variant product page's attribute options field $variantPage->save('padloper_product_attributes_options'); Hope this helps.

True. Unless one adds the flag objects=1, in which case one get a stdClass ?.

Hi @csaggo.com. Apologies, for the delay. This has taken longer than anticipated. Good news though, I now have a solution that caters for all sorts of formatting. I am currently testing and plan to release end of this week. Thanks.

@thetuningspoon, Thanks for posting this. If possible, please edit your post and address points #1 - 3 as relevant as per the job posting guidelines: E.g. remote working, US-based, similar time zone, etc ?. Thanks!

See if this topic helps? I've had issues with that findRaw page reference syntax in the past; unsure if it has been fixed in later PW versions as discussed in that topic.

Cross-posting that @horst's tutorial above subsequently became a tutorial in the Tutorials Forum here: Thanks.

No worries. Actually I think there's something funky going on with the notifications. I'm only getting notified about new threads. Subsequent posts are not triggering notifications.

Thanks for filing the bug report. I'll work on this and report here.

Yes, but this doesn't apply to Padloper. Padloper does not use a ProcessWire field (neither FieldtypeFloat nor FieldtypeDecimal) for price. Instead, it uses a custom Fieldtype that stores price, ex-price, etc. For price, the Padloper custom field utilises a DECIMAL (12,2) sub-field/column ?.

Yes. A custom field is the way to go. Not only will it survive an upgrade, it also offers much more flexibility. Incidentally, you can add any custom field to different templates to suit extra needs. E.g., if you wanted your attributes or categories to have images, you could reuse padloper_images on their respective templates. Currently, the only exception is a repeater field on a product template. They don't play along nicely due to some JavaScript issues (on the part of Padloper).

Yeah, good idea. It does create extra work for your editors though. Hopefully, they can live with that.

You are on the right track with your present code ?. I'll have a think about adding this feature to the API. These two will not work since the fields padloper_type and padloper_categories belong to the parent product, i.e., in your case, $product. Yes. This is necessary to explicitly specify that the product will use variants. This prevents 'accidental' variants if children were created for a product by mistake. This is unlikely but this safeguard is an extra layer to prevent that. The correct code for this should be: <?php namespace ProcessWire; $product->padloper_product_settings->useVariants = 1; Alternatively, since you are creating a new product (rather than amending an existing one), you can do it as follows, given that padloper_product_settings is a WireData object. <?php namespace ProcessWire; $productSettings = new WireData(); // 'physical' | 'physical_no_shipping' | 'digital' | 'service' $productSettings->shippingType = 'physical';// product shipping type $productSettings->taxable = 1; // bool int: is product taxable? $productSettings->trackInventory = 1;// bool int: is product tracking inventory? $productSettings->useVariants = 1; // bool int: is product using variants? $productSettings->colour = '#d52f10ff'; // product colour // ------ // add to product $product->padloper_product_settings = $productSettings; // OR //$product->set('padloper_product_settings', $productSettings); $product->save(); OR <?php namespace ProcessWire; $productSettings = [ 'shippingType' => 'physical', 'taxable' => 1, 'trackInventory' => 1, 'useVariants' => 1, 'colour' => '#d52f10ff', ]; $product->padloper_product_settings->setArray($productSettings); $product->save(); This requires setting the attribute on the parent product and the combination of attribute options on the variant. For instance, the product can have the attributes Size and Colour. The variants will take combinations of options for those attributes, i.e. combo of Size and Colour, e.g. Red x Small, Red x Medium, Black x Large, Black x Small, etc. The attribute options need to be children of the attribute. Hence, Red and Black are page children of Colour and Small, Medium and Large are children of Size. Attributes and Attribute Options use different templates. As you can see, it does get a little complicated. Above does not mean that each each possible Colour and Size combo should be created. For instance, you might not have a Brown x Large variant. Just skip creating it. So, for products that have and use variants, in addition to $product->padloper_product_attributes (a multi-page reference field), you also need to populate $product_variant->padloper_product_attributes_options (a multi-page reference field). Please let me know if you need help with coding this or anything else. Looking forward to seeing it! ?.

Hmm. I'll have to have a think about this. I might make this configurable. Ideally, although I see when it might come handy as per your use case, a 1-character limit should be avoided - to limit server hits, primarily.

Hi @Sylvie, Welcome to the ProcessWire forums. Please send @ryan a personal message. Thanks.

Thanks! TL;DR No; I will not provide a feature comparison list of Padloper 1 versus Padloper 2 for the sake of validating the price of the latter. The simple reason is that it is a futile exercise. Pricing a product takes into account so much more than a features list ?. Longer Read Pricing a product is not as simple as your post implies. If it was simply a matter of adding new / more features, pricing most things in life would be straightforward. All we'd have to do is add a new feature and subsequently increase the price. Fortunately, that is not how the real world works. For instance, at what point will the law of diminishing returns kick in? Or, at what point does the product become unaffordable to most users simply because more features were added? Assuming a product was priced at x and I add 20 new features, should I then price it at 20x?? If 20x is beyond reach for many customers, do I then stop adding features so that I can freeze the price at 20x? Should I remove features so that I can reduce the price? Your proposition also implies that all added features are equal with respect to their object and/or perceived values. So, if I add 1 feature, the price should go up commensurately. I guess you get my point by now. However, let's talk a bit more about this. Pricing a product is a delicate combination of various factors. Some of these include, in no particular order: Perceived value. Objective value. Product Features. Inflation. Customer service. Market place. Competition. Quality of product. Other market forces. The above is not an exhaustive list and some of the points could probably be merged into one. Tempted as I might to digress into an economics pricing class 101, I'll pass and just make a few more comments. With no relation whatsoever to the current pricing points for Padloper, my opinion is that Padloper 1 was under-priced. Not just my opinion, by the way, as various people have privately told me this (unsolicited comments). If you are still wondering whether you need Padloper 2 then you probably don't need Padloper 2 ?. Padloper 1 will work just fine in your case. Those who need Padloper 2 know it and know why they need it. So, in answer to your question, no; I will not provide a feature comparison list of Padloper 1 versus Padloper 2 for the sake of justifying the price point of the latter. It is pointless to do so as the intricacies of pricing any product are much more complex than your question implies. As for the features of Padloper 2, I'll add these to the new Padloper website in due course. Meanwhile, you can get a glimpse of these from my original post. Demo videos are also on the way.

Thanks! Definitely. The current plan is for a wishlist in this forum. Whilst a roadmap and a wishlist are not always congruent, the latter, in some cases, will feed into the former.

Updated FAQ in first post. The PHP extension bcmath is required in Padloper 2.

This thing is heading to 1M views soon by the likes of it! @ryan, this ? one is for you ?:

Hi all, I am working on demo videos for Padloper 2. In the first instance, these will be short tutorial videos to get you up and running quickly. You'll be able to use these in lieu of or in addition to the docs. I'll let you know when these are up. Thanks.

GistPad Manage your code snippets and developer notes using GitHub Gists and repositories. https://marketplace.visualstudio.com/items?itemName=vsls-contrib.gistfs Stumbled upon this today. I have watched the demo below by the creator. This is a really awesome tool! Other features include creating code documentation/notes, create code playgrounds right within VSC, interoperates with codepen, etc. Watch the video below, right to the end. Quality is not the best (it was a live stream) but it is worth it.

It does work with backend modules ?. The distinction in this case is not about backend or frontend. It is about autoload. Since Process modules are backend applications that you use on demand, there is no compelling reason to have them autoload. Hence, in your case the suggestion to create a module that autoloads and is dedicated to handling the URL hooks. Not really. There are different types of so-called backend modules, including Process, AdminTheme, Inputfield, etc. All modules have to implement the Module interface. In some cases they may not do it directly but do so via the parent class they are inheriting. For instance, you will find InputfieldFile extends Inputfield. Inputfield in turn extends WireData and implements Module. Technically, there are no 'satellite' modules. This term was just used in reference to having something on the side that is not part of the main thing (hope this makes sense). So, your 'satellite' module, given that it autoloads without restrictions, is both a backend and a frontend module. You can make it autoload based on some conditions if you wish, e.g. in the backend only, or frontend only, or for some templates only, etc. The following documentation will give you a better understanding of modules. https://processwire.com/docs/modules/ https://processwire.com/api/ref/module/

@Peter Oehman, Welcome to the forums and to ProcessWire ?. This will return an array of the names of all tables in your database. This is confusing. Do you want the name of the database or the name of some table in the database? In addition to what @BillHstated above and given that you are new to ProcessWire, the first question I'd ask is why? Why do you need to write custom SQL queries? Please let us know. There may be other ways to achieve what you are after. However, if you do need to use SQL queries, that's fine. ProcessWire also supports that. In which case, prepared statements using the ProcessWire $database API are the way to go.

@toni, What @Zeka said. You'd need an autoload module for this otherwise your hook would only run when your module is loaded which will be too late. Although this is not explicit in the blog post I linked to, it does mention autoload module.