Leaderboard

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?

sure

@ryan thank you very much for all the additions you implemented in such a short time on top of my github pullrequest. It seems that there currently nothing is left in regard of webp support in ProcessWire. But I already have one or two points for future updates to the image rendering engines, that should be implemented when all browsers will support webp and we don't need fallback jpegs or pngs anymore. ?

@kongondo amazing amazing amazing as ever!!

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.

https://modules.processwire.com/modules/inputfield-simple-mde/

Suppose you have a module where you want users to be able to fill out some fields for a configuration, but then the user should be able to add several of these configurations. This is something I've come up against a few times when working on modules. Any suggestions of strategies for this? I'm thinking of something similar to a Repeater - is this possible in a module configuration? I know my module could add a page to the tree and literally use a Repeater field within it but I'm not keen on that because (a) the Repeater module isn't installed by default and it seems a bit mad to require it just for a module configuration, and (b) I'd prefer to have the module configuration done in the module settings rather than on a separate page The only alternative I can think of is to use a textarea field in the module config and require users to carefully format/separate the values for multiple settings on a single line, and with each subsequent line being a different configuration. This seems a bit primitive and error-prone, although it is what I have been using thus far. Is there some middle ground between these two options? Do you think some sort of repeatable block for module config would be a good feature to add to PW? Not something that actually adds pages like a Repeater, but rather something that still allows the whole module config to be stored as a string in the DB.

Module: Auto Smush https://github.com/matjazpotocnik/AutoSmush Optimize/compress images. In Automatic mode images that are uploaded can be automatically optimized. Variations of images that are created on resize/crop and admin thumbnails can also be automatically optimized. In Manual mode "Optimize image" link/button will be present. This allows manual optimization of the individual image or variation. In Bulk mode all images, all variations or both can be optimized in one click. Will process images sitewide. Two optimization "engines" are avaialable. reShmush.it is a free (at the moment) tool that provides an online way to optimize images. This tool is based on several well-known algorithms such as pngquant, jpegoptim, optipng. Image is uploaded to the reSmush.it web server, then optimized image is downloaded. There is a 5 MB file upload limit and no limit on number of uploaded images. "Local tools" is set of executables on the server for optimizing images: optipng, pngquant, pngcrush, pngout, advpng, gifsicle, jpegoptim, jpegtran. Binaries for Windows are provided with this module in windows_binaries folder, copy them somewhere on the PATH environment variable eg. to C:\Windows. Similar modules: JpegOptimImage by Jonathan Dart: https://processwire.com/talk/topic/6667-jpegoptimimage/ TinyPNG Image Compression by Roope: https://github.com/BlowbackDesign/TinyPNG ProcessImageMinimize by conclurer: https://processwire.com/talk/topic/5404-processimageminimize-image-compression-service-commercial/ Forum discusion: https://processwire.com/talk/topic/12111-crowdfunded-tinypng-integration-module/ Module created by Roland Toth (@tpr).

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

I did not see the option to specify the maximum number of discounted items the customer is able to buy. Without seeing the screencap and reading "Customers must add quantity of items specified to their cart", I would assume that – for example – for a Buy 1 Get 2 promo I need to put number 1 into "Buys Quantity" and number 2 into "Gets Quantity" but you did the opposite.

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!

First of all I really like that you are thinking big and in the long run you want to include features which are mostly paid options in other systems. I also like a lot what we can see so far, this is great work indeed! A couple of notes / questions about these work in progress discount features: Discount Type: - Free Shipping should not be in the group of mutually exclusive types, as it is common to combine it with the other three (% / fix / B.X.G.Y.) currently in the works. - Maximum of items please ? Regarding the screencap's Buy X Get Y sneak peak: How useful is a Buy 2 get 1 promotion? ? What I mean is that "Gets Quantity" implies that I need to enter 3 and not 1, doesn't it? To put it another way: we have the term "Buy X Get Y", in which term X comes first, next is Y. But you swapped them and also called them in an ambiguous way, because "Get Y" becomes "Buys Quantity" and "Buy X" becomes "Gets Quantity". This is confusing. Or am I missing something?

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!

Is there any way of keeping HTML comments in content rendered via Markup Regions? Per default all comments seem to get filtered out (Why this?). There is a forum thread touching this topic but it doesn't answer how to get the comments back. I found in 'wire/core/WireMarkupRegions.php' there seems to be an option "exact" with is explained as: but I'm not sure if that's what I need. At least changing the default value in wire, doesn't seem to make any difference. I also found that comments starting with a hash symbol will be kept intact, like <!--#Test --> but those are actually intended as Markup Region Hints so it might affect performance to use them as regular comments!?

It doesn't look like there is a way to keep HTML comments intact when using the core Markup Regions feature. Even if there was a way to set the "exact" option you mentioned (which there isn't currently because the Markup Regions methods aren't hookable), comments are also removed here. You could make a feature request at GitHub for an option to keep HTML comments.

UPDATE OK, after I've faced that for and against again, I've decided to make the module freely available. If you are interested, you can test the current state of development. I already put the module on GitHub. Please note that the software is not yet intended for use in a production system. (Alpha version). For example, the configuration and handling of the VAT rates are still missing. Also the dashboard is still incomplete. And many other things needs to be improved and implemented... ? If you like, you can also submit feature requests and suggestions for improvement. I also accept pull requests. https://github.com/gadgetto/SnipWire

