Gadgetto

I have pushed a small fix regarding the new "multiple product templates" feature. Please redownload at GitHub.

I just implemented your feature request! ? Multiple product-templates are now allowed! Just get latest version on GitHub!

The problem is, taxes handling needs to be bomb proof, otherwise the store merchant could get problems with the taxes authorities. Taxes is one of the last things which needs to be finished before the first release. I'm in contact with the Snipcart guys and I think this should be solved in short time.

UPDATE 2020-01-14 What's new - what has been added - what has changed: I had to completely remove the DateRangePicker.js library because of quirks on mobile devices and accessibility problems. The dashboard date range picker has been completely rebuilt with default ProcessWire fields - and I think it looks great + its now fully working on mobile devices + its more accessible! The orders detail panel is now also capable of changing order statuses and adding order comments (including customer notifications, tracking number and tracking url) Finalized the discount editor: create, edit, delete, archive, unarchive Snipcart discounts A lot of internal fixes and enhancements One of the greatest features of the current version is the dashboard performance. I was able to increase the REST API execution speed by the factor of 2 - 2.5 times What's next: I'm still struggling with taxes handling. Especially the handling of shipping taxes is a complex thing and drives me crazy... DONE! Finishing the remaining detail panels Implementing Subscriptions Implementing Digital Products (probably not in the first release) Implementing a more flexible product template handling (probably not in the first release) DONE! And of course - release! Here are some fresh screens:

Not in the first release. But multiple product templates are definitely planned.

To also give it a visual representation you can additionally add: $f->addClass('ui-state-disabled');

I know Jens, but I'd like to use same references as PW uses. An PW is not yet on ECMAScript 6.

Great, this works - thank you!

Sorry, for sure I meant SnipWire (I edited my post)! I don't see a reason why this shouldn't work. It probably would be the best, if you install and use the latest versions of SnipWire module and only use custom code where SnipWire isn't ready yet or is missing features you'd like to use. As I don't have a documentation available yet, please don't hesitate to ask your questions here and I'll try to help. If you find any problems/bugs or if you have suggestions for improvement while using SnipWire, it would be great if you could post back here or post an issue at GitHub so I could fix it.

I have a PW panel with a button element inside. When this button is clicked, the panel should close and the button action (href is triggered via JavaScript) should be executed in the main window (from where the panel was opened). In the current state, when the button is clicked, the action is processed within the panel, which is not what I want. Here is the button code: /** @var InputfieldSubmit $btn */ $btn = $modules->get('InputfieldButton'); $btn->attr('name', 'delete_discount'); $btn->href = $this->snipWireRootUrl . 'discounts/?id=' . $item['id'] . '&action=delete_discount'; $btn->aclass = 'DeleteDiscountButton'; $btn->text = $this->_('Delete discount'); $btn->icon = 'trash'; $deleteButton = $btn->render(); Here is the JS part which is triggered when button is clicked: $('.DeleteDiscountButton').on('click', function(e) { e.preventDefault(); var a_href = $(this).attr('href'); ProcessWire.confirm( discountActionStrings.confirm_delete_discount, function() { // dialogue OK click window.location.href = a_href; } ); }); Any hints on how this could be done?

I'm glad you like SnipWire! ? Important: SnipWire is not yet ready for production environments! Subscriptions are on my backlog and will be definitely in the first release!

Thanks for you input @flydev, I did check the technique you posted, but IMHO it's not very UX friendly. It first makes the user think that he can choose an option. I solved it in an easy way by disabling the select and an additional hidden field (as posted above).

The REST API of SnipCart requires this value with each POST or PUT request, but it may not be changed once submitted.

Done - sorry I always forget this...

Here is the complete code - now with working simulated "readonly" InputfieldSelect:

Oh damn - I have it! just add this line before processing input: // Manually write values for disabled fields to WireInputData before processing form input $input->post->set('type_disabled', $input->post->type); $form->processInput($input->post); It's that easy! ProcessWire rocks!

Here is the complete method to process the form! Please note: This code isn't finished and some parts (e.g. validation and sanitation part) may look unnecessary... The form can be used for editing (update) or adding (create) SnipCart discounts. In editing mode the method is called with a SnipCart payload ($item) array from REST API and the form is populated with the fetched values. In adding mode the form is populated with default values. Some fields like the documented field below in code (near the middle of the code), needs to be readonly in edit mode as not all parts of a SnipCart discount can be changed after creation. The problem is, a SELECT field can't be set to "readonly" in HTML - only "disabled" is possible. But a disabled field won't be submitted when form is posted. For a good user experience I'd like to simulate a readonly field and submit the value of the disabled select field with the help of a hidden field. This works so far, except that I wasn't able to populate the disabled select field after the form was submitted and the $form->processInput($input->post) method was called. This is the problem I'd like to solve. Maybe someone has an idea on how to do this.

Just see that processInput is hookable. Maybe it's possible to hook into this method and "simulate" the processing for the disabled field?

The problem is $form->processInput($input->post) won't populate the disabled field as the value isn't in the post array. And the disabled select field is empty after posting. So I'm now trying to get the field populated "after" the form is processed or something else - really don't know how to do it currently ...

The locked/disabled field value won't be in the post array. The value should be posted but not be editable. I feed the SnipCart REST API with an array of key->value pairs and the "not editable" value still needs to be in the array.

The best way to simulate a readonly InputfieldSelect seems to be: set an disabled attr to the desired select field "myfield" change the name of the select field to e.g. "myfield_disabled" use an additional hidden form field and give it the name of the disabled select field "myfield" The only problem I have after this is, that the form processing complains that the field has no value - but this should be solvable...

Setting to Inputfield::collapsedNoLocked renders the field as simple list item without a form field element. So the locked/readonly value won't be submitted.

@kongondo, @flydev, aah, I'm so stupid - forgot that <select> doesn't have attr readonly... I'll solve this by setting the <select> disabled and adding a hidden field with the preselected value instead.

In a ProcessModule I'm trying to set an API InputFieldSelect or InputFieldText to readyonly using the HTML attr readonly="readonly". I have tried this but this has no effect: /** @var InputfieldSelect $f */ $f = $modules->get('InputfieldSelect'); if ($action == 'edit') $f->attr('readonly', 'readonly'); $f->name = 'type'; $f->label = $this->_('Type'); $f->required = true; $f->value = $type; $f->columnWidth = 100; $f->addOptions($this->getDiscountsTypes()); The HTML source looks OK (it has the readonly attr), but the readonly attribute seems to be ignored. <select id="Inputfield_type" class="required uk-select" name="type" readonly="readonly"> ... </select> Is this possible?

OK, I have it: var orderActionStrings = config.orderActionStrings; $('.ResendInvoiceButton').on('click', function(e) { e.preventDefault(); var a_href = $(this).attr('href'); ProcessWire.confirm( orderActionStrings.confirm_resend_invoice, function() { // OK click window.location.href = a_href; } ); }); This will fully replace this var orderActionStrings = config.orderActionStrings; $('.ResendInvoiceButton').on('click', function() { return window.confirm(orderActionStrings.confirm_resend_invoice); }); with a nice vex dialog! @bernhard thank you for your forum thread! I would have never found this feature as it is completely undocumented (except in the sources).