kongondo

Quick follow-up to last announcement regarding Discounts. Here's a screenshot ( @szabesz look away now ? - giant padding! will work on it later) of the Discount bulk view/edit screen (WIP). Discounts bulk view/edit

That's where Dart comes in :-). Have a look at the docs and examples. With Dart alone, you can build anything from backend servers, console programs and anything in between. Erm, no you don't. Look at the real world examples/showcase. We are talking Alibaba, Reflectly, Hamilton Musical, and the likes. For iOS we have Cupertino Material design. I am not saying these alone are enough to go by but so far, and I have done extensive research, I have yet to come across anyone mentioning that they have to maintain two code bases. In fact, they all say quite the opposite - they have done away with two code bases and their UI renders exactly as they intended in their targeted platforms. How so? The only thing I don't like so far is the styling and structure baked right inside the widgets. I think flutter had the advantage of learning from other solutions and picking the best bits and improving on the not-so-good bits. I am not a zealot (yet :-)), but the more I dive deeper into Dart and Flutter, the more I get convinced that Google got this one right :-).

It's amazing how much progress they've made since that article. was written For those thinking of diving into Flutter/Dart or even just Dart, don't be scared ?. An advantage we have as PW developers is the OOP side of PHP. Coupled with CSS (styling, box model, etc) and HTML (widget-like structures) plus JavaScript, it makes the dive into Dart (and other [modern] languages) not-so-painful. So you call it a Map we call it an Associative Array (or Dictionary in Python). You call it a List, we call it an Array. So you have collection.map()...that looks familiar. It's dot notation and I've seen map in JavaScript. We can do that, but we also know $this->something....etc. The flutter widget inspector looks really cool, btw. I am also happy that my code of choice, VSC, has Dart plugins and is mentioned in the official Flutter/Dart pages. Me and my ramblings...?

Aah..I see. Hmm, let's have a think...

Actually, some systems (e.g. Shopify) have it as an exclusive. I'm not sure I follow. Please expound. I am confused myself ?. Is it the 'Gets Quantity' that is confusing or the demo? Thanks!

A year or so later, I have seen the future. Actually, I just stumbled upon it. Just when I was diving into Angular + TypeScript + NativeScript for mobile apps, I recently came across this thing, Flutter. I have been totally blown away! The last time I was this excited was when I discovered ProcessWire :-). Long story short, before I ended up here, I was looking at Kivy and BeeWare. I managed to pick up Python along the way. Kivy looks promising. I am interested in both mobile and desktop apps and it ticks those boxes. Then along comes Flutter and wow! Cross platform, write once deploy everywhere (iOS, Android, Embedded, Windows, Mac). It's still early days but I am totally convinced. I was a bit hesitant because it is a Google project (you know, their history of killing off projects...) but since it is open source and there are some big players already involved, I am sold. Flutter compiles to machine code! It comes with lots of widgets out of the box, both for iOS and Android. You can also ask it to compile to JavaScript (like TypeScript can and does). To program in Flutter you use Dart, a language developed by Google. I came across Dart a while back. Back then, it was considered a dead language. It has made a resurgence, thanks to Flutter. If you know your OOP and JavaScript, it is very easy to pick up, in an hour or so. If looking at Flutter, have a look at Hummingbird as well. What do you folks think? Anyone used Flutter before?

News Update - 26 May 2019 Discounts GUI Most work since the last update has gone to the discounts GUI. I also took the opportunity to trial the Tabbed interface suggested by @szabesz. I think I like the results. There are some crazy JS/CSS issues affecting the layout though. They seem to be coming from the ProcessWire navigation. Sometimes the padding is affected. This realigns correctly when you hover your mouse over the ProcessWire navigation. The dev inspector shows some dynamic activity going on, meaning JS. I'll post this in a separate post in the forums. Please note that this is still WIP. There are 4 types of discounts, each of which can be further refined by other factors including usage limits per order, globally, per customer, minimum requirements (purchase or amount), customer eligibility, etc. Discounts can be applied to specific products or categories or to the entire order. Percentage discounts Fixed amount/value Free Shipping Buy X Get Y Currently, discounts have to be created manually by the shop staff and customers have to enter a discount code at checkout. In future, we'll consider adding automatic discounts which will kick in if certain conditions are met. Here's a short video demoing the creation of discounts. Thanks.