Thanks Ryan and horst!

Important security update! Hi RockGrid users, I'm very sorry for that, but I have to announce a security update. If you are using RockGrid on a public site please upgrade to v0.0.22 (Fieldtype) immediately. It is a simple but important update: https://github.com/BernhardBaumrock/FieldtypeRockGrid/commit/0be2086139c84f775937246ed2985ac4c4a3e9c3; The proplem exists on all RockGrid fields with AJAX turned ON. In this case it was theoretically possible to expose the field data to a user that should not be allowed to see this data (in the worst case even a guest user) if the user knew how to do it and he also knew the name of the rockgrid field. The update now restricts access for AJAX field data to superusers only. You can easily adjust that via simple hooks: // rockgrid access control $wire->addHookAfter("InputfieldRockGrid::access", function(HookEvent $event) { // all grid data is accessible for all logged in users $event->return = $this->user->isLoggedin(); }); Or more granular via the fieldname: // rockgrid access control $wire->addHookAfter("InputfieldRockGrid::access", function(HookEvent $event) { $field = $event->arguments(0); $user = $this->user; $access = $event->return; switch($field) { case 'field1': case 'field2': case 'field3': $access = $user->isLoggedin(); break; case 'field4': $access = ($user->name == 'foo'); break; } $event->return = $access; }); Field 1-3 is allowed for logged in users, field4 only for user foo and all other fields only for superusers (default rule). I'm not totally happy any more with several aspects of RockFinder and RockGrid, but it is the best option I have so far (until I can build something totally new, maybe with tabulator if tests work well). Special thx to @Zeka for bringing this issue to my attention by coincidence in the other topic!

Is this still the best approach to handle site-wide custom settings without any modules? Edit: Oh, I see this thread is older than my two daughters ? Sorry for that.

I am really looking forward for this ecommerce module. Are there any plans about pricing for the module for now? Thank you!

This looks fabulous! Saw in your screen the example for selling digital fonts. This looks great. A question: will it be possible to give a variant (let’s say: Font Italic) an option to sell it with different license types? Mostly you have something like: Licence 1 = 1-5 User, Price X License 2 = 6-20 User, Price Y And when do you think is Padloper 2 ready to take off? ?

Wow super! The API system look amazing! I know you still have to tell us many things, like how works the discounts, users management, shipments, payments, etc. But I will like ask a few things ? The API system for get the $order data will change? eg: At the moment I am using the success page or the checkout page to send the order data to external platforms such as our management, Mailchimp, google analytic etc. Will it be possible to continue doing it from there? I see there is the discount page, but also will be possible to change the price in the shopping cart based on the items loaded? eg: discounts based on quantity. Will it be possible to do this as a backend or do it with a separate hook? Will it be possible to choose the type of shipment in the checkout process? eg: normal, super fast... A curiosity, are you also creating new payment module? I think that ProcessWire has the potential to become the cms with the best e-commerce system around!

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 ?

Hi can anyone tell me how to use markup cache with images. @Can @pwFoo Thanks regards

Well, I'm no pro at this and you could probably improve it, but here's my attempt which serves my current needs pretty well: /** * Creates a repeater field with associated fieldgroup, template, and page * * @param string $repeaterName The name of your repeater field * @param string $repeaterFields List of field names to add to the repeater, separated by spaces * @param string $repeaterLabel The label for your repeater * @param string $repeaterTags Tags for the repeater field * @return Returns the new Repeater field * */ public function createRepeater($repeaterName,$repeaterFields,$repeaterLabel,$repeaterTags) { $fieldsArray = explode(' ',$repeaterFields); $f = new Field(); $f->type = $this->modules->get("FieldtypeRepeater"); $f->name = $repeaterName; $f->label = $repeaterLabel; $f->tags = $repeaterTags; $f->repeaterReadyItems = 3; //Create fieldgroup $repeaterFg = new Fieldgroup(); $repeaterFg->name = "repeater_$repeaterName"; //Add fields to fieldgroup foreach($fieldsArray as $field) { $repeaterFg->append($this->fields->get($field)); } $repeaterFg->save(); //Create template $repeaterT = new Template(); $repeaterT->name = "repeater_$repeaterName"; $repeaterT->flags = 8; $repeaterT->noChildren = 1; $repeaterT->noParents = 1; $repeaterT->noGlobal = 1; $repeaterT->slashUrls = 1; $repeaterT->fieldgroup = $repeaterFg; $repeaterT->save(); //Setup page for the repeater - Very important $repeaterPage = "for-field-{$f->id}"; $f->parent_id = $this->pages->get("name=$repeaterPage")->id; $f->template_id = $repeaterT->id; $f->repeaterReadyItems = 3; //Now, add the fields directly to the repeater field foreach($fieldsArray as $field) { $f->repeaterFields = $this->fields->get($field); } $f->save(); return $f; } And here's an example of calling it: $f = $this->createRepeater("sc_promos","sc_promo_active sc_promo_code sc_promo_discount","Promotional Offer","shoppingCart"); You can then use $f to add your new repeater field to a fieldgroup/template.