The API will change a bit. Everything goes through Padloper (the new module/class I talked about in the post above). An Order Object will contain everything about the order stored in several properties. For the curious, there are two main fields for an order (outside order ID, etc). One field is of type Order and contains the overall data about an order, e.g. total price, total quantity, total shipping, customer name, customer address, order status, etc. The second is for individual items (also called list items) in an order. This will hold data about each item (product) in an order, e.g., the price, quantity, fulfilment status, variant id, tax, etc. To send order data to your endpoints will be as simple as this: // get an order $order = $padloper->getOrder($id); /* overall order data */ // total price/cost $order->totalPrice; // total discounts applied $order->totalDiscount; // totalShipping $order->totalShipping; // order items $items = $order->items; foreach($items as $item) { $item->title; $item->price; $item->totalPrice; $item->fulfilmentStatus; } // explode $data = $order->items->explode(array('title','price','tax')); $json = json_encode($data); As you can see, you can cherry-pick what you want to send to other services. Also note that each item within an order has its own fulfilment status. This is helpful in tracking each items status. I will give an update after I finish with this post, specifically about discounts. You will still be able to hook into prices if you wish but we have 4 types of discounts in-built that cover most scenarios. Yes :-). Our shipping classes and modules are all ready. I only need to implement the backend GUI. Briefly though, shipping is made up of these: Shipping Zone: Geographical, from post/zip code all the way up to continent. Shipping Rates: Light goods, heavy, 10 items, $30 order, flat, etc. Shipping Methods: Normal, Super Fast, Slow, Next Day, etc. Shipping Option: A combination of Shipping Rate and Shipping Method: e.g. Your order falls under the shipping rate 'Heavy Goods'. If you want them fast, you pay $40. If are in no hurry, you pay $10.,etc Using the GUI, you will create your shipping zones. Each zone can have its own rates, methods and options. I have spoken about shipping zone before. Please see this post. Yes, but not now. Probably after the release of Padloper 2. We have two existing Payment Modules that we can work with, although they too will be polished a bit (given the various suggestions we've seen in the forums). Definitely :-). In your example, Licence 1 and 2 are just variant options themselves. See the demo below. I am planning to hire a number of octopuses so we can type faster ?. Seriously though, I am working as hard as I can. Maybe after the summer. Please see the first post in this thread, under Pricing Model. Thanks all!

Oh, oh. Someone forgot to set limits to upload sizes and/or client-side image resizing ??. Good question. I'm not sure whether the code below will work. I don't know whether such images are counted by ProcessWire as uploaded or it is just their resizing that is an issue. I don't have a test image to use but try the below please in a Tracy console and let me know. It is just checking for empties. If it doesn't work maybe we can search by image size (0x260) instead. $empties = $pages->find("template=media-manager-image,media_manager_image.count=0"); d($empties,'EMPTIES');

.....And @LostKobrakai the "stingiest" among the so-called top posters ??.

Btw, mainly for @bernhard and @adrian who have previously looked at RTM code, InputfieldRuntimeMarkup now behaves similar to many inputfields in that it gets its values from the Fieldtype's wakeupValue(), i.e. from $this->attr('value'). The previous implementation seemed a bit unclean to me when I looked at it recently. We had the inputfield doing its own eval() or wireRenderFile(). Now I've moved everything to FieldtypeRuntimeMarkup plus added a small helper class in there to handle such things. All the inputfield does now is serve values, as inputfields are meant to do.

Update: Blog 2.4.3 Changelog Added method to find embedded images for use as featured image(s), for example. Thanks @Karinne Cyphers How to use the method findEmbeddedImages($markup, $limit=1). $blog = $modules->get("MarkupBlog"); $posts = $pages->find("template=blog-post,sort=-blog_date,limit=10"); foreach($posts as $post) { // get only one embedded image // $embeddedImages = $blog->findEmbeddedImages($post->blog_body); // get 5 embedded images $embeddedImages = $blog->findEmbeddedImages($post->blog_body,5); // if embedded images found if(count($embeddedImages)) { // do something with $embeddedImages array // simple array where each value is a URL to the embedded image } } As you can see, the $markup is not limited to blog_body. Module has been updated in the modules directory.

Update version 006 - 11 May 2019 Finally got a bit of time to work on this module. Changelog Namespacing: ProcessWire 3.x Support only from now on. Removed the module's CSS and JS files. They are unnecessary. Switched to $files->render() instead of wireRenderFile(). Option to check for and optionally use InputfieldAceExtended for code highlighting in the PHP custom code textarea. Thanks to @adrian , @diogo and others who suggested this. Option to specify number of rows for the PHP custom code textarea (@note: for some reason, it's not working with Ace Extended. It does work with plain textarea). Removed the option (in field settings) to search for files to render under /site/modules/FieldTypeRuntimeMarkup/ as these could get overwritten during upgrades. Refactored code to prevent unnecessary re-rendering of output, thanks @adrian Render PHP file mode is now supported for frontend use as well, thanks @Noel Boss Changed license to MIT. Please note this is the new master and is available in the modules directory. Screenshots Over to you @bernhard ?.

Media Manager version 012 (released 10/05/2019) Happy to announce the latest release of Media Manager. Changelog ProcessWire 3.x support only. New GUI to match AdminThemeUiKit Upload Anywhere (drag and drop to upload in Media Manager Library and Media Manager Inputfields). Custom fields/columns - add any field to any of the Media Manager templates and access them as a property of a MediaManager object. Edit a single media including its custom fields I would like to thank all the beta testers! Documentation Documentation is now complete! Please report any missing links or anything that is not clear. Upgrading Grab the latest version of JqueryFileUpload (version 008) from here. Upgrade to that version (note: it is also namespaced) Grab the latest version of Media Manager using resend download links form here. Simply overwrite existing files but delete the files MediaManagerTabs.php and pocketgrid.css in the old files. Hit module refresh. You might need to clear compiled files several times. For most beta testers, upgrading has gone smoothly. However, two people have reported an error about class ProcessMediaManager not found in line 20 of MediaManagerUtilities. I have not been able to resolve this issue. I suspect FileCompiler is trying to be clever or some module loading order change? Please let me know how it goes. Beta testers, please upgrade as well. A few things have changed including a fix for the bug reported in the previous post. Screenshots Please refer to the documentation for more photos. Thanks!

Excellent find! You've saved me some debugging headache, thanks :-). A user reported missing images in grid view (table view was fine) and I couldn't figure out what was going on (I didn't have access to that site) but it was also a German user :-). Fixed in the release version (012). Please see post below.

I have something nearly ready for this as well as similar methods I worked on in the past but never got a chance to commit. I hope to conclude these by the end of this week. I'll post here when done.

Not an answer, just curious what the use case is?

Great find buddy! Thanks. Wow! This is massive!

No; Products are still pages ? (just NOT your own pages). ProcessWire is so versatile you can throw many things at it and it handles just fine. A custom Fieldtype is just one that doesn't ship with ProcessWire core. It is still a Fieldtype like any other. An Inputfield is just for displaying and capturing edited data. A Fieldtype does not need to have an Inputfield. As for custom db tables, even Padloper 1 uses them :-).

OK. Let's arrange to have a chat, please, thanks.

Actually, this is incorrect. It is top priority for me now not least because I struggle with CSS (as I've stated previously) ?. The less CSS headache I have to deal with later the better for me. I see what you mean. Should hopefully be a simple fix...just remove the uk-margin. Looks great! Thanks for the idea. I was contemplating this question since I thought about it myself. I'm not sure though. I'll have to think a bit more about this. Yes. I was going to mention this in my post but I forgot. You will then be able to access them at $product->your_repeater; $product->another_custom_field; etc. The code is already there. The only thing I haven't decided is how to add the custom fields and how to edit them. In Media Manager all you need to do is to add your field to the template and editing is done in a modal. Editing the page itself (where it lives in PW). For Padloper, it is not that straightforward. I am trying to avoid modals as best as I can. Even if you added your custom field to the products template and was to edit it in a modal or different page, some users will probably be confused since they will not be able to see variants. on that page! I purposefully left out Inputfields for the custom Fieldtypes I created for Padloper. We don't need them since nothing is edited on the page. Given, the current UI can be transferred to the Inputfields but I am not keen on that. I'll need to have a proper think about his, especially RE repeaters. Any and all ideas are welcome :-). No, that's not correct. The video doesn't show inventory management at all. The inventory dash will list all variants where available alongside products that do not have variants. I haven't decided how to best display the table. The current ideas are: a simple table showing all variants and 'single' products a table/list that groups variants of one product together (something like mini-panels) A table listing products with variants hidden in accordions Whichever UI we go with, filters will still be available. Thoughts? The only core Fieldtype Padloper 2 uses are Pagefields (2), Textarea(2, 1 of which is rich text), Title and Images. Everything else is either a custom Fieldtype or a custom table. Is below good enough for prices ?? For prices we use the type decimal(12,2).

News Update - 3 May 2019 - Part Two Class Padloper - Public API We have re-written the Padloper Class (Padloper.module) to server as proxy class for use as a public API for everything you need to do with Padloper (except rendering; we don't do that :-), see previous post). Think of ProcessWire $pages variable. This is something similar in that it allows you to interact with (retrieval and manipulation) with Padloper at a higher level. Rather than multiple methods from multiple classes such as $modules->get("PadCart")->someMethod() or $modules->get("PadCheckout)->anotherMethod(), you will only need to interact with one class, Padloper. This will hopefully streamline your development process. Most (maybe all) of the current modules will be "converted" to Padloper core classes (.php) and/or absorbed in other classes. This means less modules will be installed. With one class (proxy class but also with native methods) you won't need to know (but good if you did :-)), the names of the fields that Padloper will ship with. Your code could be as simple as this: // get the class $padloper = $modules->get("Padloper"); // find a limited number of products $products = $padloper->findProducts(); // find products matching a criteria $selector = "brand=toshiba,price>200"; $products = $padloper->findProducts($selector); $selector = "tags|categories~=Vane,type*=Jac,description~=Some text,images.count>3"; $products = $padloper->findProducts($selector); $selector = "inventory<=10,variant_option=size|colour,variant_option_value=red|black"; $products = $padloper->findProducts($selector); // find related products $related = $padloper->findRelatedProducts($product); // get current cart $cart = $padloper->getCart(); // add item to current cart $padloper->addCart($item); // import products $padloper->importProducts($imports);// array/json/csv // get an order $order = $padloper->getOrder($id); // export orders $padloper->exportOrders($selectedOrders); // etc for customers, discounts, downloads, categories, tags, brands, variants, reports, inventory, types, etc Note the short 'field names' in the selectors. For instance, there are no fields known as brand or tags or categories in Padloper (they have other names and/or are subfields) but Padloper will convert them into something ProcessWire will be happy with. Currently, we don't support Or:groups, sub-selector selectors and similar using the 'short-field-names-selectors' . For such, you would need to pass the the full names and subfields of the Padloper fields you want to query to findProducts(), etc. The Padloper Class is also useful for debugging your shop, producing reports using the API, etc.. We'll talk about this and more in future posts.

News Update - 3 May 2019 - Part One The little speckled fella has been very busy on the trail. Despite being the smallest of its kind, she has lofty dreams. We've been working on the API and the Products GUI. In the next post, I'll tell you more about the API. Products Features and GUI Though there are a few issues still pending (aren't there always? sigh), I am relatively pleased with the results. Of course, during beta testing we'll received and incorporate feedback as best as we can. Only UI-Kit theme will be officially supported. Multilingual fields if site is multilingual Ajax powered inputs for fast and convenient editing Four types of products Physical product requiring shipping Physical product not requiring shipping (for collection) Digital product Service/Event (etc) products - e.g. Swimming lessons, Consultancy services, Hotel booking, etc Product Classification (ajax powered) by: Type: e.g. Belt, trousers, etc Brand: Puma, Sanyo, whatever (editors can type in or import brand names + planning to support logos) Categories (aka Collections): Multiple categories, e.g. Men, Girls, Hospitality Tags: Multiple tags can be entered, e.g. sale, amazing, etc Product Variants (consists of an Option (e.g. Colour) and an Option Value (e.g. Red) Add zero or n variants as you wish Live preview as you build variants Each created product variant can be enabled/disabled. Devs can then decide to either show that variant as unavailable or not show them at all. That's up to you :-). Apart from classifications, shipping class, inventory policy, weight and dimensions units, title and description (and this latter one may change), almost all product properties will vary by variant if variants are used Product properties include: Images Colour (more on this below) Downloads (centralised and reusable) Price and Compare Price (aka former price) Inventory policy (whether to track or not) Charge taxes SKU (stock keeping unit) Inventory (quantity) Allow back orders (aka overselling) - @note: this can be set per variant. This is useful if one variant can be restocked faster than others Weight Length Width Height Weight Unit (mg, g, kg, oz, lb, t) Dimensions Unit (mm, cm, m, in, ft ) Shipping Class - can be used for product-based shipping if needed (e.g. bulky goods, light, fragile, small items, perishable, etc) Images (more on this below) Downloads (more on this below) Images Multiple images can be added to both a product and its variants (in case its has some). Images add to the product itself can be used with all variants Images added to a variant are tracked/tagged as belonging to only that variant In some cases, it may not make much sense to add different images for similar variants. For instance, a small red hat and a large red hat could probably share the same images. Although we do not currently support specifying an already uploaded image as belonging to a group of variants, this may change in the future Colour Similar to images, can be set at both product and its variants level Colour saved in RGBA format Downloads Also similar to images, can be populated for both both product and/or its variants Multiple files can be added to a product A file designated for 'whole' product will be available to download irrespective which variant of the product was purchased Conversely, a file or files saved for a variant will only be available to the buyer if they buy that variant of the product The above is useful if you want buyers to be able to download different files of the same product. For instance, recently someone needed to sell two versions of a font as part of one product. This is a solution for such cases. TODO List Lots! e.g. default settings for some properties, e.g. weight unit, shop currency, etc. For the frontend, we are creating a rich language-aware API that you can use to build your shop however you want. There will be no rendering of markup (but see first post in this thread about a separate fully functional frontend shop). In the next post, we talk a bit about the API. Before that, here are some screenshots and a video demo (if you can spare some 20 minutes away from watching, er..., cat videos? ?) Screenshots Video Demo Thanks ?

How are you setting up your featured image? Blog will first attempt to check for a featured image by getting the first image with the tag 'featured' or whatever tag you passed to it in the option 'post_image_tag'. If no image is found and the rendered Blog Post is a 'small one', i.e. summarised, it will try to get the first embedded image in blog_body if blog_body is not blank. Assuming you are using the former approach (meaning you tag your featured images), you can just use ProcessWire API directly to get the featured image using getTag(). Here are some examples: # retrieve first image with the tag 'featured' or user-specified 'tag' # // assuming you are on a blog-post page $image = $page->blog_images->getTag('featured'); $image = $page->blog_images->getTag($options['post_image_tag']); $image = $page->blog_images->getTag('some-tag'); // getting the blog page(s) from another page $p = $pages->get(1234); $image = $p->blog_images->getTag('my-tag'); // we got an image if($image) { // go wild }

Maybe the issue needs to be sorted from intelephense side? If it is provided file associations, it should, theoretically, work. ?